So you didn't have the courage to read the above mentionned essay? You lazy wannabe cracker! Then i'll summarize the situation for you: the problem with timelock3+ is that it rips out some code of the app, patching it at runtime
if all the lights are green! Needless to say that this crap encrypts
the missing bytes, so u won't find this "ready_to_patch" in a dummy dll or so...Marigold had come to the conclusion that the missing snippet had to be copied (but he didn't explain how) then patched directly onto the exe. So I understood "copied by hand". What was in his case acceptable, because the snippet wasn't that long ("only" 16E bytes), is here impossible: as you'll see, an improvement of tl31inj.dll (among others?) is that the "Bag of bytes" (how silly) is growing. For this app it ranks 0x716 (=1814) bytes. My aim is to explain how to let bloated timelock do its dirty work, and then gently stop it for saving the code to a file.
Netscantools seems to be a useful tool for those who want to know more about networks (although some of the functionnality it offers already exists under MSDOS, like "tracert", but this is not the point). Doesn't seem that bloated & then deserves to be bought if U really intend to use it. Anyway you won't see no ready_made crack here,cause we aren't stealers, are we ?
Back to the topic. A few lines from the dissasembled file of nststd.exe will quickly explain it:
//******************** Program Entry Point ********
:004FA000 FF74240C push [esp+0C]
:004FA004 FF74240C push [esp+0C]
:004FA008 FF74240C push [esp+0C]
:004FA00C 68D879A084 push 84A079D8
:004FA011 68C1FED07D push 7DD0FEC1
:004FA016 68A29C5D1E push 1E5D9CA2
:004FA01B FF15D4A24F00 call dword ptr [004FA2D4] ---> this is the infamous call
:004FA021 68FFFFFFFF push FFFFFFFF
:004FA026 FFD0 call eax ---> when returning eax contains the correct adress,
which is the target "real" entry point
:004FA028 C20C00 ret 000C --> yes, thats all!
As one can easily experiment, bypassing 4FA01B leads to nothing, even with the correct eax, coz this is precisely where tlock will patch. I didn't want to delve into the "heavy" tlock encryption, crc checking (it checks its integrity, as the target's one), all that boring stuff...Seems that it'd be easy to let it do the job :-)
Here we have two possibilities:
1)you have a working trial version, then jump over the 50 next lines.
2)Like me, you "burnt" it on the first trial day by pushing the date 1 month ahead, just to see what happens, when restoring back the clock. (No, it's expired for good :=)
So up to work with tl31inj.dll. We have at first to bypass the dialogbox with the "try" button grayed for ever. With Sice we find it easily:
:100081FF 6A00 push 00000000
:10008201 A164A30310 mov eax, dword ptr [1003A364]
:10008206 6840830010 push 10008340
:1000820B 6A00 push 00000000
* Possible StringData Ref from Data Obj ->"TL_DLG_MAIN"
|
:1000820D 687CF60310 push 1003F67C
:10008212 50 push eax
* Ref To: USER32.DialogBoxParamA, Ord:008Eh --> when ret.,eax=1 if pressed "try first" |
:10008213 FF1530960410 Call dword ptr [10049630]
:10008219 8BF8 mov edi, eax
So we bpx 10008213 (care with relocation, on my pc it was 508213...)
when sice pops,F10, press cancel, then r eax=1 to simulate the "try_it" push.
*** useful tip: don't try to patch at 10008213 to gain time. As you can see, this is an absolute adress, the loader will PATCH after you, in case of relocation (this is highly probable), causing a highly probable crash....Doing this right you have to patch the relocation table. More on this at the end.
*** end of useful tip.
Infortunately, this is not enough, as marigold noticed with the previous version. Now we are stuck in a routine beginning at 1002B020:
* Referenced by a CALL at Addresses: (a hundred of these follow)
||
:1002B020 83EC20 sub esp, 00000020
:1002B023 B908000000 mov ecx, 00000008
:1002B028 56 push esi
:1002B029 57 push edi
:1002B02A BE28730310 mov esi, 10037328
:1002B02F 8D7C2408 lea edi, dword ptr [esp+08]
:1002B033 F3 repz
:1002B034 A5 movsd
:1002B035 8B44242C mov eax, dword ptr [esp+2C]
:1002B039 8B4C2430 mov ecx, dword ptr [esp+30]
:1002B03D 8D54241C lea edx, dword ptr [esp+1C]
:1002B041 89442420 mov dword ptr [esp+20], eax
:1002B045 8B442418 mov eax, dword ptr [esp+18]
:1002B049 52 push edx
:1002B04A 8B54240C mov edx, dword ptr [esp+0C]
:1002B04E 50 push eax
:1002B04F 894C242C mov dword ptr [esp+2C], ecx
:1002B053 8B4C2414 mov ecx, dword ptr [esp+14]
:1002B057 51 push ecx
:1002B058 52 push edx
* Reference To: KERNEL32.RaiseException, Ord:01C9h
|
:1002B059 FF15F4950410 Call dword ptr [100495F4] -->i'm afraid we won't go back from here :-)
:1002B05F 5F pop edi
:1002B060 5E pop esi
:1002B061 83C420 add esp, 00000020
:1002B064 C20800 ret 0008
To get out of this trap, just bpx 1002B020, restart the whole thing and when it pops assemble a: ret 0008 (remember a "hard" patch wont work coz of the CRC check...here causing a page fault...How mighty they are at "Previewsoft" !)
Now whoever you are, expired or not, the app is working, (although weak cracked !). By pressing F12 one or two times you should be brought back in 4FA021 (look above) just before the damned call eax. As you can see, eax is now 43D680 and this location contains no longer bogus code...
We restart then the whole process with a bpm 43D680, just to see how & where the big patch is aplied. We land here:
* Reference To: KERNEL32.ReadProcessMemory, Ord:01D8h
|
:10015C23 FF158C940410 Call dword ptr [1004948C]
:10015C29 85C0 test eax, eax
:10015C2B 740B je 10015C38
.....
..... some code here
.....
:10015C6A 50 push eax
:10015C6B 8D8D48FFFFFF lea ecx, dword ptr [ebp+FFFFFF48]
:10015C71 E84A140000 call 100170C0
* Referenced by a Jump at Address:10015C5C(C)
|
:15C76 8D45D8 lea eax, dword ptr [ebp-28]
:15C79 50 push eax
:15C7A 8B8548FFFFFF mov eax, dword ptr [ebp+FFFFFF48] ;this is the length = 0x716
:15C80 50 push eax
:15C81 8B854CFFFFFF mov eax, dword ptr [ebp+FFFFFF4C] ;where to fetch the patch
:15C87 50 push eax
:15C88 8B4DD4 mov ecx, dword ptr [ebp-2C] -->where to apply (=43D680)
:15C8B 51 push ecx
:15C8C 56 push esi
* Reference To: KERNEL32.WriteProcessMemory, Ord:0283h
|
:10015C8D FF1588940410 Call dword ptr [10049488] --> go ahead, patch it!
:10015C93 85C0 test eax, eax
Now we have all the elements to kick this timelock crap out for good: press F12 to get up to 4FA021. It's quite clear: we want to save 716h bytes from 43D680 to a file. How proceed ? Well let's assemble a small program using win32 API that'll make it for us !
As it seems, the code over 4FA028 is bogus. So We'll work here.
a 4FA040
then type the following instructions: (i rely on win32 help & include files for the pushes with creatfilea and writefile)
push 0 ; bogus but necessary
push dword ptr 80 ; file_attributes_normal (don't forget dword ptr or
;it will push a "signed" FFFFFF80...I spent 2 hours on this bug!)
push 02 ; create_always
push 0 ; null (security field)
push 0 ;file is not shared
push 40000000 ;file is write only
push 004FA200 ; the adress of the name of the file.
call kernel32!createfilea
push eax ; eax=handle. We push it for later closehandle
push 0 ; a dummy one
push 004FA100 ; where to store the number of bytes written
db 68 16 07 00 00 ; this is:push dword ptr 0716, I didn't manage a "real dword" push!
push 43D680 ; we save from here
push eax ; the handle
call kernel32!writefile
call kernel32!closehandle ;the handle is still on the top of the stack
push ff
jmp 43D680 ; bye bye!
Well, just type eb 4FA200 and enter the full pathname of the file where the data will be stored, for example "C:\bigpatch",0
& now.... g=4FA040.
I hope your HD hasn't gone formatting, mine is OK :-)
************************
Well, what are you gonna do with this bigpatch file ?
Some ideas: Use hexworkshop's cut&paste facilities to replace the 1814 bogus bytes at offset 3D680 (in nststd.exe now) with bigpatch; or write a small asm program that'll do it for you. Is the app fully functional now?
No, don't forget to patch the entry point with a jmp 43D680 (offset EF400 : E9 7B 36 F4 FF)
Special bonus: Silly banner will be cleared with 00 00 patched at offset 32B81.
Finally, a word to our fellows at "PREVIEWSOFT":
Dear programmers, for the next version of timelock, (and for us to enjoy for some time again with your expensive gadget :-), you should take into consideration using the date of installation in your encryption algos, this is one weak point of the scheme, coz it allows us to restart the app even when the expiration is reached ! So go back to work and next time please, be more modest in your adds ....
I wont even bother explaining you
that you should BUY this target program if you intend to use it for a longer
period than the allowed one. Should you want
to STEAL this software instead, you don't need to crack its protection
scheme at all: you'll
find it on most Warez sites, complete and already regged, farewell.
You are deep inside Fravia's page of reverse engineering,
choose your way out:
Back to timelock
homepage
links
search_forms
+ORC
students' essays
academy database
reality cracking
how to search
javascript wars
tools
anonymity academy
cocktails
antismut CGI-scripts
mail_Fravia
Is reverse engineering legal?