Microcorruption: Cusco

Wed 03 May 2023

The Scenario

The exercise informed me I was up against hardware version B, but now running software revision 2. I still had a LockIT Pro HSM-1 to contend with (but more likely bypass entirely), but by this point I was fairly confident in what I expected from the firmware.

Understanding The Code

A screenshot of the disassembly of the login function

main() once again is a stub for login() so that's what I spent most of my time understanding. Since there wasn't much to login() or test_password_valid(), I coudn't find any obvious plan of attack like some secret value I could pass in or obvious security bypass. My next thought was that I was supposed to find the password that was embedded in memory somewhere, but there were no indications about where I should possibly begin looking.

A screenshot of the disassembly of the test_password_valid function

The "reminder" about password length suggested I would likely have to overflow some buffer like in Hanoi, but I couldn't figure out how I could turn it into either control of r15 or the program counter. It wasn't until I decided to complete the standard login workflow that I realized something:

A screenshot of the lock memory after receiving a password; be nice to my arrows, I drew them on a trackpad

Exploiting The Code

Once I realized right after my password buffer is the address the lock will return to after leaving login(), it didn't take much time to whip up another buffer overflow that would jump to the unlock_door() function.

These Yombinator bonds never stood a chance.