A running rough guide and notes into binary security. Thoughts are my own.

binsec introductive primer

* the execution of computer code is dependent on many support strcutures and systems that allow for portable and flexible applications.
* multiple standards and conventions to be aware of defined by ABI - byte storage (endianness) - calling conventions - the name(eip/rip), size(32/64bit) and number and type of CPU registers.

memory managament:

- Imagine a factory with a robot (CPU) whose only job is to execute instructions delivered on a conveyor belt. The robot does not question instructions — it simply executes whatever arrives.
- When a program allocates a memory buffer, it is assigned a fixed-sized section of memory. The program assumes it will only write data within that space.
- If more data is written than the buffer can hold, the excess data overwrites whatever memory happens to be next. 
Often sensitive control information such as saved return addresses or function pointers.
- By overflowing a buffer, an attacker can overwrite this control data. The robot (CPU) does not check for integrity. It will just execute. 
If you replace the information in the control room with your own code the robot will still execute it.
- The Stack grows downward. Memory writes advance upwards.

code execution wrapper:

- a binary file is just not code instrictions in the same layout as the programmer saw in the IDE.
- the code, data and support strcuture tables (for example resolving dynamic libraries) are sorted into Sections. {.text, .data, .plt, .got, .bss}
- the programmer can set security flags that will be read and applied by the executing Operating System. Providing needed security mitigations. {NX, PIE, DEP}
- wrapper is typically ELF (Linux) or PE/MZ (Windows).

---