# Csaw 17 Reversing 400 Realism

This writeup is based off of: `https://github.com/DMArens/CTF-Writeups/blob/master/2017/CSAWQuals/reverse/realism-400.md`

Let's take a look at what we have:

```
$    file main.bin
main.bin: DOS/MBR boot sector
```

So we are given a boot record. We are also given the command `qemu-system-i386 -drive format=raw,file=main.bin`, which when we run it displays a screen which prompts us for the flag. Also I wouldn't recommend doing this challenge on Ubuntu 19.04.

## MBR

x86 Real Mode 16

A couple of things about Master Boot Records that are extremely helpful to know going forward. They are always loaded into memory at the address `0x7c00`. So in gdb, we can just look at the assembly code by examining the memory starting at `0x7c00`. Secondly the code for this program is a sixteen bit assembly, in the `i8086` architecture. You will have to load it as an `x86` processor of size `16` in Ghidra. The third thing, in Ghidra when you load in the binary code will start at the address `0x0`. If you want, you can reload the binary to start at the address `0x7c00`, because that is what the address `0x0` will correlate to when it runs. For instance the address `0x1dc` in Ghidra would translate to the address `0x7ddc` when it runs (I use both address types interchangeably)

## Dynamic Analysis

When reversing this, using gdb to analyze the program as it is running is very helpful. Luckily for us, qemu has built in gdb support with the `-gdb` flag. Here is the command you need to run if you want to run the program with a listener on port `1234` (ip is localhost) for gdb:

```
$    qemu-system-i386 -drive format=raw,file=main.bin -gdb tcp::1234
```

and if you want to connect to the listener on localhost on port `1234` (before that we will set the architecture to `i8086`, so we can view the instructions properly):

```
gef➤  set architecture i8086
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB.  Attempting to continue with the default i8086 settings.

The target architecture is assumed to be i8086
gef➤  target remote localhost:1234
Remote debugging using localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000b601 in ?? ()
[ Legend: Modified register | Code | Heap | Stack | String ]
───────────────────────────────────────────────────────────────── registers ────
[!] Command 'context' failed to execute properly, reason: 'NoneType' object has no attribute 'all_registers'
gef➤  i r
eax            0x0                 0x0
ecx            0xb5e5              0xb5e5
edx            0x0                 0x0
ebx            0xdc80              0xdc80
esp            0x6efa              0x6efa
ebp            0x1234              0x1234
esi            0xfbb8              0xfbb8
edi            0x0                 0x0
eip            0xb601              0xb601
eflags         0x246               [ PF ZF IF ]
cs             0xf000              0xf000
ss             0x0                 0x0
ds             0x0                 0x0
es             0xdc80              0xdc80
fs             0x0                 0x0
gs             0x0                 0x0
```

Now that we have attached the process to gdb, let's see if the instructions begin where we would expect them to at `0x7c00`:

```
gef➤  x/4g 0x7c00
0x7c00: 0xc0200f10cd0013b8  0x220f02c883fbe083
0x7c10: 0x0f06000de0200fc0  0x000a126606c7e022
```

When we check the instructions / opcodes in Ghidra:
```
                             //
                             // ram
                             // fileOffset=0, length=512
                             // ram: 0000:0000-0000:01ff
                             //
             assume DF = 0x0  (Default)
       0000:0000 b8 13 00        MOV        AX,0x13
       0000:0003 cd 10           INT        0x10
       0000:0005 0f 20 c0        MOV        EAX,CR0
       0000:0008 83 e0 fb        AND        AX,0xfffb
       0000:000b 83 c8 02        OR         AX,0x2
       0000:000e 0f 22 c0        MOV        CR0,EAX
       0000:0011 0f 20 e0        MOV        EAX,CR4
       0000:0014 0d 00 06        OR         AX,0x600
       0000:0017 0f 22 e0        MOV        CR4,EAX
       0000:001a c7 06 66        MOV        word ptr [0x1266],0xa
                 12 0a 00
       0000:0020 bb 00 00        MOV        BX,0x0
```

So we can see here the same opcodes that we see at the start of the program (so we know that we know where the start of the code segment in memory is). Now the next step of reversing this is to identify the segment of code where the actual check happens. The elf is only `512` bytes long, so there isn't a lot of code to parse through. However, this is my first time reversing this type of architecture, and thus I am very lost.

So what I decided to do to figure out which code segments are responsible for the check, is set breakpoints at the start of various sub functions (in IDA they are titled something like `loc_8E`)

```
0x7c00

0x7c23

0x7c33

0x7c38

0x7c58

0x7c8e

0x7cdf

0x7d0d

0x7d31
```

When I ran the program normally, it just encountered the breakpoints at `0x7c58`, `0x7d0d`, `0x7c33` and `0x7c38` (in that order). So those four code segments are probably used in handling input and the display. However when we enter in `20` characters and trigger a check, we encounter a breakpoint at `0x7cdf`. So we know that `0x7cdf` is a part of the check. That code path `LAB_0000_00df or 0x7cdf` is called in two different places, at `0x7d55` and `0x7cd1`. When we run the program again, and set breakpoints for `0x7d55` and `0x7cd1` we see that the one that we hit which actually leads to the check is `0x7d55`. This is apart of the subroutine `LAB_0000_014d`, which starts at `0x7d4d`. This is also called at two different places at `0x7c78` and `0x7cba`. When we do the same trial by running the program again with setting a breakpoint at `0x7c78` and `0x7cba` to see where the call actually happens, we see that it is called at `0x7c78`.

The actual instruction at `0x7c78` is a `jnz` instruction for the previous `cmp` instruction at `0x7c6f`. Specifically this is the instruction:

```
       0000:006f 66 81 3e        CMP        dword ptr [0x1234],0x67616c66
                 34 12 66
                 6c 61 67
```

So it is comparing something against the string `flag` (it's displayed backwards in hex, because of least endian). It is probably checking to see if the input we gave it starts with `flag`. When we try running the code again with input that starts with `flag{` and ends in `}`, we see something interesting happen. It passes the check at `0x7c6f` and doesn't execute the jump at `0x7c78`. It just continues execution into `LAB_0000_008e` where it enters into a for loop. However when it is in the for loop, we don't get the error message that we're wrong and we should feel bad.

So with this new discovery, I'm pretty sure what though the check