http://www.cuteftp.com
http://www.yurisw.com
Required tools:
SoftICE
W32Dasm
HEdit (or any other hex editor).
After a newbie cracker (myself included) moves on from the limited days of serial fishing and good guessing, the time arrives to start to delve deeper into foreign code and put your first (?) time-trial crack under your belt. In this tutorial I will cover two examples of this type of protection. Our targets are HEdit v2.1.14 and CuteFTP v2.6. After installing these programs there is no place to enter a name or serial number, which causes alot of beginners to give up before trying, if they dont have any experience with this type of cracking.
Before we even hit Ctrl+D or start a disassembler, we look at the challenge with more determination to crack it than the author had trying to keep crackers out, (This is a must in all cracks). I cracked these programs out of necessity because I installed them as shareware and used up the trial period knowing that they had already been cracked and I was planning to apply someone's patch (yes, I am lazy sometimes). Needless to say the time period expired which renders our targets completely unuseable, which brings us to deal with cracking the time limitations to allow us to use the programs indefinitely.
I must add that due to the breakpoints we are setting, it is best to have no other programs running and to be fully disconnected from the internet before cracking with this method. GetLocalTime and GetSystemTime are frequently called in many programs and by the OS. The less you are doing the better.
As far as I am concerned this is the best and most useable Hex Editor available. For me this is an "essential tool". After installation, go to your control panel and adjust your date setting to simulate the program has been installed for a month or two (if i remember correctly one is sufficient). Run the program. Instead of loading up (and reading a file if you right clicked on one to run HEdit) it pops up with a message box stating that your trial has expired. All that you have at this point are 3 buttons: Order Info (a help file), uninstall, and quit. Select quit. My first guess was that upon installation some kind of date parameter was stored to make a compare each time HEdit is run, the second guess is that HEdit is checking the system date/time at startup. If date > 30 days after install = display message and quit.
A common windows API method 'GetLocalTime' is used in many cases (like this target). So we enter softice (Ctrl+D) and set a breakpoint on our possible call (bpx GetLocalTime), and run the program. Almost immediately SoftICE interrupts after GetLocalTime has been called. We see (in the green line at the bottom before our cursor line) that we are in Kernel32 (CrackZ - unsurprising since GetLocalTime is provided by Kernel32.dll), so we press F11 (most of the time only once) to return to the calling code (the green line should reflect that you are in HEDIT!). Now that we are in HEdit's code we should step through the code line by line (F10) and try to get a feel for what is taking place. We continue to press (F10) until the "trial expired" dialog box appears taking note of memory addresses.
Once you see the dialog appear quit and rerun HEdit and follow the steps above until you reach the address of the call that displayed the box. In this case it isn't hard to look back over the already executed code (Ctrl+Up Arrow) and spot some "interesting jumps". The one that caught my attention first was this:
:004032CF JG 0040330E
This could be the 'jump if greater' that compares the amount of days HEdit has been installed to the limit of days allowed. So we step through the program until we reach this line. Before execution we make a minor change to test our theory.
:004032CF JG 0040330E <-- Jump if greater.
to:
:004032CF JL 0040330E <-- Jump if less.
We have used the program over the allowed time so we know it will be greater therefore it will no longer jump anymore) - (CrackZ - might be better just to remove it altogether :) ). We make these changes by typing 'A 004032CF' and entering 'JL 0040330E' and pressing enter, followed by pressing escape to exit assembly mode. Then we execute our newly changed line of code by pressing F10, then return to the program (Ctrl+D) and observe the effect our changes had. As we can now see another (different) dialog box telling us our trial time is over although we can still select 'continue' and use the program. At this point we know we have found the fatal compare and jump.
However it would be nice to rid ourselves of the dialogs altogether. So we repeat the exact same steps above until we have patched the code to jump if less rather than jump if greater, press F10 to execute our patch, but this time we do NOT Ctrl+D back into the program. The next two lines that follow do another compare and jump if less than or equal to. Could this be the test to determine whether we show the 'friendly' nag box?.
To find out, instead of letting the code jump if less or equal (meaning we haven't exceeded our trial time) lets patch it so it makes the jump regardless of the outcome of the compare. Type 'A 004032d4' then enter an unconditional jump 'JMP 004032d4' press enter, then exit assembly mode by pressing escape. Ctrl+D back to the program and voila! No nag either.
Now that we have defeated the protection, we need to patch our executable file so our temporary changes become permanent. We load HEdit.exe into our disassembler (W32Dasm). After a short wait we select 'goto code location' in the menu and enter the address of our first patch location (004032CF). We see the 'JG' code here so we look to the lower right of our screen and get the byte offset of the instruction we need patched and write it down. Then move onto our second location. 'goto code location' (004032D4) and take note of the instructions byte offset also. Same story with our third location.
The ironic part of this crack is that we are going to use HEdit to patch HEdit so that we can defeat it's protection. Quit the disassembler. Make a copy of the executable (this is important since we cant save to a running file) and run HEdit (unless you have another Hex Editor to use, then this step can be skipped). Set our breakpoint (bpx GetLocalTime) patch our locations, clear breakpoints 'BC *' and return to the program. Once we are inside HEdit load our copy (where we will apply our patch) and goto our first location.
If using HEdit, specify the location in hexadecimal '0x004032CF'), at this location we should see the hex values '73 3D' which is our jump if greater. Change these both to '90' (no operation, rather than jump if less like in our test, so that it never jumps regardless if greater or less) so nothing is done here (no jumping), then proceed to the second one.
At the second location we should see '0F 8E' which we will change to '0F 83'. Now we have all our patches permanently changed in the executable, and after saving and running (or right clicking on a file and selecting HEdit) we have no more time limitation or nag screens bothering us to register. Now we can erase the original executable and rename our copy (I told you it was important) to that of the original.
However, we are not finished yet. If you set your clock forward again you will see that the evil request is back and that you can no longer run the program. This time if we set our breakpoint and trace the code, we will see that we are jumping at a location directly above where we made our first patch. The JS (Jump if Sign) instruction is jumping after a call and some maths (multiplication and some shifting). We know we dont want this to jump anymore so we simply NOP out this conditional jump also. Apply the changes to the executable using the steps outlined above.
Please understand that nopping out instructions is not the BEST way to crack. Many NOPS are easily detected, and you are more likely to run into trouble. But this is a beginner tutorial and if you can figure out better ways to make your patchs, by all means do it. If that is the case you are probably beyond having to read this anyway.
Most of the time after completing a crack, you dont want to distribute the entire patched executable, a far more efficient way is to distribute a small patch file. This way the end user can just run the patch on their already installed program and make the changes needed. I choose to do my programming in C/C++ (CrackZ - wise choice) and have included a program that can be compiled under Visual C++. The following code will patch our locations for HEdit (and CuteFTP if you simply change the offsets and the bytes) directly to the installed executable when run inside HEdit's directory.
//-----------CUT HERE-------------------
// File Patcher for Hedit 2.1.14 Written By Sixx.
#include
#include
#include
#include
int main(int argc, char **argv)
{
FILE *fp;
printf("\n");
printf("ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿\n");
printf("³ HEdit Crack, Written by Sixx. ³\n");
printf("³ ³\n");
printf("ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\n");
fp=fopen("HEdit.exe","r+");
if(fp==NULL)
{
cout << " ß Could not open file for patching...\n\n";
return 1;
}
// Patch our locations //
fseek(fp,0x26ca,SEEK_SET); // seek to location //
fputc(0x90,fp); // patch bytes //
fseek(fp,0x26cb,SEEK_SET); // seek to location //
fputc(0x90,fp); // patch bytes //
fseek(fp,0x26cf,SEEK_SET); // seek to location //
fputc(0x90,fp); // patch bytes //
fseek(fp,0x26d0,SEEK_SET); // seek to location //
fputc(0x90,fp); // patch bytes //
fseek(fp,0x26d5,SEEK_SET); // seek to location //
fputc(0x83,fp); // patch bytes //
fclose(fp);
printf(" ß Finished Patching!\n");
return 0;
}
//----------END---------------------------
This one is almost EXACTLY the same protection as HEdit. So we will go about cracking it in the exact same manner. After installing the program, go to the control panel and simulate a passing of a couple months by setting your system date ahead, then run the program. You will be presented with a request telling you that your evaluation period has expired. The only options you have are to select registration info (which is a help file of sorts) or quit.
We will use the same breakpoint here that we did for the last target. So before running the program we pop into SoftICE and set a breakpoint on GetLocalTime. Then exit SoftICE and run the program. SoftICE will break immediately. We need to press F11 until we get into CuteFTP's code, in my case I had to press 3 times. Once in CuteFTP's code we step through the program by pressing F10 until the nag screen pops up, paying attention to memory locations as we go. Once we have located the call that pops up our nag we rerun the program and stop stepping through when we have reached our call. Then use Ctrl-Up to look back over the code for any eyecatching jumps.
I immediately noticed the following.
:00412020 JLE 00412031
It is a good possibility that this is the 'compare -> jump if' that we are looking for. So once again we rerun the program and stop at our JLE. Type 'A 00412020' and enter 'JMP 00412020' hit enter, then press escape. Then pop out of SoftICE and see what effect we had on the program. We still get a request but this one is telling us that CuteFTP will be disabled 'soon' and the program is still useable. So we have in fact found our jump. Again, it would be nice to have NO requests popup, so we step through the program once more, patch our jump and continue stepping through until we see the next JLE. If you want to repeat the steps that we did for the first one (testing it) you will see this is the 'compare -> jump if' for our second nag.
So now that we have both the addresses we need patched, we load up CuteFTP into the disassembler, go to our memory locations and get our file offsets. Once we know what to patch, we load up CuteFTP into our recently patched HEdit, patch the locations as we did in the first one. I patched them both with an unconditional jump, which is changing the hex value at our byte offsets to 'EB' which is the hex for 'JMP short' After all the patching is done, run the program free of all nags and time limits forever.
As far as a patch program to make a crack, you can use the exact same code that I included for HEdit, just change the locations and bytes. Hopefully you have found this tutorial educational and easily understandable. I tried to write this file in plain english with very little ASM code snippets (to lessen confusion and avoid the "tech-skip" that happens when the reader skips important learning parameters when faced with cryptic assembly instructions).
This tutorial was aimed at even the most impatient newbies, and has hopefully served as an almost personal lesson. HEdit and CuteFTP are in my opinion (as I have already stated) excellent tools and needless to say, if you use them, BUY THEM (damn i feel like a hypocrite). The authors DO deserve their modest registration fee. Support the authors that support our cracking habit. Any questions or comments can be e-mailed to Sixx@bisc.com. I will try to respond to everyone's e-mail. Also if you prefer, I can often be found on #cracking4newbies (efnet). Look for more tutorials as time goes by, I am going to try to pay back my debt.
The TNO team (Prophecy, Alc, Kwai_Lo) and all the people that helped me learn (Qapla, Ghiribizzo, CrackZ, Fravia, TKC), and all the elite groups.
-Sixx