BoundsChecker time limit
("Persistent file protection")

by Harwi
(05 July 1997, slightly edited by Fravia)

---

Courtesy of Fravia's page of reverse engineering

Well... even Boundschecker uses a pretty simple "Cuckoo's egg" protection scheme... actually pretty deceiving, thinking how good in assembly coding the Numega boys should be...
Thanks Harwi! Discovering this you show us the way... and I notice a very interesting "zen" touch in your reverse engineering approach, btw :-)

How I did IT.


Reverse engineering
the Protection scheme of BoundsChecker 5


(Win95 14-day trial version)


 By Harwi, 4 July 1997.






I would say that the "second" hottest debugger in the windows/dos world 

is probably BoundsChecker (BC) from NuMega. I would also say that it 

directly follows -in importance- after our beloved SoftIce, from that 

same holy company.

From the moment I first saw BC version 4 on the Visual C/C++ version 4 CD  

(VC4), about a year ago, I loved it. 

For the people who don't know about it: BoundsChecker is a debugger for 

application developers, i.e. people writing programs using the 'normal' 

application programming interface (API) for Win95 or NT or whatever, 

depending on what for a platform they are targeting. I would draw a line 

between these programmers and those writing drivers (like VXD's in windows) 

and stuff like that, where there is more low-level (assembler) programming 

involved. 

There are versions of BC for Win95, NT and Dos, I think, maybe more.

(Bug: A Bug is -in computer language- an error or condition that crashes 

or at least prevents a program from running as intended. Most bugs are due 

to logical mistakes in the sequence of execution of statements. A debugger 

is a program that lets the programmer monitor the code being executed and 

gives him a chance to understand what is happening and what is going wrong.)



Conventional Debuggers, like theone you get with most compilers are nice 

tools indeed, they let you step through the code, change variables put 

breakpoints here and there and a lot more. 

The annoying thing about them is that you have to have some sort of idea 

or intuition) where your error is located, so that you can breakpoint 

there and understand what’s going wrong.

BC on the other hand does this work automatically, because it hooks each 

and every API call, pointer read and pointer write and so on. So you 

don't put any breakpoints anymore, you just run your program inside 

BC and BC will break whenever your program executes any error, and 

display the source code, together with relevant explanations. 

The responsable for theis brilliant tool is -as far as I know- Matt 

Pietrek, who was (or still is?) project leader for BC at NuMega (if 

you are reverse engineering anything at all you MUST have read his 

books :-) 

I must state here that I believe BoundsChecker absolutely worth its 

price, and should I ever use it for commercial purposes, I will 

purchase a copy!



Sadly enough the first demo I had, on the VC4-CD, was limited to 

debugging an application called Bugbench, that made the ugliest 

programming errors -that kind of errors that everyone who has 

ever done application development loves to find in her/his source 

code.

Too bad that I didn't know how to crack it at that time... I could 

not, because I hadn't yet learned enough about cracking.



When I came across Fravia's Page, about a month ago, I read +ORC's 

tutorial and a lot of the students' essays, and after reading, I 

tried to crack BoundsChecker and guess what: I got it. 

That was a great success for me :-) 



So, here comes the interesting part...




How I did IT. 



First I downloaded bc50_v(1).exe from http://www.numega.com.  

Download quickly! I don't know how long they'll keep it there after 

the publishing of this essay... (you'll be able to fetch it from other 

+crackers though :-)



Being all excited about this new "time limited" version, I installed it 

at once, without saving important system stuff, like the registry, and 

the various windows directory files... 

A mistake and a pity, because later I had to fetch another computer 

and re-install the same software again, in order to see which registry 

entries had been made and HAD NOT been removed by the uninstaller, a 

fact evident, since the time limit expiration did hold after 

uninstalling.



Unfortunately I made a second mistake, assuming that BoundsChecker 

saved the date information inside the registry. This is common with 

many programs, NOT with BoundsChecker! 

Therefore I didn’t backup the VERY IMPORTANT (and unfortunately huge) 

file list of both the windows directory 

and  the windows\system directory. 

Too bad - comparing the registry backup with the registry after the 

install didn't give me any clue... no suspicious looking entry at 

all. 

Not very smart! I had wasted the two machines I had available for 

my installations and still wasn’t able to just reinstall BC in order 

to use it after the trial period expires. That means only one thing: 

the date information must be hidden somewhere in ANOTHER file 

installed on my machine.



By simply uninstalling BC you will not reset your trial period anew. 

I found that you can play around with the system date, though, and 

in this way you'll be able to use BC as long as you want. 

But that’s not what I like, and of course for such kidding you have 

to remember the original install date, in order to be able to set 

the system date within the allowed 14 days, which is also neither 

really "elegant" nor nice.

I had to crack this target, I felt it :-)



What did I do? 

Using SoftIce I put a breakpoint on GetSystemTime API function.  

Then I started BC and ... nothing! BC is not calling GetSystemTime, 

how is that possible? Are they using some fancy stuff to get the 

date? I was puzzled. 

I load Bugbench and press the Run button, the Trial Dialog pops up. 

Still no call to GetSystemTime, I’m missing something here.

I went and got a coffee (I’m sorry Fravia! there were no cocktails 

around) and thinked about it. 

Lets try DialogBoxParamA, somewhere the target must open that 

dialogbox! 

I pressed Run again.

There we are! SoftIce comes up, I type ‘stack’, but no callstack 

is displayed, I don’t know what this means, maybe someone can 

explain it (?). 







I step through the system code to the next return.

That’s it I am now in TLOCK32.DLL, before I didn’t even know that 

TLOCK32 was used by BC because BC.EXE does not have an import 

section, so you can’t see what DLL’s are used. The DLL’s in the 

BC directory don’t say what they import either. To see the static 

imports of .exe and ...dll files, you can use the “Quick View” 

that comes with windows. 

If disassembled BC.EXE still does not have any explicit reference 

to TLOCK32.DLL, so it is either dynamically loaded or loaded by 

some other DLL (BTW in the disassembly one can see a lot more 

imports then the “Quick view” is displaying).



Where is TLOCK32.DLL… search, aha! It’s in windows\system, possibly 

a file that is not removed by the uninstaller.

But since I’m here let’s see what the dialog does. I put a breakpoint 

one line in front of the call to DialogBoxParamA (and GO); back 

in windows I close the dialog with Cancel and open it again with 

Run. In SoftIce again: some pushes before the call to DialogBoxParamA, 

there is the address of the callback for this dialog pushed, I put 

a breakpoint on the callback and remove the one inside DialogBoxParamA. 

Go! And back in SoftIce inside the dialog callback function. BC must 

now initialize the controls to display how far in the trial we are. 

I step through the code and find some GetDlgItem and SetWindowTextA 

calls and then a suspicios looking section where a memory location 

is compared to 1,2 and 4. That looks like a flag! 

The corresponding jumps go to quite large blocks of code inside the 

callback, maybe I am lucky and they do something to the state of the 

application here. I remove all breakpoints and set one right in 

front of that compare section. GO! Back in windows (after closing 

the dialog with Cancel) I advance my system date by two days. Press 

Run... SoftIce pops up… the flag (loaded to EAX) holds a 2, GO! “12 

Days left” in the blue bar and the message inside the box saying “12 

Days left…”. Cancel and again Run… SoftIce, EAX is still 2, I change 

to 1. GO!

GOTCHA! 14 Days left! Beauty!

Cancel, and advance the date by one year, Run ...  back in SoftIce 

the flag (EAX) is 4, GO! “Trial expired”, no Blue anymore, Cancel! 

And Run… SoftIce: The Flag is still 4, change it to 1, GO! But now, 

still “Trial expired” what’s that? I thought I had it, Cancel and 

Run ... now the flag is 2, what’s that? GO! Ahhh! Blue! and “14 Days 

left”. And now press OK, the Bugbench starts and I try some Errors, 

it works BC displays them. So it is only a matter of the initialization 

of the dialog controls. When the trial is over you can set the flag 

to 1 and the trial will begin anew. All you must do is close the dialog 

and reopen it again; you will get a new trial period.



Now I disassemble TLOCK32 and here I find the answer why I didn’t 

catch the GetSystemTime calls, Simple! GetSystemTime is not called 

- they call GetLocalTime. Something to remember.



So what do I do with that flag? 

I change from:

	:100029EA 7417	je 10002A03    // New trial

crk	:100029EA 7517	jne 10002A03



Start BC again, load Bugbench and press Run … and … and … and... 

NOTHING! No dialog no starting Bugbench, nothing!

Why that? Maybe a there is a checksum? I look again at the 

TLOCK32.ASM file. 

Then I change:

	:100029EC 83F802	cmp eax, 00000002     // Whithin trial 

crk	:100029EC 83F801	cmp eax, 00000001 





Start BC, load Bugbench and press Run, here we go, the dialog 

pops up and after OK Bugbench starts.

I play around with some dates and it works fine.

Here is the section where the flag is compared completely.

     :100029E2 A198FA0010    mov eax, [1000FA98] // This seams to be a sort of flag 

     :100029E7 83F801        cmp eax, 00000001   // new trial

     :100029EA 7417	     je 10002A03

crk  :100029EA 7517          jne 10002A03      	 // checksum is 1+

     :100029EC 83F802        cmp eax, 00000002   // Whithin trial 

crk  :100029EC 83F801        cmp eax, 00000001     

     :100029EF 0F848F000000  je 10002A84         //also  for checksum -1	

     :100029F5 83F804        cmp eax, 00000004   // trial is over

     :100029F8 0F8466010000  je 10002B64        

     :100029FE E981010000    jmp 10002B84  





I think this approach has its own beauty because it displays the 

protection dialog and thereby lets you remember the great victory 

of the past. But when you start your compiler, the dialog is also 

displayed and since we know now where BC stores its state, lets see 

if we cannot get ride of that dialog completely. 

The questions that come to mind are (at least to me): 

What about the flag being equal 3? What does the flag value 3 

tell BC about its state? 

Some playing with the flag (and SoftIce) soon gives the friendly 

answer: 

YES! 3 means, BC has been purchased. Some more playing with memory 

read/write breakpoints gives the location where it is easy to 

change a byte and a second to make the checksum happy. Here is 

what I changed so that there is no dialog popping up anymore 

(still inside TLOCK32.DLL):



	…

	:100011F9 DFE0	fbld tbyte ptr eax

	:100011FB F6C401	test ah, 01



/// and here I crack for no dialog

	:100011FE 752e	jne 1000122e

crk	:100011FE 7500	jne 10001200 // checksum difference is –2e



	:10001200 BE04000000	mov esi, 00000004

crk	:10001200 BE03000000	mov esi, 00000003 // checksum difference is –2f



	:10001205 EB27	jmp 1000122E

	:10001207 BE04000000	mov esi, 00000004

crk	:10001207 BE052e0000	mov esi, 00002e05 // for checksum only , back to 0



	:1000120C E8CF090000	call 10001BE0

	:10001211 6A00	push 00000000

	:10001213 E8F8010000	call 10001410



Of course there are a lot more ways to crack this, mine is just one 

of them. I must also say that I have been extremely lucky to find 

the code (with the flag-compare) inside the dialogs callback fairly 

soon. If I hadn’t, I might not have gone back to the callback. 

But, to speak with +ORC, sometimes you need some Zen.



Someone may ask, where the installation date is stored... I must 

admit that I still don’t know that, but I also don’t care much, 

because I’m not going to break into my locked main door when my 

bathroom window is open.



Harwi, 05 July 1997

homepage links anonymity +ORC students' essays tools cocktails
search_forms mailFraVia

Is reverse engineering legal?