Time Trials Cracking

  • Upload
    vio99us

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

  • 7/28/2019 Time Trials Cracking

    1/5

    Cracking Time Trials, A tutorial by Sixx.------------------------------------------(word wrap on now)

    Required tools:SoftIceW32DASMHedit (or another hex editor)

    After a newbie cracker (myself included) moves on from the limited days of serial fishing and good guesses, the time arrives to start to delve deeper into foriegn code and put your first(?) time trial crack under your belt. In this tutorialwe will cover two examples of this type of protection. Our targets in this tutare HEDIT 2.1.14 and CuteFTP 2.6. After installing these programs there is no place to enter a name or serial number, which causes alot of beginners to give upbefore 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 withmore 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 sharewareand used up the trial period knowing that they had already been cracked and planning 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 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 GetSystem time are frequently called in many 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 methis 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 correctlyone is sufficient).Run the program. Instead of loading up (and reading a file if you right clickedon one to run hedit) it pops up with a messagebox 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 is that upon installation somekind of date parameter was stored to make a compare each time hedit is run, so the 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 target). 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 after getlocaltime has been called. We see (in the green line at the bottom beforeour cursor line) that we are in Kernal32, so we press f11 (most of the time onlyonce) to return to the calling code (the green line should reflect that you arein 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 making notice of memoryaddresses. Once you see the dialog appears quit and rerun hedit and follow the steps above until you reach the address of the call that displayed the box.

  • 7/28/2019 Time Trials Cracking

    2/5

    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 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 untilwe 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 therefore it wont make the jump anymore)

    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 ifless rather that jump if greater, press f10 to execute our patch, but this timewe 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 havent exceeded our trial time) lets patchit 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 s

    o our temporary changes become permanent. We then load the 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 offsetof the instruction we need patched and write it down. Then move onto our secondlocation. 'goto code location' (004032d4) and take note of that instructions byte 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 sothat 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). Setour 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')

    Ath 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'.

  • 7/28/2019 Time Trials Cracking

    3/5

    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 nor nag screens bothering us to register. Now we can erase theoriginal 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 requestor 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 math (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 patches, by all means do it. But if that is the case you are probably beyond havingto read this tut anyway..

    Most of the time after completing a crack, you dont want to distribute the entire 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 program and make the changes needed. I choose to do my programming in C/C++ and have included a program that can be compiled under Visual C++. The following code willpatch our locations for hedit (and CuteFTP if you simply change the offsets andthe bytes) directly to the installed executable when ran 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(" (Get the tutorial :) \n");printf("\n");

    fp=fopen("HEdit.exe","r+");

    if(fp==NULL){

    cout

  • 7/28/2019 Time Trials Cracking

    4/5

    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.6This 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 ofa couple months by setting your system date ahead, then run the program. You will be presented with a requestor telling you that your evaluation period has expired. The only option you have are to select registration info (which is a help file of sorts) and quit.

    We will use the same breakpoint here that we did for the last target. So beforerunning the program we pop into softice and set a breakpoint on getlocaltime (bpx 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 mycase I had to press 3 times. Once in cuteftp's code we step through the programby 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 requestor up we rerun the program and stop stepping through when we have reached our call. Then usectrl-up to look back over the code for any eyecatching jumps. Which I immediately notice the following.

    00412020 JLE 00412031

    It is a good possiblitiy that this is the compare->jumpif that we are looking for. So once again we rerun the program and stop at our JLE. Type 'a 00412020' andenter '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 istelling us that cuteftp will be disabled 'soon'. And the program is still useable. So we have infact found our jump. Again, it would be nice to have NO requestors popup, so we step through the program once more, patch our jump and continuestepping through until we see the next JLE. If you want to repeat the steps thatwe did for the first one (testing it) you will see this is the compare->jumpiffor 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 newly patchedhedit, patch the locations as we did in the first one. I patched them both with

  • 7/28/2019 Time Trials Cracking

    5/5

    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 free of all nags and time limits forever.

    As far as a patch program to make a crackfile, 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. Itried to write this file in plain english with very little asm code snippets (tolessen 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 hippocrite).The authors DO deserve their modest registration fee. Support the authors that support our cracking HABIT...

    Any questions or comments can be emailed to [email protected]. I will try to respondto everyone's email. Also if you prefer, I can often be found on #cracking4newbies (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 helped me learn (Qapala, Ghiribizzo, CrackZ, Fravia, TKC, many others), and all the leet groups...

    -Sixx