Folder Guard v4.11 Crack
========================
 

1) Introduction

2) The Essay

3) Last Words

4) Contact
 
 

1) Introduction
    ---------------
 
 

Folder Guard is basically a protection program that prevents you (or anyone else)
from deleting any of the files/folders you have specified. You can put quite a
big "lock" on them and i must say that it does a very good, of course i have not
*REALLY* tried to get past the protection but i think its enough for most users out there.

You can find this and other great programs (Singularity is one of them) at
http://www.winability.com - they are all pretty small and download is fast.

2) The Essay
    ---------------

So, without further delay, i will now show you how i got a valid serial for my name...

I assume that already have found the registration window and entered something
(i used TheWhiteRaven, 1 Licensed copies and for a serial the good old 12345678)
and probably pressed Register just to see how it behaved. If so you have also
already noticed that the "wrong code" message was displayed using the API
MessageBoxA, which to me is very interesting - i always try to attack the program
from the wrong direction, backwards - so i put a breakpoint on it and sure enough,
SoftICE appeared when i pressed Register again.

But as you can see we are inside the API, lets use F11 to leave and return to
Folder Guard.
Now i do as i almost always do, i have a look around the code that has displayed
the "wrong code" message to see if i can find some obvious JZ/JNZ jumps that
might help me find where it decides that the serial i entered is wrong...but here i
didn't find anything at all that looked like that. No worry, just pressing F12 and then
have a new look might solve the mystery...still nothing, just "common" code that
doesnt seem to involve anything special.

Lets have F12 a third go and...voila! Now we have just left a call at 1001460C
and below us is a GetDlgItemInt and SetFocus call, but im more interested in
what he have above us - some JZ and JNZ jumps that look quite interesting.
Why you might wonder? Well, look at which addresses they jump to...they jump
past the call that presents the "wrong code" to us.
This is all i have to know right now, any jump that jumps past the "wrong code" very
often is a jump that gives the "good code" message :)

We can test out teory by first clearing our old breakpoing and then place a new
one the first JZ jump, this whould be at address 100145E4, and then play with them
using the R FL Z command to see if one of them might do what we hope it does.
Go ahead and try...

...and now you´re done. Found anything interesting...? I certainly did, heres how the
jumps work:

First jump          : nothing, at least nothing obvious - it just seems to reach the RET
                          as quick as it possibly can.
Second jump     : "good code" appears! this is what we wanted, now we know that
                          we are in the right place of the code...
Third jump        : we are informed of using a "old code", this might be useful if
                         someone wants to get a code for a older version but this is
                         useless to us Lets concentrate on the second jump we tested, this
                         is how it looks:

CALL 10015664

TEST EAX,EAX

JNZ 1001467C

And if you know your assembly you have already understood this code, but i´ll
tell you anyway: (1) the first is just a call to some functions elsewhere inside the
program to be executed, (2) secondly it tests EAX with EAX and finally (3) if it isnt
zero then the jump will be taken and we have a good serial.

So what makes it chose either 1 or 0 to return from the call? We´ll just have to
step inside to and have a look, wont we? So be brave and press F8 to enter the
call... :)

Nothing to special about this piece of code, heres the basic layout:

(i have changed it a little but only to make it easy to understand)

CALL 10015692

TEST AX,AX

JNZ Good_Serial
 

CALL 10015458

TEST AX,AX

JZ Bad_Serial
 

CALL 10015472

TEST EAX,EAX

JZ Bad_Serial
 

CALL 1001562C

TEST EAX,EAX

JZ Good_Serial
 

Bad_Serial:
 

MOV EAX,0

JMP Exit
 

Good_Serial:
 

MOV EAX,1
 

Exit:
 

RET
 
 

Hope you get this, it looks a little messy but just look at it from SoftICE and
you will get the picture...

As you already know we of course want the program to reach the Good_Serial
section by taking the correct jumps, and now we have two choices - either work
on the first one that will jump to Good_Serial at once or try to attack those other
three calls that are somehow connected.

I choosed the last one, the three connected calls, as my target - of course you
can always try to see what the first one does but as these three works just as
well i dont care much for which road i take towards the goal. So step into the
first (of three) calls and see why it doesnt think its a good serial...not much here,
step into the call that exists there again and see how it looks inside...interesting.
At 10014D43 is a CMP CL, [EBP+0C] and just below a common JNZ jump.
Lets see what it is that it compares, a quick "D EBP+0C" and "? CL" will give us
the answer to all our questions. It compares 'F' with the first character in our serial
and if they fail we will take the jump, we´d better do as it wants, right?

Make the first character of the serial a 'F' and run it again...now we get past that
check but fail on just a little bit down, 10014D67, and now its the second character
it doesnt like. Instead of 2 a 6 will fit much better, make the required changes
and try it again...*sigh* - even more checks. But they look easy enough, the third
character is a 0 and the other two are hardcoded values and always should read
9 and 8.
Make the changes and continue reading...

Now you should have a serial looking like this: F6098678, and it should pass right
through the first of three calls, right? Wrong! Try it you will see for yourself...the
compares are different?!? ...this was not what i was expecting to see.
Lets try again and change them so they are good and see if they change
again...for me only the second and third character are failing the compare - now
they should read 2 and 6, whats happening?

Lets try again now and see if we can pass the TEST EAX,EAX after the first
call...yes!

Now it works, so lets forget what happend before and continue on to the second
(of three) call to see what is going on inside...enter the new call...and look at all
the instructions inside. Luckily we dont have to bother about them right now as we
are currently only looking for new some CMP´s that we can "play with" :) And there
are two of them inside this call, at the bottom, so F10 you way through the code
(and ignore the CMP EAX,10) until you reach the CMP [ECX+EBP-1E], AL instruction.
Its just the same as the other ones, now its the 7 that suppost to be a 6 - do it and
move on...hey! Now we cant get past the first call again, one of the compares must
have changed...again...but now i think i know why - lets try and change back
the 6 to a 7 and run it...aha.

It works just as i thought, apparently those two first bytes in the serial is some sort
of checksum for the rest of the serials characters added together. And if we just
change on of them the checksum is also changed - thats whats causing the compares
to fail.

So for now on we must remeber that whenever we change something we will have to
go back and change the second and third byte in the serial to make the checksum
check :)

Good! Having solved that little problem we can continue where we left off, just
repair the checksum so it accepts the 7-to-6 change, by looking for CMP´s and
making them valid.

Since the 6 check now works we will jump over the RET at 10014E0E and face the
next CMP we must "play with". And now its the last character, 8, thats going to be
substituted for a 2 that will do the job. You might notice that there isnt any JZ/JNZ
after the CMP - but thats only because its been "hidden", its replaced with
a SETZ CL function that does just the same but only it doesnt jump :)

And now our work on this call is done, as you can see we are now not taking the
jump to Bad_Serial anymore but continues into the third one...and we can leave it
just as quick :)

The third call will return that the serial is valid and jump past the Bad_Serial, thus
it is now a fully working valid serial - cool...

And now our work here is done, well, if we wanted we could have investigated
that first call as well but i dont feel like it - i have a valid serial for a program i
probably never will use and thats fine with me :)
 

3) Last Words
    ----------------

This was a very interesting and funny crack to do, especially that part with the
checksum was a very good idea i must say. At least the author has tried to make it
somewhat difficult to crack but not too hard - all this took me 30-40 minutes...
 

4) Contact
    ------------

In case you have any comments, questions or complaints you can e-mail me at

 TheWhiteRaven@StarTrekMail.Com

or visit my home on the WWW at

 TheWhiteRaven.Cjb.Net
 

Enjoy!

- TheWhiteRaven (1999-09-15)