Home    Training    Downloads    Tutorials    Arbitary    Get Fate    Proxy Info
Training session 41: Delphi DCU Cracking
Difficulty: Easy
Learn how to Crack simple DCU Components
Creator: m101


The DCU (Delphi Compiled Unit) file format is a proprietry file format created by Borland to provide an intermediate point between compiled code, and source code. It is the simple reason why Delphi's compiler can generate a compiled executable in an almost unnoticable period of time.

The reason a DCU can be compiled so fast is because all of the assembly instructions have already been written, the only thing the compiler has to do is write in the addresses to each function or procedure in relation to the compiled executable.

So why would you want to crack a DCU file? Well, developers out there quite regularly create Components which are distributed in this format so they do not have to provide the source code, which is especially important for Shareware Components.

What You Need:

DeDe or DCU32INT (DeDe Recommended)
A Hex Editor (Hiew Recommended)
Delphi 7 (For Testing)
Some Brain

The Target:

NSELib 2.1a for Delphi 7

NSELib is a very nice Component written by Whirling Dervishes to simplify the creation of Name Space Extensions, i would recommend it to anyone for this task as it makes it almost unbeleivabely simple, you barely need to know what a Name Space Extension is to use it.

When you attempt to register an Extension created with this you get a nice little nag screen informing you that it is a demo, this also occurs every time the Extension is loaded.

Getting Started:

Now, firstly I must state there is very little documentation on the DCU format around, so this is infact my first attempt to crack a Delphi Component, and since i didnt have the time to go through the source of DeDe's DCU Components i had to do a little trial and error to get a working result.

The first thing to do is create an Extension to see this nag screen, install the Component, go into Delphi, go to New > Other, then to Namespace Extensions, and then select Name Space Extension Project and click Ok. Go through the Wizard and create yourself a simple Extension Shell. Now compile the result. I named mine Test, so the resulting DLL is callled Test.dll.

To bring up the name space, pull up a Command Prompt, locate the folder Test.dll is in, then type:
regsvr32 Test.dll
You should get a nag popup saying "This is the Demo version of NSELib.". We now have our target. Now deregister the dll so we can recompile it later using:
regsvr32 /u Test.dll
You will also need to kill explorer.exe in the task manager, then start it up again by going to File > New Task (Run...) > explorer.exe. You will have to do this everytime you test a new fix.

If you go into the Program folder for Component and do a search for files containing 'Demo' the following will be returned:
C:\Program Files\Whirling Dervishes\NameSpace Extension Library\

C:\Program Files\Whirling Dervishes\NameSpace Extension Library\Examples\ButtonTest\
Obviously the last set are irrelivent, and INSTALL.LOG is also useless, so that leaves nselibwizardd7.bpl and NamespaceApp.dcu. Now since our nag is not inside the source the wizard generated, our target must be in NamespaceApp.dcu.

Open up DeDe, go to Dumpers > DCU Dumper. Now locate NamespaceApp.dcu and click Process, no option changing should be necessary. Generally speaking, in Delphi people rarely use MessageBoxA to display a simple message, they use ShowMessage() instead, so if we check through the 'uses' statements generated by the Dumper then we can find:
  Dialogs {
This means this unit uses Dialogs.ShowMessage() at some point, now if you have looked much at what this Component does, ShowMessage() should really only be necessary for errors, or in this case, our Nag Screen.

Since the Nag is shown when the Component is first registered, we can safely presume the call should be in TNameSpaceApp.Create(). So go through till you find this and you will find the following:
constructor TNameSpaceApp.Create (Self: TNameSpaceApp; _Dv_: false..true);
   00000000 : 53                            PUSH EBX
   00000001 : 56                            PUSH ESI
   00000002 : 84 D2                         TEST DL,DL
   00000004 : 74 08                         JE +8; (0xE)
   00000006 : 83 C4 F0                      ADD ESP,-16
   00000009 : E8(00 00 00 00                CALL @ClassCreate{0x38}
   0000000E : 8B DA                         MOV EBX,EDX
   00000010 : 8B F0                         MOV ESI,EAX
   00000012 : B8(C8 00 00 00                MOV EAX,TNameSpaceApp.Create{0x6C}+200
   00000017 : E8(00 00 00 00                CALL ShowMessage{0x56}
   0000001C : B2 01                         MOV DL,$01
As you can see, that JE at line 4 does not jump far enough past the call to ShowMessage() to be of any use, so this is not an error call, that means it must be our Nag!

Generally speaking, a few NOP's would be enough to kill the call to ShowMessage(), but as I stated earlier, the DCU undergoes quite a bit of relocation when Compiled, this means the 00 00 00 00 is replaced by the Compiler in the line:
   00000017 : E8(00 00 00 00                CALL ShowMessage{0x56}
Now since i havent gone enough into the format to find the table which tells the Compiler which addresses to replace with what, I am not going to patch that line at all, rather i am just going to force the line to be skipped. Since we have to be careful about altering any Registers, we shall patch line E to unconditionally jump to line 1C. In this case the instruction "JMP 1C" is "EB 0A" so lets patch it. Open up your Hex Editor, do a search for "53 56 84 D2 74 08 83 C4 F0 E8".

You will find yourself at 10A0, so that means we want to patch 10AE. Go to this location, change the Byte's to "EB 0A" and save the result. Now Completely recompile our test project, then Register our Extension again, if you have followed these instructions correctly you should get absolutely no Nag!

URL or Email