From fb86216e8cb59e4abfb007b2406aca8c0c06ae54 Mon Sep 17 00:00:00 2001
From: RazviOverflow <41084837+RazviOverflow@users.noreply.github.com>
Date: Sun, 4 Aug 2024 19:03:17 +0200
Subject: [PATCH] Update relro.md

---
 .../common-binary-protections-and-bypasses/relro.md    | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/binary-exploitation/common-binary-protections-and-bypasses/relro.md b/binary-exploitation/common-binary-protections-and-bypasses/relro.md
index 3ec6b9927..693d582f1 100644
--- a/binary-exploitation/common-binary-protections-and-bypasses/relro.md
+++ b/binary-exploitation/common-binary-protections-and-bypasses/relro.md
@@ -17,17 +17,19 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
 
 ## Relro
 
-**RELRO** stands for **Relocation Read-Only**, and it's a security feature used in binaries to mitigate the risks associated with **GOT (Global Offset Table)** overwrites. Let's break down the concept into its two distinct types for clarity: **Partial RELRO** and **Full RELRO**.
+**RELRO** stands for **Relocation Read-Only**, and it's a security feature used in binaries to mitigate the risks associated with **GOT (Global Offset Table)** overwrites. There are two types of **RELRO** protections: (1) **Partial RELRO** and (2) **Full RELRO**. Both of them reorder the **GOT** and **BSS** from ELF files, but with different results and implications. Speciifically, they place the **GOT** section *before* the **BSS**. That is, **GOT** is at lower addresses than **BSS**, hence making it impossible to overwrite  **GOT** entries by overflowing variables in the **BSS** (rembember writing into memory happens from lower toward higher addresses).
+
+Let's break down the concept into its two distinct types for clarity.
 
 ### **Partial RELRO**
 
-**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. By **positioning the GOT above the program's variables in memory, Partial RELRO aims to prevent buffer overflows from reaching and corrupting the GOT**.&#x20;
+**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. Partial RELRO makes **the non-PLT part of the GOT section (usually referred to as .got from readelf output) read only**. Bear in mind that other sections like the .got.plt are still writeable and, therefore, subject to attacks. This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
 
-This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
+Note: By default, GCC compiles binaries with Partial RELRO.
 
 ### **Full RELRO**
 
-**Full RELRO** steps up the protection by **making the GOT and .fini\_array** section completely **read-only.** Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
+**Full RELRO** steps up the protection by **making the entire GOT (both .got and .got.plt) and .fini\_array** section completely **read-only.** Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
 
 However, the trade-off with Full RELRO is in terms of performance and startup time. Because it needs to resolve all dynamic symbols at startup before marking the GOT as read-only, **binaries with Full RELRO enabled may experience longer load times**. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.