Milestone map
Milestone map
2 milestones
Do the course work in public
2–4 weeks (5 hrs/week)
Take Identifying Security Vulnerabilities in C/C++ Programming for free and do the Binary Exploitation challenges on memory bugs (stack and buffer overflows, then format strings and the heap), each with a write-up. Keep everything in one public repo or notebook as you go. OSSU lists a Coursera course. We use free Binary Exploitation modules that check each solution for you.
Proof required
Link your public repo or notebook with the Binary Exploitation challenges on memory bugs (stack and buffer overflows, then format strings and the heap), each with a write-up, and a screenshot or log showing the self-check passed.
What gets checked
- Each challenge is marked solved on your account on the course site.
- Write-ups explain the memory bug.
- Each names how the code should have been written.
Common mistakes
- Copying posted answers: verifiers read the history.
- Skipping the self-check, then asking for review too early.
Powstik Guide
A public repo or notebook with the Binary Exploitation challenges on memory bugs (stack and buffer overflows, then format strings and the heap), each with a write-up.
Steps
- Make a public repo or notebook first.
- Do one unit at a time and commit after each.
- Run the self-check: Solve each challenge in the browser workspace; the site checks the flag you submit and marks the challenge solved.
- Write a short README: what is here and how to run it.
- Ask three people who know the topic to check it.
Template
README Course: Identifying Security Vulnerabilities in C/C++ Programming (pwn.college: Binary Exploitation (Arizona State University)) What is here: How to run it: Self-check result: What was hardest:
What gets sent back
- No history, just one big upload.
- Self-check not shown.
- Code that does not run from the README.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Each challenge is marked solved on your account on the course site.
- Write-ups explain the memory bug.
- Each names how the code should have been written.
- Ask one question about a choice in the code; the answer should be clear.
You'll sign in first, then come straight back here.
Fix a memory bug in C code
1–3 weeks (5–8 hrs/week)
Use what you learned. Make a small C program with a memory bug you found (by a fuzzer or sanitizer), and the fix. Keep it small enough to finish in about two weeks.
Proof required
Link a small C program with a memory bug you found (by a fuzzer or sanitizer), and the fix, with a README that says how to run or read it.
What gets checked
- The bug is shown by a tool's output.
- The fix removes it (tool output after).
- The write-up is clear.
Common mistakes
- A project too big to finish.
- A demo that only works on your machine.
Powstik Guide
A small C program with a memory bug you found (by a fuzzer or sanitizer), and the fix.
Steps
- Write one line: what it does and for whom.
- Build the smallest version that works.
- Test it on someone else's machine or with someone else reading it.
- Write the README.
- Ask three people to check it.
Template
README What it does: Who it is for: How to run it: What I would do next:
What gets sent back
- Does not run from the README.
- Not clearly the person's own work.
- Claims more than it does.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- The bug is shown by a tool's output.
- The fix removes it (tool output after).
- The write-up is clear.
- Check that the work is the person's own.
You'll sign in first, then come straight back here.