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