## https://sploitus.com/exploit?id=52773B5A-22AE-5359-83C0-55FEC3391914
# Stack Buffer Overflow โ Shellcode Injection (Educational Project)
> **Programming Fundamentals โ First Semester Project**
> A hands-on study of a classic stack-based buffer overflow in a C++ program, exploited to redirect execution into injected shellcode that launches the Windows Calculator (`calc.exe`) as a harmless proof-of-concept.
---
## โ ๏ธ Disclaimer
This project was completed for an **academic course** as an introduction to memory-safety concepts and low-level program behavior. The payload used here does **nothing malicious** โ it simply opens the Windows Calculator, the standard "hello world" of exploit demonstrations. All testing was performed **locally, on our own machines**, inside a controlled lab environment with OS protections deliberately disabled for study.
Do not use these techniques against systems you do not own or have explicit permission to test. The purpose here is **defensive understanding**: learning how a vulnerability arises so you can avoid writing one.
---
## ๐ Overview
Buffer overflows are one of the oldest and most instructive vulnerability classes in software security. This project walks through the complete lifecycle of one:
1. **The vulnerability** โ a C++ program that reads user input into a fixed-size stack buffer with no bounds checking.
2. **The analysis** โ using **Immunity Debugger** to inspect the stack, find the exact offset that overwrites the saved return address, and locate a usable `JMP ESP` instruction.
3. **The exploit** โ crafting a payload (padding + return-address overwrite + NOP sled + shellcode) that redirects execution into our own code.
4. **The result** โ the vulnerable program launches `calc.exe` instead of returning normally.
The full write-up with screenshots is in [`report/PF_ESP_Report.pdf`](report/PF_ESP_Report.pdf).
---
## ๐งฉ The Vulnerability
```cpp
char buffer[64];
cout These steps require an **x86 Windows environment you control**, with modern protections disabled. This is intentionally *not* how real software should run โ the mitigations exist precisely to stop this attack.
1. **Compile the vulnerable program** with an old/permissive toolchain (32-bit).
2. **Disable protections** for the study (this is why the exploit works at all โ see the [Modern Mitigations](#-why-this-doesnt-work-on-real-software) section):
- **DEP** (Data Execution Prevention)
- **ASLR** (Address Space Layout Randomization)
- Stack canaries / `/GS` (compiler stack protection)
3. **Generate the payload:** compile and run [`src/exploit.cpp`](src/exploit.cpp) to produce `payload.bin`.
4. **Attach Immunity Debugger** to the vulnerable process and feed it the payload.
5. Observe execution jump into the shellcode โ **Calculator opens**.
Detailed, screenshot-by-screenshot walkthrough: [`report/PF_ESP_Report.pdf`](report/PF_ESP_Report.pdf).
---
## ๐ก๏ธ Why This *Doesn't* Work on Real Software
A key learning outcome: this exploit only succeeds because we **turned the defenses off**. On a normally-configured modern system, each of these would break it:
| Mitigation | What it does | Effect on this exploit |
|------------|--------------|------------------------|
| **DEP / NX** | Marks the stack non-executable | Shellcode on the stack won't run |
| **ASLR** | Randomizes memory addresses | Hardcoded `JMP ESP` address becomes unreliable |
| **Stack Canaries (`/GS`)** | Places a guard value before the return address | Overflow is detected before `main()` returns |
| **Safe functions** | `fgets()` / `gets_s()` enforce a length limit | The overflow never happens in the first place |
**The fix in the source code is one line:**
```cpp
// Vulnerable:
gets(buffer);
// Safe:
fgets(buffer, sizeof(buffer), stdin);
```
---
## ๐ Repository Structure
```
.
โโโ README.md # You are here
โโโ src/
โ โโโ vulnerable.cpp # The program with the buffer overflow
โ โโโ exploit.cpp # Builds payload.bin (padding + JMP ESP + NOP + shellcode)
โโโ docs/
โ โโโ VULNERABILITY.md # Deep-dive: why gets() breaks, stack anatomy
โ โโโ LEARNINGS.md # What we learned (C++ + security concepts)
โโโ report/
โ โโโ PF_ESP_Report.pdf # Full lab report with debugger screenshots
โโโ LICENSE
```
---
## ๐ What We Learned
This was our **first-semester Programming Fundamentals** project, and it connected C++ language basics to real security consequences. Highlights:
- How the **call stack** actually works โ buffers, saved EBP, and the return address.
- Why **memory-unsafe functions** like `gets()` are dangerous, and what safe alternatives exist.
- **Little-endian** byte ordering (why the `JMP ESP` address is written backwards).
- Reading **assembly and CPU registers** (ESP, EIP) in a live debugger.
- The purpose of real-world **exploit mitigations** โ and a new appreciation for *why* they exist.
Full reflection in [`docs/LEARNINGS.md`](docs/LEARNINGS.md).
---
## ๐ฅ Authors
First-semester group project.
- **[Your Name]** โ *Roll No. / ID*
- **[Group Member 2]** โ *Roll No. / ID*
- **[Group Member 3]** โ *Roll No. / ID*
*Course: Programming Fundamentals ยท Instructor: [Instructor Name] ยท [University Name], [Semester/Year]*
---
## ๐ License
Released under the [MIT License](LICENSE) for educational use.