Archive for the ‘Programming’ Category

Windows 7 API Hooking

February 25th, 2009

Just wanted to give a heads up to anyone who utilizes API hooking heavily and wants their code to be compatible with Windows 7. Assuming things stay the way they are (which they probably will, this is the first time I’ve seen this before, so its not standard ‘beta build’ practice — checked with Vista and XP) then you will need to modify some of your API hooks.

Kernel32.dll now just ‘wraps’ a lot of APIs and the implementation is actually stored in KernelBase.dll.  This means if you want your code to work properly you’ll have to do this (example given with CreateProcessInternalW — unrelated code removed):

// Hook CreateProcessInternalW in KernelBase if it exists, or in Kernel32 otherwise.
// Needed because API moved to KernelBase in Windows 7.
// TODO: Implement alternative using NTDLL hooks. Priority: 2
FARPROC pCreateProcessInternalW = (hKernelBase) ? (GetProcAddress(hKernelBase,
“CreateProcessInternalW”)) : (GetProcAddress(hKernel32,”CreateProcessInternalW”));
CreateProcessInternalW_Trampoline = reinterpret_cast<tCreateProcessInternalW>(pCreateProcessInternalW);

// Perform the actual API hooking if the pointers are valid
if (pCreateProcessInternalW)

So basically, most of your code can stay the same, it’s just the retrieval of the API pointer that needs to be updated. Whether you’re using GPA, EAT, whatever, you’ll need to check for KernelBase.dll first. Tested and working on XP through Windows 7. Please note I have NOT verified that IAT hooking will work without modifications, but I’m assuming it should.

If you end up testing IAT hooking in Windows 7 please let me know how you go. Also, I haven’t compiled a list yet of all redirected functions, I will if I get the time, otherwise just test your code with CreateProcessInternalW.

Programming, Reverse Engineering, Windows , , , , ,

Analysis of Conficker

February 21st, 2009

SRI have done a very comprehensive and indepth analysis of Conficker including the latest variant boasting fun new features.

Great read, I highly recommend it if stuff like this interests you (malware development, windows internals, reversing malware, etc):

Click here for epix (and the analysis)

Programming, Reverse Engineering, Security, Windows , , , ,

Object Creation. How and where.

February 21st, 2009

This seems to be something that confuses a lot of newbies so I’m going to take the time to explain it properly here.

‘Inspiration’: Example

First off. PE Files. Although we can ignore most of the details of the PE file format for the purposes of this there are still some basics that are important. A PE file has ’sections’. One of those sections is ‘.text’, this is typically where code is stored. Another we need to know about is ‘.data’, this is typically where global variables are stored. The last we need to know about is ‘.rdata’, this is typically where global constants, hardcoded strings, floating point constants, etc are stored.

Nitpicker’s Corner: I said “typically” because packers often abuse intricacies of the PE file format which are irrelevant for this discussion in order to avoid the use of these standard sections and confuses disassemblers and debuggers. I am dealing ONLY with regular PE files created by regular compilers such as MSVC++, Intel, etc.

Second. The stack and the heap. The stack is a LIFO (Last In First Out) data structure typically used for things like passing parameters to functions, temporarily saving or “pushing” values stored in registers to be restored or “popped” back later, storing local variables, saving function return addresses, etc. All threads typically have their own ’stack’ to manage. The heap is a ‘pool’ of dynamically allocated memory typically used to store objects which are dynamically allocated at runtime because there size or other details cannot be known at run time. For more info on either of these subjects please consult any book on computer science, or wikipedia.

Nitpicker’s Corner: I am referring only to the stack/heap structures/concepts in terms of their relevance to this discussion and only the implementations which I have outlined. I am aware that the “stack” is also a common data type.

The following is a “typical” C++ application.

Nitpicker’s Corner: Typical in the sense in which objects are created  in multiple fashions ane the application uses fairly standard C++ concepts.

Nitpicker’s Corner: Application is obviously not thread-safe due to lack of serialization on global objects.

#include <iostream>
#include <string>

std::string MyGlobalString(”Foobar”);
std::string* pMyOtherGlobalString = new std::string(”Foobar2″);

std::string& GetStaticString()
static std::string MyStaticString(”Foobar3″);
return MyStaticString;

void MyStringSub()
std::string MyStackString(”Foobar4″):
std::string* pMyHeapString(”Foobar5″);
// Do something here

int main()
std::cout << MyGlobalString << *pMyOtherGlobalString
<< GetStaticString() << std::endl;
return 0;

Now the question is, which objects are stored where?

MyGlobalString will typically be stored in the ‘.data’ section becaues it is a global object.

pMyGlobalString will typically be stored in the heap, but a pointer to it will be kept in the ‘.data’ section, again because it is a global object.

MyStaticString will typically be stored in the ‘.data’ section because it is also a ‘global’ object. Whats that you say? Its not a global? Well by defining it ’static’ we technically are defining it as ‘global’. Static objects are created when the program first runs and not destroyed until the program quits, they are effectively globals as far as the compiler is concerned, the only differences are at the higher language level. The differences at the lower level are negligible.

MyStackString will be stored on the stack because it is local to a function.

pMyHeapString will be stored in the heap but the pointer to it will be stored in the stack because it is local to a function.

What is interesting though is where all the strings like “Foobar1″, “Foobar2″ etc are stored. They are NOT stored in the ‘.data’ section with our string objects. Hardcoded C-style strings will typically be stored and referenced through the ‘.rdata’ section. This is because std::string objects are created at runtime but the underlying c-style string needs to be stored somewhere. This “somewhere” is usually ‘.rdata’ because the section is designed for constants and will typically be paged as read-only when in memory. Our hard-coded strings never need to be changed so this is the perfect spot to put them.

Programming, Reverse Engineering, Windows , , ,