Real Understanding Of Serial Generation

[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 !