I was kinda let down by the difficulty of Whitehorse compared to its predecessor - sure the underlying vulnerability in Reykjavik was also similar to a previous challenge, but the twist forcing the loss of the automatic disassembly made it hit different. But the time for reminiscing is later - the time for hacking is now.
The Scenario
The manual for this exercise informed me I was up against hardware version C software revision 3, which still unlocks everything through the attached LockIT Pro HSM-2 but now has a new firmware that has been reimplemented "according to our internal Secure Development Process." Let's see how secure that process truly is.
Understanding The Code
Like Whitehorse, main() is a stub function that calls login(); unlike Whitehorse there are calls to first strcpy() the password to a new location and memset() to zero out the original location before the call to conditional_unlock_door().
Exploiting The Code
Since this isn't my first rodeo I understood this level's trick immediately: strcpy() returns when it sees its first null byte, so my shell code couldn't have any nulls [1]; additionally the zeroing out of the original password and the fact that I still had to overwrite the return pointer meant I had to ensure my shell code fit in 16 bytes. My first idea didn't work but my second did, so I quickly got access to these bonds as well and boarded a plane to South Africa.
| [1] | I wanted to write my shellcode in Whitehorse without nulls to be extra leet, but I got lazy. Let this be a lesson, kids: sometimes being less lazy now means you can be much lazier later. |