The Scenario

The manual for the Lockitall LockIT Pro of this level is different, letting me know I'm up against hardware version B, software revision 1 - now featuring a LockIT Pro HSM-1 so I won't be able to just read the password out of the firmware this time around.

Understanding The Code

Looking at main() didn't help much this time around as it's just a stub for login() with this firmware, but I can use the same analysis for login() without much difference. The login process is fairly straightforward:

• get the password from the user with getsn()
• check it with test_password_valid()
• if address 0x2410 has the value 0x92 afterwards, unlock the door

One thing to note is the lock explicitly stating passwords are eight to 16 characters inclusive, but looking back at the user guide it seems as though the arguments login() passes to getsn() will accept passwords up to 27 characters long...

I also took a look at test_password_valid() in case there may be something useful but it was pretty clear it was mainly a stub function as well: do a little bit of work setting up the registers before pushing them onto the stack and triggering an interrupt to send control to the HSM. I don't 100% get why the sign extension is necessary after getting the value back from the HSM, but in the end it doesn't even matter.

Exploiting The Code

I spent a decent amount of time at the start stepping through the code slowly trying to figure out if the interaction between the lock and HSM had some subtle bug I could exploit, but then I realized the address the lock checks for the flag is right after where the password is stored so I could just "overflow" the password buffer and set the flag value myself.

Now that I've finally used a real binary exploitation technique [1], I'm ready to get to work.