Cracking Time Trials, A tutorial by Sixx.

-----------------------------------------(word wrap on now) Required tools: SoftIce W32DASM Hedit (or another hex editor) After a newbie cracker (myself included) moves on from the limited days of seria l fishing and good guesses, the time arrives to start to delve deeper into forie gn code and put your first(?) time trial crack under your belt. In this tutorial we will cover two examples of this type of protection. Our targets in this tut are HEDIT 2.1.14 and CuteFTP 2.6. After installing these programs there is no pl ace 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 crtl-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 plan ning to apply someone's patch (yes, I am lazy sometimes). Needless to say the ti me period expired which renders our targets completely unuseable, which brings u s to deal with cracking the time limitations to allow us to use the programs ind efinitely. I must add that due to the breakpoints we are setting, it is best to have no oth er programs running and to be fully disconnected from the internet before cracki ng with this method. GetLocalTime and GetSystem time are frequently called in ma ny programs and by the OS. The less you are doing the better. Our first target: Hedit 2.1.14 As far as I am concerned 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 sim ulate 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 messagebox stating that your trial has ex pired. All that you have at this point are 3 buttons: order info (a help file), uninstall, and quit. Select quit. My first guess is that upon installation some kind of date parameter was stored to make a compare each time hedit is run, so t he second guess is that hedit is checking 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 targ et). So we enter softice (ctrl-d) and set a breakpoint on our possible method (b px getlocaltime), and run the program. Almost immediately softice interrupts aft er getlocaltime has been called. We see (in the green line at the bottom before our cursor line) that we are in Kernal32, 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 lin e by line (f10) and try to get a feel for what is taking place. We continue to p ress (f10) until the "trial expired" dialog box appears making notice of memory addresses. Once you see the dialog appears quit and rerun hedit and follow the s teps 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) and spot some "interesting jumps". The one that catches my attention first is t his: 004032CF JG 0040330e This could be the 'Jump If Greater' that compares the amount of days hedit has b een 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. change: 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 th erefore it wont make the jump anymore) We make these changes by typing 'a 004032cf' and entering 'jl 0040330e' and pres sing enter followed by pressing escape to exit assembly mode. Then we execute ou r 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 'conti nue' 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. S o we repeat the exact same steps above until we have patched the code to jump if less rather that 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 anoth er compare and jump if less than or equal to. Could this be the test to determin e whether we show the 'friendly' nag box? To find out, instead of letting the co de jump if less or equal (meaning we havent exceeded our trial time) lets patch it so it makes the jump regardless of the outcome of the compare. Type 'a 004032 d4' then enter an unconditional jump 'jmp 004032d4' press enter, then exit assem bly 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 s o our temporary changes become permanent. We then load the hedit.exe into our di sassembler (w32dasm). After a short wait we select 'goto code location' in the m enu 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 that instructions byt e offset also. Same story with our third location. The funny 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 e xecutable (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 wil l apply our patch) and goto our first location. (if using hedit, specify the loc ation in hexadecimal '0x004032cf') Ath this location we should see the hex values '73 3d' which is our jump if grea ter. Change these both to '90' (no operation, rather than jump if less like in o ur test, so that it never jumps regardless if greater or less) so nothing is don e 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 sav ing and running (or right clicking on a file and selecting hedit) we have no mor e time limitation nor 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 o f the original. However, we are not finished yet. If you set your clock forward again you will s ee that the evil requestor is back and that you can no longer run the program. T his time if we set our breakpoint and trace the code, we will see that we are ju mping at a location directly above where we made our first patch. The JS (Jump i f Sign) instruction is jumping after a call and some math (multiplication and so me shifting). We know we dont want this to jump anymore so we simply nop out thi s conditional jump also. Apply the changes to the executable using the steps out lined above. Please understand that nopping out instructions is not the BEST way to crack. Ma ny nops are easily detected, and you are more likely to run into trouble. But th is is a beginner tutorial and if you can figure out better ways to make your pat ches, by all means do it. But if that is the case you are probably beyond having to read this tut anyway.. Most of the time after completing a crack, you dont want to distribute the entir e patched executble, a far more efficient way is to distribute a small patchfile . This way the end user can just run the patch on their already installed progra m and make the changes needed. I choose to do my programming in C/C++ and have i ncluded 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 ran inside hedit's directo ry. //-----------CUT HERE------------------// File Patcher for Hedit 2.1.14 Written By Sixx. #include #include #include #include <fcntl.h> <fstream.h> <stdio.h> <string.h>

int main(int argc, char **argv) { FILE *fp; printf("\n"); printf("\n"); printf(" Hedit Crack, Written by Sixx! \n"); printf(" (Get the tutorial :) \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--------------------------That's it for Hedit... Our Second target: CuteFTP 2.6 This one is almost EXACTLY the same protection as hedit. So we will go about cra cking 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 wil l be presented with a requestor telling you that your evaluation period has expi red. The only option you have are to select registration info (which is a help f ile of sorts) and 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 (bp x getlocaltime). Then get out of softice and run the program. Softice will break immediately. We need to press f11 until we get into cuteftp's code, which 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 locati ons as we go. Once we have located the call that pops up our requestor up we rer un 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. Which I immediate ly notice the following. 00412020 JLE 00412031 It is a good possiblitiy that this is the compare->jumpif that we are looking fo r. 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 requestor but this one is telling us that cuteftp will be disabled 'soon'. And the program is still useabl e. So we have infact found our jump. Again, it would be nice to have NO requesto rs 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->jumpif for our second nag. So now that we have both the addresses we need patched, we l oad up cuteftp into the disassembler, go to our memory locations and get our fil e offsets. Once we know what to patch, we load up cuteftp into our newly 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' After all the patching is done, run the program f ree of all nags and time limits forever. As far as a patch program to make a crackfile, you can use the exact same code t hat 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 i mportant learning parameters when faced with cryptic assembly instructions). Thi s tutorial was aimed at even the most impatient newbies, and has hopefully serve d as an almost personal lesson. Hedit and CuteFTP are in my opinion (as i have already stated) excellent tools a nd needless to say, if you use them, BUY THEM! (damn i feel like a hippocrite). The authors DO deserve their modest registration fee. Support the authors that s upport our cracking HABIT... Any questions or comments can be emailed to Sixx@bisc.com. I will try to respond to everyone's email. Also if you prefer, I can often be found on #cracking4newb ies (effnet). Look for more tutorials as time goes by, I am going to try to pay back my debt : ) Greetings must go to: the TNO team (Prophecy,Alc,Kwai_lo), all the people that h elped me learn (Qapala, Ghiribizzo, CrackZ, Fravia, TKC, many others), and all t he leet groups... -Sixx