Basic Binary Protections
Just some bad notes
Binary Protections (ASLR/PIE/NX)
if ASLR is enabled, need to leak an address from the memory region
offset between addresses will not change
PIE (Position Independent Executable)
ASLR for the actual binary’s code and memory regions
NX (Non-Executable)
Stack region of the memory is not executable
You can determine this using
vmap
gef➤ vmmap Start End Offset Perm Path 0x0000000000400000 0x0000000000401000 0x0000000000000000 r-- /tmp/tryc 0x0000000000401000 0x0000000000402000 0x0000000000001000 r-x /tmp/tryc 0x0000000000402000 0x0000000000403000 0x0000000000002000 r-- /tmp/tryc 0x0000000000403000 0x0000000000404000 0x0000000000002000 r-- /tmp/tryc 0x0000000000404000 0x0000000000405000 0x0000000000003000 rw- /tmp/tryc 0x00007ffff7dcb000 0x00007ffff7df0000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so 0x00007ffff7df0000 0x00007ffff7f63000 0x0000000000025000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so 0x00007ffff7f63000 0x00007ffff7fac000 0x0000000000198000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so 0x00007ffff7fac000 0x00007ffff7faf000 0x00000000001e0000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so 0x00007ffff7faf000 0x00007ffff7fb2000 0x00000000001e3000 rw- /usr/lib/x86_64-linux-gnu/libc-2.29.so 0x00007ffff7fb2000 0x00007ffff7fb8000 0x0000000000000000 rw- 0x00007ffff7fce000 0x00007ffff7fd1000 0x0000000000000000 r-- [vvar] 0x00007ffff7fd1000 0x00007ffff7fd2000 0x0000000000000000 r-x [vdso] 0x00007ffff7fd2000 0x00007ffff7fd3000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so 0x00007ffff7fd3000 0x00007ffff7ff4000 0x0000000000001000 r-x /usr/lib/x86_64-linux-gnu/ld-2.29.so 0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000022000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so 0x00007ffff7ffc000 0x00007ffff7ffd000 0x0000000000029000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so 0x00007ffff7ffd000 0x00007ffff7ffe000 0x000000000002a000 rw- /usr/lib/x86_64-linux-gnu/ld-2.29.so 0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 rw- 0x00007ffffffde000 0x00007ffffffff000 0x0000000000000000 rw- [stack] 0xffffffffff600000 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
Stack Canary
Random value placed at bottom of stack frame
if it is overwritten, then there is memory corruption (or in this case BOF) and terminates the program
Typical Stack Canary check in a binary
0x0000000000401169 <+55>: mov rax,QWORD PTR [rbp-0x8] 0x000000000040116d <+59>: xor rax,QWORD PTR fs:0x28 0x0000000000401176 <+68>: je 0x40117d <main+75> 0x0000000000401178 <+70>: call 0x401030 <__stack_chk_fail@plt>
Using debugger to check the stack canary from RBP/EBP
gef➤ x/g $rbp-0x8 0x7fffffffdfe8: 0x92105577ff879300 ``` a Here we can see is the stack canary. We can tell that it is the stack canary from several different things. Firstly it is the value being used when it is doing the stack canary check. Also it is around the spot on the stack it should be. Also it matches the pattern of a stack canary. While they are random they do fit a general pattern. For `x64` elfs, the pattern is an `0x8` byte qword, where the first seven bytes are random and the last byte is a null byte. For `x86` elfs, the pattern is a `0x4` byte dword, where the first three bytes are random and the last byte is a null byte.
Last updated