··· Window$ Reverse Engineering Tutorials ···

TRW2000 and Hmemcpy
an essay on reversing by

Purpose of this essay:
To show you the advantages of TRW2K, a very good replacement of SoftIce and to
teach you the workings of the famous hmemcpy-function.

Some knowledge of reversing and assembly, and some understanding of the
inner workings of windoze.

A few weeks ago I discovered a new debugger named TRW2000. I was looking for
a replacement for SoftIce since SI didn't run underneath Windows Millennium
(though this has been solved now). In my opinion SoftIce is a great debugger,
though there are some disadvantages. First of all, when you run SoftIce
underneath a Win9x OS it has to be loaded in the autoexec.bat. This means
that it HAS to be loaded prior to the operating system (btw: this is not the case in WinNT).
So when you're not studying reversing, some programs (like games ;) won't
run because they detect SI. You can of course create a boot menu, but
IMHO this is not a nice way.

The advantages of TRW2000 are many. First of all, for most commands it uses
the same syntax as SI. So when you’ve studied hard to understand SI you can still
apply it on TRW2K.
Second, it can be loaded and unloaded any time you want. When you start
TRW2K, a graphical frontend starts, you drag and drop the executable you
want to 'debug' and you press load. Then the debugger shows up at the
programs' entry point. You may then place a breakpoint or press 'x' to
return to the application.
TRW2K is also very small. You can easily put it on a floppy.

If you ever stumble upon a program you cannot easily debug because of a
SI-detection routine TRW2K also comes in very handy. You can first start
the program you wish to crack and then start TRW2K with another program
(notepad for example). You then set a breakpoint and continue the previous
loaded program. Since the SI detection is uaually located at the beginning
of a program you can easily circumvent it.

I've read many tutorials on this famous breakpoint, but most tutorials
only tell you 'press f12 34 times and then...', so I decided to try
to give you some more information.

Hmemcpy is a windows API-function. This means it is called from within a standard
windows-DLL which is part of the kernel (which is actually the operating
system). Hmemcpy stands for 'Huge Memory Copy' and is usually used to
copy text or properties from certain controls (a control is part of a window, like
a text-edit field or a pushbutton).
Unlike what most people think it is not always the programmer who intentionally
uses this function. In visual programming languages many code is prewritten by
calling functions from DLL's (like the ones from Visual Basic or Visual C++, Delphi
and others). These DLL's often contain references to Hmemcpy.

How to use Hmemcpy
As a cracker your goal is to reach the code where the serial validation is done. So
actually you're always trying to find a breakpoint just before this validation is done.
Usually the first try involves breakpoints on common API-functions like
GetWindowsTextA, StrCmpA and other obvious functions (open your windows
API-reference to figure out what these functions do; it's outside the scope of this

If these won't work, there's always a function which has success, our famous
Hmemcpy. This function has a disadvantage though. Since it is called by so many
programs and functions there's a big chance you enter the program-source way to
early. There's also a chance you arrive in a hmemcpy-function called from another
application since windows is multitasking.

The CountDown Approach
I usually take this approach:
- Fire up TRW2K with the program you want to analyze, TRW pops up at the program
entry point.
- Type 'x' to return to windows to allow futher execution of the program
- Open the registration box where you have to enter your name and serial and fill
in the fields with bogus-info (like RalDnor, 666-666-666).
- Before you click the Ok-button (or validation button ;) press ctrl-n to return in TRW.
- Type 'bpx hmemcpy' to set a breakpoint on Hmemcpy.
- Now the important part: press 'x' to continue execution. You'll notice TRW pops-up
again at the next call to Hmemcpy.
- Repeat the above procedure untill the 'invalid code' messagebox pops up. Now you've
got a general idea how many times hmemcpy is called before the bogus-code is
discarded. It is usually a good idea to do this whole procedure again since (as I
explained before) hmemcpy can also be called by another program in the mean-time.
- Everytime you repeat this procedure be sure to disable the breakpoint temporarily
untill you click on the validation-button. In TRW you do this by entering 'bd 1'
(disable the first breakpoint). You can re-enable it by typing 'be 1' (breakpoint enable).
- Next you repeat the procedure but stop just before you enter the last cal to hmemcpy,
before the messagebox shows up. Now you're as close to the validation routine as
you can get.

The StepOver approach
There's also another approach. It differs from program to program which one is faster,
and it also depends on how many hmemcpy calls are made before the validation.
You can use this one when there's only one hmemcpy call (which is highly unlikely,
especially with more than one edit-field), or you can use it if there's still a lot of code
available after the last Hmemcpy-call before the validation routine.
- As explained earlier you enter TRW in the Hmemcpy-call. You then press F12 a few
times untill you arrive at the program itself (you can verify this by looking at the bottom-
half of the screen. There you can see where you are. Usually it looks like:
- Then you step through the program only by using F10 (step line-by-line through the code,
not following calls). Everytime you're about to step over a call press F9 to place a new
breakpoint on the call (b.t.w. make sure you've cleared the Hmemcpy breakpoint, 'bc'
is the command to clear a breakpoint).
- Everytime you arrive on a new call clear the former breakpoint and place a new one on the
- Lastly you arrive at the point where the 'invalid code'-messagebox pops up. Luckily you still
have a breakpoint on the last call before the messagebox is called. So now you can
enter the bogus-info again and you'll arrive at the last call which is in most cases
the validation routine :)

Greetz fly out to: Therios, Pipsel, ShellShock, Richard B., Zoltan, _dose, _mammon, Fravia,
AxE, all at +HCU Linux, Lenny, +SandMan, Harlequin and all others I met on the digital highway.

If you've got some comments on this article feel free to mail me at: