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 :cool:

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

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 :D

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

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 :D
i wonder why microsoft didn't implement a registry value for uxtheme unsigned themes like they did for SFC disable :D

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

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.

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

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.

"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.

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.

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

CoverXP too.

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 ! :mad:

WhoCares wrote:

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

jsteed

redbull,

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

RE: Serial generation
 

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

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

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 :D

there are already leaked keys

But we can blacklist the leaked keys in next version. Right? Or, if program uses the online license check method, we could disable the keys.
The point is that the hacker should not be able to create the keygen.

Why you need keygen if you have one valid key and it's not blaclisted yet?
You can enter look what winrar do it, make dump of unpacked code, rebuild and go on....so 1000bitRSA or 2000bitRSA it doesn't matter until it hasn't good release...

one other thing that came to my mind - what is if you "simply" patch it but you do not find the call home?
if i would make an protection i would try to make an serial number independant (hidden) connection to my
company - and you would be happy that you patched the jump...

Well supprisingly your always know if it calls home, thnx to SP2 for XP or Zone Alarm or Port Explorer, my Fav at the moment... I actually brought this one too, though I could not crack it... Sigh..

But with the above it will tell you every time it wants to talk then just sniff the packets to find out what it wants... :D


Pozzy!

The obvious conclusion imho, is that keygens are the best solution. The great thing with a keygen (unlike *most* patches), is that there's a pretty good chance it will work with subsequent releases of the same app.

Once you have mastered the art of patching, it is definitely worthwhile attempting to try creating a keygen. It helps you learn an awful lot more about reverse-engineering.

Of course, there are times when a patch and a keygen is the best solution. I can remember downloading keygens for SubmitWolf 5.x and the keys they generated all got accepted, no problem. But when it did it secondary online check to see if you were licenced to download the updates/addons it failed. This is why I created a keygen and patch combined, and it worked a treat.

But let's be honest, both methods are worthy ways of allowing free software to proliferate. Do whatever you're comfortable with. :D