Netscantools3.1 trial (What's new with timelock3.1 ?)
Saving the missing code at run_time
student
Timelock
23 April 1998
by JaZZ
Courtesy of Fravia's page of reverse engineering
fra_0102
980423
JaZZ
0100
TL
PC
Whatta style! Here we have a "new" contributor that goes straight to the point. Timelock busting once more! And a little windoze routine-patch, everything very well explained, even if you could not care less about netscantools, it's worth downloading it IN ORDER TO FOLLOW THIS ESSAY. Crack the 'last' timelock protection scheme inside it and then throw it away.
Ah yes, no beginners here.
Enjoy! Whatta style!
There is a crack, a crack in everything That's how the light gets in
Rating
( )Beginner (x)Intermediate ( )Advanced ( )Expert
NO beginners

Well I didn't know the existence of these "timelock" goodies when i targeted Netscantools. So ladies & gentlemen, i am very proud to contribute to the demystification of quite an overrated crap : tl3*inj.dll. Just have a check on their website Here (previewsoft), & u'll see what I mean: very cracker-intimidating ! Well, let's go on, poor little crackers that we are, against the brutality of such schemes. But it might be advisable to read marigold's "virginity restored" before.
Netscantools3.1 trial (What's new with timelock3.1 ?)
Saving the missing code at run_time
Written by JaZZ


Introduction
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.


Tools required
Our beloved Softice, f'course.
Wdasm89.

Target's URL/FTP
You'll find it here: www.nwpsw.com
the name is nst31.exe for those who prefer ftp search....
for info tl31inj.dll is 459264 bytes.


Essay
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 :-)
************************


Final Notes
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 ....
Ob Duh
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:

timelock
Back to timelock

redhomepage redlinks redsearch_forms red+ORC redstudents' essays redacademy database
redreality cracking redhow to search redjavascript wars
redtools redanonymity academy redcocktails redantismut CGI-scripts redmail_Fravia
redIs reverse engineering legal?