Real Understanding Of Serial Generation

I am just wondering how many people here actually take the time to reverse the serial protection and understand it or do you just grab the code section to create a keygen or obviously the simple old bypassing schemes (74 to EB etc.. xor eax, eax and so on)...

I am in the middle of reversing a serial protection I messed with 1 1/2 years ago which I myself have usually rarely done and I am finding it frustrating but quite refreshing at the same time! Besides, it will just broaden my 25 years of messing with code.

Wackyass

[redbull]

Good question...

I always try to understand the code that makes up the serial routine.. IF i understand it properly then I jsut write a quick keygen.

However sometimes the programmer who did the app you are cracking goes crazy and tries to make the routine as complex to understand as possible.

Normally you find that the serial routine is a CALL with about two or three dependant CALLs

For Example

GetSerial() relies on gets() and strncpy() and atoi()

So I rip all the procs out of the file then paste the asm into my high level language, wrapper it with a procedure to setup the stack properly and just
call the bugger.

Sometimes cracking the fucker is much easier than keygenning (example is WINRAR), but I do prefer generating valid keys becuase modifying the exe is risky.

my 2 cents

[MaRKuS-DJM]

why is it risky? i don't see any risks if you made a clear patch. try to keygen uxtheme to load every non-microsoft theme

[redbull]

The only risk I see is if the program has patch detection which you dont know about [or never throught about] (ie it calcs a signature for certain routines and compares it against a sig which has been injected into the binary)

If the patch detection routine fails (ie patch detected) you never know what the binary will do to you ....

so keys are much better than patches

[MaRKuS-DJM]

but for online-checks there's no other way then patching... and a 100% working patch is the same. not for updates, but for current version. generic patch is key for next version
i wonder why microsoft didn't implement a registry value for uxtheme unsigned themes like they did for SFC disable

Nearly all the reversing I do anymore is serial number reversing. As Wackyass said, just changing the odd jmp instruction is not very interesting. Reversing the serial number generation functions is a much more intellectual challenge.
My procedure for doing this is to first find the piece of code that performs the SN check. I then step through each function to find out what it does. Next, I write a C function that does the exact same thing. Finally, I write another C function, if possible, that does the inverse. When finished, my inverse functions are an exact key generator. The challenge is in creating the inverse functions.
As examples, the InstallShield creation programs have SN's that can be inversed in a straightforward manner, although finding the key checking section of code is a bit tricky. On the other hand, the Wise creation program is much more difficult. Here, one cannot create an inverse function. One has to fully understand the author's method in order to reverse it.

jsteed

[WhoCares]

a little bit off-topic, new InstallShield uses RPC (through ISScriptBridge.dll) to call custom script functions, and "setup.inx" uses new file format so old script decompilers are useless.

Originally Posted by jsteed

As examples, the InstallShield creation programs have SN's that can be inversed in a straightforward manner, although finding the key checking section of code is a bit tricky. On the other hand, the Wise creation program is much more difficult. Here, one cannot create an inverse function. One has to fully understand the author's method in order to reverse it.

jsteed

[MaRKuS-DJM]

Originally Posted by jsteed

As Wackyass said, just changing the odd jmp instruction is not very interesting. Reversing the serial number generation functions is a much more intellectual challenge.

that's not 100% correct. just changing a jmp is for targets like WinRAR. there are targets with more complex things like just changing a jump. together with CRC checks it's a fantastic new world... and unpacking makes it perfect.

i must prove a serial is better than a crack. but there are things you will never keygen... things with online-checks... or nag-screens which are shown in full versions (yeah, i had one which always showed "powered by"). or as i said the UXTheme.dll of windows XP or the SFC_OS.dll. or Trillian Pro 2

in fact there are two interesting worlds so i think there's no need to call one boring

[dyn!o]

Hmm... probably it's just my nature to find holes in everything (software, girls, my body, posts ). Let me take a voice then....

"a serial is better than a crack"
Please take a look at my post in "dll serial fishing/patching help needed(easy)" thread. My opinion: we should avoid the generalisation of statements.

"there are things you will never keygen"
I would say: 'there are things you can't keygen at the moment'.

things with online-checks
Let's see then... hmm... online authorization (or 'check' if you prefer)... a kind of fresh wind in the protections forms. So, I am receiving an software which requires online authorization, moreover, it requires the authorization on every execution. Let's make it more complex: it takes use of asymmetric RSA-1024 crypto. Confused? Better no, because we add IP logging, remote code splicing (by downloading missing fragments) and hardware dependency. Can it be harder? Sure, but we don't want to masturbate ourselves.

So, we have a nice protection with online features. What is the problem then? In my humble opinion: none. Even if the code is crypted with asymmetric crypto algo, the key is based on hardware architecture and fragments of code are downloaded progressively, we can always make a dump and capture/unpack missing bytes during the execution. Then rebuild our work and prepare clean relase. Sounds easy? Sure, but it can be really complex in the reality - but I repeat: it is possible.

If it comes to the UXTheme.dll, SFC_OS.dll or TrillianPro 2 - I won't take a voice because I didn't touch it .

Best regards.

[MaRKuS-DJM]

"there are things you will never keygen... things with online-checks..."
you understood this wrong. it was for things where a patch is neccessary like online-check programs. Trillian is not keygennable because it sends a name & password to server to validate if you bought it and then starts.

maybe you are right... we should not generalize statements.

[WhoCares]

some online-checks can be keygened.

Some progs go online only to get some activation info then write it to registry or files. When they starts, they just check the activation info from registry/files. An offline-keygen can generate the desired activation info and directly write it into registry/files.

[MaRKuS-DJM]

you are talking about CuteFTP 6 well this type... but not the type who checks every time you go online.

[TmC]

CoverXP too.

[Michel]

Some progs go online only to get some activation info then write it to registry or files.

Yes, this is one kind of online-check : in this case, the real check is done by the prog itself, and the server is only needed to provide somme infos. So, it's often easy to emulate a false server's answerd by patching the prog.

But it's another story when the prog ask the server to do some real job, sending to him the local infos. Here, it's the server wich do the check, and if you don't give the right key, you remain off... That's the case of many trading softs witch needs to use fresh quotes for sample. Basically, it's like a simple ftp : without psw, no entry !

WhoCares wrote:

a little bit off-topic, new InstallShield uses RPC (through ISScriptBridge.dll) to call custom script functions, and "setup.inx" uses new file format so old script decompilers are useless.

I was refering to the programs that create the scripts, not the scripts themselves.

jsteed