reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: competition-firmware-layout
|
||||
description: Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for firmware images, partition tables, boot chains, update packages, extracted filesystems, embedded configs, and device-facing trust boundaries. Use when the user asks to unpack firmware, map partition layout, inspect bootloader or init chains, recover update keys or credentials, trace config loading, or explain how a device surface reaches the decisive artifact. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
|
||||
---
|
||||
|
||||
# Competition 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
|
||||
|
||||
1. Preserve the original image, extracted partitions, unpacked filesystems, and patched copies as separate artifacts.
|
||||
2. Map outer container, partition table, bootloader, kernel, rootfs, config, and update metadata before editing anything.
|
||||
3. Track the boot or update chain in order instead of jumping straight to the most interesting file.
|
||||
4. Record keys, signatures, offsets, partition boundaries, and init entrypoints in one compact evidence chain.
|
||||
5. 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.md` for 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
|
||||
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Competition Firmware Layout"
|
||||
short_description: "Map firmware partitions, boot chains, and extracted secrets"
|
||||
default_prompt: "After $ctf-sandbox-orchestrator is active, use $competition-firmware-layout to map this firmware image, extract partitions, trace the boot or update chain, and recover decisive secrets or branches."
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -0,0 +1,27 @@
|
||||
# Firmware Layout Checklist
|
||||
|
||||
## First Pass
|
||||
|
||||
- Identify outer container, partition headers, compression, checksums, and appended images
|
||||
- Record partition names, offsets, sizes, filesystem types, mount points, and hashes
|
||||
- Separate bootloader, kernel, initramfs, rootfs, config, and update payloads
|
||||
|
||||
## Boot Or Update Chain
|
||||
|
||||
1. Boot ROM or vendor bootstrap
|
||||
2. Bootloader or secure boot stage
|
||||
3. Kernel and initramfs
|
||||
4. Root filesystem init path and services
|
||||
5. Update verifier, installer, and post-install hooks
|
||||
|
||||
## Evidence To Keep Together
|
||||
|
||||
- Boundary facts: offsets, sizes, signatures, hashes, partition names
|
||||
- Consumed state: keys, certs, passwords, default configs, scripts, or service files
|
||||
- Reachable effect: debug service, auth branch, update bypass, or recovered artifact
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Editing extracted files before recording pristine offsets and hashes
|
||||
- Mixing config recovered from one partition with behavior sourced from another without proving the link
|
||||
- Treating an extracted secret as decisive without showing where the boot or update flow actually consumes it
|
||||
Reference in New Issue
Block a user