#Reverse : CTF File

1 messages · Page 1 of 1 (latest)

oak chasm
#

What have you tried? There’s a strcmp and it asks for 2 arguments. Is it doing anti debugging techniques?

pallid grove
#

My advice would be that you don't have to understand the transformation if you can make the program do the work for you. Brute force is a viable option if you can use some extra and/or intermediate information from runtime/debugging to reduce the search space.

obtuse gyro
pallid grove
#

You should try some inputs and just observe their transformations, change your inputs a bit and observe again.

obtuse gyro
obtuse gyro
pallid grove
#

my "brute force" completes in just over 1 minute so it's not a real brute force imo. I don't think it's cheating :p

#

I used gdb yes, but there are some other options. I think edb-debugger from github provides a more visual interface that is more akin to x64dbg from windows (but less feature rich)

obtuse gyro
pallid grove
#

yeah earlier this morning

obtuse gyro
#

Ok THANKS !

obtuse gyro
obtuse gyro
#

ok il lauch bruteforce

#

i'm wainting

#

waiting

#

just @pallid grove Should the argument we use at the beginning be in the form FLAG{...} or can it be any arbitrary argument?

pallid grove
#

I think it's important to take the other things I said into account though:

My advice would be that you don't have to understand the transformation if you can make the program do the work for you. Brute force is a viable option if you can use some extra and/or intermediate information from runtime/debugging to reduce the search space.
and
You should try some inputs and just observe their transformations, change your inputs a bit and observe again.

A straight up brute force will take forever.

obtuse gyro
#

Ah... okay, I'll look into it then.

#

As I mentioned before, I think, I found this:
V0Xae3bTxyq9rtbj.

My reasoning is that our input is modified and then compared to this string, and if they match, we get the flag. So, I'm going to try brute-forcing by starting with this string and modifying it.

What do you think?

pallid grove
#

I think you shouldn't start brute forcing until you know with a good degree of certainty that it will lead to a valid result, but you should definitely try and see how things behave

obtuse gyro
#

Alright, I'll try debugging by injecting a character and using GDB to analyze what operations are being performed.

obtuse gyro
#

I'm looking everywhere, but it's all over the place, and I can't make sense of it. Do you have a little hint for me

#

I'm not good enough at reverse; I'll need to work on that.

pallid grove
#

I only looked at the tranformation code enough to decide that was a big mess I didn't want to dig into. What I meant earlier was that if you look at the input & output of the transformation code you might be able to think of ways to use that to find the password without understanding it. Basically input buffer of the transformation function before and after it executes, just observe what happens to that as a whole. Observe what a change in input does to a change in output.

#

pop "hello" into it, what comes out? What happens when instead you pop "yello" into it, etc

obtuse gyro
#

No matter what I put in, it outputs "Dommage...". I can't seem to do step by step or place a breakpoint.

pallid grove
#

yeah, it's a bit annoying because the binary is stripped

obtuse gyro
#

How did you manage to find the right answer just by trial and error? Did you get inspired by V0Xae3bTxyq9rtbj?

pallid grove
#

you can use starti in gdb to break automatically in the dynamic loader before the binary executes. You can then use info proc map to see where it is loaded in memory. From there you can place breakpoints on addresses you found in IDA with break *0xdeadbeef IDA will have the process loaded at some base address too (I use Ghidra, which had the base address of 0x10000 iirc).

obtuse gyro
#

i use ghifra too

#

okay i trie it

#

i search in stack in ghidra

pallid grove
# 
redshift@pico ~/random_mixed/folie_virtuelle $ gdb -q folieVirtuelle
Reading symbols from folieVirtuelle...
(No debugging symbols found in folieVirtuelle)
(gdb) starti hello
Starting program: /home/redshift/random_mixed/folie_virtuelle/folieVirtuelle hello

Program stopped.
0xf7fe29e0 in _start () from /lib/ld-linux.so.2
(gdb) info proc map
process 17661
Mapped address spaces:

        Start Addr   End Addr       Size     Offset  Perms   objfile
        0x56555000 0x56556000     0x1000        0x0  r--p   /home/redshift/random_mixed/folie_virtuelle/folieVirtuelle
        0x56556000 0x56557000     0x1000     0x1000  r-xp   /home/redshift/random_mixed/folie_virtuelle/folieVirtuelle
        0x56557000 0x56558000     0x1000     0x2000  r--p   /home/redshift/random_mixed/folie_virtuelle/folieVirtuelle
        0x56558000 0x5655a000     0x2000     0x2000  rw-p   /home/redshift/random_mixed/folie_virtuelle/folieVirtuelle
        0xf7fc2000 0xf7fc6000     0x4000        0x0  r--p   [vvar]
        0xf7fc6000 0xf7fc8000     0x2000        0x0  r-xp   [vdso]
        0xf7fc8000 0xf7fc9000     0x1000        0x0  r--p   /usr/lib/ld-linux.so.2
        0xf7fc9000 0xf7fed000    0x24000     0x1000  r-xp   /usr/lib/ld-linux.so.2
        0xf7fed000 0xf7ffb000     0xe000    0x25000  r--p   /usr/lib/ld-linux.so.2
        0xf7ffb000 0xf7ffe000     0x3000    0x33000  rw-p   /usr/lib/ld-linux.so.2
        0xfffdd000 0xffffe000    0x21000        0x0  rw-p   [stack]
(gdb) break *0x56556956
Breakpoint 1 at 0x56556956
(gdb) continue
Continuing.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Breakpoint 1, 0x56556956 in ?? ()
(gdb) x/5i $eip
=> 0x56556956:  lea    0x4(%esp),%ecx
   0x5655695a:  and    $0xfffffff0,%esp
   0x5655695d:  push   -0x4(%ecx)
   0x56556960:  push   %ebp
   0x56556961:  mov    %esp,%ebp
(gdb)
#

^ here's an example of setting a breakpoint on main with gdb

#

tbh I'm not very used to debugging with gdb so this might not be the best approach but it worked for me

# 
        00011956 8d 4c 24 04     LEA        ECX=>param_1,[ESP + 0x4]
        0001195a 83 e4 f0        AND        ESP,0xfffffff0
        0001195d ff 71 fc        PUSH       dword ptr [ECX + local_res0]
        00011960 55              PUSH       EBP
        00011961 89 e5           MOV        EBP,ESP

This is the start of the function you screenshotted in your OP. If you go window -> memory map you can see where the base address is for ghidra (it says so in the title of the memory map window). You just have to adjust for the base address you see in gdb.

obtuse gyro
#

okay

#

i trie it

#

It's the one that tells me "Dommage...".

#

i trie to do a break in this adress

#

maybe it's 000120d9 ?

image.png
#

i trie a breakpoint on is

pallid grove
obtuse gyro
#

I haven't mentioned it yet, but I really want to thank you for the time you're giving me for my CTF. I truly appreciate it. @pallid grove

pallid grove
obtuse gyro
#

Adresse_GDB = Adresse_Ghidra - Adresse_base
Adresse_GDB = 0x000120e4 - 0x00010000 = 0x000020e4

#

so for

#

i can do break *0x20e4
?

#

i trie it

pallid grove
#

keep in mind .rodata is data, not code. The data you mentioned is at (ghidrabase + 0x20E4), in gdb it will be at (gdb_base + 0x20E4)

#

but you can't breakpoint on data like that, only on code

obtuse gyro
#

hummm how can I do it then hahaha for you to get there so easily you must be good at reverse

pallid grove
#

what are you trying to do with the breakpoint? The address you mentioned is just after the "Dommage..." string

obtuse gyro
#

to tell you all I'm quite lost, as I told you the reverse I'm not good with it, and I try as best I can haha ​​and I also discovered gdb, I said to myself I'm going to put a break point for then maybe debug? but that doesn't seem to be the solution

pallid grove
obtuse gyro
#

Okay, I've had enough. Since last night, I've been at it, pulling an all-nighter trying to decipher the code with IDA and everything. Now, I've pinpointed the problem, but I'm running out of time and I'm completely exhausted. It's driving me crazy!

obtuse gyro
#

@pallid grove

gritty spear
obtuse gyro
#

OKKK

gritty spear
#

id reccomend you make sure you understand the assembly instructions happening at the bottom of the basic block. strcmp, add, test, and jnz

#

there are two paths the binary can take at the jnz instruction, you just want to influence it to take the other path

obtuse gyro
obtuse gyro
gritty spear
#

its worth a try

#

if you understand how the jnz branch is being taken you can understand how to influence it

#

bon chance or whatever they say in french 😉

obtuse gyro
pallid grove
#

Just altering the control flow isn't enough in this exercise because the block that prints the flag uses your input to print it

gritty spear
#

👍 ahh i thought that might be a risk

pallid grove
#

I do think debugger fluency is part of the issue here and gdb being entirely text based doesn't make that learning curve better

#

You already have to understand what is happening and know exactly what you want to inspect because the ui doesn't present it to you without you asking for it

gritty spear
obtuse gyro
#

@pallid grove when you succes have the flag, you do only gdb or ghidra ?

pallid grove
#

I used a mix of both to understand what was going on. Ghidra helped me figure out where to place breakpoints, then I used gdb to understand what happened and I also used gdb (sort of) to eventually extract the password and the flag.

obtuse gyro
#

okay and you used gihdra for the memory map or for other things

pallid grove
#

for looking around the code

obtuse gyro
#

@pallid grove i send you a message in dm ^^

obtuse gyro
#

@gritty spear thank you for your help but I didn't make it in time

#

and thanks for GEF !