undtron1

Packers and Unpackers: phase 1

Tron version 1.30
by The Undertacker
(19 September 1997, heavily modified by Fravia+)

Courtesy of Fravia's page of reverse engineering

Well, this essay by our srilankan friend: The Undertaker, has given me the possibility to open our new section: "Packers and Unpackers: the arms race". I have modified this essay, editing it, since the exact ROAD used by The Undertacker in order to find the protection scheme was far from clear... I hope that The Undertaker will agree with my changes, if not, I'm ready to modify whatever he feels should be adjusted :-)

TRON v.1.30
EXE UNPACKER WITH ANTI-DEBUGGING FACILITY
BY
The Undertaker -=BANDA=-

This is the windows' dark age... a period of fear and poverty and black magical software arts, where only few wizards, inside the high Micro$oft's towers, know how to assemble and disassemble software, while the stupid peasants programmers are condemned to use ineffective and overbloated languages, and the Lord of the Gates laughs at their feeble attempts to break free of an imposed OS-poverty.

Because Micro$oft does not want people to be free, see, they would loose money in such a process... they are pushing everybody to learn VB+, Access and all other NON powered programming languages... keeping assembly aside. Only "fringe's" little groups: demomakers, reverse engineers, virus writers and crackers still use assembly, and they too are in danger, censored and sued and prosecuted by the lackeys and servants of the black Lord of the Gates.

People that use LOW powered languages can do only very little, only miserable things. So Micro$oft can dominate the software arena very easily... where are the assembly coders (and the resources) that, if concentrated on a simple software developing project, would quickly push Word for windows in the oblivion that such a miserable wordprocessor deserves? Nowhere... you only get as flawed "concurrence" to MS-abomination, aborts like Wordpro, Wordperfect for windows, amipro and similar poor concoctions, written in the overbloated languages of the enemy and THEREFORE unable to fight him aside.

The reason for the weak protection schemes used by Micro$oft is not that they "don't care" if we crack or not their programs, is their "hybris": they think that people are already "done", that everybody only knows low powered programming languages... that assembly is only propriety of few reverse engineers (a good ancient race of white non-commercial wizards, a race that has almost disappeared... +ORC has tried hard to "revamp" interest in it, yet the knowledge is -as before- confined to the few readers of these lines) and to the research and development engineers (many of them were crackers at dawn, then followed the dark path of money... and are now greedy servants of the big corporations and our worst enemies)

So! Learn right now ASSEMBLY LANGUAGE (and nothing else until you have 
learned it). 
The more you learn and understand the more you'll be able to damage Micro$oft!
Try to contribute something, to the world, in order to get rid of Micro$oft's 
"one man show".
Develop a O/S (No kidding! If you try you can do it... you can do ANYTHING 
when you know assembly!) in order to kick Micro$oft away from the 
scene.
I will release my O/S early 1998 all over the web (BANDA v1.0b GUI).

Finally, I would like to thank Fravia+ for his great contribution to our 
world of assembly.

OK, let's start our work... we are here, to day, in order to use fully a very 
important tool for our reverse engineering endeavours: TRON, a very good 
(and powerful) Unpacker. 
As usual, we are reversing targets only for fun and for educational purposes... 
tron is a good tool, made by a good programmer (Michael Bauder, Germany).
A pity that it is so miserably protected. Anyway, if you use it, pay for it, as I 
did. This is a very good dos application (yes, there are still very good quality 
DOS programs available) and deserves it.

TRON is better than the well know UNP.
This tool has an unique feature for "anti-debugging" tricks.
This program can unpack files packed with UNKNOWN packers & encrypters, 
tracing through the packed code (yes, it spares us our own work!).

OK, download this program here and let's start 
reversing it right now.

Tools:	Wdasm89: create your tron.alf

Let's see what "hooks" we have: run a "forbidden" option (say -u) and you'll
get following nag-string: 
"Unregistered! You must register to use this part of tron"
And what does our target make afterwards? The program stupidly exits 
back to DOS! That's GOOD! :-)

In all banal dos programs there are terminate with return code interrupts (21/4C). 
These represent  the end of the program, and like all endings, there may be 
"happy ends" and "sad ends". 
If you have done something wrong (like for instance asking for a registered 
option being unregistered :) you'll get a sad ending, most of the time.
Let's start reversing from there. We'll find quite a lot of INT 21/4C inside 
this target (probably one for each recognised packer... dunno... who cares?), 
yet most will be under the "happy ending" form 21/4C-00... like this one, 
taken as example:

:0001.197E B8004C                 mov ax, 4C00
:0001.1981 CD21                   int 21

which does NOT interest us, since 00 (in al) is, as I said, the "normal 
termination". There are only two different int 21/4C inside our target, 
and, loo and behold, they have both to do with the protection of tron!

THE FIRST "UNHAPPY" INT 21/4C inside tron:
* Referenced by a Jump at Address:0001.192C(C)
|
:0001.193D E8F0FF          call 1930
:0001.1940 A1B711          mov ax, word ptr [11B7]
:0001.1943 8B16B511        mov dx, [11B5]
:0001.1947 A30B11          mov word ptr [110B], ax
:0001.194A 89160D11        mov [110D], dx
:0001.194E E83200          call 1983   
:0001.1951 B44C            mov ah, 4C  ;terminate with unknown ret code in al
:0001.1953 CD21            int 21      ;could be anything the previous call
                                              ;decides
THE SECOND "UNHAPPY" INT 21/4C inside tron:
:0001.3C25 B8FF4C          mov ax, 4CFF  ;returns -1, a really "sad" ending
:0001.3C28 CD21            int 21         

AH AH!, a call immediately before the first one, responsable for an 
eventual sad ending... we'll need to have a look!
:0001.194E     call 1983
:0001.1953     INT21/4C_who_knows until we examine the previous call?


AH AH! The second one returns FALSE!
We'll need to backtrace, if you look at your dead listing you'll see 
that a file has been closed short before... and you could go back
from here...
:0001.3C28	INT 21/4C_FF

Let's have a look at both "unhappy" interrupts... as you'll see the 
first one will show THE START of our target's protection, and the 
second one will show THE END of our target's protection. 
Since going forward is easier than backtracing, we'll begin 
investigating the suspect call before the first int 21/4C unknown 
ending (note that, if necessary, we could have proceeded the other 
way round, "remounting" back to our target's protection from the 
int 21/4C that returns the "sad ending" FF). 
The first occurrence of an eventual "not normal" termination is 
preceded by a call which we have to investigate... as you'll see, 
it checks about the eventual "necessity" to check the user:

* Referenced by a CALL at Address:0001.194E
|
:0001.1983 803E730B01      cmp byte ptr [0B73], 01  ;check flag check user
:0001.1988 7503            jne 198D                 ;continue with list_o_calls
:0001.198A E95E03          jmp 1CEB                 ;check user


* Referenced by a Jump at Address:0001.198A(U)
|
:0001.1CEB 813E0202FB75    cmp word ptr [0202], 75FB   ;check the Reg value
:0001.1CF1 7409            je 1CFC                     ;Registered User! Go ahead!
:0001.1CF3 BA3809          mov dx, 0938                ;Bad user, beggar off!
                       ;at ~38 you have inside the code of our target the 
                       ;string "0D/0A/UNREGISTERED!!! you must register to use 
                       ;this part of tRON!
:0001.1CF6 E89E22     call 3F97          ;call INT 21/2 output char
:0001.1CF9 E9F41E     jmp 3BF0           ;close file and terminate -1

Infact, if you follow the unconditional jmp to 3BFO, you'll soon land here:
:0001.3C25 B8FF4C                 mov ax, 4CFF  ;returns -1
:0001.3C28 CD21                   int 21

OK, that's war for tron's protection:
The crack seems indeed utterly simple:
:0001.1CF1 7409    je 1CFC    ;Registered User! Go ahead!
changed into
:0001.1CF1 EB09    jmp 1CFC   ;Anybody! Go ahead!

Well, looking behind at the protection scheme used by tron, and at the code snippet we have examined, one would probably not readily agree with tron's Author about this program being written in "Pure HARDCORE Assembler! What else? 16 & 32 bit technology!", as they claim inside tron.doc :-)

BTW, there is another, completely different way to track the same scheme:
Use Softice 2.8 for DOS
Create a packed file lhaed.exe using a packer
Run Softice loader with ldr tron -u lhaed.exe
BPX CS:194E  (:0001.194E     call 1983)
Follow the call and so on (see above).

Many thanks to the +HCU guys!

The Undertacker -=BANDA=- //SRI LANKA//

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

Back to the arms race

is reverse engineering legal?