Challenge 6 was a 64 bit statically linked ELF binary. Now I haven't yet finished solving it (hey it's hard ;)) but have got through half of it. I needed a tiny hint though this time to set me on the right track. Anyway though...its complex enough that I can write about Part 1. Later maybe I'll add Part 2 once I solve it someday. If not and I look at spoilers, I'll try and blog about the learnings :). Ok lets start.
Once I ran file and identified it was statically linked, I sighed inwardly. That's coz static binaries have the Linux libraries that they are linked to as part of the binary. This ensures that these binaries will run on any system - unlike when there is dynamic linking in place, and dependency on specific libraries. From a reverse engineering standpoint this is bad, because the disassembly in IDA is cluttered with library code and its super hard to identify what code is user written.
Ran the file in a VM. Always make sure you run the file in a VM. All it did was come back with "no". That's it. So the next thing is to find out where the "no" was referenced. So after a bit of stepping in and stepping out, the call at 45dea0 looked suspicious - it pointed to another function at 45dce0. This eventually makes a call to sub_452079. A quick tip incase you start to debug 452079 but forget where it was called from is to either:
-- Hit ESC to go back and Ctrl+Enter to come forward again
-- Or right click on sub_452079 in the IDA View and click List cross references to
Anyway, on first sight 452079 looks like a gold mine with a ton of juicy strings. Every single one of them is utter garbage. So I just kept scrolling in IDA till I saw the last (or so I thought) strings go by. And set a breakpoint after that. Sometimes it'd not hit my breakpoint because it's position was wrong. But slowly, after a few attempts, I managed to find out where the "No" was getting called from - 4535bb. And then the very next call at 4535c5 was causing the program to exit.
So one thing was then clear, I had to skip that jump for sure, so I used a little bit of gdbinit magic :) for now to patch the program in memory and see where it leads me. The .gdbinit file is something that gdb runs commands from before starting to run the program.
------
br *0x4535b4
commands
set $ps=$ps&0x4
continue
end
-------
This basically breaks execution at 4535b4 and unsets the zero flag so execution can jump over the exit code, and then continues execution.
Well, that worked for a while but then I crashed after some time with a very fishy looking "Program has a segfault" error. Digging further revealed that all this was happening at 41F21C. So usually when something like that happens, the code that is making that happen is usually in the call just above that. So.. digging into the call at 41F211..revealed that there was a line at 474319 which made a syscall and had an argument of 0x65 [syscall(0x65)]. This means that there is some kind of system call being made...and it's very interesting many times ;). But we need to find out what 0x65 stands for. So let's search for a syscall table online. We find a nice one at:
https://filippo.io/linux-syscall-table/
What's 65? semop. Eh? Linux IPC? Wtf. What does that even mean? Ah its Hex. And the table is decimal :). 65 in hex is 101 in decimal and that...is ptrace. Ah that makes sense. ptrace() is a call on Linux that detects if code is running inside a debugger, like us. gdb remember? So we need to run outside gdb. But then how do we find out what's going on? We can't. So we do some more gdbinit magic. Heh.
----------------
br *0x41f21c
commands
set $ps=$ps|0x40
continue
end
-----------------
Okay, that sets the zero flag, because this time ..that's what we want and jump to 41F232...not to the silly SEGV message.
Great...then we continue debugging...and the program just hangs. Like just hangs. Nothing I do makes a difference. In the past, when I've debugged and a program has hung, it's been because it's potentially waiting for some network connection and listening. Checking with netstat and lsof revealed nothing this time, so the next logical candidate was a long long sleep() call.
So .. hitting a Ctrl+C inside gdb gave me the address of where the "hanging" was happening.
--------------
Breakpoint 2, 0x000000000041f21c in ?? ()
^C
Program received signal SIGINT, Interrupt.
0x0000000000473d50 in ?? ()
--------------
Hmm... 473d50. What's there? Ha. Another syscall...this time its 0x23. Or 35 in decimal. Lets go back to our syscall table again. Ah there we go. nanosleep(). Man page - "nanosleep() suspends the execution of the calling thread until either at least the time specified in *req has elapsed"
ok..that's the first argument to nanosleep() then which is some huge number. Now where is the first argument stored. It's called from 473C67...and the arguments are stored in the lines just above that. That's rdi and rsi then. That's how things happen in Linux...the arguments are stored in registers and not explicitly pushed on to the stack like in Windows. So... if we can edit rdi to a smaller value than what's currently there....which is
(gdb) x/d $rdi
0x7fffffffd530: 3597
(gdb)
...that's 3597 seconds. 1 hour. I'm not sure we want to wait for an hour before resuming debugging. So I did some more gdbinit magic and edited rdi at runtime to 0x10.
--------------------------
br *0x473c67
commands
set $rdi=0x10
continue
end
--------------------------
... which should have caused sleeping for 10 seconds. But it didn't and almost returned instantly. :D. Not sure why. Didn't dig too deep though as my purpose was to get past the sleep() call.
The code went on ..after this. But if you're still following along I'd advise you to straight away put a breakpoint on 44bb2b :D. Coz all the code .. well most of it :) after the nanosleep() and before 44bb2b is utter utter junk and you'll just waste hours stepping in and out.
There is a call here to 44b942. Scroll down here as well...until you see the last 2 calls inside this function. A little debugging reveals that the call at 44bb2b is an exit call and the program just exits here. Which usually, usually means that the call before that has some juicy stuff. This is the call at 401164. But while this function looks different and interesting....its very unclear where the flag is hidden here. Coz all that happens inside here is a lot of integer operations and some fancy math :(.
Now at this point I got stuck and decided to ask for help on reddit. 2 people who had already solved it very kindly poked me in the right direction ..while talking about arguments. Ah... the program has arguments? How many? What? Time for strace. Thanks guys :)
strace ./C6 1234 abcd ... shows me that SEGFAULT message. Means its 2 arguments. Nice. I'm still unclear though, about how to identify via static analysis...how many arguments a program takes.
Anyway... so then logically, what are those arguments? So running the function with no arguments...if you remember gave us "No"...but running it with 2 arguments gives us "bad". Trying to figure out where bad came from in the first place was another big pain.
Eventually though as it turns out...bad is called from 2 places 43710a and 4371DE. The first one checks if the 1st argument has 10 digits
cmp rax, 0xa
and if that's satisfied...it goes on to 437120 ...else it goes to "bad". The second "bad" message is at 4371DE.... and the comparison is at 4734b4. Now this was the first place I found that IDA was wrong. :-o. This caused more chaos. Eventually with gdb's help I found out that the comparison was happening at 4734b4.
.text:00000000004734AE mov eax, [rdi-0Ah]
.text:00000000004734B1 mov ecx, [rsi-0Ah]
.text:00000000004734B4 cmp eax, ecx
Now one of these (I forget which) contains a string "bngcg`debd" and the other...I have to enter the right input so it computes to this string. A little bit of playing around with 10 digit numbers and I found the right number. (I think I got lucky here directly with numbers, I could have easily tried strings and struggled a while longer :D)
The first argument is 4815162342.
I haven't figured out what the 2nd argument is...and want to slog at this a while more before reading the many great solutions to this that are already online. But...this was complex enough for me to put it out :)
Hopefully I'll have part 2 soon. Until then ...adios :)
Once I ran file and identified it was statically linked, I sighed inwardly. That's coz static binaries have the Linux libraries that they are linked to as part of the binary. This ensures that these binaries will run on any system - unlike when there is dynamic linking in place, and dependency on specific libraries. From a reverse engineering standpoint this is bad, because the disassembly in IDA is cluttered with library code and its super hard to identify what code is user written.
Ran the file in a VM. Always make sure you run the file in a VM. All it did was come back with "no". That's it. So the next thing is to find out where the "no" was referenced. So after a bit of stepping in and stepping out, the call at 45dea0 looked suspicious - it pointed to another function at 45dce0. This eventually makes a call to sub_452079. A quick tip incase you start to debug 452079 but forget where it was called from is to either:
-- Hit ESC to go back and Ctrl+Enter to come forward again
-- Or right click on sub_452079 in the IDA View and click List cross references to
Anyway, on first sight 452079 looks like a gold mine with a ton of juicy strings. Every single one of them is utter garbage. So I just kept scrolling in IDA till I saw the last (or so I thought) strings go by. And set a breakpoint after that. Sometimes it'd not hit my breakpoint because it's position was wrong. But slowly, after a few attempts, I managed to find out where the "No" was getting called from - 4535bb. And then the very next call at 4535c5 was causing the program to exit.
So one thing was then clear, I had to skip that jump for sure, so I used a little bit of gdbinit magic :) for now to patch the program in memory and see where it leads me. The .gdbinit file is something that gdb runs commands from before starting to run the program.
------
br *0x4535b4
commands
set $ps=$ps&0x4
continue
end
-------
This basically breaks execution at 4535b4 and unsets the zero flag so execution can jump over the exit code, and then continues execution.
Well, that worked for a while but then I crashed after some time with a very fishy looking "Program has a segfault" error. Digging further revealed that all this was happening at 41F21C. So usually when something like that happens, the code that is making that happen is usually in the call just above that. So.. digging into the call at 41F211..revealed that there was a line at 474319 which made a syscall and had an argument of 0x65 [syscall(0x65)]. This means that there is some kind of system call being made...and it's very interesting many times ;). But we need to find out what 0x65 stands for. So let's search for a syscall table online. We find a nice one at:
https://filippo.io/linux-syscall-table/
What's 65? semop. Eh? Linux IPC? Wtf. What does that even mean? Ah its Hex. And the table is decimal :). 65 in hex is 101 in decimal and that...is ptrace. Ah that makes sense. ptrace() is a call on Linux that detects if code is running inside a debugger, like us. gdb remember? So we need to run outside gdb. But then how do we find out what's going on? We can't. So we do some more gdbinit magic. Heh.
----------------
br *0x41f21c
commands
set $ps=$ps|0x40
continue
end
-----------------
Okay, that sets the zero flag, because this time ..that's what we want and jump to 41F232...not to the silly SEGV message.
Great...then we continue debugging...and the program just hangs. Like just hangs. Nothing I do makes a difference. In the past, when I've debugged and a program has hung, it's been because it's potentially waiting for some network connection and listening. Checking with netstat and lsof revealed nothing this time, so the next logical candidate was a long long sleep() call.
So .. hitting a Ctrl+C inside gdb gave me the address of where the "hanging" was happening.
--------------
Breakpoint 2, 0x000000000041f21c in ?? ()
^C
Program received signal SIGINT, Interrupt.
0x0000000000473d50 in ?? ()
--------------
Hmm... 473d50. What's there? Ha. Another syscall...this time its 0x23. Or 35 in decimal. Lets go back to our syscall table again. Ah there we go. nanosleep(). Man page - "nanosleep() suspends the execution of the calling thread until either at least the time specified in *req has elapsed"
ok..that's the first argument to nanosleep() then which is some huge number. Now where is the first argument stored. It's called from 473C67...and the arguments are stored in the lines just above that. That's rdi and rsi then. That's how things happen in Linux...the arguments are stored in registers and not explicitly pushed on to the stack like in Windows. So... if we can edit rdi to a smaller value than what's currently there....which is
(gdb) x/d $rdi
0x7fffffffd530: 3597
(gdb)
...that's 3597 seconds. 1 hour. I'm not sure we want to wait for an hour before resuming debugging. So I did some more gdbinit magic and edited rdi at runtime to 0x10.
--------------------------
br *0x473c67
commands
set $rdi=0x10
continue
end
--------------------------
... which should have caused sleeping for 10 seconds. But it didn't and almost returned instantly. :D. Not sure why. Didn't dig too deep though as my purpose was to get past the sleep() call.
The code went on ..after this. But if you're still following along I'd advise you to straight away put a breakpoint on 44bb2b :D. Coz all the code .. well most of it :) after the nanosleep() and before 44bb2b is utter utter junk and you'll just waste hours stepping in and out.
There is a call here to 44b942. Scroll down here as well...until you see the last 2 calls inside this function. A little debugging reveals that the call at 44bb2b is an exit call and the program just exits here. Which usually, usually means that the call before that has some juicy stuff. This is the call at 401164. But while this function looks different and interesting....its very unclear where the flag is hidden here. Coz all that happens inside here is a lot of integer operations and some fancy math :(.
Now at this point I got stuck and decided to ask for help on reddit. 2 people who had already solved it very kindly poked me in the right direction ..while talking about arguments. Ah... the program has arguments? How many? What? Time for strace. Thanks guys :)
strace ./C6 1234 abcd ... shows me that SEGFAULT message. Means its 2 arguments. Nice. I'm still unclear though, about how to identify via static analysis...how many arguments a program takes.
Anyway... so then logically, what are those arguments? So running the function with no arguments...if you remember gave us "No"...but running it with 2 arguments gives us "bad". Trying to figure out where bad came from in the first place was another big pain.
Eventually though as it turns out...bad is called from 2 places 43710a and 4371DE. The first one checks if the 1st argument has 10 digits
cmp rax, 0xa
and if that's satisfied...it goes on to 437120 ...else it goes to "bad". The second "bad" message is at 4371DE.... and the comparison is at 4734b4. Now this was the first place I found that IDA was wrong. :-o. This caused more chaos. Eventually with gdb's help I found out that the comparison was happening at 4734b4.
.text:00000000004734AE mov eax, [rdi-0Ah]
.text:00000000004734B1 mov ecx, [rsi-0Ah]
.text:00000000004734B4 cmp eax, ecx
Now one of these (I forget which) contains a string "bngcg`debd" and the other...I have to enter the right input so it computes to this string. A little bit of playing around with 10 digit numbers and I found the right number. (I think I got lucky here directly with numbers, I could have easily tried strings and struggled a while longer :D)
The first argument is 4815162342.
I haven't figured out what the 2nd argument is...and want to slog at this a while more before reading the many great solutions to this that are already online. But...this was complex enough for me to put it out :)
Hopefully I'll have part 2 soon. Until then ...adios :)
No comments:
Post a Comment