Microcorruption 0x03 - Hanoi
Prev: 0x02 Sydney
Next: 0x04 Cusco
This level’s manual states that the lock connects with a security module – a separate software called the HSM-1 – to check the password. If we check the Lock Manual posted on the site, page 4 explains that the HSM-1 module takes a password and then sets a byte in memory if the password is correct. If we look at main, it calls a single function called “login.” Let’s take a look.
In this function, something immediately stands out to us: a call to “unlock_door” which, sure enough, does exactly what the name suggests. If we work backwards from this function, we find a “jne” instruction at address 4560, and preceding that is a “cmp.b” instruction which compares 0xff with the value at address 0x2410. If we can get this memory value to be 0xff, we fail the jump and fall into the “unlock_door” function.
Looking up in the “login” function, there are several references to the memory address 0x2400 and 0x2410. The most recent one just before the “cmp.b” instruction is a “getsn” call, which, based on our knowledge of "gets" in other programs, and what we can read in the lock manual, should take our password input and place it into the first argument passed to it, which is 0x2400. Now, according to the program output, passwords are between 8 and 16 characters, so a valid password is not larger than 0x10 which means that nothing should be written to 0x2410. Right?
Whoops, looks like we found an issue: the other argument passed to “getsn” (other than the address to place to string) is the length of the input, and in this case it’s 0x1c, or an additional 12 characters beyond what the program said we should be able to enter!
Go ahead and enter 16 bytes of whatever hex input you’d like, followed by “ff.” I used “41414141414141414141414141414141ff”
Prev: 0x02 Sydney
Next: 0x04 Cusco
Next: 0x04 Cusco
This level’s manual states that the lock connects with a security module – a separate software called the HSM-1 – to check the password. If we check the Lock Manual posted on the site, page 4 explains that the HSM-1 module takes a password and then sets a byte in memory if the password is correct. If we look at main, it calls a single function called “login.” Let’s take a look.
In this function, something immediately stands out to us: a call to “unlock_door” which, sure enough, does exactly what the name suggests. If we work backwards from this function, we find a “jne” instruction at address 4560, and preceding that is a “cmp.b” instruction which compares 0xff with the value at address 0x2410. If we can get this memory value to be 0xff, we fail the jump and fall into the “unlock_door” function.
Looking up in the “login” function, there are several references to the memory address 0x2400 and 0x2410. The most recent one just before the “cmp.b” instruction is a “getsn” call, which, based on our knowledge of "gets" in other programs, and what we can read in the lock manual, should take our password input and place it into the first argument passed to it, which is 0x2400. Now, according to the program output, passwords are between 8 and 16 characters, so a valid password is not larger than 0x10 which means that nothing should be written to 0x2410. Right?
Whoops, looks like we found an issue: the other argument passed to “getsn” (other than the address to place to string) is the length of the input, and in this case it’s 0x1c, or an additional 12 characters beyond what the program said we should be able to enter!
Go ahead and enter 16 bytes of whatever hex input you’d like, followed by “ff.” I used “41414141414141414141414141414141ff”
Prev: 0x02 Sydney
Next: 0x04 Cusco