Exam Report — Oswe

Include 10 lines above and below the vulnerable code. Failure #3: Forgetting the “White-Box” Rule Do not write the report as if you discovered the vulnerability via fuzzing. Say: “While reviewing routes.php, the application fails to validate the ‘action’ parameter before passing it to call_user_func_array().” Failure #4: Poor Screenshot Hygiene Blurry images, terminal text too small, or screenshots that edit out critical error messages. OffSec requires clear, readable proofs.

Treat the report as a separate, 24-hour exam. Sleep, hydrate, then review every line of code you pasted, every command you typed, and every screenshot you took. The difference between an OSWE and a “failed attempt” is often just 5 hours of careful documentation.

I recommend the following directory structure for your report assets: oswe exam report

Explain step-by-step how user input flows from the entry point (e.g., a $_POST['file'] parameter) to a sink function (e.g., include() or system() ). OSWE examiners look for this “taint flow” analysis.

/oswe_exam_2024/ /screenshots/ /app1/ code_lfi.png exploit_run.png proof_flag.png /exploits/ app1_exploit.py app2_rce.php report.md During the 48-hour exam, you are exhausted. You will forget what a screenshot was for. Use a timestamp tool or a notebook. Include 10 lines above and below the vulnerable code

Example Python output to include in report:

Use relative paths and generic listener commands. Document every external command. Failure #2: Missing Code Context You show a weakness but not the surrounding code. For instance, you find a SQL injection, but you don’t show the sanitization attempt (e.g., addslashes() ) that you bypassed. The examiner needs to see why the developer’s fix failed. OffSec requires clear, readable proofs

Your goal is to provide a document that allows Offensive Security’s lab team to verify your findings.