Jekyll2026-03-19T12:58:57+00:00https://jiva.io/feed.xmljivajiva's homepageMicrocorruption CTF Jakarta Write-up2018-06-24T15:20:00+00:002018-06-24T15:20:00+00:00https://jiva.io/blog/microcorruption-ctf-writeup-jakartaSummary:
This is a write-up of my solution to the Microcorruption CTF challenge “Jakarta” (LOCKIT PRO r b.06).
From the challenge overview, they indicate that input length checking has been
beefed up some more:
OVERVIEW
- A firmware update further rejects passwords which are too long.
- This lock is attached the the LockIT Pro HSM-1.
Let’s dissect the code and see what they’re up to.
In the main() function we see a similar call to login(). However in this
program, we’re presented with a message indicating that we need to provide a username and password. Additionally, they indicate that a length restriction
is in place:
Authentication requires a username and password.
Your username and password together may be no more than 32 characters.
Further down, we see multiple call to puts(), two calls to strcpy() and then some code that surrounds a call to unlock_door().
Let’s run the program and see how the stack looks like after the first strcpy()…
We’ll start off by entering AAAAAAAAAA as the username and setting breakpoints before and after the first strcpy().
We see that the username is copied to the stack starting at address 3ff2. Also note, there appears to be a return address not too far away from our input on the stack, located at address 4016 and containing 4440. This is the return address from the call to login() from main(). Also pay attention to the instructions starting at address 45c8 - we’ll discuss this in a bit.
Before we move on to the second strcpy(), let’s see what happens when we try to overflow the return address with a long username…
The offset to the return address is 36-bytes. We input AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABB and watch as the return address is replaced with 4242. However, the program errors out because we failed the cmp.b #0x21, r11 check. Bummer, I guess we have to keep trying :frowning:.
Notice from the first video what was happening at 45c8, where we passed the first length check and stepped through the following code:
The program loads the value 0x1f into r14 then subtracts r11 (the length of the username) from it, which effectively gives us the allowed length of the password. Once getsn() is called, r14 and r15 is pushed on to the stack, and then we’re prompted to enter in a password. It’s not clear from the code, but r14 appears to contain an upper limit of the number of bytes that can be read in from getsn() into the input buffer (which is located at 2402 and pointed to by r15).
This means that we’ll be unable to read in more than 0x1f-len(username) number of bytes… Or does it? Let’s see what happens when we input 32-bytes:
Because of an integer-underflow vulnerability, we’re able to increase the password buffer read-limit from 0x1f-len(username) to 511 bytes (0x01ff), all while staying within the length check (cmp.b #0x21, r11) - sweet!
Now that we’re able to get more than 32 bytes onto the stack, let’s try to overflow the return address (located at 4016) with a 6-byte password…
Although we’re able to successfully overwrite the return address, the program calls __stop_progExec__ before returning. :pouting_cat:
Stepping through the code, we can see that there’s an additional length check occurring at 45ee:
After our password is copied onto the stack, the code iterates over the password that’s in the input buffer (which is not on the stack), and calculates the combined length of the username and password which will be stored in r15.
Then, if the calculated length is greater than 0x21, the program exits without returning.
However, pay close attention to the comparison instruction being used: cmp.b
All single-operand and dual-operand instructions can be byte or word
instructions by using .B or .W extensions. Byte instructions are used to access
byte data or byte peripherals. Word instructions are used to access word data
or word peripherals. If no extension is used, the instruction is a word
instruction.
The .b means that the comparison is performed on the lower byte of r15!
What if we were able to roll the length past 0xff? Remember that we were able to
find a bug that increased the password read length to 511. I think we’re on to something :smirk_cat: …
We’re able to control PC! By using a 224-byte password (with the 5th and 6th byte overwriting the return address), we’ll roll the final value in r15 when it gets added to r11 (i.e. 0x20 + 224 == 256 == 0x100), and when the cmp.b instruction is performed, we’ll effectively bypass the length comparison. Then instead of exiting out of the program, the code finishes until it returns. Let’s try jumping execution to unlock_door() instead of 4141…
This is a write-up of my solution to the Microcorruption CTF challenge “Montevideo” (LOCKIT PRO r c.03).
In the manual, they claim to have increased their security practices:
OVERVIEW
- Lockitall developers have rewritten the code to conform to the
internal secure development process.
- This lock is attached the the LockIT Pro HSM-2.
We’ll see about that :wink:. Let’s take a look at the code.
Looking at the main() function, we can see that a single function named login() is called.
Inside of login(), we see that after a password prompt, a call to strcpy() is made. The password prompt itself, “Remember: passwords are between 8 and 16 characters.”, implies that there’s some sort of length checking in place. Let’s play around in the debugger and see if this is actually the case.
After setting breakpoints before and after the call to strcpy(), we run the program and enter AAAAAAAAAA as the input. We keep an eye the address pointed to by the stackpointer (sp == 43ee) and watch the function place our input onto the stack.
Pay close attention to the bytes soon after our input ends: 3c44. If you stepped through the program from the beginning, you’ll notice that this value on the stack is actually the return address (443c) that was pushed as a result of the call to login() from main() originally! Let’s try overwriting these bytes (which are at offset 17 and 18), and see if we can control the program counter…
We try the input BBBBBBBBBBBBBBBBAA and watch the memory address containing the return address get overwritten. After continuing execution past the second breakpoint, we see the program crash and pc contain 4141! :feelsgood:
Now that we’ve confirmed a stack buffer overflow vulnerability exists, we need to find a way exploit it.
In classical buffer overflow exploit examples, the payload (usually shellcode) is stuffed at the beginning of the buffer that we’re overflowing.
Then, the return address is overwritten so that it points back to the start of our buffer.
When the executing function returns, the address of the buffer is popped into the program counter and our payload gets executed.
If we were to try something similar here, that means we’d have to stuff our payload into 16 bytes (because the 17th and 18th byte map to the return address on the stack). That’s not that much room :thinking:. Oh and don’t forget, if the payload includes any null bytes, strcpy() won’t copy the entire input to the stack :worried:.
Since this program contains the familiar conditional_unlock_door() function which pushes (a useless) 0x7e to the stack before calling the interrupt, I decided to write shellcode that will overwrite the 0x7e with 0x7f (the code to unlock the door).
After some careful trial and error with the assembler, I meticulously wrote the following code:
mov #0x7f01, r12 # load 0x7f01 into r12
add #-0x1, r12 # subtract 0x01 from r12 (resulting in 0x7f00)
swpb r12 # swap the two bytes (resulting in 0x007f)
mov r12, 0x445e(r6) # write 0x007f into 0x445e
call #0x4446 # call to conditional_unlock_door()
My shellcode will essentially put the value of 0x7f into register r12 (by performing some byte manipulations in order to avoid null-bytes in my payload), and will then replace the 0x7e in conditional_unlock_door() with 0x7f. After the overwrite happens, a call to conditional_unlock_door() is made…
Great Success! :boom:
3c40017f3c538c10864c5e44b0124644ee43
Note that the shellcode is exactly 16 bytes :sweat_smile:
This is a write-up of my solution to the Microcorruption CTF challenge “Novosibirsk” (LOCKIT PRO r c.02).
In this challenge, we’re giving a hint right from the start:
OVERVIEW
- This lock is attached the the LockIT Pro HSM-2.
- We have added features from b.03 to the new hardware.
If you recall from the b.03 challenge (Addis Ababa), we had to exploit a printf() vulnerability using %n to write to an arbitrary memory location.
Let’s see if we need to do something similar in this challenge…
Inside main(), we can see that printf() is called a few times as well as strcpy(). Let’s try entering AB%x and see what the program outputs.
We get back AB4241 - which means our input was placed into printf(). Awesome! Recall from Addis Ababa that we were able to use %n to write at arbitrary locations in memory. We’ll leave out the details of how to exploit format-string vulnerabilities, but if you need a primer, I recommend reading scut’s whitepaper “Exploiting Format String Vulnerabilities”.
Let’s check out the program again and figure out where we can write stuff to in order to unlock the door. Here’s the code for conditional_unlock_door():
From Whitehorse we learned that 0x7f is required to be pushed to the stack
(before the interrupt call) in order for the door to unlock. However we can see here that 0x7e gets pushed to the stack instead.
Thankfully, we can use the format %n, which will write the number of bytes read before it, to a location of our choosing. More specifically,
let’s write 0x7f to address 44c8 by using 127 (0x74) characters and an %n…
This is a write-up of my solution to the Microcorruption CTF
challenge “Whitehorse” (LOCKIT PRO r c.01).
I found this challenge to be relatively straightforward and easy to solve. Let’s check out what the program is doing.
After the call to main() and then login(), we see a new function named conditional_unlock_door() is being called.
After this call returns and if r15 is not 0x0, the message “Access granted” is printed and we return out of the function.
Let’s try some input and examine the state of the memory.
Our input AAAAAAAAAA is placed onto the stack. Following the password buffer, we can see the return address to 0x443c for when we return out of login().
After returning from getsn(), the stack pointer address sp is moved into register r15 and the program calls conditional_unlock_door().
The code will move some values around in the registers, and call the interrupt
with code 0x7e (?) and before returning, will execute the instruction
mov.b -0x4(r4), r15 which will move a null byte from before our password
buffer into r15. Because of this, the tst r15 instruction in login() will
fail.
Two things to note. First, we should be able to overwrite the return address 0x443c. Second, conditional_unlock_door() (the way it’s coded) will actually never
unlock the door. From the previous challenges, we learned that the code to the interrupt was 0x7f.
However, conditional_unlock_door() uses the code 0x7e, which doesn’t actually unlock the door. Bummer.
But… what if we injected the instructions to the old unlock_door() onto the stack
(via our password buffer) and returned execution to it? After all, it’s only 12 bytes
long and should fit in the buffer with room to spare before we reach the return
address.
Let’s whip up our new payload, making sure we fix the address of the call to INT()
give it a shot…
:+1: :beers:
Flag (mouse over to reveal)
30127f00b01232452153304141414141743e
]]>jivaMicrocorruption CTF Santa Cruz Write-up2017-09-10T21:05:00+00:002017-09-10T21:05:00+00:00https://jiva.io/blog/microcorruption-ctf-writeup-santa-cruzSummary:
This is a write-up of my solution to the Microcorruption CTF
challenge “Santa Cruz” (LOCKIT PRO r b.05).
This challenge required a few tricks in order to unlock the door, so let’s get down to it.
The meat of the logic lives inside login(), and there’s substantially more going on here than compared
with the previous challenges. Let’s dissect it and learn what it’s doing…
The first part of login() outputs a message to the user indicating that a username and password are both required.
The second part of login() prompts a message asking for a username. After submitting the username, the code prints
it back to the user, and then it is copied onto the stack.
The third part of login(), similar to the last one, prompts a message asking for a password. After submitting the password,
the code will print it back to the user, and will go on to copy the password onto the stack.
Let’s go into the debugger and pause execution at this point and observe what the memory looks like (I’ll use 10 A for
the username and 10 B for the password)…
We can see that after the second call to strcpy(), our username was copied onto the stack starting at 0x43a2, and our password
was copied onto the stack starting at 0x43b5. Notice that the program left 16 bytes on the stack for the username,
in addition to a null byte. Then we see two bytes, 0x08 and 0x10, followed by our password.
Also note that about 6 bytes after the end of the password
buffer, we see the bytes 0x4044, which looks like the return address from the login() call inside main().
Let’s keep this in mind and continue dissecting login().
After the second call to strcpy(), this part of the code will loop through the bytes of the password while at the same time
incrementing a byte offset pointer which is located in r14. If the value at the address location of r14 is 0x0,
the jnz will not be executed.
At this point, the length of the password will be calculated by subtracting the byte offset pointer located in r14 with the pointer
to the beginning of password located in r15. This length will be stored in r11. This is where things get a little interesting.
The instruction mov.b -0x18(r4), r15 will move the byte 0x10 from the memory located between the username and the password
on the stack into r15. Then sxt r15 will perform a sign-extend on r15, and after this, cmp r15, r11 will compare the two
registers (in our example, r11 == 0x000a and r15 == 0x0010). The following jnc instruction will jump execution to
0x45fa if r11 is greater than r15, else, an “Invalid Password Length” error will be printed and execution will be halted.
It’s clear that 0x10 is a length value that we can potentially control with an overflow… Let’s continue.
This next chunk of code will move the byte located at r4 - 0x19 (the 0x08 before the 0x10) into r15, will do a
sign-extend on r15, and then will cmp r15, r11 (r5 == 0x08, r11 == 0x000a). If r11 is less than r15, the
program will print an error message indicating the password length was too short, and will exit.
We now know that the two bytes between the username and password buffers are length fields that we can potentially control.
Let’s figure out the last part of the login() function…
The instructions between 0x4610 and 0x462a are manipulating registers in various ways and are pushing
various addresses (related to the username and password buffers)
onto the stack. After the call to the interrupt, things become interesting. Let’s set a breakpoint on the tst.b instruction
at 0x4634 and examine the stack…
Notice how the program is going to test the memory location at r4 - 0x2c (0x43a0 a.k.a. sp) for 0x0, and
if it is, will continue to jump to 0x4644 which will eventually exit the code. This is
strange because it appears that this memory is never going to contain anything besides0x0, due to the fact that
earlier in the code, the instruction mov.b #0x0, -0x2c(r4) was executed.
After printing out the message “That password is not correct”, we encounter another tst.b instruction, however
this time, we are checking the address r4 - 0x6. If these two tst instructions pass, we will eventually
return out of the function. So what can we do with this?
Remember the return address pushed onto the stack from the call to login() from main()? Check out the memory dump
and the location in relation to the password buffer. Surely we can reach it by overflowing one of the buffers! However,
we must account for a number of checks that are in place. Let’s recap:
The byte value 0x10 (address 0x43b4) will be used to check the max length of the password.
The byte value 0x08 (address 0x43b3) will be used to check the min length of the password.
The memory address 0x43a0 (tst.b r4 - 0x2c) must contain 0x0.
The memory address 0x43c6 (tst.b r4 - 0x6) must contain 0x0.
If we can satisfy these conditions, then we can cleanly reach the location of the return address on the stack, while
at the same time avoiding any premature calls to __stop_progExec__(). Sweet!
We should be able to safely ignore the check happening at #3; this area is towards the top of the stack, and
the parts that we are going to modify are below this. Our payload will be split across two strings.
The username will overwrite both the min-length byte and the max-length byte, and we need to make sure that the
max-length byte is >= the length of whatever password we decide. The min-length byte needs to be <= the password
we choose.
We need to overwrite the return address located at r4, however #4 requires that a byte between the end of the
original password buffer and the return address must be 0x0. Because strcpy() terminates the copy on null bytes,
we cannot have any null bytes in our payload, therefore, we cannot overflow the password buffer to overwrite the return
address. However, we can overflow the username buffer and not only overwrite the length values, but write all the way
until we overflow the return address. So how will we write the null byte to satisfy requirement #4? Well we can just have
strcpy() null terminate the string for us, right where we need the null byte! Let’s craft our payloads and cross our
fingers…
This is a write-up of my solution to the Microcorruption CTF
challenge “Johannesburg” (LOCKIT PRO r b.04).
This challenge does away with printf() altogether. Probably for the best.
Let’s check out what they have up their sleeve for this one.
Let’s try running the program with AAAAAAAAAAAAAAAAAAAA and see what happens…
We see the message Invalid Password Length: password too long. It appears as if they
may have finally implemented proper bounds checking. I’m still a little suspicious. Let’s
try a lot more A's (like 100 or so)…
In addition to the password length message, we notice a few more things:
More than 16 bytes were allowed to be input
We actually overwrote part of the data segment in memory (e.g. see [overwritten])
The user input is actually being copied to a higher location in memory
Since main() only calls login(), let’s dissect it and see how it works:
After prompting the user for input, strcpy() is eventually called
and our user input is copied onto the stack. This is where things get a little interesting.
After returning from the call to test_password_valid(), we eventually execute the jz #0x4570
instruction which will jump us to 0x4570, which will execute a puts() call
on the string That password is not correct. Immediately after, we execute the instruction
cmp.b #0xec, 0x11(sp), and then jeq #0x458c <login+0x60>. That’s a really strange cmp
instruction - the code is checking to see if the memory location after the buffer on
the stack is 0xec, and if it isn’t, proceeds to call puts() on
Invalid Password Length: password too long. Let’s set a break point on that cmp instruction
and check out what the debugger looks like when it pauses. We’ll try using 10 A's this time,
so as to not corrupt any memory…
It looks like the code is using a hard-coded stack canary (which lives at 0x43fd)!
If the canary is over-written, the program uses this logic to assume that the length of the
user input was too long. However, we can control what’s overwritten memory location of the stack canary - Great!
Right after the location of the stack canary in memory, we see another interesting pair of bytes:
0x3c44 (or when reversed, 0x44c3). Recall the memory values after the call to main():
4438 <main>
4438: b012 2c45 call #0x452c <login>
443c <__stop_progExec__>
443c: 32d0 f000 bis #0xf0, sr
As it turns out, 0x443c is the return address pushed onto the stack from the call to login()
from main(), which is conveniently placed right after the value of the stack canary in memory!
Sounds like we’re ready to craft our exploit. We’ll load up the buffer with A's, place the
stack canary value 0x3c at the 18th byte offset, and we’ll overwrite the return address to 0x4566
(the call to unlock_door() from login())…
This is a write-up of my solution to the Microcorruption CTF challenge “Addis Ababa” (LOCKIT PRO r b.03).
Right off the bat, in the description of the challenge, we get a hint dropped:
OVERVIEW
- We have verified passwords can not be too long.
- Usernames are printed back to the user for verification.
- This lock is attached the the LockIT Pro HSM-1.
Let’s see exactly how the program is going to print back the usernames to the user…
This code is significantly larger than the last one. However, it’s very clear that they changed
one major thing: the use of printf() instead of puts().
Let’s just play around with the inputs and see what the program spits back out…
It looks like whatever input string we give it (e.g. AAA:BBB), the program will print back.
All signs are pointing to a format string vulnerability, but let’s verify that’s actually the case by
throwing a few %x's at it and seeing if we get anything interesting back…
Sweet! Upon inputting AA%x%x, we get the output AA4141, which means
that we are reading two 1-byte hex-encoded parameters from the stack (i.e. the A's at the beginning of our input).
I won’t spend time explaining how format string vulnerabilities work in this writeup, but you can check out
scut’s whitepaper “Exploiting Format String Vulnerabilities” for a useful guide.
Now let’s try and see if we can use %n to write to a location in memory. I’ll use the input value
BA%x%n to start with. Also, I’ll set a breakpoint at memory location 0x46b2 inside of login(),
which is the cmp.b #0x6e, r14 instruction. This should allow us to break on the handling of the
%n (n == 0x6e) format string parameter and lets us examine the registers and memory during execution.
As you can see, by using the %n parameter, we were able to overwrite the memory address 0x4142 (e.g. BA, the first
two bytes of our input) with the value that was in register r10
(i.e. 0x2, the number of bytes written out by printf()). Great!
Now, let’s take a step back and see exactly what we need to do to unlock the door…
Inside of main(), we can see that after the call to printf() returns, the instruction tst 0x0(sp)
will execute. This instruction will test the sp register against 0x0, and will jump over the
unlock_door() call if it’s zero. Let’s set a breakpoint this on instruction and
input AAAA and see what the registers look like…
Looks like 0x40c4 has a 0x0 value and indeed prevents the call to unlock_door() from executing.
I wonder what will happen if we use our newly weaponized format string vulnerability and write
a non-zero value to the sp register (location 0x40c4)…
This is a write-up of my solution to the Microcorruption CTF challenge “Cusco” (LOCKIT PRO r b.02).
This version claims to fix the conditional flag overwrite issue that we exploited in the last challenge:
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.
This indeed appears to be the case.
Let’s check out the entire program and then see if we can figure out what’s going on:
So I’ll admit, this one took me a little longer to figure out. Let’s go through the
basic steps I took to see where I got stumped:
main()
4438 <main>
4438: b012 0045 call #0x4500 <login>
All main() does is make a call to login(). Let’s follow login()…
After a few calls to puts() to print out the password prompt message,
the code makes a call to test_password_valid(). Upon returning, login()
tests the value of r15 (at 0x4524). If r15 is not 0, we skip the jz instruction
at 0x4526 and proceed to unlock_door(). Let’s pay attention to r15 while
test_password_valid() is executing…
After shifting values inside of various registers/memory, the instruction mov.b -0x4(r4), r15
eventually sets a 0 value into r15. The instruction sxt r15 (sign extend)
is executed on r15 (effectively doing nothing since the value is 0x0),
and soon returns back into login(), where r15 is tested against 0. It does not
appear that we have any influence over the memory address that’s moved into r15 :anguished:.
After racking my brain for a while, and continuously stepping through various parts of program,
I noticed something interesting…
This version of the code isn’t storing our input at 0x2400 as it was originally, and
instead is much closer to the program counter!
Notice how close our user input (AAAAAAAAAA) is to pc.
I wonder if we can overwrite parts of the program code!
Let’s try a bunch of A's and see what happens…
Looks like we can! Another interesting thing to note, I tried to input about 200 or so A's,
but only 48 were copied onto the stack. I suspect maybe during the copy onto the stack,
__do_copy_data() is being invoked and we’re overwriting instructions as we’re in the
middle of executing them? I wasn’t able to step the code to this level of precision so I’m not sure.
However, this is sort of a moot point because of what happens as a result of inputting
so many bytes…
We can control the pc register. Sweet! Now all we need to do is to figure out the byte offset
to reach pc and figure out a suitable location to jump the
execution to. After some experimenting with input strings of various lengths
and keeping an eye on the pc register, we can see that the 17th and 18th byte
of our input will overflow into the pc register. Let’s try overwriting pc with 0x4528, the
call #0x4446 <unlock_door> instruction inside login() which comes right
after the jz instruction we were trying so hard to bypass…
:+1: :beers:
Flag (mouse over to reveal)
414141414141414141414141414141412845
]]>jivaMicrocorruption CTF Hanoi Write-up2017-08-30T23:17:00+00:002017-08-30T23:17:00+00:00https://jiva.io/blog/microcorruption-ctf-writeup-hanoiSummary:
This is a write-up of my solution to the Microcorruption CTF challenge “Hanoi” (LOCKIT PRO r b.01).
main() this time only makes a call to a function called login(). Let’s dissect login():
Straight away, the instruction at 0x455a catches my eye, cmp.b #0xc7, &0x2410.
Ultimately, this instruction will compare the byte located at memory address 0x2410,
with the value 0xc7, and if they are equal, the door will unlock. Let’s set a breakpoint
on the instruction and inspect the memory region around 0x2410 when execution pauses.
When being prompted for the password, I used AAAAAAAAAA.
Check out the memory dump and notice where our input is (hint 0x2400).
Notice that right after the 16th byte, the 17th byte will land in 0x2410. Great!
Although the password prompt says to use a password of length 8 to 16 characters,
let’s try using a 17-byte password and attempt a one-byte overflow into 0x2410 with
0xc7 and see if we can unlock the door…
This is a write-up of my solution to the Microcorruption CTF challenge “Reykjavik” (LOCKIT PRO r a.03).
The last two challenges were relatively straightforward and pretty easy to solve. This version promises “military-grade encryption”:
This is Software Revision 02. This release contains military-grade
encryption so users can be confident that the passwords they enter
can not be read from memory. We apologize for making it too easy
for the password to be recovered on prior versions. The engineers
responsible have been sacked.
Let’s see what they have up their sleeves. As always, let’s check out what’s going on in main():
As you can see, this version does not have a call to check_password(). Instead, the program makes a
call to enc() and then makes another call to a mysterious portion of memory located at 0x2400. Interesting.
Another thing to note is that the memory located at 0x2400 doesn’t actually appear to contain anything interesting
before the program is run (i.e. contains a bunch of zeros):
Let’s set a breakpoint on the main() function and see if we can figure out what’s going on:
Did you catch that? It looks like the portion of memory located at 0x2400 is being allocated beforemain() is called.
Let’s step through the program as soon as it’s executed and keep an eye on 0x2400. Let’s also keep an eye on what
instructions are being executed:
We can see that before we enter into main(), a call is made to __do_copy_data().
In this function, 0x7c bytes are being copied from 0x4538 into 0x2400.
Interesting. Let’s continue on to enc() and observe what it does:
So… we can see that this subroutine is doing a number of things.
Let’s attempt to break down these instructions down slightly to get a sense of what’s going on:
Instructions 0x4490 to 0x449a are going to loop while loading bytes
0x00 to 0xff into the memory address starting at 0x0x247c.
Instructions 0x449c to 0x44d6 appears to be obfuscating the previously created 256 bytes
using the string located at 0x4472, ThisIsSecureRight?
Instructions 0x44d8 to 0x4510 appear to be using the previously obfuscated byte string
as an XOR key to the original data written at memory location 0x2400.
After returning back into main(), call #0x2400 is immediately executed. Stepping through
this code reveals sensible instructions are being executed.
It appears as though the bytes at memory location 0x2400 were originally obfuscated/encrypted,
and the call to enc() ultimately deobfuscated/decrypted this memory for us. Sweet! Let’s dissect these
bytes and disassemble them to see if we can see what instructions are going to be executed:
After stepping through this deobfuscated code, we can see that it is printing out the password input prompt.
After entering in the password and stepping forward a few instructions, we see that the program will exit or
continue based on the result of cmp #0xab11, -0x24(r4). In other words, the door should open if the password is
0xab11. Wow… so much for that “military-grade encryption”! Let’s try it out (don’t forget the byte order):
