exploit-lab

## https://sploitus.com/exploit?id=E6812B62-9BA3-552D-B770-87B3114229D0
# Threadbare — Exploit-Development Training Lab

## Introduction

Threadbare is a hands-on exploit-development lab built around a deliberately vulnerable multithreaded TCP service called **tdsvc** (Thread Dispatch Service). The lab guides you from first principles — reading the binary, understanding its concurrency model, and fingerprinting its mitigations — through a complete exploit chain that achieves remote code execution via a reverse shell. Every technique you practise here maps directly to real-world skills: information leaks, control-flow hijacking, ROP chain construction, and stack-pivot trampolines.

The target, tdsvc, is a 58-thread x86-64 service. Two ingress threads accept TCP connections, parse framed requests, and enqueue jobs onto a mutex-protected queue. Fifty-four worker threads dequeue those jobs and dispatch them to handlers — both intentional bugs live in those handlers. Two egress threads drain a separate response queue and write replies back to clients. This architecture lets you observe how bugs surface inside a thread pool and why standard single-threaded exploit assumptions sometimes need adjusting.

The lab is self-contained and sequential. You work through eight modules, each building on the last, with tiered hints and a complete walkthrough available if you get stuck. By the end you will have written a pwntools exploit script that reliably defeats live ASLR and lands an interactive reverse shell against a running instance of tdsvc.

---

## Safety

tdsvc binds exclusively to **127.0.0.1:9999** and never listens on any external interface. All exploit traffic in this lab targets the loopback address. The lab does not disable ASLR system-wide, does not modify kernel parameters, and contains no destructive payload surface — the most it does is spawn `/bin/bash` locally. Do not deploy tdsvc on a shared machine, a VM with bridged networking, or any host reachable from an untrusted network. It is intentionally broken software.

---

## Prerequisites

- Comfort reading and writing C (pointer arithmetic, structs, memory layout)
- x86-64 assembly basics (registers, calling convention, stack frame layout)
- Linux CLI fluency (processes, file descriptors, netcat, tmux/screen)
- Python 3 for scripting exploits

You do **not** need prior exploit-development experience; that is what the lab teaches.

---

## Setup

Run the setup script once from the lab root:

```
bash setup.sh
```

The script is idempotent — re-running it is safe. It will:

1. Verify or install gdb
2. Install pwndbg into `~/tools/pwndbg`
3. Install ropper and pwntools via pip
4. Verify that `nc` (netcat) is available
5. Build tdsvc with `make`
6. Print a checksec summary of the resulting binary

After setup completes, build manually at any time with:

```
make          # build bin/tdsvc
make run      # start tdsvc (blocks; use a second terminal for the exploit)
make checksec # re-print mitigation summary
make clean    # remove build artefacts
```

---

## Module Syllabus

| # | Directory | Title | What you do |
|---|-----------|-------|-------------|
| 00 | `modules/00-environment.md` | Environment | Verify the toolchain, explore the lab layout, confirm tdsvc builds and binds |
| 01 | `modules/01-recon.md` | Reconnaissance | Read the source, map the thread model, enumerate mitigations, draft an attack plan |
| 02 | `modules/02-the-leak.md` | The Leak | Craft OP_RANGE frames to trigger the OOB read; compute PIE base, libc base, and heap pointer |
| 03 | `modules/03-control-flow-hijack.md` | Control-Flow Hijack | Measure the exact offset to the saved RIP via OP_PROCESS; overwrite it with a controlled value |
| 04 | `modules/04-trampoline.md` | Stack-Pivot Trampoline | Find a `pop rsp; ret` gadget; pivot execution into the heap buffer; understand why the inline space is too small |
| 05 | `modules/05-rop-chain.md` | ROP Chain | Build the execve ROP chain in `conn->payload`; lay out the argument strings; chain the gadgets |
| 06 | `modules/06-egress-delivery.md` | Egress Delivery | Set up the reverse-shell listener; trigger the full chain; catch the shell |
| 07 | `modules/07-reliability.md` | Reliability | Handle threading races, add retry logic, harden the exploit for consistent one-shot execution |

---

## File Layout

```
exploit-lab/
├── README.md               ← you are here
├── setup.sh                ← one-time toolchain installer
├── verify.sh               ← end-to-end exploit validator
├── Makefile                ← build, run, checksec, clean targets
├── src/                    ← tdsvc source code
│   └── tdsvc.c
├── modules/                ← lab modules (work through in order)
│   ├── 00-environment.md
│   ├── 01-recon.md
│   ├── 02-the-leak.md
│   ├── 03-control-flow-hijack.md
│   ├── 04-trampoline.md
│   ├── 05-rop-chain.md
│   ├── 06-egress-delivery.md
│   └── 07-reliability.md
├── hints/                  ← tiered hints (try these before walkthrough/)
├── cheatsheets/            ← quick-reference cards for tools
│   ├── gdb-pwndbg.md
│   ├── ropper.md
│   └── pwntools.md
├── walkthrough/            ← step-by-step narrative (spoilers)
├── solution/               ← complete working exploit script (spoilers)
│   └── exploit.py
└── bin/                    ← compiled output (created by make)
    └── tdsvc
```

---

## Running verify.sh

`verify.sh` is the lab's acceptance test. It builds a fresh tdsvc, starts it under live ASLR, runs `solution/exploit.py`, and confirms that a reverse shell connected and ran a command. Run it from a normal terminal (not inside gdb):

```
bash verify.sh
```

A passing run prints something like:

```
[+] Build OK
[+] tdsvc started (pid 12345)
[+] exploit.py connected
[+] shell command confirmed: uid=1000(user)
[+] PASS
```

If it fails, check that nothing else is already bound to 9999, that the listener port is free, and that pwntools is installed.

---

## How to Work Through the Lab

Start at module 00 and proceed in order. Each module states its goal, gives you the relevant source locations and protocol details, poses a set of tasks, and points at hints when needed. Resist the urge to jump ahead — the later modules assume specific results (leaked addresses, measured offsets) that you compute in earlier ones.

When you get stuck, consult the tiered hints in `hints/` first. Hints are numbered and graduated: hint 1 gives a nudge, hint 2 gives a stronger direction, hint 3 essentially tells you what to do without writing the code for you. Only open `walkthrough/` or `solution/` when you have genuinely exhausted the hints and want to understand a technique rather than rediscover it. Reading the solution without attempting the work first is a reliable way to feel like you learned something without actually having done so.