Exploit-Dev

Unlike stack memory which grows downward from high addresses and is automatically managed via function call frames, Heap memory grows upward from lower addresses and is managed explicitly at runtime via dynamic allocation. Understanding heap layout and allocator metadata is fundamental to analyzing heap exploitation primitives (such as use-after-free, heap overflows, fastbin dupes, and unlink exploitation). Core Allocation Primitives malloc(size): Requests size bytes from the heap and returns a generic pointer. The returned memory is uninitialized. calloc(num, size): Allocates memory for an array and initializes all bytes to zero (mitigates information disclosure bugs). realloc(ptr, size): Resizes an existing heap block, either expanding in-place or allocating a new region, copying existing data, and freeing the old chunk. free(ptr): Releases the allocated chunk back to the heap manager. Kernel Interface: brk/sbrk vs. mmap The userspace memory allocator (e.g., Glibc’s ptmalloc) interacts with the Linux kernel using two primary system calls: ...

When debugging binaries during exploit development or wargames, third-party frameworks like GEF, Pwndbg, or Peda provide helpful dashboard views. However, in restricted testing environments, CTF shells, or isolated embedded targets, you may not have internet access or Python dependencies installed to run external tools. You can configure vanilla GDB to provide an automated register and stack inspection view using native define hook-stop hooks in ~/.gdbinit. Custom ~/.gdbinit Configuration Create or update ~/.gdbinit in your home directory: ...

When writing or modifying custom assembly shellcode (such as egg hunters, socket reuse payloads, or stagers), you must verify that the payload functions correctly before embedding it into a full exploit delivery chain. A standard C test harness executes shellcode by casting a char array in memory to a function pointer and calling it directly. The C Test Harness #include <stdio.h> #include <string.h> // Example: Software breakpoint (INT3) or your target shellcode const char shellcode[] = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"; int main(int argc, char **argv) { printf("Shellcode length: %zu bytes\n", strlen(shellcode)); // Cast the array address to a callable function pointer int (*ret)() = (int (*)())shellcode; // Transfer control flow to shellcode ret(); return 0; } Compilation Flags: Disabling Modern Mitigations Modern compilers enable Stack Canaries and enforce Non-Executable Memory (DEP / NX) by default. If you attempt to execute data placed in the .rodata or .data section without special flags, the kernel terminates the process with a SIGSEGV / segmentation fault. ...

When exploiting buffer overflows in space-constrained stack frames (e.g., when the vulnerable buffer is only 20 or 30 bytes), you cannot fit a standard 50-byte shellcode payload directly on the stack. A classic exploitation technique is ret2env: injecting the shellcode into an environment variable (export EGG=...) and redirecting execution to its address located near the high end of the process address space. Why Addresses Shift Environment variables reside at the top of the user stack directly below the initial stack frame. Because the program name (argv[0]) is pushed onto the stack immediately following the environment pointer (envp), the exact address of an environment variable depends slightly on the length of the binary name: ...