Microcorruption: Jakarta

Wed 10 May 2023

The Scenario

Arriving in Jakarta, I find my next opponent is Lockitall LockIT Pro revision b.06, whose manual claims "We have added further mechanisms to verify that passwords which are too long will be rejected". Second time's the charm, and all that. Or maybe eighth? I dunno, I just break into things; let me see what I'm up against.

Understanding The Code

I see a lot of similarities between the firmware for this lock and the one in Santa Cruz [1], but the biggest difference makes itself apparent before I get to a prompt: a notice stating "Your username and password together may be no more than 32 characters".

A partial screenshot of the disassembly of the login function

The implementation seems decent enough: strcpy() the username into position, check the length and abort if it's too long; then do the same for the password, checking the combined length; if the combined length is acceptable, continue with the rest of the login flow.

Exploiting The Code

As before my primary goal is to figure out how to jump to unlock_door(), but it seems Lockitall has put their singular half-decent programmer in charge of this firmware - entering a large username leads to failure, but the firmware is smart enough to reduce its acceptable password length by the length of the given username.

After stepping through the code for the 17th time, I realized where said half-decent coder made their fatal error: the length checks were only bytewise so writing more than 256 bytes of input would overflow the least significant byte of the register for an effective length of 0 [2].

Once I noticed this flaw the lock was done for; by the time anyone realized what happened I was already on my way to Ethiopia. Nice try Lockitall, maybe revision b.07 will be the winner.

[1]Which makes sense, The lock in Santa Cruz was revision b.05
[2]Really 255 bytes, since there's still the trailing null at the end of the password