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
You are deep inside Fravia's page of reverse engineering,
choose your way out:
homepage
links
anonymity
+ORC
students' essays
tools cocktails
search_forms
mailFravia
Is reverse engineering legal?