Reports that survive review
Clear affected versions, reachable surfaces, impact, logs, and payloads. Less hype, more proof.
Hacker, but keep it reproducible.
I like the basic path: understand the target, map input to behavior, separate facts from guesses, then write the smallest proof that another person can replay.
Small devices, big mistakes
Firmware trees, web handlers, command wrappers, default configs, and every weird path between them.
Reverse before exploit
Model the binary, rename by data flow, find the primitive, then build the payload with exact offsets.
Research lanes
Firmware mapping
Extract images, trace init scripts, map web roots, find writable paths, and connect services to risky handlers.
Embedded web surfaces
Auth boundaries, config imports, command wrappers, template paths, upload flows, and fragile validation.
Reverse engineering
Function clusters, string references, parser behavior, state machines, and careful names over fast guesses.
Binary exploitation
Protections, offsets, primitives, ROP chains, libc details, and payloads that are understandable later.
CVE workflow
Minimal repro, affected endpoint, proof of impact, disclosure notes, patched build checks, and clean writeups.
Research writing
Commands, assumptions, offsets, logs, screenshots when useful, and enough context to reproduce the path.
Selected case files
These are sample note shapes: structured, basic, and biased toward evidence.
CVE / bug hunting note
Input: product behavior / Output: report skeleton
target: vendor-device-web-ui surface: authenticated handler, config import path bug shape: unsanitized input reaches privileged command wrapper impact: command execution in device context proof: minimal payload, logs, version, affected endpoint next: reduce noise, write clean repro, verify patched build
IoT firmware map
Input: firmware image / Output: quick research map
target: router-firmware.bin extract: binwalk -> squashfs-root first: init scripts, web root, default config, exposed services watch: hardcoded secrets, command wrappers, writable paths next: map service entrypoints before forming exploit ideas
Reverse engineering scratchpad
Input: function cluster / Output: working hypothesis
function: sub_4018F0 role: likely input parser signals: bounds check nearby, string table references, error-code caller risk: first names are often wrong next: rename by data flow, not by vibes
Binary exploitation note
Input: CTF binary / Output: exploit direction
binary: chall protections: NX enabled, PIE disabled, partial RELRO bug class: stack overflow candidate plan: find offset -> control RIP -> build ROP next: keep exact commands, offsets, libc, and payload shape
Toolkit
Basic tools, used carefully. Tool names are less important than the notes they produce.
Linux
Python
C
Burp Suite
Ghidra
IDA
Binwalk
pwndbg
Firmware
IoT Web
ROP
Responsible disclosure
Research principles
The note rules stay simple because good security work needs repeatability more than decoration.
- 01 Show the artifact, target version, and affected surface first.
- 02 Separate observed facts from guesses.
- 03 Keep commands, offsets, payloads, and logs exact.
- 04 Explain impact without hype.
- 05 Prefer small reproducible samples over long vague explanations.
open channel
Contact
For research discussion, collaboration, bug bounty notes, responsible disclosure, or CTF talk. Static page, no tracking, no noise.