As we have seen in our previous blog on this subject tools that provide this kind of protection are very often coded with major design flaws which enable us with quick and painless ways to work around the password protection. However today's password protection option doesn't have such flaws. And that is why we need to find an optimal way to quickly and accurately recover the password. Can it be done in this case?

Quick analysis of the protected file shows us these interesting pieces of code:

  PUSH ECX
  PUSH ECX
  PUSH 40
  PUSH 0D
  PUSH DWORD PTR SS:[EBP+20]
  CALL NEAR DWORD PTR DS:[EDI+402923]
  POP ESI
  CALL L025        ;Calculate the hash for input string
  CMP EAX,F492C2C1 ;Correct password hash
  MOV EAX,0
  JNZ L015
...
L025:              ;Slow hashing algorithm
  XOR EAX,EAX      ;Hash initialization
  PUSH ECX
  PUSH ESI         ;ESI holds the password pointer
  PUSH EDX
  XOR EDX,EDX      ;Reason why it executes 0xFFFF times
  DEC ESI          ;for every letter
L031:
  INC ESI
  XOR AH,BYTE PTR DS:[ESI]
L033:
  XOR AL,DL
  ADD EAX,434F4445 ;Constant
  MOV CL,AL
  ROR EAX,CL
  XOR EAX,55AA5A5A ;Constant
  DEC DX
  JNZ L033
  CMP BYTE PTR DS:[ESI],0
  JNZ L031
  POP EDX
  POP ESI
  POP ECX
  RET

Now just by looking at this piece of code we see that the author of the program thought of many things when it comes to protected file's security. Why? Algorithm in charge of hashing the string is really slow because it executes 0xFFFF times for every letter of the password. If it wasn't for this bruteforcing  this algorithm would be nice and quick. But before we go for that extreme we should always check for possible shortcuts that can enable us to skip the password necessity.

Since we already know that password hash must be 0xF492C2C1 lets see if the memory content decryption has a weakness.

  PUSHAD
  MOV EDI,EAX
  MOV ESI,EDX
  MOV EAX,48415348 ;Hash initialization
  XOR AL,BYTE PTR DS:[ESI]
  CALL GetPasswordHash
  MOV EBX,EAX
  XOR AH,BYTE PTR DS:[ESI]
  CALL GetPasswordHash
  SHR ECX,2
  MOV EDX,ECX
L011:              ;Decrypt first section
  XOR DWORD PTR DS:[EDI],EAX
  MOV CL,AL
  ADD EDI,4
  ROL EBX,CL
  XOR EAX,EBX      ;Keys for decryption: EAX and EBX
  MOV CL,BH
  ROR EAX,CL
  ADD EBX,EAX
  DEC EDX
  JNZ L011
  POPAD
  RET

Here is what happens here. Just before the program decrypts the first section it initializes two 32bit decryption keys. Both keys are initialized from the password string, more accurately the keys are password hashes. Second key is calculated fist. This key which is stored in EBX register is a direct product of password hash for algorithm initialize value 0x48415348. However this value isn't a constant, it is modified by XORing with the fist letter of the password. That is why the already calculated  password hash we have 0xF492C2C1 isn't enough to break this algorithm. Fist key is calculated last and its value is stored in EAX register. Hashing algorithm for this key calculation is a direct result of first key stored in EBX XORed with the fist letter of the password. Only by having the state of both keys for decryption beginning we can correctly decrypt the file. However we put it the password seems like a must for decryption. We are going to return to shortcuts a bit later, lets discuss the bruteforce option first.

Building a bruteforcer for this algorithm is quite easy. We just need to go through the all possible combinations that a password can take in order to recover the 'lost' password. However that proves to be a much harder task then it sounds. Building the bruteforcer isn't a problem but the time its needed for recovering a simple password which is only 4 characters in length is very long. Take a look at this program log to see a basic log which shows the "slowness" of this algorithm. It seems that author of the program saw bruteforce as a potential risk and made it slow on purpose. But this isn't the only problem. Our bruteforce test shows that passwords collide meaning the multiple passwords have the same hash. Any of these passwords will unlock the program but it won't be decrypted correctly and therefore it will crash. Here is how the bruteforce program log looks like:

Correct password for this sample is: "ap0x" but to recover it bruteforcer needed approximately 4 minutes. And as you can see in log file time needed to go through every four character password combination (a..z + A..Z + 0..9) is more then 2 hours. And even that isn't a guarantee because you have check every password since the protection doesn't have an additional validation to check if the code decrypted correctly. Since that is way too slow for any practical use on longer passwords we return to finding the algorithm weakness.

But is there a weakness? If we look at the decryption algorithm we see that both EAX and EBX keys are needed for decryption to work correctly. However only one key, EAX, is used to decrypt data by XORing the file memory content. Therefore recovering the password would be easy if we knew the first four bytes unencrypted. Which we don't... Could it help if we need the unencrypted value of any random sequence of bytes in the file? It might but that would mean that we would also need one more information for that location, the value of ECX register because it is used to modify successive decryption keys. Is there just such a sequence of bytes? Sure, at the end of file whose sections are aligned to PE.FileAlignment (and its a must for this protection) we have at least 12 bytes which are zeroes. Last four bytes in that case are equal to EAX decryption key at that time, which leaves EBX and CL as unknowns. Four bytes before that we have the same story. In order to recover EAX, EBX and CL we must do the following:

• Reverse the decryption algorithm so it decrypts the memory backwards
• Bruteforce that decryption to recover EAX, EBX and CL values
• Make sure that those key values are correct since algorithm does collide
• Decrypt the file backwards using the correct keys

Since keys are 32bit and we already know the value of one of those at one point we can bruteforce keys between 0x00000000 and 0xFFFFFFFF in order to get the missing EBX and CL values. That is much faster then trying to bruteforce the infinity of possible passwords. Reversed algorithm can be seen in the source code under the function named PEPDecryptFile.

Writing a bruteforcer for PEPasswordEncryptor is a nice reversing exercise especially when algorithm shortcut inspection is involved. As always binary, source code and the samples are included with the blog. Until next week...

PEBrute
(package contains unpacker binary, source and samples used)

Now it theory only one password should be able to unlock such protected application and allow its execution without any possibility of removing the protection without the correct password. Well that's the theory behind such tools but they themselves have a weakness too because there still must be a way for the application to check the validity of the inputted password. So regardless of the protection executable password protection solution must do one of the following:

• Compare passwords or password hashes to determine whether or not to execute the file
• Use the inputted password for code decryption and verify the decrypted content by hashing

So, not a lot of options to choose from. First model would be the least secure since no content is encrypted and the second most secure requiring password bruteforce to be removed. Lets see what we are dealing with in LCCrypto's case. Entry point of the protected file looks like this:

  MOV EAX,DWORD PTR SS:[ESP] ;Pointer to ExitProcess API
  AND EAX,FFFF0000
L002:
  CMP DWORD PTR DS:[EAX],905A4D
  JE L006
  SUB EAX,1000
  JMP L002
L006:
  PUSH EBP

Very simple way to get the kernel base most commonly used in malware which could flag this sample as malicious by some anti-virus vendors. Following this we have:

  MOV EBP,EAX
  ADD EAX,DWORD PTR DS:[EAX+3C]
  MOV EDI,DWORD PTR DS:[EAX+78]
  ADD EDI,EBP
  MOV ESI,DWORD PTR DS:[EDI+20]
  ADD ESI,EBP
  XOR EDX,EDX
L007:
  MOV EAX,DWORD PTR DS:[ESI]
  ADD EAX,EBP
  CMP DWORD PTR DS:[EAX],50746547
  JNZ L025
  CMP DWORD PTR DS:[EAX+4],41636F72
  JNZ L025
  CMP DWORD PTR DS:[EAX+8],65726464
  JNZ L025
  CMP WORD PTR DS:[EAX+C],7373
  JNZ L025
  MOV EAX,DWORD PTR DS:[EDI+24]
  ADD EAX,EBP
  MOVZX EBX,WORD PTR DS:[EAX+EDX*2]
  MOV EAX,DWORD PTR DS:[EDI+1C]
  ADD EAX,EBP
  MOV EAX,DWORD PTR DS:[EAX+EBX*4]
  ADD EAX,EBP
  MOV DWORD PTR DS:[407408],EAX
L025:
  ADD ESI,4
  INC EDX
  CMP EDX,DWORD PTR DS:[EDI+18]
  JNZ L007

Another code which is used to locate GetProcAddress API pointer. This is crucial since that API and already located kernel base are all that this protection needs to locate all other needed APIs to create password input dialog and process it. Code that creates the window and its elements is located just after the code locates all needed APIs. Code that is of interest is here:

  PUSH DWORD PTR DS:[407004]
  CALL NEAR DWORD PTR DS:[407410] ;FreeLibrary
  PUSH DWORD PTR DS:[407000]
  CALL NEAR DWORD PTR DS:[407410] ;FreeLibrary
  CMP BYTE PTR DS:[407881],0
  JE L008
  MOV EAX,004012C0 ;OriginalEntryPoint
  JMP NEAR EAX
L008:
  PUSH 0
  CALL NEAR DWORD PTR DS:[407414] ;ExitProcess

This is what happens when the window message processing loop just above this exits, and that will happen when the created window associated with that message processing loop terminates by window closing. Which means that if the byte at address 0x00407881 isn't set to zero LCCrypto will pass the code execution to original entry point which in this case isn't encrypted at all. Patching this compare in memory and closing the window would do the trick. Removing the protection completely would be as easy as setting the entry point address in the PE header to 0x000012C0. Normally our work would be done here, but lets dig in just a little bit more.

  PUSH 10
  PUSH 0040776E
  PUSH 64
  PUSH DWORD PTR SS:[EBP+8]
  CALL NEAR DWORD PTR DS:[407460] ;GetDlgItemTextA
  CALL 00407FF9 ;Calculate CRC32
  LEA EBX,DWORD PTR DS:[40776E]
  CALL 00408021 ;Update CRC32
  CMP DWORD PTR DS:[40775E],EAX ;Compare password CRC32
; DS:[0040775E]=0E1A88EF
  SETE BYTE PTR DS:[407881] ;Set the correct password switch

This code bit here processes the inputted password. As we can see from the code above inputted password is hashed with CRC32 and that value is compared with the value 0x0E1A88EF, and that means that hash for the password must be 0x0E1A88EF for protection to pass the control to original code. Now, leaving alone the fact that we can patch the file, think about what we can do to legitimately start the application. Bruteforce the hash? What about make a string that has the same one?

CRC32 algorithm collides which means that we can create such a string. Without going into coding a program that can do that we use a PeID plugin called CRC32 made by Gelios on a simple text file containing only the string "pwd". After the file's CRC32 has been set to 0x0E1A88EF our string "pwd" becomes "pwd€va" which is a string with the CRC32 hash we need. Entering such string into program will fool it into thinking that is the original password making LCCrypto execute the file normally.

We didn't do any coding today because it wasn't necessary. However we did investigate the security of one executable password protection and saw all the flaws its has. Next time we return to this topic we will do some coding in order to make a bruteforce engine that will recover the password used to protect the file. Until next time...

Download protected sample

Proof of this thesis is found at the very beginning of our task. Entry point itself lays on a challenge. Polymorphic decryption is used to decrypt most of the crypter body. Since this code is random we must do something to handle it and all similar cases found in the crypter body.

L000:
  LODS BYTE PTR DS:[ESI]
;
; Totally random decryption code
;
  STOS BYTE PTR ES:[EDI]
  LOOPD L000

Since both start and end patter can be defined with the LODS and STOS instructions code in between can be easily located. But what to do with it? Simple way of handling this would be extraction of this code and dynamic generation of decryption code with the following structure:

; __stdcall function long Decrypt(EAX, ECX)
  PUSH EBP
  MOV EBP,ESP
  MOV EAX,DWORD PTR[EBP+8]
  MOV ECX,DWORD PTR[EBP+C]
;
; Totally random decryption code pasted here
;
  LEAVE
  RET 8

Here ECX and EAX are input variables since they change. EAX is equal to byte pointed by ESI since its loaded with LODS, and ESI at start points to first byte after LOOPD instruction. Decryption size is static and its calculated and stored just before this decryption loop inside the crypter body. Since LOOPD decrements the ECX value it must be handled before every call to our decryption function. Return value of our decryption function is the value of decrypted byte. This is one way of dealing with polymorphic decryption functions and therefore this or similar approach will be used every time we encounter such obstacle while unpacking the crypter. If we were making a dynamic unpacker skipping this polymorphic decryption would be as easy as setting a hardware breakpoint on the first byte after LOOPD and waiting for it to hit.

This first layer of encryption is the most important one since all the data needed for our unpacker is encrypted by it. If you remember when coding dynamic unpacker first logical step is to collect data about imports. Situation is a bit different when it comes to static unpackers. First thing to do is of course decrypt everything that needs decrypting. With the first layer already decrypted we move on to decrypting section content. Following code processes sections:

  MOV EDI,EAX
  ADD EDI,DWORD PTR DS:[EDI+3C]
  MOV ESI,EDI
  ADD ESI,0F8
  XOR EDX,EDX
L005:
  CMP DWORD PTR DS:[ESI],63727372 ;rsrc
  JE L046
  CMP DWORD PTR DS:[ESI],7273722E ;.rsr
  JE L046
  CMP DWORD PTR DS:[ESI],6F6C6572 ;relo
  JE L046
  CMP DWORD PTR DS:[ESI],6C65722E ;.rel
  JE L046
  CMP DWORD PTR DS:[ESI],4379     ;yC
  JE L046
  CMP DWORD PTR DS:[ESI],6164652E ;.eda
  JE L046
  CMP DWORD PTR DS:[ESI],6164722E ;.rda
  JE L046
  CMP DWORD PTR DS:[ESI],6164692E ;.ida
  JE L046
  CMP DWORD PTR DS:[ESI],736C742E ;.tls
  JE L046
  CMP DWORD PTR DS:[ESI+14],0
  JE L046
  CMP DWORD PTR DS:[ESI+10],0
  JE L046
  PUSHAD
  MOV ECX,DWORD PTR DS:[ESI+10]
  OR EBX,EBX
  JNZ L035
  MOV ESI,DWORD PTR DS:[ESI+14]
  ADD ESI,EAX
  CALL 0040748B
  JMP L038
L035:
  MOV ESI,DWORD PTR DS:[ESI+C]
  ADD ESI,EAX
  CALL 0040744E  ;Decrypt content
L038:
  MOV EDX,EBP
  ADD EDX,00402D3E
  LEA EAX,DWORD PTR DS:[EDX]
  PUSH EAX
  RET
  MOV EAX,0
  INT 0D
  POPAD
L046:
  ADD ESI,28
  INC EDX
  CMP DX,WORD PTR DS:[EDI+6]
  JNZ L005
  RET

All sections are processed by names. Every section except the ones named rsrc, idata, edata, rdata, tls and yC is decrypted. That kind of logic must be incorporated in our unpacker aswell. Decryption of content is done with another polymorphic decryption loop. Same procedure as described above can be applied. After that is done all that remains is that we fix imports and correct the entry point.

Now for the imports... Not exactly a hard task once we locate yC's internal data. Scroll down to the end of the crypter code, until you find this:

  PUSH EBP
  MOV EBP,ESP
  PUSH EDI
  MOV EAX,DWORD PTR SS:[EBP+10]
  MOV EDI,DWORD PTR DS:[EAX+9C]
  MOV EDX,EDI
  ADD EDX,crackme_.00403393
  PUSH DWORD PTR DS:[EDX]
  POP DWORD PTR DS:[EAX+B8]
  MOV DWORD PTR DS:[EAX+B4],EDI
  MOV DWORD PTR DS:[EAX+9C],0
  MOV EAX,0
  POP EDI
  LEAVE
  RET

Following this is a simple data structure containing the following:

; DWORD - LoadedBase (default: ImageBase)
; DWORD - OriginalEntryPoint address (RVA)
; DWORD - yC protection options selected (All options: 0x3C)
; DWORD - File checksum (custom algorithm)
; DWORD - Crypter body memory checksum (custom algorithm)
; DWORD - Reserved; Store place for a boolean variable
;
; Simplified IID (Image Import Descriptor)
;
; DWORD - Pointer to name of the first DLL in the IAT (RVA)
; DWORD - Pointer to IAT for the first DLL(RVA)
; DWORD - Reserved; OriginalFirstTrunk
; DWORD - Pointer to name of the second DLL in the IAT (RVA)
; DWORD - Pointer to IAT for the second DLL(RVA)
; DWORD - Reserved; OriginalFirstTrunk
; etc. for all DLLs

As we can see all the data we need is decrypted with the first polymorphic decryption and easily located. What we need from this is to read the location of DLL names and API pointers for every DLL and rebuild IIDs linking this data. Additionally all strings are encrypted so we need to go through the API pointers and decrypt them with the following algorithm:

  PUSH ESI
  PUSH EDI
  MOV ESI,EAX
  MOV EDI,EAX
L004:
  LODS BYTE PTR DS:[ESI]
  ROR AL,4
  STOS BYTE PTR ES:[EDI]
  CMP BYTE PTR DS:[EDI],0
  JNZ L004
  POP EDI
  POP ESI
  RET

Once that is done we have imports sorted and since we know the address of the original entry point we only need to write it to PE header and optionally strip to crypter section to complete the unpacker. Optionally because if crypter is used on programs with TLS table it will be moved to the crypter section and if we don't want to rebuild that as well we can just keep the crypter section.

Writing an unpacker for Yoda's Crypter is a fairly complex task since there are few details to worry about. It provides an interesting challenge for any reverser. As always unpacker, source code and the samples are included with the blog. Until next week...

TitanEngine ReversingLabs Corporation

RL!deY0daCrypter 1.x (package contains unpacker binary, source and samples used)

We are going to do some TitanEngine coding in order to make it do a complete opposite of what it is meant for. We are going to force our good friend Titan to recreate a crypter we already made an unpacker for. Crypter we are recreating is called LameCrypt. So, what does LameCrypt do?

Its a very very simple crypter designed only to crypt the first executable section by XORing with 0x90. Extremely simple protection mechanism which looks just like this:

  PUSHAD
  PUSHFW
  MOV EBX,4C000
L003:
  XOR BYTE PTR DS:[EBX+401000],90
  DEC EBX
  CMP EBX,-1
  JNZ L003
  POPFW
  POPAD
  MOV EAX,0044CF38
  JMP NEAR EAX

That is the entire crypter code. To recreate it we will copy the binary for the code above and leave the constants blank. After processing that binary data looks like this:

60 66 9C BB 00 00 00 00 80 B3 00 00 00 00 90 4B
83 FB FF 75 F3 66 9D 61 B8 00 00 00 00 FF E0

All the zeroes above will be filled with the following data: virtual size of the first section, virtual offset of the first section and the address of the original entry point. This data, once filled to code above, will be written to the new section. List of actions to perform for this would be:

• Read necessary PE32 data
• Fill the  binary data from above
• Add new section to PE32 file
• Fill written data to it
• Encrypt the first section by XORing it with 0x90
• Update PE header data

Since this is a very simple crypter its code is very short. What makes this a Halloween post is the spooky fact that TE can be forced to create his own worst enemies, crypters! Until next time...

TitanEngine ReversingLabs Corporation

LameCrypter (Package contains binary and source files)

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