Weird error using the method explained in “loading a dll from memory” article

While I was trying the code by Joachim Bauch I noticed a strange behaviour loading user32.dll. The test program I’m using to do some tests crashes with an eccess violation error on a portion of memory virtually loaded at runtime.

For those who has not read the article I present a quick sum up of the technique, focusing on the necessary steps only:
1. allocate the necessary bytes required to store all the bytes of the dll
2. copy the original dll bytes inside the new allocated memory buffer
3. perform base relocation adjusting the necessary references
4. call DllEntryPoint directly from the new allocated buffer
5. when you don’t need the dll anymore it frees the allocated buffer

The error occours when the buffer is completely deallocated. The technique seems to be right but the question arises: why the hell someone needs to access an address inside a deallocated memory?

The problem is not strictly related with Joachim’s code itself, it’s an error caused by the use of user32.dll! At the moment I haven’t tried all the system dll, but if you understand the problem I’m pretty sure you’ll be able to solve it with another dll involved.

I have all the source code in front of me but when the problem is not totally related with it I prefer to use a debugger approach.

When the exception occours your debugger breaks here:

7C91E464 MOV EAX,DWORD PTR FS:[18] ; TEB
7C91E46A MOV EAX,DWORD PTR DS:[EAX+30] ; PEB
7C91E46D MOV EAX,DWORD PTR DS:[EAX+2C] ; PEB.KernelCallbackTable
7C91E470 CALL DWORD PTR DS:[EAX+EDX*4] ; call dword ptr [0xB72A10], access violation occours here!

The address (0xB72A10) is inside the allocated buffer, it’s obviously an entry of a vector. EAX represents the starting address of the vector and EDX is an index, each dword is an element of the vector. Starting address is 0xB72970, I only have to understand what’s behind that address.

Load user32.dll inside IDA and look at the vector, the xref will bring you inside DllEntryPoint:

7E39B3F6 mov eax, large fs:18h ; TEB
7E39B3FC mov eax, [eax+30h] ; PEB
7E39B3FF mov eax, [eax+18h] ; PEB.ProcessHeap
7E39B402 mov hHeap, eax
7E39B407 mov eax, large fs:18h
7E39B40D mov eax, [eax+30h]
7E39B410 mov dword ptr [eax+2Ch], offset off_7E392970 ; PEB.KernelCallbackTable

Can you see where the problem is? No!?! Ok, take a look at the same code that has been copied inside the allocated buffer (base relocation performed!):

00B7B3F6 MOV EAX,DWORD PTR FS:[18]
00B7B3FC MOV EAX,DWORD PTR DS:[EAX+30]
00B7B3FF MOV EAX,DWORD PTR DS:[EAX+18]
00B7B402 MOV DWORD PTR DS:[BD1224],EAX
00B7B407 MOV EAX,DWORD PTR FS:[18]
00B7B40D MOV EAX,DWORD PTR DS:[EAX+30]
00B7B410 MOV DWORD PTR DS:[EAX+2C],0B72970 <-- look here!!!

At the beginning of user32.dll there’s a particular initialization, it involves the heap and the KernelCallbackTable address. Both values are changed according to the new image base address but they will not be changed back to the old values.
If you don’t want an access violation inside your program you’ll have to restore the old values, nothing else…

The conclusion is simple, the code is perfectly right but it may be prone to this kind of weird conceptual bug… pay attention when you load a system dll!

QuickTime (not exploitable) bug leads to a crash

In an old post I talked about a bug able to crash QuickTime on startup, here’s a QuickTime crash that occours when you close the application. The bugged code is something like:

movzx edx, ax   
push edx                            ; lpData
push 1                              ; dwType
push 0                              ; Reserved
push eax                            ; lpValueName
push ebp                            ; hKey
call ds:RegSetValueExW

Do you see anything strange? Have a look at RegSetValueEx parameters, the last one is defined as:
__in_opt const BYTE *lpData
It’s a pointer to string. Pay attention to the previous instruction, movzx. The content of edx is limited to 16bits and it can cause stack buffer overflow. I don’t know anything about the value stored inside ax, but I’m not interesting in it.

The crash occours under particular conditions. Again, you have to change something inside QTPlayerSession xml file (located inside “Application Data/Apple Computer/QuickTime”). Here’s an example of a possible list stored inside the xml file:

QuickTime parses the file and create the entries inside the right registry key. The snippet I posted above will not be executed in normal condition, but it’s possible to run it cheating a little. Try modifying the file creating two equal entries:

Run QuickTime, close it and the program will crash due to a stack buffer overflow.

(Un)fortunately it’s not possible to exploit the bug, and due to the nature of the bug I don’t think it will cause problems to the users, it’s only an annoying box to close. If you have a crash like that you can try looking at the xml file…

QuickTime v7.4.5 crashes reading malformed QTPlayerSession.xml files

QTPlayerSession.xml (located under %USERPROFILE\Application Data\Apple Computer\QuickTime\) is used to store various user settings. Among all, it’s used to save a list of favorite movies, and a list of the recent opened files. These lists are called FavoritesListName and MRUListNameWithURLs, here is a possible definition:



There’s a *key* definition followed by an *array* keyword. Inside the *array* tags QuickTime saves some values.
A single item is composed by two lines, the first one (“test 1”) represents the name showed by QuickTime while the other (“C:\Programs\QuickTime\Sample.mov”) is the path of the file. No matter what you write inside the string tag, QuickTime doesn’t check if the text is valid or not.
When QuickTime is fully loaded you can see the items from the *favorites* and *open recent* menu items (I don’t know the right english item’s names because I have an italian version of the software).

When QuickTime starts, it retrieves all the possible information parsing the xml file. It scans MRUListNameWithURLs values, and after that it checks FavoritesListName list. Like every parser, it scans the file tag by tag saving the content of each line inside the memory. When it has all the necessary structures stored inside the memory, the program proceeds retrieving the stored information in order to put them in the right places: *recent opened files* and *favorites files*.

QuickTime takes the values to put inside the two menu items running this piece of code:
1: movzx eax, word ptr [esi]
2: lea eax, [esi+eax*4+4]
3: lea eax, [eax+edi*4]

After instruction at line 2 EAX register points to a series of DWORD values, each DWORD value contains a pointer to a single information to retrieve; EDI represents the index because the dwords are taken one at a time. When MRUListNameWithURLS is checked I have something like:
EAX -> 68 D2 34 01 08 D3 34 01 D8 D3 34 01 50 D4 34 01 0D F0 AD BA AB AB AB AB
0134D268 points to a structure containing "Another test"
0134D308 points to a structure containing "C:\abc.mov"
0134D3D8 points to a structure containing "The last one"
0134D450 points to a structure containing "path"

The bytes above are stored inside a piece of memory allocated at runtime using RtlAllocateHeap function. Every time the snippet above will be executed the program will take a single string, depending on the index value. The items retrieved from the xml file are showed under the right menus when QuickTime is fully loaded. As I said before, there are two defined items for a single file so QuickTime always execute the code two times. The last 8 bytes pointed by EAX are not related with any string, they are just old bytes.

Can you understand what I’m trying to say?
The xml file is updated by QuickTime, but you can edit it. The problem occours when you modify FavoritesListName and MRUListNameWithURLs a little, using something like:



You can modify FavoritesListName in the same way. Of course you can define some more items. The point is that QuickTime is not able to handle item definition without the necessary two lines (name to display and path of the file) inside MRUListNameWithURLs and FavoritesListName; writing down 1 or 3 or 5 or 7 (or 9…) lines between *array* tags you’ll get the same result, a crash.
Why? Well, because the program will take the next not initialized 4 bytes and you don’t know what they are.

I could be wrong, but I don’t think it’s possible to exploit it. It’s a bug that can lead to a sort of denial of service because the crash occours in the initialization process. If your copy crashes you can try checking the xml file.