0x18.

18. Global Offset Table(GOT) and Procedure Linkage Table(PLT) - bin.0x12

: Content
-> Global Offset Table(GOT)
-> Procedure Linkage Table(PLT)
-> Dynamic Libraries

: Create a very simple C program that calls two "libc" functions.
-> vim test.c
-> int main(){
        printf("Hello World!\n");
        printf("This is LiveOverflow\n");
        exit(0);
        return 1;
}
-> gcc tset.c -o test
-> ./test
-> Hello World!
This is LiveOverflow
-> So you write two "printf" and "exit." These two functions are obviously external.
-> We did not define these functions for ourselves. And when they compiled the binary, they came from "libc."
-> When "gcc" is used, "libc" is dynamically connected to this binary. It is included in the program that means something that is not "libc."
-> With 'ldd', you can see the dynamic library referenced in.
-> ldd test
linux-vdso.so.1 (0x00007fff695dc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd28fb23000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd290116000)
-> This binary shows that "libc" is required and indicates the path of the system, where you have your "libc" binary.
-> This is great because it allows the program to be much smaller.
-> "libc" can be updated without recompiling the binary.
-> This, however, means that the addresses of "libc" may vary from version to version.

: How do I compile the binary into the assembly when I need to know the correct address?
-> Can I create a "call" command? Here, "PLT" and "GOT" appear.

: Let's open this binary on the "Hopper" deserter and explore the key features.
-> Installing “Hopper” for linux
-> Execute “Hopper”
-> The first thing that stands out is "printfs()”. Where is it? 
-> Why do I need a "puts()" call?
-> The deserter specified a constant string, not a dynamic format string.
-> Therefore, the "printf" was replaced with "puts".
-> Anyway, there are three functions here.
-> "Hopper" appears to have a "j" appended to the name of the location of the "call."
-> call j_puts (j = jump???)
-> We don't end with "libc putts()" We're still in binary. What about us, too?
-> This binary does not include "libc". We arrived at the "plt" section.(Process Link Table)
-> jmp qword [ds:puts@GOT]
-> And if you "call" here, you immediately jump to the address stored in the address.
-> This location is called "@GOT".
-> Now we're in a segment called "GOT." (Global Offset Table). And any jump will jump.
-> ; Section .got.plt
-> GOT
_GLOBAL_OFFSET_TABLE_:
-> List / Table of address
puts@GOT:
   dp 0x0000000000602000 ; XREF=j_puts
-> The address is stored here. And the address currently stored here is being referenced.
: So what are they doing here?
-> During compilation we do not know the address of "puts" or "exit". So we just make a function.
-> We call the location where we know where we are the "PLT" section.
-> If you want to use an external function in a library, you must somehow use the actual function.

: Debugging for “Hopper”
-> set the break point.
-> step in.
-> Check the address of “_dl_runtime_resolve”.
-> You can use the proc file system to view the memory map of the process and see that the "_dl_runtime_resolveve address belongs to this "ld.so" binary.
-> pidof test
-> ???
-> cat /proc/3803/map
-> ???
-> "man ld.so" is a dynamic linker/loader.

: The global offset table is very useful when creating an exploit.
-> Arbitrary Write - we have a vulenrability that allows us to write a value anywhere in memoey.
-> The address of the global offset table for a particular function can be simply overwritten.
-> And the next time this function is called, the code is redirected anything.
-> Arbitrary Read - leaking a value from the memory of the process. For example with Use-After-Free or Format String vuln
-> The global offset table of the binary is always fixed. So the address you control when you can read, you can read the entry of the global offset table, which is the address.
-> It can then be used to calculate the offset for other positions in the "libc".
-> Useful when you want to find a "rop gadget" or go back to "libc."
-> If binary addresses can be leaked even if the binary uses "ASLR", then an offset for the global offset that repels randomization of the addresses can be calculated.
-> It then leaks the address of "libc."

: Format4(C Code)(/opt/protostar/bin/format4)
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int target;

void hello()
{
  printf("code execution redirected! you win\n");
  _exit(1);
}

void vuln()
{
  char buffer[512];

  fgets(buffer, sizeof(buffer), stdin);

  printf(buffer);

  exit(1);  
}

int main(int argc, char **argv)
{
  vuln();
}
-> Return address of the stack and other technologies for the control shall be used.
: Find a global offset table that redirects code execution using the format string vulnerability.