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 :-)
EXE UNPACKER WITH ANTI-DEBUGGING FACILITY
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
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
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
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
: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 , 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!
: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
+ORC students' essays tools
antismut search_forms mail_Fravia
is reverse engineering legal?