PowerArchiver 2006 v9.50.28 Cracking Tutorial

PowerArchiver 2006 v9.50.28 Cracking Tutorial

by Pramod software Labs

       Target:  PowerArchiver 2006 v9.50.28

       Level: Intermediate

       Tools: OllyDbg 1.10; PEiD 0.93; ImportREC 1.6; LordPE; ToPo v1.2; PEditor 1.7; AntiDetectOlly Patch 2.21 

       Introduction: This step-by-step tutorial will explain how to unpack EXECryptor 2 and to crack                 PowerArchiver      2006 using code injection.

As you know, Teddy Rogers released a patch for PowerArchiver 2006 9.50 and some lame ducks ripped it off. I hope they read this tutorial; maybe by learning they stop to steal others hard work.

Execryptor is quite a powerful protector. It features quite good protection. Here is a list of protection tricks reversers have noticed:

  *    garbage code.

  *    hides OEP, replaces original code with metamorphic garbage code.

  *    damaged import table

  *    does not use "GetProcAddress" but directly traverses DLL export table

  *    rdtsc trick

  *    closes Olly windows 

  *    SEH tricks

  *    contains instructions that Olly does not handle well:

·         lock int3

·         lock int1

·         ds:int3

  *    damaged EXE header

  *    has its own TLS table

1. Analysis and OllyDbg configuration:

Open PEiD and load POWERARC.exe:

 

I mentioned PowerArchiver is packed with EXEcryptor; how come PEiD shows it’s packed with UPX?

Well, the answer can be found analyzing the sections:

 

As you see, there are no sections named UPX0/1/2, not even one of the usual UPX sections. Therefore, the packer must be other. Considering the .tls section and the others, this kind of structure is typically EXEcryptor.

EXEcryptor is a bit more than a simple packer; it hides a little trick to execute itself: uses the TLS structure.

TLS callback function gets executed even before EXEs import table is processed and DLLs are loaded. This way, EXEcryptor executes itself before the PE header’s Entry Point (EP), so we’ll need to configure OllyDbg in order to stop at system entry point or use the NtGlobalFlag plugin for Olly - it allows to break on TLS callback functions -, so we can follow the packers’ execution since its beginning.

First of, we’ll use a little program that hides Olly specifically from EXEcryptor: AntiDetectOlly Patch 2

We chose “Directory”, browse for ollydbg.exe (or other name, if you have used RE-Pair before) and Patch IT!

Now, we open Olly, press ALT+O to open Olly options, Events > Make first pause at: and we choose System breakpoint

 

To finalize configuring Olly, we will use Hide Debugger plugin and select ALL the options:

Now, we save the options, restart Olly and load POWERARC.exe

2. Finding the Original Entry Point (OEP):

As mentioned before, EXEcryptor executes itself before the EP. This is not the case but, in some versions, the packer exploits the TLS structure to detect the debugger and we need to start tracing the code from there to determine were we are being detect in order to remove the detection.

We can see the TLS structure Callback with LordPE:

The Callback direction is 00A6F010 and that’s where usually, the program starts to execute.

To prove if it is or not, we go to Olly and press ALT+M to open the Memory map and use F2 to set a breakpoint on access in the section comprehending the direction 00A6F010. In this case, it is .rdata:

 

We press F9 (Run) twice and Olly stops here:

 

OK. That’s your EP. Although in this case, you don’t need to follow the steps above, there are cases in that you’ll or else, Olly won’t be able to break before it crashes.

Now that we are at the EP, we’ll start to unpack the executable. If we manually, trace a bit of the code, we see that EXEcryptor jumps often between the code section (CODE) and the different sections of the packer. So we need to find a zone inside de packer were the code is already unpacked and were we can work at our free will.

That unpacked point will be our first entrance to the real CODE section. With Olly stopped at EP, we press ALT+M to open the Memory map, select the CODE section and set a memory breakpoint on access:

                                   

 Next, press F9 and Olly stops here:

 

 

This jump sends us to section a26losg3, we are not interested. Again, press F9 and Olly stops here:

Now, the code will return to the section .v0lowmiu, were we started tracing. So, one more F9 and…

Yes! We stopped at the first point were CODE section is executed. We can even see the first call to IAT.

Very well, at this point, the program is unpacked in memory and we going to take 004079C0 as our OEP.

As we are here, we’ll find out were the IAT starts, were it ends and what’s its size.

Select the first call to IAT

 

And press Enter:

 

We can see the IAT is restored. Let’s go collect the data so we can dump.

Select the first instruction and press F10 + Follow in dump > Memory address

 

Once at the dump window, we scroll up the code till the IAT begins:

        

And then, we scroll down till the IAT ends:

As usual, the kernel32.dll string closes the IAT table.

So, we have: Start: 00A68258 - Finnish: 00A68DF = Size: BA0

3. Dumping and rebuilding the IAT

Don’t close Olly and open LordPE. From the processes list, select powerarc.exe and choose dump full…

When it’s done, save the dump file and name it POWERARC_dump.EXE.

Next, close LordPE and open ImpREC. Select powerarc.exe from the list. We will now enter the data we have, knowing we need to subtract the base value: 

OEP =  004079C0 – 00400000 =    79C0

RVA = 00A68258  –  00400000 = 668258

Size =   00A68DF8  – 00A68258 =   BA0

Next, select Get imports, followed by Show invalid and finally, cut the invalid section with Cut thunk(s)

Cool. Now you have a non-working dumped file with a repaired IAT. You can think you failed something while unpacking the executable but, I assure you that you didn’t. In fact, the size of POWERARC_dump_.EXE is about 8.17Mb, twice the original size and if you use Resource Hacker, you can see the String Table dialogs, which is impossible with the original file. The thing is that you need to fix the dumped file.J

4. Fixing the dumped file

First, we will fix the program’s PE. Open PEditor and be sure you have these settings:

 

Apply the changes and close PEditor.

The Base of Code characteristic change to 00001000 is for Olly to consider as the executable’s base of code the RVA (Relative Virtual Address) of CODE section and not the RVA of .v0lowmiu which is EXEcryptor code.

Next, we open another instance of OllyDbg without closing the one that’s running and we load the executable POWERARC_dump_.EXE. It stops at System Entry Point; we press F9 and it stops at our OEP.

We do this because, as I explained before, the OPE we found is not the real one. EXEcryptor jumps a lot between de code section and the packer sections so we picked a point were the code was already unpacked in the memory but, of course, it will return to the packer and at that moment, the registers and stack values must match. And that’s what we are going to prove. In case they don’t match, we have to manually modify the values.

We are going to compare both Olly instances we have running:

                                     OriginaL                                                                                           Dumped

 

 

The values don’t match.

Close Olly instance with POWERARC_dump_.EXE loaded and open ToPo so we can create a new section and change the OEP at sections’ beginning. In this section we’ll fix the stack by entering the missing values, set the registers according to the “original” and jump to the OEP we have found. After that, the program should run.

Open ToPo and select:

 

Browse for POWERARC_dump_.EXE, give it a 1024 bytes size so you can write something and select Redirect Entrypoint, this way, it will point the EP to the begging of the section we are about to add. Finally, press Do it!

 

Close ToPo and open again, a second OllyDbg instance.

Load POWERARC_dump_.EXE and Olly stops at System Entry Point; we press F9 and it stops in the new section, in my case, is C2D000. Now, roll up your sleeves to create this patch:

 

When you finish, select all the patch and press F10+ Copy to executable> Selection:

 

And save your patch with Save file:

 

Next, press F9 and the executable runs just fine :)

5. Registering PowerArchiver 2006

Press the button Enter Registration Code…, enter some data and press OK.

 

Back to OllyDbg’s CPU window, press F10 + Search for > All referenced text strings:

 

When the References window opens, press F10 + Search for text:

 

And enter PowerArchiver’s message first two words: “Registration information…” Uncheck the Case Sensitive box so Olly will ignore the upper and lowercases, check the Entire scope box so Olly starts to search for the words right form the top of the page.

Next, press OK and Bam! There’s the message in Olly:

 

There’s another message we are interested in: “Please restart PowerArchiver to complete registration…”

Also, we see a Windows registry address and a couple of related strings: “Regname” and “Regnumber”

This means the authors have changed the registration process and now, the program stores the data in the registry if certain conditions are fulfilled when the user enters the name and serial and at startup, it loads the data from registry and checks if it’s correct or not.

Select the message line and press Enter to go back to the CPU window

 

 

Our theory confirms. We see that there’s a comparison to 0Ah=10d – one of the conditions -, if the result is equal or greater (JGE), it jumps over the “Registration… incomplete.” message and moves on to copy a value stored in DS:[7EAC70] to EAX and then, to compare EAX first byte to 0 at addresses 006FDB71/76 – the second condition -, if it is 0 (JE), the code jumps at address 006FDB79 to the message “Please restart PowerArchiver to complete…”.

This means our serial has to be at least, 10 digits long but, it also means that the key for our success is to determine the constant in EAX and to find the spot where it is compared to 0 at startup so we can do something there.

As far as the constant is concerned, it’s easy:

 

EAX = [007EAC70] = 00A65D2C

If you want to prove the value it takes is really 0, just set a BP at the comparison instruction, go back to PowerArchiver registration menu and press OK. When Olly breaks, this is what you’ll see:

 

Now, to search for the comparison at startup, press F10 + Search for > All sequences:

 

And write the instruction CMP BYTE PTR DS:[EAX],0, replace EAX by  A65D2C and press Find:

“Huston, we have a problem”. Unknown identifier.

Don’t despair; there’s another way: Search for the correspondent binary string.

Press CRTL+B or F10 + Search for > Binary string:

 

And type the instruction CMP BYTE PTR DS:[A65D2C],0 correspondent code:

 

 

Press OK and…

 

yeah we have found it...,.

So, what’s next?

Well, we know that if the code is unregistered the value in 00A65D2C is 0; so, to get the program to run registered, we must be sure 00A65D2C takes the value 1 at startup.

MOV BYTE PTR DS:[A65D2C],1

We are going to edit our first patch to add 3 bytes to the code:

 

Now, we save our patch, press CTRL+F2 to restart debugging and press F9 to run PowerArchiver 2006:

 

THE END

Mission accomplished!

I hope you enjoyed. See you next time. J