# Rev and GDB/Ghidra

## What's Rev?

Rev stands for **Rev**erse engineering. This category is exactly what it says: you're often given a compiled binary file and you (should) reverse it to determine what it actually does, and how to exploit it from there.

Normally when you have a program in any language, it will get **compiled** down to machine code, and then you or your system (depending on which language it is) runs the compiled machine code (binary code). However, the 1s and 0s of machine code is often **too hard to interpret** reasonably.

Therefore, there are tools to do the opposite of that and turn machine code back into human-readable code such as Assembly or C (two low-level languages closer to machine code but still somewhat reasonable to read and interpret).

## Okay but how do I do that?

There are two main ways to do this and you often would want to use both in most rev challenges.

- Decompile the binary beforehand, look at what code does, and program an exploit from there (tools such as **Ghidra**)
- Run the binary, use breakpoints to pause code as it is running, inspect memory and CPU registers (essentially CPU's memory) to make sure exploit is working (tools such as **GDB/GEF**)

## Ghidra basics

Installation command: `source <(curl -sL https://tjcsec.club/ghidra)`

When you open Ghidra, you want to hit `File>New Project>Non-shared project` and then give it a name. This allows you to drag and drop CTF challenges into one location. After hitting `finish`, just drag and drop your binary file into ghidra, and leave everything as default (should call format as `ELF`). Once imported, double click on the imported file to launch Ghidra.

When Ghidra prompts to analyze a file, allow it to analyze as this will allow you to turn the `ELF` into `C` code.


It will automatically turn code into `Assembly` code, but going under `Symbol Tree>Functions>(whatever function to analyze, like main)` gets the acutal `C` code (this can be a bit more human-friendly than assembly code).

If it does't work, try opening `Window>Decompiler` before clicking on main.


Right clicking on a varaible gives you many options, such as assigning it a new type and assigning it a new name. This may make it easier to organize your code.

## GDB/GEF

Once you have coded an exploit, it makes sense to ensure that your exploit is working. Using a tool like **GDB** does exactly that.

It's a terminal tool and can be installed through `sudo apt-get install gdb`

Opening a file is a lot simpler than Ghidra: `gdb (executable)` on your terminal.

GDB is used for breakpoints, which allow to stop your code temporarily to inspect the memory and registers.

Some useful commands:
|Command| What it does|
| ------------------ | ------------------------------------------------ |
| b | Breakpoint at current line |
| b \*0xdeadbeef | Breakpoint at the memory address 0xdeadbeef |
| b myFunc | Breakpoint right before calling myFunc |
| b \*myFunc+4 | Breakpoint 4 lines below start of myFunc |
| r | run (restarts your code) |
| c | continue until next breakpoint |
|l | list source code |
| bt | Print Stack Trace |
| p/x | Print variable |
| x/40x \*0xdeadbeef | Print 40 memory bytes starting at address |
| x/40x $esp | Print 40 memory bytes starting at $esp register. |

### GEF: GDB on steroids

GEF (GDB Enhanced Features) has a larger variety of commands, which mostly do what Ghidra also does. It's mostly for deassembly and other tools that can be used right before running code, just like Ghidra. However, you may not need the GEF commands for the challenges today, assuming Ghidra is working for you.
|Command| What it does|
|----------|-----------------------------------------------------------------------------------------------------|
| disas | Dissasemble a file |
| checksec | Check any security features on a file (this may help determine what **kind** of challenge there is) |
| vmmap | Display a process' entire memory mapping |