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).

Stack Protection x86 - Canary

Basically a Stack integrity sentinel value.

Our Layout Map	Our Actions
Thread Control Block (TCB linux) (TEB windows) => FS_base => TLS
Thread Local Storage (TLS)	- glibc create cancary value and stores in TLS
Registers	- LOAD, STORE, COMPARE, BRANCH

Dump main()	Stack Frame	The Stack - Canary	Thread Local Storage - Canary

Stack Protection ARM - Canary

    * The ARM LOAD process:
                            At runtime a pointer to the TLS canary value is store in the ARM literal pool (think .text section)
                            Memory loads work off relative addressing. The memory expression must be resolved to be calculated.
                            For Example r3, (PC + #80). Program Counter + 80offset is resolved and mem addr is stored in r3.
                            The r3 memory addr is dereferenced and the value is stored in r3.

---