[Inori]

I'm coding a short alpha-numeric keygen in C right now and I was wondering if you guys have any tips or ideas to help me out. Thanks!

[dropzon3]

hmm, normally you write keygens for applications to generate valid serial/registration keys.

But that doesn't seem to be how you're using the term? What exactly are you trying to build?

[Inori]

hmm, normally you write keygens for applications to generate valid serial/registration keys.

But that doesn't seem to be how you're using the term? What exactly are you trying to build?

Some 'fifa sticker' thing my friends have been bugging me about. It's a per-pack key. Unlike an iTunes or XBox or whatever, the key is specific to the pack and can be reused. So, It should be a little easier

[Inori]

Ughhhhh... F*ck it, this is messing with my head. If anyone can make a keygen that pumps out anything like these, that would be awesome

[dropzon3]

Actually the fact that you don't have access to the program that generates these makes it more difficult nor less difficult.

When you have the application its a matter of reverse engineering the validation logic.

Regardless it is not so much of a programming issue as it is an issue of determining how the code is validated/generated. Codes like this are intentionally difficult to figure out because certainly you're not the only one trying to get them.

There are a lot of different tricks that can be used in codes like this, often there is some type of built-in checksum. Take credit card numbers for example which follow a slight derivative of the Luhn algorithm:

Take the number:
4417 1234 5678 9113

Double the 1st, 3rd, 5th, 7th ... etc digits:
8 4 2 7
2 2 6 4
10 6 14 8
18 1 2 3

Now sum up all the 'digits' (double digit numbers are added as just their digits)
8+4+2+7+2+2+6+4+(1+0)+6+(1+4)+8+(1+8)+1+2+3 = 70

The number will always be evenly divisible by 10. This is the checksum for creditcard numbers intended to detect common mistakes when entering the numbers; mistakes like entering any single wrong number, transposition of numbers 25 -> 52 for example.

Of course there is yet more but figuring out the checksum is often a good first step.
Some resources to help you:
http://en.wikipedia.org/wiki/Luhn_algorithm
http://en.wikipedia.org/wiki/Verhoeff_algorithm
http://en.wikipedia.org/wiki/Damm_algorithm

With card cards numbers other numbers actually mean something beyond just meeting that checksum.
First digit: Identifies the industry all bank issued credit card numbers will start with a 4,5 or 6.
The First Six(including first digit) identify the issuing company
The remaining digits(excluding last digit) is the account number
The Last Digit is in place to make Luhn's algorithm work it just rounds out the number so its divisible by 10.

Now of course these particular numbers likely are not going to have the same setup like these numbers won't have an 'account number' or an issuing company or belong to a particular industry. This is just an example of how the numbers all matter using a common everyday example.

You may be able to get away with just figuring out the checksum, or you might need to provide some other valid identifiers(like the country or region may be built into these numbers)

It is not easy but get your hands on as many numbers as possible and start analyzing them for patterns. One of the easiest things to do is just perform a frequency analysis determine what characters are most likely to show up in general, for each column, is it random or is there a pattern. Are there groups that often show up together. Its not easy and it will take time. They obviously don't want you to be able to generate these without knowing the secret. Also XOR...people who are being 'creative' always like to jump and use XOR for some reason.

A few things that I do notice from the few numbers that I cared to copy down from that video is:
1st character is always C
6th character is always 2
10th character is always 6

Look for patterns in how they add up and interact with each other. the C 2 6 might be standard globally or they might change for different stores/regions/time so analyze more numbers and see what you can figure out.

EDIT: Just continued that video beyond the few I had looked at and the very next one for those seeming static digits had: C 3 and 7 so I'd say figure out how those changes affected the rest of the number and you might be onto something.

[Inori]

Actually the fact that you don't have access to the program that generates these makes it more difficult nor less difficult.

When you have the application its a matter of reverse engineering the validation logic.

Regardless it is not so much of a programming issue as it is an issue of determining how the code is validated/generated. Codes like this are intentionally difficult to figure out because certainly you're not the only one trying to get them.

There are a lot of different tricks that can be used in codes like this, often there is some type of built-in checksum. Take credit card numbers for example which follow a slight derivative of the Luhn algorithm:

Take the number:
4417 1234 5678 9113

Double the 1st, 3rd, 5th, 7th ... etc digits:
8 4 2 7
2 2 6 4
10 6 14 8
18 1 2 3

Now sum up all the 'digits' (double digit numbers are added as just their digits)
8+4+2+7+2+2+6+4+(1+0)+6+(1+4)+8+(1+8)+1+2+3 = 70

The number will always be evenly divisible by 10. This is the checksum for creditcard numbers intended to detect common mistakes when entering the numbers; mistakes like entering any single wrong number, transposition of numbers 25 -> 52 for example.

Of course there is yet more but figuring out the checksum is often a good first step.
Some resources to help you:
http://en.wikipedia.org/wiki/Luhn_algorithm
http://en.wikipedia.org/wiki/Verhoeff_algorithm
http://en.wikipedia.org/wiki/Damm_algorithm

With card cards numbers other numbers actually mean something beyond just meeting that checksum.
First digit: Identifies the industry all bank issued credit card numbers will start with a 4,5 or 6.
The First Six(including first digit) identify the issuing company
The remaining digits(excluding last digit) is the account number
The Last Digit is in place to make Luhn's algorithm work it just rounds out the number so its divisible by 10.

Now of course these particular numbers likely are not going to have the same setup like these numbers won't have an 'account number' or an issuing company or belong to a particular industry. This is just an example of how the numbers all matter using a common everyday example.

You may be able to get away with just figuring out the checksum, or you might need to provide some other valid identifiers(like the country or region may be built into these numbers)

It is not easy but get your hands on as many numbers as possible and start analyzing them for patterns. One of the easiest things to do is just perform a frequency analysis determine what characters are most likely to show up in general, for each column, is it random or is there a pattern. Are there groups that often show up together. Its not easy and it will take time. They obviously don't want you to be able to generate these without knowing the secret. Also XOR...people who are being 'creative' always like to jump and use XOR for some reason.

A few things that I do notice from the few numbers that I cared to copy down from that video is:
1st character is always C
6th character is always 2
10th character is always 6

Look for patterns in how they add up and interact with each other. the C 2 6 might be standard globally or they might change for different stores/regions/time so analyze more numbers and see what you can figure out.

EDIT: Just continued that video beyond the few I had looked at and the very next one for those seeming static digits had: C 3 and 7 so I'd say figure out how those changes affected the rest of the number and you might be onto something.

Dude this could be an entire thread in reverse engineering! Thanks a ton!