So I'm trying to generate a random code which would look similar to something like this: HQNC-PHD4-QFJE-QTY6

I know how to getnerate random numbers, but not letters.
And I don't know how to put them into on sequence, should I use databases or something, I have no idea.

Here what I have so far.

This is for the random number.

You realize that to crack a product registration code that is 16 characters long, you need to make a maximum of 3,189,059,870,763,703,892,770,816 guesses ?

Have you calculated that in hours, days & months ?

Actually its 42,949,672,960,000,000,000,000,000. Thanks for the great lecture and help daddy. And no, it's to crack anything.

Actually, no, because letters 'O' and 'I' are not used in registration codes because they get confused with zero & one.

But whatever, uh-huh, it's not to crack anything.

I would make a list of the alphabet, then generate a random number including and between 1 and 26, then reference the list by index.

SetConst RandLetter = lstAlphabet[$RandNum]

Pardon me for jumping in here, but, in actuallity, it's probably even more confusing than that:

In most cases that I've encountered, the license key is comprised of a subset of letters and numbers corresponding to 32 values. This means that, taking the normal 26 letter alphabet, and the 10 standard numbers, you have to lose FOUR values. Usually I, O are chosen for the reasons IPA mentioned, but the omitted values can be completely and arbitrarily chosen by the prospective vendor. The REASON there are 32 values is because that corresponds exactly to 5 bits, and with some simple math, 5 sets of 5, 5-bit values fits nicely and conveniently into a 128-bit integer, upon which you can (handily) perform mathematical operations.

Since we're using only 125 of the potential 128 bits, you are left with "only" (approximately) 4.2535295865117307932921825928971e+37 (or 4,253,529,586,511,730,793,292,182,592,897,100,000) possible permutations. Iterating these sequentially, processing, say, 100000 entries per second, it would take you on the order of 13,478,621,905,695,397,600,870,099 years (YMMV). For references' sake, that's approximately 10 quadrillion times the present-day age of the universe! So if, for example, one key in every quadrillion is considered a valid key, on average, it would only take you a period of time approximately equal to the age of the universe to find it! (Oh, and there's NO WAY you'll achieve 100k interations per second at present-computing speeds!)

Now, it's perfectly reasonable to hope you'd find a valid key sooner, but let's say you get REALLY lucky and find it in 1-billionth of the average time; well you're STILL talking about 13 years spent searching

I hope that gives you an idea of the scope of the task you're facing...

Don't forget, that also assumes you know the 32-character mask chosen by the vendor (remembering that it can be any combination of letters and digits, in any order, comprising 32 values) AND that you know which 3 bits they've chosen to ignore (usually the MSB's or LSB's are chosen b/c it makes the math easier, but there's nothing mandating that particular choice). FYI: NOT knowing which 3 bits you can ignore increases the potential range of values by a POWER of 8... (2³) turning your 1-in-a-billion, 13-year-long, lucky-strike into 815,730,721 years...

I would also suggest that any logic for making the sequence random is inherently faulty. First of all, if it's an attempt to crack a key, it's just not worth the cost: Ignoring the fact that true-randomness is a myth on computers, the lost processor cycles generating them, and confirming that the generated number isn't a repeat far outweighs any potential benefit of a using a non-sequential attack (remember, those numbers above assumed 100,000 successful interations per second, you DO NOT have processor cycles to waste!) OTOH, if we take you at your word and assume that, say, you're just looking to make up keys for an application that you're writing (or some such thing), then random numbers STILL don't make sense, as you're giving up the opportunity to have a mathematical basis for checking validity (the most common means to verify a particular code). For example, Microsoft uses the same code generation system for all of its software keys. But which keys will work on which products is determined by a mathematical operation that seeds the generator differently depending on what application you're making keys for. As a result, despite the fact that all MS apps use keys chosen from the same 125-bit range of values utilising the exact same translation string, Office keys won't work on Windows, Windows keys won't work on other versions of Windows, Word keys won't work for Excel etc. etc. etc. and each application can quickly determine on its own if the proffered key is valid simply by perfoming some math on the value and comparing it with the appropriate seed (no costly look-ups to the internet, or huge (exploitable) databases of keys required!).

So, good luck with whatever it is that you're trying to do, it's not a simple chore to successfully hack these things, which is probably exactly why this method was chosen (and has been pretty widely adopted), and if you're making keys up, hopefully this will suggest some thoughts/concepts/ideas to you that you may not have considered previously.

-Triane

...all that being said, and bearing in mind that I haven't written a lick of AC Tools code for somewhere between 4 and 5 years, and STRICTLY conforming to what you asked for:


I'm interested in this thread strictly because I've spent much of the past year designing and implementing a license key + rights management system for a software package that I'm developing for my employer. Needless to say I've had a lot of exactly this sort of thing on my plate for many months now...

-Triane

Wow, after reading that, my head hurts

*shrug*

After a while, you just get number-numbness.

From the side of the vendor, it's a lot less complicated, inasmuch as you know all the things the person on the other end has to guess... We also wanted to embed a pile of information in our keys, and ended up deciding that 128 bits wasn't sufficient (we're using 1024-bits now, similiar to PK encryption keys)...

Our keys contain a license issue date (14 bits), license expiry date (14 bits), the number of workstations permitted under the license (8 bits), the UID of the workstation (48 bits), a UID for the client who's license it is (512 bits), and an internal hash value to validate the key against (32 bits). All the other bits are random and with the exception of the customer ID, very few of the bits listed above are contiguous.

Furthermore, we plan to use a non-standard base-64 hashing value to output a result that LOOKS like standard base-64 data, but which (obviously) couldn't be decoded usefully using the standard base-64 decoding algorithms.

When I was experimenting w/ 128-bit keys though, just to give you an idea, our original hashing key was "ABC9DEF2GHJ3KLM4NPQ5RST6UVW7XYZ8". Omitting "0" (zero), "O" (oh), "1" (one), and "I" (eye). Even that key isn't terribly complex, but that should demonstrate just how complicated trying to reverse-engineer 128-bit keys can be...

-Triane

I was recently trying to crack RSA, RC4 stuff for EQ2 and I couldn't do it. Just too crazy for me so I had to break the program in a certain spot so the key was right there. Once we have the key it is all over but the crying but trying to "brute force" this stuff makes me insanely giggle to chortle.

You're starting to sound like Chef Brian...