Microcorruption 0x02 - Sydney
Prev: 0x01 New Orleans
Next: 0x03 Hanoi
The manual for this level shares that they’ve patched the lock from New Orleans by removing the password from memory. Indeed, when looking at main we can see that there is no longer a “create_password” function which must mean that the “check_password” function is operating a bit differently. Let’s take a look.
Right off the bat, the first instruction is a compare which compares a two-byte hex value with 0x0(r15), which we can see stores the address of the dummy string we entered. If they aren’t equal, we jump to 44ac which clears the r14 and r15 registers before returning.
Continuing, there are a total of four compares, and although they are occasionally written differently and precede different types of jumps (jnz, jne, and jeq), if we follow the control flow we find that they are all treated similarly: if any comparison fails, we jump to 44ac and return with a value of 0 in r15, meaning we fail to unlock the lock.
So, although the password is not placed into memory via a “create_password” function like in New Orleans, it is still technically stored in memory via these instructions. If we combine the hex from each of the comparison instructions, we have our password!
However, keep endianness in mind: this site’s architecture is little endian, meaning that memory addresses are written bytewise backwards (least significant byte first). In other words, a two-byte value like 0x1234 would be written into memory as 0x3412. Conversely, a value written as 0x7890 in memory will be interpreted as 0x9078.
Thus, if the comparison values are 0x5634, 0x4056, 0x5924, and 0x7c5e, then we must reverse the bytes of each hex value before combining. Enter “3456564024595e7c” as the password to solve the level.
Prev: 0x01 New Orleans
Next: 0x03 Hanoi
Next: 0x03 Hanoi
The manual for this level shares that they’ve patched the lock from New Orleans by removing the password from memory. Indeed, when looking at main we can see that there is no longer a “create_password” function which must mean that the “check_password” function is operating a bit differently. Let’s take a look.
Right off the bat, the first instruction is a compare which compares a two-byte hex value with 0x0(r15), which we can see stores the address of the dummy string we entered. If they aren’t equal, we jump to 44ac which clears the r14 and r15 registers before returning.
Continuing, there are a total of four compares, and although they are occasionally written differently and precede different types of jumps (jnz, jne, and jeq), if we follow the control flow we find that they are all treated similarly: if any comparison fails, we jump to 44ac and return with a value of 0 in r15, meaning we fail to unlock the lock.
So, although the password is not placed into memory via a “create_password” function like in New Orleans, it is still technically stored in memory via these instructions. If we combine the hex from each of the comparison instructions, we have our password!
However, keep endianness in mind: this site’s architecture is little endian, meaning that memory addresses are written bytewise backwards (least significant byte first). In other words, a two-byte value like 0x1234 would be written into memory as 0x3412. Conversely, a value written as 0x7890 in memory will be interpreted as 0x9078.
Thus, if the comparison values are 0x5634, 0x4056, 0x5924, and 0x7c5e, then we must reverse the bytes of each hex value before combining. Enter “3456564024595e7c” as the password to solve the level.
Prev: 0x01 New Orleans
Next: 0x03 Hanoi