Microcorruption 0x01 - New Orleans
Prev: 0x00 Tutorial
Next: 0x02 Sydney
Now we’re on our own. This level, like the others, greets us with the user manual for the lock. Most of this is fluff, but as you advance to new levels it will be important to read this to understand their security patches.
Running the program with “c,” we can see that the program itself is very straightforward: the user is asked for a password, and then is notified whether it is correct or incorrect. Let’s reset and debug.
When we examine the Disassembly window, we can see that the program kicks off with some initialization instructions that we’re not too concerned with, so let’s break at main (4438) and continue.
After adding a value to the sp (“esp”) register, main calls a function “create_password” that we will step into. Here’s what it does:
Press “f” to finish executing the “create_password” function and you’ll find a nice string of hex at address 0x2400: 6249 496f 222f 30. Is this the lock’s password? We can see a “check_password” function up ahead, so let’s break at it and continue, once again entering “AAAA” when prompted.
Since we suspect the password was just placed into memory, let’s check for a comparison instruction. The first one we find is at 44c2: a “cmp.b” instruction which compares two memory addresses. More specifically, we know that cmp.b is a byte comparison because of the “.b” modifier (we saw this earlier with the “mov.b” instruction in the “create_password” function as well). This instruction compares “@r13” (the value at the address stored in r13) with “0x2400(r14)” (the value at an offset of 0x2400 from the address stored in r14). We can see that r13 is 439c, and r14 is 0000 which means its 0x2400 offset is simply 2400.
So, this line is comparing the first byte of r13 with 0x2400. When we check these values using “read,” we find that r13 contains the address of our “AAAA” string (“41414141”), and 2400 contains the hex string we generated via “create_password.”
This seems to confirm our suspicion… but why is it only checking one byte? Continuing, we can see that r14 is incremented and used to check through each byte separately when the function reiterates before finishing once it has read 8 bytes of data due to the final compare.
So, our suspicion from way back in the “create_password” function was correct: this function generates the lock password which is then compared against the password that we enter. If it matches, the value of 1 is placed into r15 which is tested in main’s instruction 4454 that will either pass or fail us accordingly.
Enter “solve” in order to attempt to crack the real lock and enter “6249496f222f30” as the password. Don’t forget to check the box in the prompt to indicate hex input.
Bam! We’ve solved it.
Prev: 0x00 Tutorial
Next: 0x02 Sydney
Next: 0x02 Sydney
Now we’re on our own. This level, like the others, greets us with the user manual for the lock. Most of this is fluff, but as you advance to new levels it will be important to read this to understand their security patches.
Running the program with “c,” we can see that the program itself is very straightforward: the user is asked for a password, and then is notified whether it is correct or incorrect. Let’s reset and debug.
When we examine the Disassembly window, we can see that the program kicks off with some initialization instructions that we’re not too concerned with, so let’s break at main (4438) and continue.
After adding a value to the sp (“esp”) register, main calls a function “create_password” that we will step into. Here’s what it does:
- The instruction at 447e moves the value of 0x2400 into r15. Simple enough. When we check the Live Memory Dump, we can see that this address is full of zeroes.
- The instruction at 4482 moves the value of 0x62 into 0x0(r15). “0x0(r15)” can be read as “a 0x0 offset of the address stored in r15,” or “the address r15 + 0x0.” Step through this instruction and then check the address 0x2400 on the Live Memory Dump. Sure enough, 0x62 is right there.
- Continue to watch 0x2400 in memory as you step through a few more instructions. It’s pretty easy to see what’s happening here: the byte listed in each mov.b instruction is being copied to a growing string at address 0x2400.
Press “f” to finish executing the “create_password” function and you’ll find a nice string of hex at address 0x2400: 6249 496f 222f 30. Is this the lock’s password? We can see a “check_password” function up ahead, so let’s break at it and continue, once again entering “AAAA” when prompted.
Since we suspect the password was just placed into memory, let’s check for a comparison instruction. The first one we find is at 44c2: a “cmp.b” instruction which compares two memory addresses. More specifically, we know that cmp.b is a byte comparison because of the “.b” modifier (we saw this earlier with the “mov.b” instruction in the “create_password” function as well). This instruction compares “@r13” (the value at the address stored in r13) with “0x2400(r14)” (the value at an offset of 0x2400 from the address stored in r14). We can see that r13 is 439c, and r14 is 0000 which means its 0x2400 offset is simply 2400.
So, this line is comparing the first byte of r13 with 0x2400. When we check these values using “read,” we find that r13 contains the address of our “AAAA” string (“41414141”), and 2400 contains the hex string we generated via “create_password.”
This seems to confirm our suspicion… but why is it only checking one byte? Continuing, we can see that r14 is incremented and used to check through each byte separately when the function reiterates before finishing once it has read 8 bytes of data due to the final compare.
So, our suspicion from way back in the “create_password” function was correct: this function generates the lock password which is then compared against the password that we enter. If it matches, the value of 1 is placed into r15 which is tested in main’s instruction 4454 that will either pass or fail us accordingly.
Enter “solve” in order to attempt to crack the real lock and enter “6249496f222f30” as the password. Don’t forget to check the box in the prompt to indicate hex input.
Bam! We’ve solved it.
Prev: 0x00 Tutorial
Next: 0x02 Sydney