About competition-firmware-layout
A CTF specialization for firmware image analysis, used after `$ctf-sandbox-orchestrator` to map image structure, boot or update flows, and device behavior. It preserves original and extracted artifacts separately while tracing evidence from image boundaries to relevant behavior.
Key features
- 01Identify containers, partitions, and filesystems
- 02Map boot and update flows
- 03Record offsets, hashes, and entrypoints
- 04Separate original images from modified copies
- 05Trace exposed services and credential sources
Use cases
- 01Break down a firmware image and locate partitions
- 02Trace configuration or keys used during boot
- 03Analyze update-package verification and installation
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ zhaoxuya520/ reverse-skill --skill competition-firmware-layoutAfter installing, type/competition-firmware-layoutin Claude Code to confirm it loaded.
Bundled filesagents/openai.yamlreferences/firmware-layout.md
Details
From the project READMECompetition Firmware Layout
Use this skill only as a downstream specialization after $ctf-sandbox-orchestrator is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to $ctf-sandbox-orchestrator first.
Use this skill when the hard part is understanding how a firmware image is structured, booted, updated, and turned into reachable device behavior.
Reply in Simplified Chinese unless the user explicitly requests English.
Quick Start
- Preserve the original image, extracted partitions, unpacked filesystems, and patched copies as separate artifacts.
- Map outer container, partition table, bootloader, kernel, rootfs, config, and update metadata before editing anything.
- Track the boot or update chain in order instead of jumping straight to the most interesting file.
- Record keys, signatures, offsets, partition boundaries, and init entrypoints in one compact evidence chain.
- Reproduce the decisive secret, branch, or reachable service from the smallest extracted path.
Workflow
1. Establish Image Layout
- Identify container type, partition headers, compression, filesystem type, and any appended or nested images.
- Record offsets, sizes, hashes, mount points, and partition names before extraction mutates anything.
- Separate bootloader, kernel, initramfs, rootfs, config blobs, and update metadata as different layers.
2. Trace Boot Or Update Flow
- Map how control moves from bootloader to kernel to init to services, or from update package to verifier to installer.
- Note which credentials, certificates, passwords, seeds, or config files are consumed at each stage.
- Distinguish checked-in firmware intent from the live behavior the extracted files actually support.
3. Reduce To The Decisive Path
- Show the smallest chain from image boundary to service exposure, auth bypass, debug interface, credential recovery, or flag artifact.
- Keep extracted filesystems, derived configs, and patch experiments separate from pristine inputs.
- If the challenge becomes mostly about native crash behavior or exploit primitives after extraction, switch back to the broader reverse skill.
Read This Reference
- Load
references/firmware-layout.mdfor the layout checklist, boot-chain checklist, and evidence packaging.
What To Preserve
- Partition offsets, hashes, filesystem types, mount paths, boot entrypoints, and update metadata
- Extracted secrets, config paths, init scripts, service units, and credentials tied to the stage that consumes them
- Original images, extracted layers, mounted views, and patched copies as separate artifacts