Comparing algorithm

I'm working on a program that basically compares strings to find similarities in the way the have been generated, and so it finds the encryption key. More are the strings, better are the results...basically, with this you can create any keygen ( not only for piracy, but also for testing serial code algorithms )...It's simply to do I know, but I want to optimize the code to have more accuracy in the results. I wrote a bit of it in C ( the final version will be wrote in Python ) but I'll post it later, because it's too buggy for now and also I need suggestion about optimizing the algorithm...any idea about improving the speed? I use recursive functions and for cycles for doing the comparitions, and for now a bit of inline assembly for memory handling.
I'm also working with a different version of the program to decode tripcodes, or at least for finding the key to decode them all....I know their algorithm is very weak and they are already been decoded, but I want to do something better decoding also secure tripcodes. Ideas?

I wrote a bit of it in C ( the final version will be wrote in Python )

What the fuck.

Surely it makes more sense to prototype the other way 'round?

OK, tripcodes and many registration keys are generated by a crypto hash function, typically MD5/SHA.

To find the key to decode a tripcode, you have to break a hash function -- that is, given T and H (tripcode and hash funct.), you have to find T=H(S). Finding S given H and T is extremely hard -- it's called preimage resistance, which is a guiding property of hash functions.

What does this all mean? Well, it's simple, really...

If you think you can break a hash given a large number of inputs, you don't know enough about mathematics and computer science to do jack shit. GTFO

Your entire premise is fucked. Please LEARN2HASH and try again.

this thread is awesome!

This should be in the "fictional programming" thread.

>>3
I have the impression that registration keys are mostly hacked together ad-hoc with little understanding of the mathematics, in true G^AME PR_OGRAMMER style.
They may be vulnerable to pattern analysis, though >>1 is not the man to do it.
The "I wrote a bit of it in C ( the final version will be wrote in Python )" part does kind of give it away as a troll, though.

>>6
Many may be, yes. But no company worth their salt would do that for long.

GET IT, A CRYPTOGRAPHY PUN? WORTH THEIR SALT? HAHAHAHA

inputting as many 5's as the installer will allow you to actually works for more things than you'd expect.
i lol'd muchly when i tried that and it worked for visual studio 4 (which i obtained legally but then lost the cd key for) several years ago.

>>8
Welcome to 2007... that shit don't fly no mo. People don't actually use 12 digit CD keys that are only numbers.

>>1
You must implement the <=> operator, it is a critical component of most computer systems.

>>10

%macro <=> 2
jmp %2
%endmacro
use like

<=> eax __label

:D

>>11
Hardcore.

Some assemblers might have trouble parsing that; I suggest using the mnemonic JLEG (Jump if Lesser or Equal or Greater), or maybe JBEA (Jump if Below or Equal or Above).

>>13
Hahahaverygood

>>13
Well, clearly you need both, one for signed and one for unsigned arithmetic.

I'll write the full version in python because I want to make it a lightweight, portable script, not because I'm a troll.

Sussman could take a look at the original tripcode source, see a tripcode, and say "that's obviously the hash for key XYZ", all while he listens to two other conversations, signs autographs with one hand, and writes a Lisp program with a Dvorak keyboard with the other.

>>17
Meanwhile, who's walking the dog?

>>17
LOL!

CRYPTOGRAPHY and network security   2 No My   college is a   pain if you   wanted a silly   solution for counting.