Johannesburg

Break main

Continue into main

Only 1 function, login

Step into login

Move sp to 43ec and then shove \x7e into it.

Looks like it puts strings to screen, gets input, then calls strcpy, then checks password. Will break at test password valid function, continue through until break point, input test password, and note memory location of password just prior to test.

Test password is located at 0x43ec AND 2400. No memset called after strcpy this time...

Set breakpoint right after this call at tst r15, and step into function. 

While slightly different, it appears that this does the same nonsense as the other check password functions from previous challenges (push \x00 into -0x4r4, then mov.b -0x4r4 into r15 right before return)

Step through and observe activity, just in case I'm wrong. Looks like its the same. r15 set to 0 on exit of test, doesnt appear to be any password comparing at all?

Back in login function, looks like tst will rail and we will jump. I set many breakpoints at all the jmps, calls, returns.

Stepping through the rest of the login function, we fail the tst and jump down to 0x3f40 and put "this password is incorrect"

Then it checks to see if \x7e is 17 bytes after sp. Sp is currently pointed at the start of my password. 

It looks like 7e is there, from the instruction at 0xf140. 

this cmb.p will pass, and to we will jump to 0x3150, move sp 18 bytes, ret our of login into stop_progExec.

RESET

Fill with As

Continue through, fail the tst, and step through the remainder of login. This time however, I fail the cmp.b, so I do not jump, and I continue down to mov / put "Invalid Password Length: password too long" and then break program execution.

So no matter what I do, I need the 17th byte to be \x7e, so reset, fill with \x7e.

Continue though to 0xf190 where the cmp.b \x7e is, step through and jump down to the add instruction.

After the cmp and jeq, is successful, we can see that there are indeed more bytes than 16, and if we step through the remainder of the program, we can see that it does indeed try to execute 0x7e7e  before it finished executing, and then crashes.

RESET

Continue through until password prompt

Lets try and control pc, 

I know the 17th byte needs to be 7e, so I need to identify where in the buffer it is trying to execute. My first instinct is that I will need to pass it a memory location that either starts with or ends with 7e. So Ill fill first 16x bytes with A and then 7e, and the last 16 bytes with B.

Except it cleanly exits.

I'm thinking endianness is off, and even though I input 7e as the 17th byte, its taking the input of 7e42, and little endianing (<--- is endianing a word?) them in memory to be 427e. I check memory, and it looks like I just miss counted.....

Reset, try again.

This time, 7e is in the 17th byte location, however it still cleanly exits.

Ill add another 7e so the 17th an 18th byte are both 7e, incase its inverting my bytes.

Success!

so it looks like its attempting to execute 4242 upon crash.

Ill change up the second half of my password string, with all hex options (but not \x00) and see exactly which chars I need to change up.

Continue through until crash.

Looking at pc at time of crash, it appears to be executing 0201, so its the first two bytes after 7e that I need to put my memory location into. 

Looking through the disassembly, it looks like the unlock door function is in this program.

login function calls 0x4446 <unlock_door>, so I scroll to 4446, and it is indeed there.

It is indeed there, and it looks the same as the previous unlock door functions. So Ill put in that memory location.

RESET

New Pass: 414141414141414141414141414141417e7e4644

Continue through until end and BOOM

Door unlocked.

Notes:

I'm a little confused on MC's challenge order. This one was SIGNIFICANTLY easier than the previous challenge, which I had to complete in order to unlock this challenge. I think I must have missed something in the previous challenge, and I made it harder than it needs to be? Anyways, this was a fun little one.