CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

firmware-acquisition

Systematic firmware extraction from IoT and embedded targets — vendor portals, OTA interception, SPI flash dumping with flashrom/CH341A, eMMC chip-off, and UART/JTAG console dumps. Covers the full acquisition chain from zero hardware access to a raw binary ready for static analysis.

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Critical

Do not install without reviewing

SKILL.md
Quality
Evals
Security

Quality

Content

78%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, lean, highly actionable tiered runbook with genuinely useful troubleshooting and OPSEC content. The main defects are localized executability slips (screen baud loop, U-Boot dump labeling) and a References entry pointing to a file that is missing from the bundle.

Suggestions

Create references/ch341a-soic-wiring.md (or remove the References entry) so the body's only bundle pointer resolves to a real file.

Fix the U-Boot section: `loady` receives a file over XMODEM from the host — replace the mislabeled 'Dump via XMODEM' comment with the actual capture-and-convert flow already shown via `md.b`, and note the `sf read` + `tftp` path (1c) as the preferred full-flash method.

Add a post-acquisition validation step (e.g., `binwalk`/`file` on the final image, and size check against the chip's nominal capacity) before declaring the binary ready for static analysis.

DimensionReasoningScore

Conciseness

The body is a dense runbook: terse code blocks with instructive one-line comments, and the prose that exists ("flashrom sees 0x00 or 0xFF → chip held in reset by SoC pull-downs", the OPSEC notes) is operational knowledge Claude would not already have. No padding or explanation of known concepts. Not score 4: there are no real instances of over-explanation to trim.

5 / 5

Actionability

Most guidance is copy-paste-ready (arpspoof/mitmproxy chains, flashrom probe→dump→cmp double-read, openocd dump_image, dd + mount loop with computed offset), but a few spots fall short of fully executable: the `screen` baud-probe `for` loop cannot work as written since screen is interactive, the U-Boot block's `loady`/`md.b` sequence is mislabeled as a dump-to-host path, and Tier 3c leans on a vague "nanddump equivalent". Not score 3: the gaps are minor and localized, not pseudocode-level.

4 / 5

Workflow Clarity

The tiered sequence is explicit and justified ("cheapest and least invasive first"), prerequisites are listed, and destructive/batch operations do have verification — checksum-verify before unpacking (0a), a double-read + sha256 + cmp feedback loop with a re-seat-clip recovery action (3a), and lsblk size confirmation before/after dd (4b). Not score 5: Tier 1 (UART hex-capture) and Tier 2 (JTAG/OpenOCD) dumps lack any validation checkpoint, and there is no final image-validity check (e.g., `binwalk`/`file`) before handing off to static analysis.

4 / 5

Progressive Disclosure

Section structure is clean (prerequisites → Tier 0–4 → evidence → OPSEC → references), but the only bundle reference, `references/ch341a-soic-wiring.md` in the References section, does not exist — no references/, scripts/, or assets/ directories are present in the skill bundle, making it a dangling pointer. Scored against the actual bundle structure, a broken cross-file reference is more than a minor organization gap, so this sits below the anchor 4 ("references mostly clear") rather than above anchor 3.

3 / 5

Total

16

/

20

Passed

Description

82%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, specific description that names concrete methods and tools with good synonym coverage for triggers. Its only material weakness is the absence of an explicit 'Use when...' trigger clause, which caps completeness.

Suggestions

Append an explicit trigger clause, e.g. "Use when the user needs to dump or extract firmware from an IoT/embedded device — before static analysis begins."

Include one or two plain-language phrasings users commonly say ("dump firmware", "read the flash chip") alongside the tool names.

DimensionReasoningScore

Specificity

The description lists five concrete acquisition methods with tool names — "vendor portals, OTA interception, SPI flash dumping with flashrom/CH341A, eMMC chip-off, and UART/JTAG console dumps" — which comprehensively covers the firmware acquisition domain. Not score 4: the coverage of acquisition paths is complete rather than having minor gaps.

5 / 5

Completeness

The "what" is clear (systematic firmware extraction via named methods), but there is no "Use when..." clause or equivalent explicit trigger guidance — "Covers the full acquisition chain from zero hardware access to a raw binary ready for static analysis" describes scope, not when to invoke the skill. Per the judging guideline, a missing explicit 'when' caps completeness at 3, matching the anchor for a clear 'what' with 'when' only weakly implied.

3 / 5

Trigger Term Quality

Natural trigger terms appear with synonym variants users would actually say: "firmware extraction", "SPI flash dumping", "UART/JTAG console dumps", "eMMC chip-off", plus exact tool names ("flashrom", "CH341A") and interface names. A few natural phrasings (e.g., "dump firmware", "read the flash chip") are absent but the dump/extraction synonym coverage is comprehensive for this domain.

5 / 5

Distinctiveness Conflict Risk

Clear niche (physical/logical firmware acquisition for IoT/embedded targets) with distinct triggers — flashrom, CH341A, SPI flash, eMMC chip-off, UART/JTAG — that no adjacent skill (e.g., static analysis or reversing) would claim. Minimal conflict risk.

5 / 5

Total

18

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

14

/

16

Passed

Repository

PurpleAILAB/Decepticon

Path

packages/decepticon/decepticon/skills/standard/iot/firmware-acquisition/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.