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

         
PROTEXE V2.11 - by TOM TROFS
EXPLORING A PARANOID PROTECTION SCHEME
BY
THE UNDERTAKER -=BANDA=-

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

                ³11³10³F³E³D³C³B³A³9³8³7³6³5³4³3³2³1³0³
                ³  ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ÀÄÄÄ  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..

                undertakerd@hotmail.com


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 FRAVIA'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//

No final notes

---