so r11 becomes the length of the password

It moves the value of 43B4 into r15
This is the location just before the password.
It compares it to r11.

So the value of 43B4, which is the character s in the username, must be a value greater than the length of the password.
Let's test it again, and see if the address changes when lengths change.

We will do a password of 5 characters, and username of 10.

r11 = 5, so r11 is the length of the password
r4 = 43cc still, so it still grabs 43B4

Ahha! 43B4 is normally set to the value 10, which is 16 in hex. So normally it compares to the password length.
The thing is, the username storage can overwrite this address. So as long as we make 19th character in our username a value
which is greater than the length of our password we will not be halted at 45ec.

r4 is still 43cc, so next it grabs the value at 43B3m which is 08.
It sticks this in r15, and compares it to r11.
r11 = length of our password, r15 = hard coded value of 8.
It does a JC to skip a halt. This means the length of our password must be greater than the value at 43B3.

So, what have we learned so far:

Password length must be greater than value at 43B3, and less than the value at 43B4.
We can control these addresses by overflowing the username, so they can be whatever we need them to.
Let's keep going for now. We are going to fail this check, so we do: let r15 = 2
Now it just has to be greater than 2.

Next it looks like preparation to make the syscall to 7d, which is the password check and flag setting.
For now, I'm going to assume this will always fail and we are going to need to overwrite the return address after the login function.
Let's just step past it and keep an eye on r4, which seems to be an anchor for refercing addresses during tests.

Yep, it's still 43cc. It looks like it then tests 43A0 for zero. This is a hard coded area in the memory which we have no control over.
This will always be 0, unless by some luck we guess the right password and the int call to 7d sets it to something else.
Not likely, so expect it to be 0.

That jumps us to the password incorrect and skips the unlock function. That's fine, we plan on this happening and want to instead overwrite the return.

It looks like there's one last program halt to avoid at 465a before the function can return.
It checks 43C6 for a null byte. If it's not null it will halt the program.
This is checking for a password overflow and ensuring there's a null byte here.
43C6 is the 17th character of the password. Since the limit is 16 characters this must be a null byte.

So we can't overflow using the password, but we can overflow using the username.
This will write over 43C6, but since the password memcpy is after the username memcpy, the password will correctly stick a null byte here
as long as we use a 16 character password.

This should allow us to overflow the username, setting the return address, ensuring our hardcoded length values work against the checks, and
sticking the address 444a in it's place to jump to the door unlock.

so for our username, since s is the password max length, and u is the min length, we just need to be observant here.
The rest will fill with more garbage until we find what positions overwrite the return address, and the password will simply be 16 characters.

Alright, so lets craft some arcane passwords here and get some magic happening.
First let's ensure we can set the hardcoded values of min/max length with an overflow.

43B4 = max length (pass)
43B3 = min length (pass)

We will put a break at 45EC, right before the first jump after max length check.
in the password abcdefghijklmnopqrstuvwxyz, r = min length and s = max
so convert to hex, and replace the ascii codes 72(r) and 73(s) with 01 and 9f.
Remember, we can't use null bytes so we can't use 00, so this is the lowest and highest checks possible.
This leaves us with: 6162636465666768696a6b6c6d6e6f7071019f7475767778797a

For our password, anything with 16 chars is fine.
AAAAAAAAAAAAAAAA

Let's put these and and check our special addresses.

> read 43b3
   43b3:   019f 4141 4141 4141  ..AAAAAA
   43bb:   4141 4141 4141 4141  AAAAAAAA
   43c3:   4141 0000 0000 0000  AA......
   43cb:   0040 4400 0000 0000  .@D.....

Hey look at that, 01, and 9f!

R11 is also the length of our password, 16, so all is going as expected.
If we put a break at 4666, just before login returns, we should successfully avoid all traps and reach it.
Let's try that and C.

Success! The PC then grabs the return address of 4440.
Hey wait... I see it there, it's address 43cc and 43cd, 40 and 44 respectively.
We will attempt to overwrite this with 444a.

We can see our username starts at address 43a2
16 characters later we are at 43b2.
16 more = 43c2. 10 characters later, or A, we are at 43CC.

So, at exactly 42 characters we hit 43CC.
So character 42 must = 4a, and character 43 must = 44.
Character 18 = 01
Character 19 = 9f
Let's python this up.

'41'*17 + '019f' + '41'* 22 + '4a44'

So it's 17 + 2 = 19
+ 22 = 41
+ 2 = 43

username:
4141414141414141414141414141414141019f414141414141414141414141414141414141414141414a44

password:
42424242424242424242424242424242

Let's run it:

> read 43b3
   43b3:   019f 4242 4242 4242  ..BBBBBB
   43bb:   4242 4242 4242 4242  BBBBBBBB
   43c3:   4242 0041 4141 4141  BB.AAAAA
   43cb:   4a44 0000 0000 0000  JD......

Hey that looks good! 01 and 9f as min/max.

> read 43c6
   43c6:   4141 4141 414a 4400  AAAAAJD.
   43ce:   0000 0000 0000 0000  ........
   43d6:   0000 0000 0000 0000  ........
   43de:   0000 0000 0000 0000  ........

Uh oh, looks like our null byte check may fail, let's break right before it.
Yep, it fails, we missed the null byte by 1. Adding a 17th character to the password should fix this.

> read 43c6
   43c6:   0041 4141 414a 4400  .AAAAJD.
   43ce:   0000 0000 0000 0000  ........
   43d6:   0000 0000 0000 0000  ........
   43de:   0000 0000 0000 0000  ........

Yes! It looks good, and lets check our return address:

read 43cc
   43cc:   4400 0000 0000 0000  D.......
   43d4:   0000 0000 0000 0000  ........
   43dc:   0000 0000 0000 0000  ........
   43e4:   0000 0000 0000 0000  ........

Oops... math is hard. We are off by one character in the username before the overwrite.


4141414141414141414141414141414141019f41414141414141414141414141414141414141414141414a44
4242424242424242424242424242424242

> read 43c6 1
   43c6:   0041 4141 4141 4a44  .AAAAAJD

> read 43cc 1
   43cc:   4a44 0000 0000 0000  JD......

Perfect, we have the null byte check passing, and the return address as 444a.

There's that beautiful message: If you were not connected to the debug lock, the door would now be open. Now reset the CPU and type "solve" to run on the real lock, without the debugger. The CPU completed in 12835 cycles.
Let's solve it.