Solving seVeb's Crackme05
I’ve recently found myself wanting to further my reverse engineering skills. One of the ways I’ll be doing this is by working on crackmes. This one in particular is from Crackmes.de user seVeb and is called crackme05. It’s marked as a C/C++ program compiled for Linux and is rated as being easy. Sounds like a perfect place to start!
Initial Look
When I extracted the archive I was greeted with 3 files. The first two are binary files, the only difference presumably being one is built for 32-bit and the other for 64-bit. The third is a readme, which contains a simple description of the challenge:
1Welcome to crackme05 reverser!
2Your task is simple, figure out a way to generate valid serials.
3Patching is as expected not allowed. Write a keygen and tell us
4how you solved the crackme.
5Invoke the crackme with the –help or -h flag for additional help.
Fair enough! Let’s start by running the executable (note, I’m just going to focus on the 32-bit version with the assumption the logic is identical in both). Running it with no arguments or with the -h flag gives us the same general message as the readme, as well as specifying that we should pass the key as the first argument to the program.
If we try running the program with some random input as the first argument we get an error that tells us that the serial isn’t 19 chars. This sure seems like some progress already!
And sure enough, if we try it again with a 19-character string we get a new error:
While this is some helpful progress, we’re far from done. I think this is probably about all we’re going to ascertain from simply running the program, however, so let’s jump into reverse-engineering the thing!
Reversing with Ghidra
I loaded the binary into Ghidra, which was able to locate the main() function, which it came up with the following decompilation of (note that I did correct the function signature to make things a bit nicer):
1int main(int argc,char **argv)
2{
3 int iVar1;
4 undefined4 *puVar2;
5 uint uVar3;
6 char *pcVar4;
7 undefined4 *puVar5;
8 uint uVar6;
9 int in_GS_OFFSET;
10 bool bVar7;
11 byte bVar8;
12 int local_fc;
13 undefined local_f7;
14 undefined local_f6 [112];
15 undefined2 local_86;
16 int local_14;
17
18 bVar8 = 0;
19 local_14 = *(int *)(in_GS_OFFSET + 0x14);
20 if (argc < 2) {
21 usage(*argv);
22 iVar1 = 1;
23 }
24 else {
25 local_fc = 0;
26 while (argv[local_fc] != (char *)0x0) {
27 iVar1 = strcmp(argv[local_fc],"--help");
28 if ((iVar1 == 0) || (iVar1 = strcmp(argv[local_fc],"-h"), iVar1 == 0)) {
29 usage(*argv);
30 iVar1 = 1;
31 goto LAB_08048732;
32 }
33 local_fc = local_fc + 1;
34 }
35 rock((int)argv[1]);
36 paper(argv[1]);
37 scissors((int)argv[1]);
38 cracker((int)argv[1]);
39 puVar2 = &local_86;
40 pcVar4 =
41 "Passed serial is invalid! Just flip your table when you\'re stuck, it will solve your problemcertainly!\n...right?"
42 ;
43 uVar6 = 0x72;
44 bVar7 = ((uint)puVar2 & 2) != 0;
45 if (bVar7) {
46 local_86 = 0x6150;
47 puVar2 = &local_86 + 1;
48 pcVar4 =
49 "ssed serial is invalid! Just flip your table when you\'re stuck, it will solve your problemcertainly!\n...right?"
50 ;
51 uVar6 = 0x70;
52 }
53 uVar6 = uVar6 >> 2;
54 while (uVar6 != 0) {
55 uVar6 = uVar6 - 1;
56 *puVar2 = *(undefined4 *)pcVar4;
57 pcVar4 = (char *)((undefined4 *)pcVar4 + (uint)bVar8 * 0x3ffffffe + 1);
58 puVar2 = puVar2 + (uint)bVar8 * 0x3ffffffe + 1;
59 }
60 if (!bVar7) {
61 *(undefined2 *)puVar2 = *(undefined2 *)pcVar4;
62 }
63 puVar2 = (undefined4 *)&local_f7;
64 puVar5 = (undefined4 *)&DAT_08048d20;
65 uVar6 = 0x71;
66 bVar7 = ((uint)puVar2 & 1) != 0;
67 if (bVar7) {
68 local_f7 = 0x19;
69 puVar2 = (undefined4 *)(&local_f7 + 1);
70 puVar5 = (undefined4 *)&DAT_08048d21;
71 uVar6 = 0x70;
72 }
73 if (((uint)puVar2 & 2) != 0) {
74 *(undefined2 *)puVar2 = *(undefined2 *)puVar5;
75 puVar2 = (undefined4 *)((int)puVar2 + 2);
76 puVar5 = (undefined4 *)((int)puVar5 + 2);
77 uVar6 = uVar6 - 2;
78 }
79 uVar3 = uVar6 >> 2;
80 while (uVar3 != 0) {
81 uVar3 = uVar3 - 1;
82 *puVar2 = *puVar5;
83 puVar5 = puVar5 + (uint)bVar8 * 0x3ffffffe + 1;
84 puVar2 = puVar2 + (uint)bVar8 * 0x3ffffffe + 1;
85 }
86 iVar1 = 0;
87 if ((uVar6 & 2) != 0) {
88 *(undefined2 *)puVar2 = *(undefined2 *)puVar5;
89 iVar1 = 2;
90 }
91 if (!bVar7) {
92 *(undefined *)((int)puVar2 + iVar1) = *(undefined *)((int)puVar5 + iVar1);
93 }
94 decraycray((int)&local_86,(int)&local_f7);
95 iVar1 = 0;
96 }
97LAB_08048732:
98 if (local_14 == *(int *)(in_GS_OFFSET + 0x14)) {
99 return iVar1;
100 }
101 /* WARNING: Subroutine does not return */
102 __stack_chk_fail();
103}
This function is pretty straight-forward, but let’s take a closer look at what’s going on. First, we forward declare a bunch of variables. Next, we have the following:
1local_14 = *(int *)(in_GS_OFFSET + 0x14);
2if (argc < 2) {
3 usage(*argv);
4 iVar1 = 1;
5}
All this is doing is reserving space for a 19-character string in a variable called local_14 and checking that we’ve supplied at least one argument. If we haven’t, it displays the usage prompt.
Assuming we did provide an argument, we drop into the else clause of the above if statement. This is where things start to get a bit more interesting:
1local_fc = 0;
2 while (argv[local_fc] != (char *)0x0) {
3 iVar1 = strcmp(argv[local_fc],"--help");
4 if ((iVar1 == 0) || (iVar1 = strcmp(argv[local_fc],"-h"), iVar1 == 0)) {
5 usage(*argv);
6 iVar1 = 1;
7 goto LAB_08048732;
8 }
9 local_fc = local_fc + 1;
10 }
11 rock((int)argv[1]);
12 paper(argv[1]);
13 scissors((int)argv[1]);
14 cracker((int)argv[1]);
The first part of this is just a while loop that is looking for either the -h or –help flag. It’s the four function calls after this that should look interesting. We can see that the passed parameter is being passed to four separate functions (rock, paper, scissors, and cracker). It’s also worth noting that the errors we got when we were just running the application earlier reference rock and paper.
rock()
Let’s start by taking a look at the rock() function. After renaming a few variables we get the following decompilation:
1void rock(int serial)
2{
3 int sz;
4 int i;
5
6 sz = 0;
7 i = 0;
8 while (*(char *)(serial + i) != '\0') {
9 if ((*(char *)(serial + i) < '-') ||
10 (('-' < *(char *)(serial + i) && (*(char *)(serial + i) < '0')))) {
11 printf("ROCK 1: %i - %c\n",i,(int)*(char *)(serial + i));
12 bomb();
13 }
14 else {
15 if ((*(char *)(serial + i) < ':') || ('@' < *(char *)(serial + i))) {
16 if ((('Z' < *(char *)(serial + i)) && (*(char *)(serial + i) < 'a')) ||
17 ('z' < *(char *)(serial + i))) {
18 printf("ROCK 3: %i - %c\n",i,(int)*(char *)(serial + i));
19 bomb();
20 }
21 }
22 else {
23 printf("ROCK 2: %i - %c\n",i,(int)*(char *)(serial + i));
24 bomb();
25 }
26 }
27 sz = sz + 1;
28 i = i + 1;
29 }
30 if (sz != 0x13) {
31 puts("ROCK 4: Serial not 19 chars!");
32 bomb();
33 }
34 return;
35}
There are a few things that I think are immediately obvious here. First, most of the function is made up of a while loop that is iterating over the entire serial. Second, at the very end, we have an if statement that checks if the size of our serial is 0x13, which confirms the suspicion that our serial is going to be 19-characters long.
Let’s take a look at the logic within the while loop.
Looking at this we can see that there are a number of if-else clauses. Let’s look at the first one:
1if ((*(char *)(serial + i) < '-') || (('-' < *(char *)(serial + i) & (char *)(serial + i) < '0')))) {
2 printf("ROCK 1: %i - %c\n",i,(int)*(char *)(serial + i));
3 bomb();
4}
In this case, we can see that we will have a call to bomb() if the current character (I’ll call this c from now on) matches the following:
1c < '-' || '-' < c < '0'
If we jump into the else block of this if-statement, we have another bit of logic:
1if ((*(char *)(serial + i) < ':') || ('@' < *(char *)(serial + i)))
We can see that this evaluates to true if:
1c < ':' || c > '@'
We can also notice that if the above condition fails, we will have a call to bomb(). We can therefore conclude that our serial cannot have the characters: : ; < = > ? @
Let’s see what logic we have in the next if-statement that gets called if the above test passes:
1if ((('Z' < *(char *)(serial + i)) && (*(char *)(serial + i) < 'a')) ||
2 ('z' < *(char *)(serial + i))) {
3 printf("ROCK 3: %i - %c\n",i,(int)*(char *)(serial + i));
4 bomb();
5}
Analyzing this we can see that we will get a call to bomb() when the following is true:
1(c > 'Z' && c < 'a') || (c > 'z')
In other words, we now know that our key can’t contain the characters: [ \ ] ^ _ ` { | } ~ DEL
Successfully Passing the Checks in rock()
Let’s really quickly put together everything that we’ve just learned looking at the rock() function. From this, we know that our serial is going to be 19-characters long. We also know that, at this stage of verification, any one of the 19 characters can come from the following set: – [a-z] [A-Z] [0-0]
This is a great start, but we’ve still got 3 more stages of verification to figure out!
paper()
Referring back to the main() function, we can see that the next function fall is to paper(), which decompiles to the following:
1void paper(char *key)
2{
3 int iVar1;
4 int iVar2;
5
6 iVar1 = (int)(char)(key[10] ^ key[8]) + 0x30;
7 iVar2 = (int)(char)(key[0xd] ^ key[5]) + 0x30;
8 if ((iVar1 < 0x3a) && (iVar2 < 0x3a)) {
9 if ((iVar1 < 0x30) || (iVar2 < 0x30)) {
10 puts("Paper 1 lower");
11 bomb();
12 }
13 }
14 else {
15 puts("Paper 1");
16 bomb();
17 }
18 if (((int)key[3] == iVar1) && ((int)key[0xf] == iVar1)) {
19 if (((int)*key != iVar2) || ((int)key[0x12] != iVar2)) {
20 puts("Paper 3");
21 bomb();
22 }
23 }
24 else {
25 puts("Paper 2");
26 bomb();
27 }
28 return;
29}
Just taking a quick look at this code it becomes obvious that there are 4 code paths that will result in a call to bomb(). As long as we can avoid these code paths we’re good to go on this stage.
The logic is largely centered around two XOR operations, stored in iVar1 and iVar2:
1iVar1 = (int)(char)(key[10] ^ key[8]) + 0x30;
2iVar2 = (int)(char)(key[13] ^ key[5]) + 0x30;
If we take a moment to analyze the layout of the if-statements, I think it becomes clear that, to pass this stage, the following needs to be true:
1(iVar1 < 0x3a && iVar2 < 0x3a) && (key[3] == iVar1 && key[15] == iVar1)
and the following needs to be false:
1(iVar1 < 0x30 && iVar2 < 0x30) && (key[0] != iVar2 || key[18] != iVar2)
These are conditions that our keygen will need to take into account to pass this verification stage.
scissors()
Let’s move on to looking at the third validation stage, the scissors() function:
1void scissors(int serial)
2{
3 int iVar1;
4 int iVar2;
5
6 iVar1 = (int)*(char *)(serial + 2) + (int)*(char *)(serial + 1);
7 iVar2 = (int)*(char *)(serial + 0x11) + (int)*(char *)(serial + 0x10);
8 if ((iVar1 < 0xab) || (iVar2 < 0xab)) {
9 puts("Scissors 1");
10 bomb();
11 }
12 else {
13 if (iVar1 == iVar2) {
14 puts("Scissors 2");
15 bomb();
16 }
17 }
18 return;
19}
In this stage, we have two code paths that will result in a call to the bomb() function. This logic is once again centered around two variables, iVar1 and iVar2. Cleaning things up a bit we get the following logic for these:
1iVar1 = serial[2] + serial[1];
2iVar2 = serial[17] + serial[16];
We will get a call to bomb() if the following conditions are met:
1(iVar1 < 0xab || iVar2 < 0xab) || (iVar1 == iVar2)
As long as these conditions aren’t met, we pass this third stage of serial validation.
cracker()
That brings us to the fourth validation function, cracker(), which decompiles to the following:
1void cracker(int serial)
2{
3 if ((int)*(char *)(serial + 0xe) + (int)*(char *)(serial + 4) + (int)*(char *)(serial + 9) != 0x87
4 ) {
5 puts("cracker 1");
6 bomb();
7 }
8 return;
9}
In this case, we only get a call to bomb() if the condition of the if-statement evaluates to true. Cleaning things up a bit, we can see that this happens under the following condition:
1(serial[14] + serial[4] + serial[9]) != 0x87
We can actually simplify this even further. Recall that in the rock() function we determined that the smallest possible character our serial could contain was the – character (0x2d). Well, it’s not exactly Earth-shattering news that 0x2d * 3 = 0x87. This means that our condition can actually be thought of as saying that the following condition must be met in our serial:
1serial[14] == 0x2d && serial[4] == 0x2d && serial[9] == 0x2d
Yep, we know for sure what 3 of the 10 characters in our key are now!
Back to main()
Let’s go back to main() now. Assuming we make it through the rock, paper, scissors, and cracker stages without hitting a call to bomb(), we hit the following stretch of code:
1puVar2 = &local_86;
2 pcVar5 =
3 "Passed serial is invalid! Just flip your table when you\'re stuck, it will solve your problemcertainly!\n...right?"
4 ;
5 uVar7 = 0x72;
6 bVar8 = ((uint)puVar2 & 2) != 0;
7 if (bVar8) {
8 local_86 = 0x6150;
9 puVar2 = &local_86 + 1;
10 pcVar5 =
11 "ssed serial is invalid! Just flip your table when you\'re stuck, it will solve your problemcertainly!\n...right?"
12 ;
13 uVar7 = 0x70;
14 }
15 uVar7 = uVar7 >> 2;
16 while (uVar7 != 0) {
17 uVar7 = uVar7 - 1;
18 *puVar2 = *(undefined4 *)pcVar5;
19 pcVar5 = (char *)((undefined4 *)pcVar5 + (uint)bVar9 * 0x3ffffffe + 1);
20 puVar2 = puVar2 + (uint)bVar9 * 0x3ffffffe + 1;
21 }
22 if (!bVar8) {
23 *(undefined2 *)puVar2 = *(undefined2 *)pcVar5;
24 }
25 puVar2 = (undefined4 *)&local_f7;
26 puVar6 = (undefined4 *)&DAT_08048d20;
27 uVar7 = 0x71;
28 bVar8 = ((uint)puVar2 & 1) != 0;
29 if (bVar8) {
30 local_f7 = 0x19;
31 puVar2 = (undefined4 *)(&local_f7 + 1);
32 puVar6 = (undefined4 *)&DAT_08048d21;
33 uVar7 = 0x70;
34 }
35 if (((uint)puVar2 & 2) != 0) {
36 *(undefined2 *)puVar2 = *(undefined2 *)puVar6;
37 puVar2 = (undefined4 *)((int)puVar2 + 2);
38 puVar6 = (undefined4 *)((int)puVar6 + 2);
39 uVar7 = uVar7 - 2;
40 }
41 uVar3 = uVar7 >> 2;
42 while (uVar3 != 0) {
43 uVar3 = uVar3 - 1;
44 *puVar2 = *puVar6;
45 puVar6 = puVar6 + (uint)bVar9 * 0x3ffffffe + 1;
46 puVar2 = puVar2 + (uint)bVar9 * 0x3ffffffe + 1;
47 }
48 iVar4 = 0;
49 if ((uVar7 & 2) != 0) {
50 *(undefined2 *)puVar2 = *(undefined2 *)puVar6;
51 iVar4 = 2;
52 }
53 if (!bVar8) {
54 *(undefined *)((int)puVar2 + iVar4) = *(undefined *)((int)puVar6 + iVar4);
55 }
56 decraycray((int)&local_86,(int)&local_f7);
57 uVar1 = 0;
Yep, we’re not quite out of the woods just yet!
What it appears is going on here is that we are generating a second string and passing this new string, along with the serial, into a function called decraycray(). If we look at this function, we get the following (after I renamed some variables, anyway):
1void decraycray(int str,int serial)
2{
3 int i;
4
5 i = 0;
6 while (*(char *)(str + i) != '\0') {
7 putchar((int)(char)(*(byte *)(str + i) ^ *(byte *)(serial + i)));
8 i = i + 1;
9 }
10 putchar(10);
11 return;
12}
I think you can plainly see that all this function is doing is XORING each character of the created string and the serial together. A reasonable assumption would be that this is the logic that is generating the message we’ll get upon entering a successful key.
This means that there’s just one final step left… write a keygen!
Writing the Keygen
It’s finally time to put together everything that we’ve learned to write a keygen. Let’s start with the simplest aspects of generating the key:
- The key is 19 characters long
- The set of possible characters is: – [a-z] [A-Z] [0-0]
- We know that character 4, 9, and 14 must be –
Starting with this base logic, we can get the following Python code to get our keygen started:
1import string
2import random
3# Generate the set of possible characters as a byte array
4char_options = string.ascii_lowercase + string.ascii_uppercase + string.digits + '-'
5valid_chars = bytearray()
6valid_chars.extend(map(ord, char_options))
7
8# Generate a random serial that is 19 characters long
9serial = [random.choice(valid_chars) for i in range(19)]
10
11# We know that positions 4, 9, and 14 must be a '-' char
12# This is technically done in the cracker() stage, but we'll just do it here...
13serial[4] = 0x2d
14serial[9] = 0x2d
15serial[14] = 0x2d
16print(serial)
This is a good start, but we are far from having all of the logic we need to generate a valid serial for this program. The next step will be to implement the logic that we uncovered in the paper() stage of the program.
If you’ll recall, there are several cases where we need to generate a character for the serial that is bound by some given condition. As such, I want to add the following function to the keygen that will take in a lambda function that represents a condition and a list of valid characters from which it’ll pull a random entry that meets the given condition. This is what I came up with:
1# Generates a random character based on a supplied condition
2def conditional_random(cond, chars):
3 res = []
4 for c in chars:
5 if cond(c):
6 res.append(c)
7 return random.choice(res)
With this done, I can easily add in the logic that was uncovered by reversing the paper() function:
1# Logic from the paper() stage
2serial[8] = conditional_random(lambda x: (x ^ serial[10]) <= 9, valid_chars)
3serial[5] = conditional_random(lambda x: (x ^ serial[13]) <= 9, valid_chars)
4iVar1 = (serial[10] ^ serial[8]) + 0x30
5iVar2 = (serial[13] ^ serial[5]) + 0x30
6serial[3] = iVar1
7serial[15] = iVar1
8serial[0] = iVar2
9serial[18] = iVar2
Lastly, we just need to add the logic from the scissors() stage, which isn’t too dissimilar from what we just did.
1# Logic from the scissors() stage
2serial[1] = conditional_random(lambda x: x + serial[2] > 170, valid_chars)
3serial[16] = conditional_random(lambda x: x + serial[17] > 170 and serial[1] + serial[2] != x + serial[17], valid_chars)
There’s just one final thing to do to finish up the keygen. If you run it in this state you’ll see one small issue… it’s outputting a byte-array instead of a string:
So, we just need to add a quick conversion:
1print("".join([chr(c) for c in serial]))
Putting the whole thing together we get the following program:
1import string
2import random
3# Generates a random character based on a supplied condition
4def conditional_random(cond, chars):
5 res = []
6 for c in chars:
7 if cond(c):
8 res.append(c)
9 return random.choice(res)
10
11# Generate the set of possible characters as a byte array
12char_options = string.ascii_lowercase + string.ascii_uppercase + string.digits + '-'
13valid_chars = bytearray()
14valid_chars.extend(map(ord, char_options))
15
16# Generate a random serial that is 19 characters long
17serial = [random.choice(valid_chars) for i in range(19)]
18
19# We know that positions 4, 9, and 14 must be a '-' char
20# This is technically done in the cracker() stage, but we'll just do it here...
21serial[4] = 0x2d
22serial[9] = 0x2d
23serial[14] = 0x2d
24
25# Logic from the paper() stage
26serial[8] = conditional_random(lambda x: (x ^ serial[10]) <= 9, valid_chars)
27serial[5] = conditional_random(lambda x: (x ^ serial[13]) <= 9, valid_chars)
28iVar1 = (serial[10] ^ serial[8]) + 0x30
29iVar2 = (serial[13] ^ serial[5]) + 0x30
30serial[3] = iVar1
31serial[15] = iVar1
32serial[0] = iVar2
33serial[18] = iVar2
34
35# Logic from the scissors() stage
36serial[1] = conditional_random(lambda x: x + serial[2] > 170, valid_chars)
37serial[16] = conditional_random(lambda x: x + serial[17] > 170 and serial[1] + serial[2] != x + serial[17], valid_chars)
38print("".join([chr(c) for c in serial]))
Running the program now will output a string that looks something like this:
The question is, does it work? Let’s find out!
Bingo! We’ve successfully reverse-engineered the serial checking algorithm of this application and implemented a working keygen for it.
#Reverse-Engineering #Assembly #C #Ghidra #Crackme #Hacking #Python