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

redbull,

Originally Posted by redbull

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.

How long of the stack should i pay attention to set it up properly? And how can i do that?

Hope you would explain more detail about this 'cause i'm really a newbie Thanks

Best regards

Hi,

For a start, I think you should eliminate stack usage from the "key generation" procedure and stick to register-based stuff. Most HLL's embedded asm feature also enables you to readily point to the offset of static data objects, eliminating the need for *you* to calculate stack offsets, etc. If that is unavoidable, it requires careful knowledge of the interaction between the function prelude, the stack frame, &c. Therefore I suggest that you avoid this, and/or code the keygen in asm - the only *real* language

-archaios

[Sailor_EDA]

Actually this is a very good question and I've always wondered if the good crackers out there really took time to understand what the developer is actually doing. I'm fairly new to cracking and I guess a little naive and I've always tried to understand the underlying serial generation code. Although I understand how the serial is being generated, the calls etc, I don't think there's ever been a time when I could say what kind of implemtation it was - twofish, crc etc. I guess that would be really difficult to know what algorithm it might be solely by looking at low level dissassembly. But I have seen on Fravia's forum where some of the gurus really know - maybe one day I'll be like them.

winrar isn't keygenable cause it uses 1000bit RSA

Originally Posted by posiedon

winrar isn't keygenable cause it uses 1000bit RSA

It is as soon as there is one leaked valid key...

there are keygen useless because online checks, sometimes cracked/cracks are better than keygen and maybe done easier than cracking.. newbies cracks in the way change 74 for 75, experience crackers injects code /IAT and maybe rebuild all exe file or dll in some way, makes code redirection and kills crc checks, so i don't believe that could be boring to play with some code and do it in your own way , at the end a 'good' crack will do the same as keygen and maybe better if cracks says enter any code to register and any name

It is as soon as there is one leaked valid key

there are already leaked keys