Cusco
User Manual
Lockitall LOCKIT PRO r b.02
______________________________________________________________________
User Manual: Lockitall LockIT Pro, rev b.02
______________________________________________________________________
OVERVIEW
- We have fixed issues with passwords which may be too long.
- This lock is attached the the LockIT Pro HSM-1.
DETAILS
The LockIT Pro b.02 is the first of a new series of locks. It is
controlled by a MSP430 microcontroller, and is the most advanced
MCU-controlled lock available on the market. The MSP430 is a very
low-power device which allows the LockIT Pro to run in almost any
environment.
The LockIT Pro contains a Bluetooth chip allowing it to
communiciate with the LockIT Pro App, allowing the LockIT Pro to
be inaccessable from the exterior of the building.
There is no default password on the LockIT Pro HSM-1. Upon
receiving the LockIT Pro, a new password must be set by first
connecting the LockitPRO HSM to output port two, connecting it to
the LockIT Pro App, and entering a new password when prompted, and
then restarting the LockIT Pro using the red button on the back.
LockIT Pro Hardware Security Module 1 stores the login password,
ensuring users can not access the password through other means.
The LockIT Pro can send the LockIT Pro HSM-1 a password, and the
HSM will return if the password is correct by setting a flag in
memory.
This is Hardware Version B. It contains the Bluetooth connector
built in, and two available ports: the LockIT Pro Deadbolt should
be connected to port 1, and the LockIT Pro HSM-1 should be
connected to port 2.
This is Software Revision 02. We have improved the security of the
lock by removing a conditional flag that could accidentally get
set by passwords that were too long.
(c) 2013 LOCKITALL Page 1/1
> break main
Breakpoint set
> continue
This time, the main function only calls the login function.
login
Let's set a breakpoint at the login function.
> break login
Breakpoint set
> continue
Once inside the login function, we can see that it asks the user to input the password into a buffer using getsn.
The buffer is 48 bytes wide and is located at the location of the stack pointer sp.
Let's set a breakpoint at 0x451a.
> break 0x451a
Breakpoint set
> continue
That tells us that the input buffer us stored at 0x45ee
Let's set a breakpoint right before the function returns at 0x453a.
> break 0x453a
Breakpoint set
> continue
We can continue execution after providing the input.
> continue
While examining our input in memory, we can see something interesting.
As we can see the stack pointer sp now points to the beginning of our input.
Let's step once to the ret instruction using the s command.
> continue
The stack pointer now points at the location 16 bytes after the start of the buffer because the add 0x10, sp instruction just got executed.
When the the ret instruction executes, the bytes pointed to by the sp is treated as the return address.
Return address overwrite
<==: Value is stored at the address
<--: Points to the address
╎ .... .... ╎
┌─────────────┐
*==> 0x43ee │ 6161 6161 │
╱ 0x43f0 │ 6161 6161 │
╱ 0x43f2 │ 6161 6161 │
║ 0x43f4 │ 6161 6161 │
║ 0x43f6 │ 6161 6161 │
║ 0x43f8 │ 6161 6161 │
║ 0x43fa │ 6161 6161 │
║ 0x43fc │ 6161 6161 │
input buffer ==║ ├╌╌╌╌╌╌╌╌╌╌╌╌╌┤
║ *==> 0x43fc │ 6161 6161 │
║ ╱ ├╌╌╌╌╌╌╌╌╌╌╌╌╌┤
return addr ==* 0x43fe │ 6161 6161 │
for login ║ ╎ .... .... ╎
║ ╎ .... .... ╎
╲ ╎ .... .... ╎
╲ ╎ .... .... ╎
*==> 0x441E │ 6161 6161 │
└─────────────┘
╎ .... .... ╎
So we can overwrite the return address with out input as it overlaps with the buffer.
Let's check if there is any interesting function that we want to return execution flow to.
unlock_door
There's an unlock_door function at 0x4446. This is something we would really like to execute.
If we pass the 17th and 18th bytes as 0x46 and 0x44 respectively, we can hijack execution flow and cause unlock_door to be executed after login.