Packers and Unpackers
by The Undertaker, 13 January 1998
(edited, more than slightly, by reverser+)
Courtesy of Reverser's page of reverse engineering
reverser's comments
Our Srilankan friend (and major contributor) is alive and kicking, once more working on the packers and unpackers project (I advice anyone to read The Undertaker's previous very good essay about good powerful TRON). The Undertaker will show you through this essay that you would be well advised to stop whining and complaining about "too easy protection schemes" and start having a look at the exe protectors. Those nice (mostly dos based, for obvious power reasons) programs that should avoid exefiles reversing. The EXE protectors themselves, of course, must use heavy anti-debugging tricks in order NOT to be reversed, as you will see in this very interesting essay... -alas for the protectors- the +HCU cannot allow anything to merrily run wild and unreversed around for all too long :-)
There is a crack, a crack in everything
That's how the light gets in
( )Beginner (x)Intermediate (x)Advanced ( )Expert
An understanding of common dos cracking techniques is a pre-requisite. Don't even try to follow this if you are a beginner (in that case mark it and come back later).
Written by The Undertaker
No introduction
Tools Required
Debugger (SoftIce 2.80)

Of course, you may choose any other tools you like.

Program History
No history

After a long period of busy schedule finally I managed to start again my reverse engineering essays. Today we will explore another EXE protector, called PROTEXE. Exploring EXE protectors you will learn a lot, believe me. This happens because normally they use good encription & anti debugging tricks. In fact a reversed exe protector is not a protector any more, so they would like not to be reversed... so simple is that :-) Therefore stop complaining about too easy protection schemes and pull up your sleeves, you lazy crackers... tackle exe protectors (and learn how to work in mighty DOS/UNIX, forgetting the mostly useless windoze's razzmatazz). EXE protectors use most of the time interesting tricks like Vector replacement, and/or Self modifying code, and/or Various other anti debugging tricks. Moreover some of them uses very good protection schemes. Truly hard to crack those targets, at time. Ok, that's nice, lets get to work. First: download here TOM TROFS' PROTEXE program (version 2.11 shareware, of course uncracked). Second: protect a EXE file using PROTEXE, so that we have an own made target's example. Now let's set up our favorite tool: soft-ice 2.80 (the working version! There exists another, "crashing" version which roams the web... same length, just many minor "bytes differences"... to know which one you have fished out the net, just try it out a little, if it does not crash it's the good one, duh). Load your protected EXE file using Symbolic Loader (LDR). LDR lha.exe Now you are in Soft-Ice window, Before we analyse the code we need to study the X86 flag register. FLAGS - Intel 8086 Family Flags Register 1110FEDCBA9876543210 CF Carry Flag 1 PF Parity Flag 0 AF Auxiliary Flag 0 ZF Zero Flag SF Sign Flag TF Trap Flag (Single Step) *** IF Interrupt Flag DF Direction Flag OF Overflow flag IOPL I/O Privilege Level (286+ only) NT Nested Task Flag (286+ only) 0 RF Resume Flag (386+ only) VM Virtual Mode Flag (386+ only) Ok, lets explore the first few instructions in the protected program.... XXXX:0147 9C PUSHF -- Save The Flag Register XXXX:0148 9C PUSHF -- Pushed again to get into AX XXXX:0149 58 POP AX -- AX Contains Current Flag Settings XXXX:014A 25FF0F AND AX,0FFF -- Discard upper 4 nibbles (msb) XXXX:014D 50 PUSH AX -- Save modified flags XXXX:014E 9D POPF -- Use modified Flags. . . . . XXXX:0159 9C PUSHF XXXX:015A 58 POPF XXXX:015B 25FF0F AND AX,0FFF -- Discard Upper 4 niblles XXXX:015E 0D0070 OR AX,7000 -- If TF is on, Off it XXXX:0161 50 PUSH AX XXXX:0162 58 POPF Well, the above part is just there in order to disable the Trap Flag. If the Trap Flag is on the processor, then switch back to single step mode. Most "universal" Unpackers use this method to trace through the code. Ok lets analyse the code further down. XXXX:016A BA6400 MOV DX,064 XXXX:016D BOAD MOV AL,AD XXXX:016F EB01 JMP 172 -- *** XXXX:0171 88EE MOV DH,CH The purpose of the above part is to disable the keyboard. But as you can see there is a jump! It is directed to OFFSET:172. In the code there is no 172 whatsoever. Semms like it is jumping to the second part of mov dh,ch... what's happening? Ok it is a self modifying stuff code snippet in here. The EE at 172 is an Opcode for OUT DX,AL. See DX & AL setup for the keyboard disable.
out dx,al outputs byte al to the port number in dx. Output to any port from 0 to 65535 is performed by placing the port number in the DX register and then using an OUT instruction with dx as the first operand.
But there is no OUT DX,AL. We will check the jump then. It is directed to 172. In offset 172 you will find the opcode EE. Here you can understand what's going on: once executed the jump, the code changes to OUT DX,AL. Code MOV DH,CH has no effect until the jump instruction has been executed. This was just an easy example: within the code of oir target you will find a lot of these JMP's directed to OUT DX,AL. Let's ignore all of them and countinue our journey. XXXX:0186 33C0 XOR AX,AX XXXX:0188 8ED8 MOV DS,AX XXXX:018A FF360C00 PUSH [000C] XXXX:018E FF360E00 PUSH [000E] XXXX:0192 B84602 MOV AX,246 -- ** XXXX:0195 A30C00 MOV [000C],AX XXXX:0198 8C0E0E00 MOV [000E],CS Ok, Check above code. Mmmm It seems to be a Vector replacement for interrupt 3. Yes it is, Most of the debuggers & universal unpackers uses int 3. Replacing the int3 code to something else may hang these type of debuggers & unpackers. Let us check what is replacing the existing int 3 code. The new interrupt service routine for int 3 is located at CS:246 (chek the code). Normally Int3 code has only an IRET instruction. Lets check the new int3 ISR... U 246 XXXX:0246 8ED8 MOV DS,AX XXXX:0248 CF IRET In here int3 used to copy the contains of AX to DS.. Let's explore the code again.. If you are going through the code, You will find lot of Keyboard disable routines & interrupt masking (keyboard Int masking) routines inside our target. Bypass all of them (I think everybody knows to bypass such lame tricks, if not go raed some basic cracking stuff and come back later) and next you will landed on a CRC checking routine. Man, we'll have seen the complete PPPP (Paranoid Programmer Protection Palette)by the end of this essay! Go through the code until you find the following: XXXX:020B 81FEF78A CMP SI,8AF7 XXXX:020F 72B0 JB 1C1 XXXX:0211 PUSH DX -- ** Put a Break Point on XXXX:0211. Otherwise it will loop you a long time until SI=8AF7. BPX 211 & go (F5) Again you will see a lot of silly keyboard & interrupt Enable routines inside the code window. Steady ahead! Go through the code until you see the following... XXXX:022E 81FA2877 CMP DX,7728 XXXX:0232 7415 JZ 249 -- ** This part checks a calculated CRC with the program contains. If everything matches all nice guys go ahead. Else you will land inside a CRC failed message & dumped into dos. ("Beggar off") Mmmm... not a nice solution for people that have so patiently studied this nice paranoid code so far, is it? Ok, go through the code until you see the following. XXXX:02D2 EB01 JMP 2D5 XXXX:02D4 88EE MOV DH,CH XXXX:02D6 EA0000C615 JMP 15C6:0000 -- ******* The FAR JMP above will take you to the original code of your programm... Well in this PROTEXE you have seen (and will find if you decide to work a little on it) different types of protection methods. They are.. # FLAG register Masking. (TF MASK) # Vector Replacement. # Keyboard & interrupt Masking. # Self Modifying Code. # CRC Checking. The above methods are fairly good, if very common. The only real problematic thing for the Author, here, seem to be the implementation lacks. I think that the Coder only tried to protect the program from LAMERS. Otherwise he could and should have implemented the program's protection schemes better than that. C'mon, we are sure you can do better next time. I think that all the protection writers should try to think -at least- twice about what they are doing BEFORE plannning and writing their protection schemes. It is true this is the dammn silly windows' age, but there are still some good reverse engineers in this world... and what's the point of scaring a couple of lamers off. Either you DO NOT protect, which is a very honorable way of spreading very good software, see filemon as an example, or, if you do protect, try one more solide protection instead of a plethora of old tricks alltogether. Quantity has never won against quality. Ok, for your experiments and joy now, dear readers, Using a hex editor you just need to change a few opcodes in this program, following the lines given above. Find those opcodes and change them. Then use good powerful TRON to unpack it. Shhhhh! How easy and interesting... If you have any problems contact me... I would like to read your comments. You can write to me on following email address.. NOTE - If you compressed the program before running protexe. Then the above OFFSET address couls be different. Also you can download the PROTEXE program (version 2.11 shareware) from reverser's PAGE, here, of course uncracked. Thanks goes to +ORC and all HCU+ guys. Next time we'll move to a different type of a protector. Until then.......... REST IN PEACE The Undertaker -=BANDA=- //SRI LANKA//
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.

No final notes

way out
You are deep inside reverser's page of reverse engineering, choose your way out:
Back to PAckers and Unpackers
redhomepage redlinks redanonymity +ORC redstudents' essays 
redtools redcocktails redantismut CGI-scripts redsearch_forms redmail_reverser
redIs reverse engineering legal?