TRW2000 and Hmemcpy an essay on reversing by
(¯'=RalDnoR='¯)
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.
Prerequisites: Some knowledge of reversing and assembly, and some understanding of the inner workings of windoze.
TRW2000 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.
Hmemcpy. 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 tutorial).
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: !.text). - 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 call. - 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: raldnor@thearmy.com. http://azrael.mine.nu
