Bypassing Buffer Overflow Mitigations

1. Introduction: The Persistence of Memory Corruption

The history of software security is fundamentally defined by a persistent, high-stakes arms race between offensive innovation and defensive architectural hardening. For over three decades, the buffer overflow—a simple coding error where a program writes more data to a buffer than it can hold—has remained the bête noire of modern computing. Despite the introduction of sophisticated mitigation technologies such as Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), Stack Smashing Protection (SSP), and hardware-assisted virtualization, memory corruption vulnerabilities continue to serve as the primary vector for critical system compromise.

The premise of the modern defensive landscape is not to make vulnerabilities impossible to exist—human error in languages like C and C++ ensures their survival—but to make them impossible to exploit. However, as this report will demonstrate, the existence of "unhackable" mitigations is a fallacy. For every defensive wall erected by compiler engineers and operating system vendors, exploit developers have discovered a theoretical or practical circumvention. When the stack was hardened, attackers moved to the heap. When code injection was blocked by hardware, attackers pivoted to code reuse. When control flow was locked down by Integrity (CFI) and Shadow Stacks, attackers abandoned control flow entirely in favor of data-oriented manipulation.

This report provides an exhaustive technical analysis of the state of memory corruption exploitation in the mid-2020s. It deconstructs the mechanisms of modern mitigations and, more importantly, details the precise methodologies hackers employ to dismantle them. By synthesizing research on stack canaries, heap feng shui, kernel exploitation (ret2dir), blind return-oriented programming (BROP), and emerging data-only attacks, we reveal a complex ecosystem where the interplay of optimization and security often creates the very cracks through which attackers slip.

2. The Fortress of the Stack: Mitigations and Bypasses

The stack has traditionally been the easiest target for buffer overflows. In a classic "stack smashing" attack, a linear overflow overwrites local variables, the saved frame pointer, and finally the return address, redirecting execution to shellcode placed on the stack. Modern compilers and operating systems have introduced a triad of defenses to neutralize this trivial vector: Stack Canaries (SSP), Non-Executable Memory (NX/DEP), and Address Space Layout Randomization (ASLR).

2.1 Stack Smashing Protection (SSP): The Canary in the Code

1What Are Stack Canaries? How are they Preventing Overflow?ioriver.ioStack canaries, or cookies, represent the first line of defense against linear stack overflows. Implemented via GCC flags like -fstack-protector, a random value is placed on the stack just before the saved frame pointer and return address at the beginning of a function. Before the function returns, this value is validated. If it has been modified—implying a buffer overflow has occurred—the program terminates immediately with a stack smashing detected error, preventing the redirection of control flow.¹

2.1.1 Mechanisms of Bypass: Leakage and Precision

While effective against blind smashing, canaries are vulnerable to techniques that leverage information disclosure or structural weaknesses.

Information Disclosure (Canary Leaking):
2Cookieness: Bypass Stack Canaries using Format String Vulnerabilities - Grupo Oesíagrupooesia.comThe most reliable method for bypassing SSP is to discover the value of the canary before overwriting it. This is typically achieved through an information leak vulnerability, such as a format string bug or an out-of-bounds read. In a format string attack, an attacker might supply input like %p %p %p to a printf function, causing it to read values from the stack. By calculating the offset of the canary relative to the stack pointer, the attacker can leak the secure value. Once known, the exploit payload is constructed to overwrite the buffer, write the correct canary value back into its slot, and then proceed to overwrite the return address.² The canary validation passes because the value matches, but the return address is successfully hijacked.
Byte-for-Byte Brute Force:
4On the effectiveness of NX, SSP, RenewSSP and ASLR against stack buffer overflows - Semantic Scholarpdfs.semanticscholar.orgIn specific server architectures, such as those that fork a new process for each connection (e.g., older Apache or Nginx configurations) without re-randomizing the address space (and thus the canary) between forks, attackers can employ a byte-for-byte brute force attack.⁴

1. The Setup: The attacker sends a payload that overflows the buffer by exactly one byte into the canary.
2. The Probe: They try all 256 possible values for this first byte.
3. The Oracle: If the guess is wrong, the child process crashes (canary mismatch), and the connection closes. If the guess is correct, the process continues or hangs (depending on the payload), keeping the connection open.
4. Iteration: Once the first byte is found, the attacker proceeds to the second byte, and so on. This reduces the search space from an impossible $2^{64}$ to a trivial $256 \times 8$ attempts for a 64-bit canary.⁴

Indirect Pointer Overwrites:
Canaries fundamentally protect the return address. They do not protect local variables located above the canary in the stack frame. If a vulnerable buffer exists adjacent to a function pointer, a C++ vtable pointer, or a Structured Exception Handler (SEH) record (on Windows), an attacker can overwrite these pointers without ever touching the canary.¹ When the function utilizes this corrupted pointer (e.g., calling a virtual function), execution is hijacked before the function returns, bypassing the canary check entirely.

2.2 Data Execution Prevention (DEP) and the NX Bit

To prevent the execution of malicious code injected into the stack or heap, modern processors implement the NX (No-Execute) bit. This marks memory pages as either writable or executable, but not both (W^X). Attempts to execute instructions on the stack result in a hardware exception.⁴

2.2.1 Return-Oriented Programming (ROP)

6Return-oriented programming - Wikipediaen.wikipedia.orgWith code injection neutralized, attackers shifted to code reuse. ROP allows an attacker to execute arbitrary logic by chaining together existing snippets of code, known as "gadgets," found within the executable memory of the program or its libraries (like libc).⁶

The Anatomy of a Gadget:
A gadget is a sequence of instructions ending in a ret (return) instruction. For example, pop rdi; ret is a gadget that pops the top value of the stack into the rdi register and then returns. In the x86-64 calling convention, rdi holds the first argument of a function. By placing the address of this gadget on the stack, followed by a value (e.g., a pointer to the string "/bin/sh"), the attacker can load arguments into registers.
Chaining Execution:
A ROP chain is a sequence of addresses placed on the stack.

1. Gadget 1: pop rdi; ret (Loads "/bin/sh" into rdi).
2. Gadget 2: pop rax; ret (Loads the syscall number for execve, 59, into rax).
3. Gadget 3: pop rsi; ret (Clears rsi, the second argument).
4. Gadget 4: syscall; ret (Triggers the kernel to execute the command).

This technique is Turing-complete, allowing loops, conditionals, and arbitrary computation without injecting a single new instruction.⁶ Tools like ROPgadget automate the scanning of binaries to construct these chains.⁶

2.3 Address Space Layout Randomization (ASLR)

3How to Bypass PIE, NX and ASLR - Appknoxappknox.comASLR combats ROP by randomizing the memory locations of the stack, heap, and libraries every time the program is run. This prevents attackers from knowing the addresses of the gadgets they need.³

2.3.1 Bypassing ASLR

Information Leaks:
ASLR is brittle; it relies on the secrecy of base addresses. A single leaked address—such as a pointer to a function in libc on the stack—is sufficient to calculate the base address of the entire library. Since the offsets within the library are constant, knowing one address reveals them all. Attackers prioritize finding a vulnerability that allows them to read memory (arbitrary read) to defeat ASLR before launching a ROP attack.³
Partial Overwrites:
ASLR typically randomizes the high-order bits of an address (the page number) but leaves the low-order bits (the offset within the page) intact to preserve page alignment (usually 4KB or 12 bits). If an attacker can perform a partial overwrite of a return address on the stack, modifying only the lowest two bytes, they can redirect execution to a different function within the same memory page.¹ This technique does not require a full leak of the ASLR base, as the randomized high bits remain untouched and valid.
Blind Return-Oriented Programming (BROP):
10Blind return-oriented programming - Wikipediaen.wikipedia.orgPerhaps the most sophisticated bypass for ASLR and Canaries combined is BROP. This technique allows exploitation of a server without possessing the target binary or source code.¹⁰

1. Stack Reading: The attacker uses the byte-for-byte brute force method (relying on server restarts) to leak the canary and the saved return address.
2. Gadget Hunting: Once the return address is known, the attacker modifies it to probe for gadgets. If a modified address causes a crash, it is invalid. If the connection hangs, the attacker has likely hit a "stop gadget" (like an infinite loop or a blocking read call).
3. The BROP Gadget: The attacker searches for a specific gadget (often pop rdi; ret) that allows them to control the arguments to the write system call.
4. Exfiltration: By chaining these discovered gadgets, the attacker triggers a write call that dumps the binary's content from memory to the network socket. This allows them to reconstruct the binary, find more gadgets, and build a full RCE exploit remotely.¹⁰

3. The Heap: The New Battlefield of Complexity

13Heap Exploitation - CTF Handbookctf101.orgAs stack protections became ubiquitous, the focus of exploitation shifted to the heap. The heap is dynamic, managed by complex allocators (like glibc's ptmalloc), and lacks the rigid linear structure of the stack. Exploiting the heap requires "Heap Feng Shui"—the precise manipulation of the heap layout to align objects and corrupt metadata.¹³

3.1 Understanding the Glibc Allocator

15Heap exploitation, glibc internals and nifty tricks. - Quarkslab's blogblog.quarkslab.comThe glibc allocator manages memory in "chunks." Each chunk contains metadata: the size of the previous chunk (if free), the size of the current chunk, and flags indicating if the previous chunk is in use (PREV_INUSE).¹⁵ Freed chunks are stored in lists called "bins" to speed up future allocations.

• Fastbins: Small chunks (up to 80 bytes on 64-bit systems) stored in singly linked lists. They are not coalesced (merged) when freed.
• Unsorted Bin: A cache for recently freed chunks.
• Small/Large Bins: Doubly linked lists for other sizes.
• 16TCACHE Heap Exploitation - SecQuestsecquest.co.ukTcache (Thread Local Cache): Introduced in glibc 2.26, this per-thread cache speeds up allocations but removed many security checks present in other bins.¹⁶

3.2 Use-After-Free (UAF)

17Use after free vulnerability | Tutorial & Examples - Snyk Learnlearn.snyk.ioA Use-After-Free vulnerability occurs when a program frees a memory chunk but fails to clear the pointer, leaving a "dangling pointer." If the program later uses this pointer, it accesses memory that may have been reallocated to a different object.¹⁷

Mechanism of Exploitation:

1. Free: The attacker triggers the freeing of Object A. The allocator adds the chunk to a bin (e.g., tcache).
2. Reallocate: The attacker triggers the allocation of a new Object B of the same size. The allocator recycles the chunk from the bin.
3. Corrupt: The attacker writes data to Object B.
4. Use: The program accesses the dangling pointer to Object A. Since Object A and Object B share the same memory address, the program uses the attacker's data (from Object B) in the context of Object A.¹³
   19Use-After-Use-After-Free: Exploit UAF by Generating Your Own - Black Hatblackhat.comIf Object A contained a C++ virtual table (vtable) pointer, the attacker can overwrite it to point to a fake vtable, redirecting control flow to a ROP chain when a virtual function is called.¹⁹

3.3 Tcache Poisoning and Safe Linking

The introduction of the tcache created a fertile ground for exploitation. Since tcache bins are singly linked lists, a freed chunk contains a next pointer to the next chunk in the list.

Tcache Poisoning:
An attacker exploits a UAF or double-free to overwrite the next pointer of a chunk currently in the tcache. They point it to an arbitrary address (e.g., the __free_hook function pointer in libc or a return address on the stack).

1. First Allocation: The attacker requests a chunk. The allocator returns the poisoned chunk and updates the tcache head to the value of the next pointer (the attacker's target address).
2. Second Allocation: The attacker requests another chunk. The allocator returns the target address (e.g., the stack).
3. Write: The attacker writes to this allocated memory, achieving an arbitrary write primitive.¹⁶

Safe Linking (The Mitigation):
To prevent this, newer glibc versions (2.32+) introduced Safe Linking. The next pointer is XORed with the address of the chunk itself (shifted by 12 bits).

$$\text{Stored\_Ptr} = (\text{Address\_Of\_Chunk} \gg 12) \oplus \text{Target\_Address}$$

This ensures that simply overwriting the pointer with a raw address causes a crash when the allocator tries to dereference it. However, this mitigation relies on the secrecy of the heap address (ASLR). If an attacker leaks a valid heap pointer, they can reverse the calculation (unmask the key) and forge a valid "safe" pointer, bypassing the protection entirely.¹⁶

3.4 Advanced Techniques: House of Botcake

20how2heap/glibc_2.35/house_of_botcake.c at master · shellphish/how2heap · GitHubgithub.comThe "House of Botcake" is a modern technique designed to bypass double-free restrictions in the tcache.²⁰

1. Setup: The attacker allocates several chunks and fills the tcache (7 chunks).
2. Consolidation: They free a chunk into the Unsorted Bin (which allows coalescing) and then free an adjacent chunk that is still in the tcache.
3. The Overlap: By carefully managing allocations, the attacker can force the allocator to return a chunk that overlaps with a chunk already in the tcache. This allows them to overwrite the tcache metadata (the next pointer) of the victim chunk while it is still technically "free," setting up a tcache poisoning attack without triggering double-free detection mechanisms.²⁰

4. Virtualization and Kernel Exploitation

As applications become sandboxed within virtual machines (VMs) and containers, the Operating System Kernel and the Hypervisor have become high-value targets. Compromising these layers grants total control over the system, bypassing all user-space restrictions.

4.1 Kernel Protections: SMEP and SMAP

21ret2dir: Rethinking Kernel Isolation - USENIXusenix.orgTo protect the kernel, hardware vendors introduced Supervisor Mode Execution Protection (SMEP) and Supervisor Mode Access Prevention (SMAP). These features prevent the kernel (Ring 0) from executing code or accessing data located in user-space (Ring 3) memory.²¹ This effectively kills traditional ret2usr attacks where a kernel vulnerability would redirect execution to shellcode in the user's process.

4.2 Bypassing Kernel Protections

Kernel ROP:
22Exploiting the Linux Kernel for Privilege Escalation - ISECisec.tugraz.atJust as in user-space, attackers bypass SMEP by reusing kernel code. Instead of jumping to user-space shellcode, they construct a ROP chain using kernel gadgets. A common goal is to disable SMEP by modifying the CR4 register (flipping the 20th bit) using a gadget like mov cr4, rax.²² Once SMEP is disabled, the kernel can safely execute the user-space payload.
ret2dir (Return-to-Direct-Mapped Memory):
A more elegant bypass, known as ret2dir, exploits the kernel's memory management design. The Linux kernel maps all of physical RAM into a contiguous virtual address range known as the "physmap" (direct-mapped memory) to improve performance.²¹

1. The Synonym: When a user process writes data (e.g., shellcode) to its memory, that data resides in a physical page frame. Because the physmap maps all physical RAM, that same data is accessible via a kernel virtual address in the physmap. This creates a "synonym" or alias.
2. The Exploit: The attacker sprays the user heap with their payload. They then exploit a kernel vulnerability (e.g., a stack overflow) to redirect execution. Instead of pointing to the user-space address (blocked by SMEP), they point to the physmap address of the payload.
3. The Bypass: Since the physmap is legally part of the kernel's address space, SMEP does not trigger. The kernel executes the attacker's code, believing it to be legitimate kernel instructions.²¹ This technique completely circumvents SMEP, SMAP, and KERNEXEC by leveraging the implicit sharing of physical memory.

4.3 VM Escape: Breaking the Hypervisor

VM escape involves breaking out of a guest operating system to execute code on the host. These exploits often target the complex device emulation code in the hypervisor (e.g., QEMU, VirtualBox, VMware).

The VENOM Vulnerability (CVE-2015-3456):
24What Is A Virtual Machine Escape? How It Works & Examples - Twingatetwingate.comThis vulnerability existed in QEMU's virtual floppy disk controller (FDC). Even if the guest VM did not have a floppy drive configured, the FDC code was initialized. A buffer overflow in the command processing loop allowed a guest to overwrite memory structures on the host, leading to code execution.²⁴ This highlights a critical principle: legacy code in hypervisors creates a massive attack surface.
3D Acceleration Vulnerabilities:
26Oracle VM VirtualBox - VM escape via VGA device · Advisory ...github.comModern VMs support 3D acceleration (e.g., VirtualBox VMSVGA), which requires shared memory between the guest and host to pass graphics commands. Vulnerabilities often arise in the parsing of these commands. For example, an integer overflow in the calculation of a buffer size might allow the guest to allocate a small buffer on the host but write a large amount of data to it (Heap Overflow), corrupting host memory structures.²⁶

5. Architecture-Specific Vectors: ARM vs. x86

While x86 dominates the desktop and server markets, ARM is the king of mobile and IoT. Exploitation on ARM presents unique challenges and opportunities compared to x86.

5.1 Cache Coherency Issues

In x86 architectures, the instruction cache (I-Cache) and data cache (D-Cache) are hardware-coherent; if you write data (code) to memory, the instruction fetcher immediately sees the new code. In ARM, this is not guaranteed. If an attacker writes shellcode to memory (treated as data), it sits in the D-Cache. The I-Cache may still hold the old, stale instructions for that address.
27Buffer Overflow - OWASP Foundationowasp.orgTo successfully execute injected shellcode on ARM, the attacker must force a cache flush (e.g., using the cacheflush system call) to synchronize the caches. Without this, the exploit is unreliable.²⁷

5.2 Thumb Mode

29Tutorial of ARM Stack Overflow Exploit against SETUID Root Program | FortiGuard Labsfortinet.com31How does the ARM architecture differ from x86? (closed) - Stack Overflowstackoverflow.comARM processors can execute in two modes: ARM (32-bit instructions) and Thumb (16-bit instructions). Attackers can switch the processor state by jumping to an odd address (setting the least significant bit to 1). Thumb mode is highly advantageous for exploit developers because the instructions are denser and contain fewer NULL bytes, which are often filtered by string-handling functions.²⁹ Furthermore, the ability to interpret the same stream of bytes as either 32-bit or 16-bit instructions doubles the number of potential ROP gadgets available in a binary.³¹

6. The Post-Control Era: Data-Only Attacks

As Control-Flow Integrity (CFI) and hardware defenses like Intel's Control-Flow Enforcement Technology (CET) make it increasingly difficult to hijack the instruction pointer, attackers are abandoning control-flow hijacking in favor of Data-Only Attacks.

6.1 Bypassing CFI and CET

32Exploit Development: Investigating Kernel Mode Shadow Stacks on Windowsconnormcgarr.github.ioCFI ensures that indirect jumps and calls target valid destinations. CET utilizes a hardware "Shadow Stack" that maintains an immutable copy of return addresses. If the return address on the main stack does not match the shadow stack (as in a ROP attack), the CPU halts execution.³²

Data-Oriented Programming (DOP):
34Exploitation Techniques and Defenses for Data-Oriented Attacks - Computer Science and Engineeringcs.ucr.eduDOP attacks accept the constraints of CFI: they do not try to redirect the instruction pointer to a new location. Instead, they corrupt non-control data to alter the program's state.³⁴

• Table 1: Examples of Data-Only Attacks

Target Data	Mechanism	Impact
Configuration Flags	Overwrite boolean is_admin or authenticated.35	Privilege Escalation without code execution.
System Call Arguments	Overwrite the string pointer for system() arguments. Change ls to sh.36	Execution of arbitrary commands using valid control flow.
Loop Counters	Corrupt loop variables to force multiple iterations.	Denial of Service or memory exhaustion.
Server Pointers	Change a pointer from a specialized server to a malicious server.	Exfiltration of data.

Counterfeit Object-Oriented Programming (COOP):
37Bypassing Intel CET with Counterfeit Objects - OffSecoffsec.comCOOP is a sophisticated C++ attack that bypasses CFI. It relies on the fact that C++ virtual functions are valid CFI targets. An attacker crafts a "counterfeit" object in memory with a fake vtable. This object is designed so that when the program calls a virtual function on it, it executes a "v-gadget" (a legitimate virtual function). By chaining a loop of these virtual function calls—invoking valid functions in a valid order, but on malicious data—the attacker can perform Turing-complete operations (like ROP) without ever violating the Control Flow Graph or the Shadow Stack.³⁷

7. The Supply Chain and Automation: Scale and Reach

The industrialization of vulnerability research has led to automated tools and a focus on supply chain vulnerabilities, where a single bug affects millions of downstream systems.

7.1 The Libwebp Catastrophe (CVE-2023-4863)

In late 2023, a heap buffer overflow was discovered in libwebp, a library used to render WebP images.

• The Bug: An integer overflow in the Huffman table allocation logic allowed an attacker to write out-of-bounds on the heap.
• 39LibWebP Vulnerability: Should You Worry And What To Do? - LeanIXleanix.netThe Impact: Since libwebp is statically linked or widely used in Chrome, Firefox, Electron (Slack, Teams, 1Password), and iOS, this single vulnerability was a "zero-click" exploit vector across virtually all modern consumer platforms.³⁹
• 41Libwebp: Special Vulnerability Advisory (CVE-2023-4863) - Safety's cybersecuritygetsafety.comThe Mechanism: The exploit used a malicious WebP image. When the browser (or app) attempted to render it, the Huffman decoding tables overflowed, corrupting the heap and leading to RCE.⁴¹ This demonstrates that even with OS-level mitigations, vulnerabilities in widely shared, complex parsing libraries remain a systemic risk.

7.2 Automated Exploit Generation (AEG)

42AEG: Automatic Exploit Generation - Network and Distributed System Security (NDSS) Symposiumndss-symposium.orgTools like Mayhem and CRAX have attempted to automate the process of exploit generation using symbolic execution.⁴²

• Symbolic Execution: The engine executes the binary with symbolic variables rather than concrete inputs. It builds mathematical constraints for each branch (e.g., "if input > 10, go left"). A solver then calculates the specific input required to reach a crashing state.
• 44HAEPG: An Automatic Multi-hop Exploitation Generation Framework - PMCpmc.ncbi.nlm.nih.govThe Heap Limitation: While AEG has succeeded with stack overflows, it struggles significantly with modern heap exploits. The complexity of modeling the heap allocator (Heap Feng Shui), combined with the "state explosion" problem of symbolic execution (where the number of paths grows exponentially), means that generating multi-stage heap exploits that bypass ASLR and Safe Linking is currently beyond the capability of fully automated tools.⁴⁴ Exploitation of the heap remains a domain requiring significant human intuition and manual engineering.

8. Conclusion: The Fallacy of the Unhackable System

The "modern tools" cited in the user's query—GCC flags, virtualization, hardware enforcement—have undeniably raised the bar for exploitation. The days of the "script kiddie" launching a simple stack smash are largely over. However, the sophisticated attacker has adapted by moving down the stack (to the kernel), across the memory (to the heap), and laterally (to data-only attacks).

Current research indicates that as long as memory-unsafe languages like C and C++ form the foundation of our computing infrastructure, memory corruption will persist. Mitigations are reactive: ASLR hides addresses, but they can be leaked. Canaries protect the return address, but they can be bypassed or irrelevant to heap corruption. Even hardware-enforced isolation like SMEP/SMAP is circumvented by exploiting the underlying memory architecture (ret2dir). The future of exploitation lies in data-oriented attacks that respect the rules of control flow while subverting the logic of the application, and in microarchitectural attacks that exploit the hardware's optimization (cache, speculative execution) rather than the software's bugs. The arms race continues, with the advantage still held by those who need to find only one crack in the fortress wall.

References

1. What Are Stack Canaries? How are they Preventing Overflow?, accessed December 21, 2025 — https://www.ioriver.io/terms/stack-canaries
2. Cookieness: Bypass Stack Canaries using Format String Vulnerabilities - Grupo Oesía, accessed December 21, 2025 — https://grupooesia.com/en/insight/cookieness-bypass-de-stack-canaries-usando-format-string-vulnerabilities/
3. How to Bypass PIE, NX and ASLR - Appknox, accessed December 21, 2025 — https://www.appknox.com/blog/bypassing-pie-nx-and-aslr
4. On the effectiveness of NX, SSP, RenewSSP and ASLR against stack buffer overflows - Semantic Scholar, accessed December 21, 2025 — https://pdfs.semanticscholar.org/aeed/c52455d74f67d5e94ad17fcfb2ce1ac7fd8b.pdf
5. On the effectiveness of DEP and ASLR - Microsoft, accessed December 21, 2025 — https://www.microsoft.com/en-us/msrc/blog/2010/12/on-the-effectiveness-of-dep-and-aslr
6. Return-oriented programming - Wikipedia, accessed December 21, 2025 — https://en.wikipedia.org/wiki/Return-oriented_programming
7. Return Oriented Programming (ROP) attacks - Infosec, accessed December 21, 2025 — https://www.infosecinstitute.com/resources/hacking/return-oriented-programming-rop-attacks/
8. How Return-Oriented Programming exploits work - SecureTeam, accessed December 22, 2025 — https://secureteam.co.uk/2020/09/18/how-return-oriented-programming-exploits-work/
9. An In-Depth Survey of Bypassing Buffer Overflow Mitigation Techniques - MDPI, accessed December 22, 2025 — https://www.mdpi.com/2076-3417/12/13/6702
10. Blind return-oriented programming - Wikipedia, accessed December 22, 2025 — https://en.wikipedia.org/wiki/Blind_return-oriented_programming
11. Blind Return Oriented Programming (BROP), accessed December 22, 2025 — https://www.scs.stanford.edu/brop/
12. Hacking Blind - Reliable Computer Systems, accessed December 22, 2025 — https://rcs.uwaterloo.ca/~ali/papers/oakland14-brop.pdf
13. Heap Exploitation - CTF Handbook, accessed December 21, 2025 — https://ctf101.org/binary-exploitation/heap-exploitation/
14. Exploring Heap Exploitation Mechanisms: Understanding the House of Force Technique, accessed December 21, 2025 — https://www.darkrelay.com/post/exploring-heap-exploitation-mechanisms-understanding-the-house-of-force-technique
15. Heap exploitation, glibc internals and nifty tricks. - Quarkslab's blog, accessed December 21, 2025 — https://blog.quarkslab.com/heap-exploitation-glibc-internals-and-nifty-tricks.html
16. TCACHE Heap Exploitation - SecQuest, accessed December 21, 2025 — https://www.secquest.co.uk/white-papers/tcache-heap-exploitation
17. Use after free vulnerability | Tutorial & Examples - Snyk Learn, accessed December 21, 2025 — https://learn.snyk.io/lesson/use-after-free/
18. Using freed memory - OWASP Foundation, accessed December 21, 2025 — https://owasp.org/www-community/vulnerabilities/Using_freed_memory
19. Use-After-Use-After-Free: Exploit UAF by Generating Your Own - Black Hat, accessed December 21, 2025 — https://blackhat.com/docs/eu-16/materials/eu-16-Wen-Use-After-Use-After-Free-Exploit-UAF-By-Generating-Your-Own-wp.pdf
20. how2heap/glibc_2.35/house_of_botcake.c at master · shellphish/how2heap · GitHub, accessed December 21, 2025 — https://github.com/shellphish/how2heap/blob/master/glibc_2.35/house_of_botcake.c
21. ret2dir: Rethinking Kernel Isolation - USENIX, accessed December 21, 2025 — https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-kemerlis.pdf
22. Exploiting the Linux Kernel for Privilege Escalation - ISEC, accessed December 21, 2025 — https://www.isec.tugraz.at/wp-content/uploads/2024/09/09-kernel-exploitation.pdf
23. ret2dir: Deconstructing Kernel Isolation - Black Hat, accessed December 21, 2025 — https://blackhat.com/docs/eu-14/materials/eu-14-Kemerlis-Ret2dir-Deconstructing-Kernel-Isolation.pdf
24. What Is A Virtual Machine Escape? How It Works & Examples - Twingate, accessed December 21, 2025 — https://www.twingate.com/blog/glossary/virtual%20machine%20escape
25. Virtual machine escape - Wikipedia, accessed December 21, 2025 — https://en.wikipedia.org/wiki/Virtual_machine_escape
26. Oracle VM VirtualBox - VM escape via VGA device · Advisory ..., accessed December 21, 2025 — https://github.com/google/security-research/security/advisories/GHSA-qx2m-rcpc-v43v
27. Buffer Overflow - OWASP Foundation, accessed December 22, 2025 — https://owasp.org/www-community/vulnerabilities/Buffer_Overflow
28. Cache Attacks on ARM - Black Hat, accessed December 22, 2025 — https://blackhat.com/docs/eu-16/materials/eu-16-Lipp-ARMageddon-How-Your-Smartphone-CPU-Breaks-Software-Level-Security-And-Privacy-wp.pdf
29. Tutorial of ARM Stack Overflow Exploit against SETUID Root Program | FortiGuard Labs, accessed December 22, 2025 — https://www.fortinet.com/blog/threat-research/tutorial-arm-stack-overflow-exploit-against-setuid-root-program
30. Tutorial of ARM Stack Overflow Exploit – Defeating ASLR with ret2plt | FortiGuard Labs, accessed December 22, 2025 — https://www.fortinet.com/blog/threat-research/tutorial-of-arm-stack-overflow-exploit-defeating-aslr-with-ret2plt
31. How does the ARM architecture differ from x86? (closed) - Stack Overflow, accessed December 22, 2025 — https://stackoverflow.com/questions/14794460/how-does-the-arm-architecture-differ-from-x86
32. Exploit Development: Investigating Kernel Mode Shadow Stacks on Windows, accessed December 21, 2025 — https://connormcgarr.github.io/km-shadow-stacks/
33. How to Survive the Hardware-assisted Control- flow Integrity Enforcement - Black Hat, accessed December 21, 2025 — https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Sun-How-to-Survive-the-Hardware-Assisted-Control-Flow-Integrity-Enforcement.pdf
34. Exploitation Techniques and Defenses for Data-Oriented Attacks - Computer Science and Engineering, accessed December 22, 2025 — http://www.cs.ucr.edu/~trentj/papers/secdev19.pdf
35. Exploitation Techniques and Defenses for Data-Oriented Attacks - arXiv, accessed December 22, 2025 — https://arxiv.org/pdf/1902.08359
36. Practical Data-Only Attack Generation - USENIX, accessed December 22, 2025 — https://www.usenix.org/system/files/usenixsecurity24-johannesmeyer.pdf
37. Bypassing Intel CET with Counterfeit Objects - OffSec, accessed December 22, 2025 — https://www.offsec.com/blog/bypassing-intel-cet-with-counterfeit-objects/
38. Bypassing Intel CET with Counterfeit Objects (COOP) - Squarespace, accessed December 22, 2025 — https://static1.squarespace.com/static/5c2f61585b409bfa28a47010/t/64fb2ce1e4c6f107868c1484/1694182627599/COOP.pdf
39. LibWebP Vulnerability: Should You Worry And What To Do? - LeanIX, accessed December 21, 2025 — https://www.leanix.net/en/blog/libwebp-vulnerability-sboms
40. High-Severity Vulnerabilities Discovered in WebM Project's Libraries - Palo Alto Networks, accessed December 21, 2025 — https://www.paloaltonetworks.com/blog/cloud-security/high-severity-vulnerabilities-webm-project-libraries/
41. Libwebp: Special Vulnerability Advisory (CVE-2023-4863) - Safety's cybersecurity, accessed December 21, 2025 — https://www.getsafety.com/blog-posts/libwebp-special-vulnerability-advisory-cve-2023-4863
42. AEG: Automatic Exploit Generation - Network and Distributed System Security (NDSS) Symposium, accessed December 22, 2025 — https://www.ndss-symposium.org/wp-content/uploads/2017/09/Avg.pdf
43. Unleashing MAYHEM on Binary Code - Carnegie Mellon University, accessed December 22, 2025 — https://users.ece.cmu.edu/~aavgerin/papers/mayhem-oakland-12.pdf
44. HAEPG: An Automatic Multi-hop Exploitation Generation Framework - PMC, accessed December 22, 2025 — https://pmc.ncbi.nlm.nih.gov/articles/PMC7338205/
45. Towards Automatic and Precise Heap Layout Manipulation for General-Purpose Programs - NDSS Symposium, accessed December 22, 2025 — https://www.ndss-symposium.org/wp-content/uploads/2023-232-paper.pdf