patchmaci.htm: PATCHING Encrypted targets

	PATCHING Encrypted or packed targets Crack on the fly
15.1.2000	by macilaci
	Courtesy of Fravia's page of reverse engineering	slightly edited by Tsehp
fra_00xx 98xxxx handle 1100 NA PC	A good general method for memory patching, this can also be used on encrypted targets. I recommend this reading. Tsehp
	There is a crack, a crack in everything That's how the light gets in
Rating	( )Beginner (X)Intermediate ( )Advanced ( )Expert

Small add on for those who doesn't know how to patch an encrypted or packed target.

PATCHING Encrypted targets
Crack on the fly
Written by macilaci

Introduction

         After I have read the essay how to crack winzipkey by Torn@do I chose to write
small add on for this. The patch approach is more general so it can be used for most
packers and encryptors.

Tools required

PE format overview, Hexeditor - one with assembly view -->Hiew

Target's URL/FTP

www.blinkinc.com and many more

Program History

Encryption - to make it a bit harder for us.

Essay


I - main idea

    Did you find the place inside your target to patch? But the target is encrypted,
packed... Usually you have to patch small amount of bytes. The most work on the target
isn't the crack - it's the unpacking procedure. The main idea of the patching is to write
a small routine inside our packed target to patch the unpacked program in the memory.
Most unpackers do the work on the program start. The scheme looks like this:


            entry point
                 |
		 |
       ---------------------
       *      unpacker     *  -------\
       ---------------------         |
                 |                   | 
                 |                   |
		 | program code  <---/
                 |
       ---------------------
       *      program      *
       ---------------------	

 The unpacker contains in most cases the unpacker routine /*shrinker*/, in some cases
it contains the 'linking' procedure with GetProcAddress which makes the unpacking bit 
harder /*our case -UPX*/. The patching scheme:


            entry point
                 |
		 |
       ---------------------
       *      unpacker     *  -------\
       ---------------------         |
                 |                   | 
                 |                   |
		 | program code  <---/
                 |
       ---------------------
       *    our patcher    *  -------\
       ---------------------         |
                 |                   | 
                 |                   |
		 | program code  <---/ 
                 |
       ---------------------
       *      program      *
       ---------------------	

So we have to find the end of the unpacking routine and insert our little patch
program. Beware! - the program can contain CRC procedure, so be careful. Otherwise
you have to patch the CRC check too.


II - our example - Winzipkey patch

We found the place to patch:

0040307C: 83FB02                       cmp       ebx,002
0040307F: 0F8F48010000                 jg       .0004031CD  ; never should jump -change to nop
00403085: 33F6                         xor       esi,esi
00403087: 85DB                         test      ebx,ebx

We see that we have to patch six bytes at 40307f to nops.
Do bpm 40307f and run the program again. You will stop inside unpacker. The F12 approach is 
unusable /*with shrinker3.4 works!*/ so we have to find the end manually/*this is UPX*/. 
Setting breakpoints each after other. 
The begin of the main program looks like this:

0041421E: 55                           push      ebp
0041421F: 8BEC                         mov       ebp,esp
00414221: 6AFF                         push      0FF
00414223: 6838D84100                   push      00041D838 
00414228: 68C46F4100                   push      000416FC4 
0041422D: 64A100000000                 mov       eax,fs:[000000000]
00414233: 50                           push      eax
00414234: 64892500000000               mov       fs:[000000000],esp
0041423B: 83EC58                       sub       esp,058
0041423E: 53                           push      ebx
0041423F: 56                           push      esi
00414240: 57                           push      edi
00414241: 8965E8                       mov       [ebp][-0018],esp
00414244: FF15A0D14100                 call      Kernel32!GetVersion
0041424A: 33D2                         xor       edx,edx
0041424C: 8AD4                         mov       dl,ah
0041424E: 891568F84200                 mov       [00042F868],edx

We could find the original entry point with bpx GetVersion and finding reference to
41421E but the target changes the PE table.
The end of unpacker:

004411A1: 8A07                         mov       al,[edi]
				       or        eax, eax
                                       je        .0004411ca     ;jumps always
...
004411ca:                              popad
				       jmp       .00041421e    ;I don't think you'll see the 00041421e # in Hiew
							       ; just at the run time

When you set breakpoints between 4411a3 and 4411c9 you'll see that the program never
reaches this location. So we have some space for our patch.
The patch:


004411A1: 8A07                         mov       al,[edi]
004411A3: 50                           push      eax              ;store eax in stack
004411A4: 66B89090                     mov       ax,09090         ; 2x3=6 bytes
004411A8: 66A37F304000                 mov       [00040307F],ax   ; patch them all 
004411AE: 66A381304000                 mov       [000403081],ax
004411B4: 66A383304000                 mov       [000403083],ax
004411BA: 58                           pop       eax              ; restore eax
004411BB: EB0D                         jmps     .0004411CA        ; jump back to unpacker end

Some comments:
When patching dll's the correct way is to patch the relocation table too or write the relocated
address /*this isn't the correct way*/. However our patch doesn't require this because most
executables include this one have the base address 000400000.

Final Notes

     This approach can be used almost on any packer including the popular Shrinker. I think 
the UPX offers more security than Shrinker but patching on the fly will do the job for us.
Other packed targets /*from my experience*/: Iconforge - shrinker
                                             Shrinker demo version 3.4 - special packer
Packing - to make it easier for $hareware programmers. You can find the place to patch,
but can't patch? Can't you really?

Ob Duh

I wont even bother explaining you that you should BUY this target program if you intend to use it for a longer period than the allowed one. Should you want to STEAL this software instead, you don't need to crack its protection scheme at all: you'll find it on most Warez sites, complete and already regged, farewell, don't come back.

You are deep inside Fravia's page of reverse engineering, choose your way out:

links

Is reverse engineering legal?