Slaps you with a manual:
- This lock is attached to a HSM-2 module.
- Function to unlock door no longer in the lock firmware.
The main function just calls login. You set a breakpoint at login and a quick test input of aaaaaaaaaaaaaaaa
The login function:
- The prompt gives a range for input to be between 8 to 16 characters.
- However, the parameters for the
getsnfunction:r14: Holds the length of the input buffer.#0x30(48)characters. This is room for inputs > 16 chars.r15: Holds the address to the input buffer ->#0x34d2
- Input is passed to
conditional_unlock_door
This function passes the input into INT 7E where it seems verification of password and unlocking door happens in the interrupt. Manipulation by jumping address to call to unlock_door for example, can not work here. Function to unlock door is not in the lock firmware
From the login function, notice that the return address(held by the SP) is the value in address add #0x10, SP.
An overflow test perhaps:
You discover that the 17th - 18th bytes of the input overwrite the return address! Good, good progress :).
You can jump to any address and execute instructions at that address… time to inject some shellcode!
From the manual,INT 7F is the actual trigger to unlock.
The payload: Push 7F and call INT.
You put the payload in the input, and have the value of the 17th -18th bytes be the address of the beginning of the payload.
No knock, unlock!
Addis is how we roll! :cool: