book_secure_c.md: GOT PLT overflow minor fix

Author: Eliot-Roxbergh

c_programming/book_secure_c.md

@@ -375,7 +375,7 @@ Unrelated?; "There is one GOT per compilation unit or object module, and it is l
 - .got includes variable addresses, .got.plt includes function addresses: <https://stackoverflow.com/questions/11676472/what-is-the-difference-between-got-and-got-plt-section>, <https://stevens.netmeister.org/631/elf.html>
 - Partial RELRO (as opposed to Full RELRO) is default in GCC and ONLY protects .got, thus .got.plt is still writable and exploitable: <https://book.hacktricks.xyz/binary-exploitation/common-binary-protections-and-bypasses/relro#partial-relro>, <https://www.mdpi.com/2076-3417/12/13/6702>.
 - With Full RELRO we can try to perform a buffer overflow attack to replace the return address to a viable gadget already in got.plt.
-- With Partial RELRO can try to perform a heap overflow attack to replace the .got.plt entry itself: <https://medium.com/@0xwan/binary-exploitation-heap-overflow-to-overwrite-got-d3c7d97716f1>. My understanding is that - the stack grows downwards with new allocations and as it does the start of stack changes, the addressing start there and goes _upwards_ meaning it cannot reach the heap or GOT for instance (which would only be reachable with a new allocation that would error out due to overflow into heap memory)  (<https://security.stackexchange.com/questions/135786/if-the-stack-grows-downwards-how-can-a-buffer-overflow-overwrite-content-above/135798#135798>). TODO, is this correct: The heap cannot access the stack as it's in another virtual memory, however it can (by overflow?) access the data (/GOT) section
+- With Partial RELRO can try to perform a different kinds of overflow attacks to replace the .got.plt entry itself: <https://medium.com/@0xwan/binary-exploitation-heap-overflow-to-overwrite-got-d3c7d97716f1>. _My understanding is that - the stack grows downwards with new allocations and as it does the start of stack changes, the addressing start there and goes _upwards_ meaning it cannot reach the heap or GOT for instance (which would only be reachable with a new allocation that would error out due to overflow into heap memory)  (<https://security.stackexchange.com/questions/135786/if-the-stack-grows-downwards-how-can-a-buffer-overflow-overwrite-content-above/135798#135798>)._ It's possible on a non-ASLR system to directly read or write got.plt addresses (and other addresses such as data, but not stack?) no overflow necessary: <https://ir0nstone.gitbook.io/notes/binexp/stack/got-overwrite/exploiting-a-got-overwrite>, it exists in its memory space so to speak. Example with stack buffer overflow (TODO and TODO why is overflow necessary here) <https://www.exploit-db.com/papers/13203>.
 - Note that ASLR / PIE / PIC can make these attacks more difficult. GOT-related attacks are done to bypass certain protection mechanisms such as NX-bit.
 
 ##### Lazy Binding, PLT, GOT