ReversingLabs | Blog

Its a beautiful Monday once again. What is special about this Monday is that it has its rather long introduction story. Here is what you don't know about ReversingLabs. At the end of each week we go through preparation for Monday blog. So the team decides and creates a sample code for our blog. This was also the case last week and we picked to do a blog about using TitanEngine as static library and creating a PeID plugin for handling overlay. It a small plugin called TitaniumOverlay with options to add, remove, copy and extract overlay. But... in the last minute we found a rather obvious bug inside RemoveOverlay and decided not to use this in our blog. Then another team member decided to code an unpacker for PackMan a simple PE32 packer which packs ExE and DLL files. Which seemed like a good idea until we found that with the current debugger design you can't SingleStep after hardware breakpoints. And that once again meant that this won't get on the blog. In another try to do a sample of using TitanEngine as a static library we made an OllyDBG plugin named TitaniumHandles which would display information about open handles and mutexes with the ability to close them. Which has proven useful on more then one occasion, and OllyDBG doen't have this as option so it seemed like a good idea... That is until we found a bug in handle filtering that prevented retrieving names of certain handles. Now its Sunday afternoon and we have three great samples on how you can use TitanEngine but since there are some bugs in the engine we can't use this code yet. So what do we do (after we fix them obviously)?

We open our known formats list, place our hand over the eyes and pray that our next pick wont be an epic fail... And the pick is... PeX 0.99. Nice and easy, it should be fun to do. Gentleman, start your debuggers.

Once we start the analysis we find that the entry point has a nice message for us telling us that the sample is packed with PeX. How nice of bart^xt, the author of the packer. This can be used as a part of the signature for this format. After some tracing we find this code:

  ADD ESP,4 ; [EntryPoint + 0x254]
  POP EDX
  POP ESI
  PUSH CS
  PUSH ESI
  RETF

Which once executed leads us to level two of the packer. Formats who use multiple packing levels usually use them to process PE format specifics, such import table processing and file memory protection. In this case packer shell uses this level to fill and protect the import table. So by some more tracing we find:

  CALL NEAR EAX ; kernel32.LoadLibraryA [Level2 + 0xF0]
  TEST EAX,EAX
  JE Level2 + 0x3BF

Simple call the LoadLibraryA API call to load all needed libraries. Data we need is located as a pointer to string in EBX register which holds the name of DLL to be loaded. Some more tracing leads us to this point in code:

  ADD ESP,4 ; [Level2 + 0x1DF]
  AND EBX,7FFFFFFF
  PUSH EBX
  PUSH DWORD PTR SS:[EBP+402A18]
  CALL +0x01	;Redirected GetProcAddress call

This is a call to GetProcAddress API which locates the functions inside the previously loaded DLL file. Parameters we need from here are EBX which is either API ordinal number or a pointer to string which is the name of the function to be found in loaded DLL, and EDI which holds the pointer to IAT. More specifically the place where the API pointer will be written. Normally that would be it for import fixing but PeX has a simple redirection code we must disable before continuing the unpacking process. That code is located here:

  LEA ECX,DWORD PTR SS:[EBP+4025CB] ; [Level2 + 0x299]
  ADD EBX,DWORD PTR DS:[ECX]
  CMP DWORD PTR DS:[ECX],0B13
  JNB OverCodeThatProtectsTheImportTable
  PUSH EBX

By simple patching we change JNB jump from above to JMP and ensure that import table protection code isn't executed. Last thing we have to find is the entry point location and set a breakpoint to dump and fix the file on it. We look a little bit down the code and find this:

  PUSH 4012BF ; [Level2 + 0x396]
  JMP L003
  ???
L003:
  POP EAX
  INC EAX
  PUSH EAX
  RET

Code that will be written to packed entry point and used as a redirection to original entry point. We read this address (0x004012BF) and add one to it to get the original entry point address. Breakpoint we chose to set is a hardware breakpoint on execution, but we could have used a normal breakpoint as well since code at that address has been unpacked and written just before level switching. Once that breakpoint is hit our unpacker will finalize the unpacking in the well known manner.

Since we were (and are) low on Delphi samples, this weeks unpacker was written for that programming language. Also note that all bugs that affected the three candidates for Monday blog were fixed and will be published very soon with the next TitanEngine release. In the mean time keep checking back at our blog and forums for more info about the continuous TitanEngine development.

TitanEngine ReversingLabs Corporation

Download RL!dePeX unpacker (package contains unpacker binary, source and samples used)

This is our last blog about MEW, we promise. We intend to keep that promise since this is the last known version of MEW. Whats so special about MEW anyway?

The reason we chose to do MEW (again) is that in its version 5 it is a simple crypter which can be used as a perfect example on how to write static unpackers for these kind of crypters. That kind would be the kind that doesn't do anything to imports but only encrypts the executable code section. Next time we revisit static unpackers we will be talking about such cases. We are going to leave that aside for now because this Monday is all about simple and fast unpacker writing. Start your timers we will do in under 10 minutes.

Minute 1 - 2:

We load our sample into Olly and see the entire MEW5 code at the entry point.

  MOV ESI,0040005B
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,ECX
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,EBX
  PUSH EBX
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,ESI
  PUSH ESI
  POP EDI
L010:
  LODS BYTE PTR DS:[ESI]
  ROL AL,29
  ADD AL,BA
  ROR AL,50
  STOS BYTE PTR ES:[EDI]
  LOOPD L010
  RET

Yes, that it. The whole code. So what does it do? First it loads a pointer to all internal information into ESI register. We follow ESI in the hex dump to find that there are 3 DWORDs that have the data necessary for unpacking. First DWORD is 0x3000 which is the size of the first section, second DWORD is 0x004012c0 which is the address of the original entry point and third DWORD is 0x00401000 which is the virtual address of the first section. Code following this loads 0x3000 bytes one by one and decrypts them with a custom decryption algorithm. Here instruction sequence ROL, ADD and ROR is used to decrypt data.

Minute 3 - 4:

We make a copy of existing TitanEngine SDK sample for DEF and use that as a template for our unpacker. We are making a Delphi unpacker since,... well since TitanEngine is low on Delphi samples and this is a nice and quick exercise.

Minute 5 - 9:

We code the unpacker. First we need to read the ESI pointer and read the data from the file. Once we make that we convert third DWORD to physical address inside mapped file and we also convert the original entry point address to relative one. Simple call to StaticMemoryDecryptEx makes sure that our StaticCallBack decrypts the data by executing this custom decryption algorithm. Lastly we add the code to store the new entry point to PE32 header and we're done.

Minute 9:47 - 10:

We run the compiled unpacker to test if it works... Success!

TitanEngine ReversingLabs Corporation

Download RL!deMEW5 unpacker (package contains unpacker binary, source and samples used)

This is a followup on MEW file format analysis. As mentioned in our video blog yesterday we noticed that MEW 10 has a design flaw that wrongfully passes function names to LoadLibraryA which firstly tries to load it as a DLL file and once that has failed it passes the same string to GetProcAddress and successfully finds selected function in previously loaded DLL. We can exploit this by creating a dummy DLL file named as a function which every file on Windows imports, for example ExitProcess or GetModuleHandleA. Placing such file in %Windows%\System32 would ensure that that file is loaded each time a MEW 10 packed file is executed on the system. But we have a problem we must resolve before we proceed. As said earlier function only gets found if the DLL isn't loaded, or more specifically call to LoadLibraryA returns NULL. This must be resolved because we don't want to crash the packed fie. So to work around this we simply do this inside our GetModuleHandleA.dll file:

BOOL APIENTRY DllMain(HMODULE hModule,
   DWORD  ul_reason_for_call, LPVOID lpReserved){
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		if(GetModuleHandleA("BadGuy.dll") == NULL){
			LoadLibraryA("BadGuy.dll");
			return false;
		}
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}

Returning false at DLL_PROCESS_ATTACH makes Windows unload our GetModuleHandleA.dll but not before BadGuy.dll gets loaded. Simple code above ensures that our BadGuy.dll gets loaded only once (Windows also prevents this so this isn't really needed) since MEW 10 packed file can import GetModuleHandleA multiple times. Our BadGuy.dll only creates a new thread which displays a message box about it being successfully loaded. This could have been done with a single DLL file but we wanted to keep it short and simple.

There are many examples of design flaws in PE shell modifiers which could seriously threaten system security. Such example are not only limited to arbitrary code execution but could also lead to privilege elevation. We will continue to write about such shell modifier flaws in the future.

Download MEW 10 LoadLibrary exploit POC

This week we do a video tutorial about MEW analysis and we give pointers into making unpacker for this format. Download RL!deMEW 10 - 11 unpacker.

At the end of our BlackHat presentation on which we unveiled our TitanEngine project we promised to keep supporting it and to publish one unpacker demo per week. And this was true since our first update release for TitanEngine contained quite a few samples. But since the next update isn't all that close we will stick to our word and publish and blog about the samples ReversingLabs itself contributes. In that spirit we are revisiting the packer we created for mPack ages ago.
So why is mPack interesting? Just because we haven't yet published a source for unpacker that uses overlay to store the compressed file. Interested? Read on...

Ovelay is by definition a piece of data appended to the end of the PE file. In this case that appended data is a compressed executable which sounds logical since we know that mPack was written in Delphi as a proof of concept packer, and since overlay packing is the most simplest form of packing it was used here. The trouble with this is that the compression method weren't documented so we need to "guess" what kind of compression was used and how it was implemented. Which is the fun part of reverse engineering.

There are two things we can do here and we are going to use both approaches for both supported and known version of mPack. Firstly we can reverse the stub which decompresses the packed overlay and this is fairly easy. We can set a few breakpoints on CreateFileA and ReadFile to see when the overlay is read and then just trace until we find the algorithm in charge of decompression and just rip it so that it can be used to unpack compressed memory segment. When talking about mPack 0.2 you need to realize that compressed overlay is segmented and compressed by chunks of 0x1000 bytes of code. Each segment in the compressed overlay begins with the DWORD which tells you the size of the compressed segment. Therefore you need to keep decompressing and reconstructing the  file while that DWORD is greater then zero. Once all segments are unpacked you are done.

Second approach can be used and applied to mPack 0.3. This is a lazy man approach and that means no code tracing whatsoever. Like it? We did too. So what you want to do is just extract the overlay and take a look at the compressed overlay. Once again there is a DWORD before the compressed data. Since that DWORD is greater then the size of the overlay and its a nice and round number its safe to assume that that is the size of decompressed that. But what compression algorithm was used. First byte of the compressed overlay is 0x78, so one quick Google search and we get to this website which kindly points us to zlib compression. Yes, just that easy. No code tracing at all. But same info could be found if we got our hands dirty for a few seconds and did some file analysis.

Once the two are put together you come up with a nice unpacker which demonstrates how to use TitanEngine to write static unpackers, more specifically how to unpack packers which store compressed binaries inside overlay. And that is something we haven't shown in our samples which makes this a nice Monday exercise.

TitanEngine ReversingLabs Corporation

Download RL!deMarioPack 0.2 - 0.3 unpacker (package contains unpacker binary, source and samples used)