Log in

View Full Version : serial # and checksum problem


halfcrazed
March 17th, 2006, 01:44
I'm going to try real hard to not get the "go read the #$#@#$% FAQ" newbie response, so here it goes....

The software I'm trying to "reverse" requires two serials and a checksum value. When you open up the registration box, all it says is copy and paste all six lines from where ever you got the license info. I fed it some garbage and found it in SoftICE with
s 23:0 L -1 "randomgarbage"
then I bpm on the address, got the address and found my way into OllyDbg.
I set a breakpoint on the address, enter some garbage in the reg window again and hit the breakpoint. I followed the dump and set a memory break point in olly and followed it. To make a long story short, I found the structure of the six lines to be
User:
Addr1:
Addr2:
Code1:
Code2:
Chksm:

Hopefully the above information will let people know I'm not completly stupid and have put effort into this.

The program doesn't care what you put in for user and addr's as long as User:, Addr1:, and Addr2 is in front of it. Judging from my notes, at some point I determined Code2 to be based off of User. Yet, I never could fish out the serial, it keep going into lstrcmpiA and I couldn't see it (Scotch may be to blame for this). Eventually I found where it got pissed that I didn't have good codes in. CMP EAX, 10 then a JNZ to an address to being the "no dice sucker" window process. I simply changed that to CMP EAX, EAX to get around it hoping I would get lucky. I was wrong. When it gets to the checksum rountine, I can see what it wants, Uz in the case of the garbage I kept feeding it. Even after giving it the value it wanted, I kept getting the following problem. It gives me an error saying my key was only good for free upgrades until 12/05/1617. Too bad I can't change the clock that far back. I chased the date and changed it before it went into DosDateTimeToFileTime API. Changed the value on the stack it was giving it to a good date, but no dice. I found some keys and checksum for an old version, gave it that and it never went into the DosDateTimeToFileTime API. But it got mad because the keys are for an older version and my User.txt didn't jive with it. My guess is its calculating a date someone in the checksum routine maybe, but I can't find it. My question is, has anyone ever delt with a program like this? I'm fairly new to cracking and this is my first. Should I try to go back and find the serials it wants? Where in the hell would it be calculating the value its using for the 12/05/1617 date. I think if I could find where it was deciding that, I might be home free, but I can't find it. Any nudges in the right direction would be greatly appreciated. I'm determined to complete this.

LLXX
March 17th, 2006, 02:37
You might want to try an easier keygenme first, to see how your abilities are:
http://www.woodmann.com/forum/showthread.php?t=7783

In any case, CMP EAX 10 looks like a length check to me. One of the values is supposed to be 10 (hex or decimal) characters long.

My recommendation is to disassemble your program completely in IDA, as it is often much easier to carefully examine the flow of the program in a more relaxed state of mind than when you're tracing through it while it's running. This way you can find and document the algorithm such that you can keygen it.

I'd guess that this algorithm calculates a date from code1 and code2 (with possibly other information), while chksm is calculated on all the fields except itself, and which is verified against.

Admiral
March 17th, 2006, 09:59
It seems like you're doing well so far.

LLXX is right about using a disassembler. The debugger is your primary tool for reversing just about anything, but once you've decided upon writing a keygen and you know exactly where the validation routine is, you should be thinking about using your disassembler. IDA is an excellent choice (if you're not already familiar with it).
Although you'll lose the advantage of having a running example (which, it should be pointed out, may work against you), you can rename variables and functions. You'll probably find that the number of quantities being worked is far smaller than your debugger will lead you to believe.
So go through the routine one line at a time, renaming things as you go along, commenting everything you think may be useful (but don't just paraphrase the opcodes, as many newbies do). Once you think you have a feel for what is going on, try another run in your debugger. Working in this way, by the time you've cracked one example, you'll often have mapped out much of the pseudocode for producing a general keygen.

Good luck, and let us know how IDA works out for you
Admiral

HaRdLoCk
March 17th, 2006, 10:46
this scheme sounds like from a very well known hex editor we all use... :-) i think this is not a good start to learn about these techniques, since as far i know it uses hidden checks and stuff. i never had a look myself but i hardly assume crypto math in it...

maybe u are working on another product.. but then the registration scheme was probably inspired by the product i mean here :-)

halfcrazed
March 17th, 2006, 17:20
Good call hardlock I'm not 100% new, I play around with crackme's and can usually fish a serial out of a random program, but I don't consider myself proficient. I'm looking at it in IDA now, me and IDA's syntax don't get along real well. I'll update if I make any progress. Thanks for the responses.

HaRdLoCk
March 20th, 2006, 04:47
having a quick look in peid's kanal gives this output: Detected 7 crypto signatures (in 0.5s)

i hardly assume that rijndael is used and therefore you will not be able to fish a serial (assuming it uses decrypt function only)... thats the goal of all that crypto stuff - to not have a cleartext serial in memory. you will have to use the correct encrypt function and create a serial for your name programatically - or if you have luck the encrypt function is also compiled in the exe and you could redirect the programs flow to this routine, having it spit out a correct code. but hey... better go for keygen ;-)

Pyrae
March 20th, 2006, 18:40
In fact, it's a relatively sophisticated scheme, which uses quite some crypto.
Though it mainly boils down to some exotic symmetric stuff doing a proper keygen might be tricky (e.g. due to encrypted code sequences) and cannot - to the best of my knowledge - be achieved w/o at least a single original key.
I consider this an interesting target, but it's probably still a bit above your head atm. So I'd recommend getting yourself accustomed to the analysis of crypto serials using a couple of less complex targets first. At the very least you'll probably have to dump the idea of 'fishing' serials in favour of some more elaborate reversing techniques...


Good luck,
Pyrae

halfcrazed
March 23rd, 2006, 16:41
I've been playing around with it some this week. I took a look at the processes it goes through when it checks a serial in IDA. I'm not much of a keygen writer, and writing one for this would be a little too much work for me. So I'm trying to patch it. I've patched where it checks the serials, but I'm still messing with the date it uses after it checks the serials to see if I still qualify for "free" updates. I haven't bothered to figure out how it is deriving the date, but I have found the addresses it writes it to and the location where it is being called. Right now I've written a code cave to change the date in the two addresses I've found it stored it, but I'm getting some exception errors when I do that. I should probably just admit this programs protection is better than me, but I'm too fucking stubborn for that. I'll update if I get the exception errors figured out. Thanks for all the responses.