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

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

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

Quality

Content

75%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.

The body is an action-dense, well-sequenced acquisition guide with validation checkpoints where it matters most (flash reads) and strong OPSEC/evidence handling. Its main weaknesses are a dangling local reference and uneven validation across the non-flash tiers.

Suggestions

Create references/ch341a-soic-wiring.md (or remove the citation) so the one local reference resolves to a real bundle file.

Add explicit verification steps to the UART/JTAG and eMMC tiers (e.g. sha256sum + size check on the dumped image) to match the flash tier's validate-then-proceed pattern.

Mark target-specific placeholders consistently and note which values must come from the device datasheet/probe output to make the commands more copy-paste ready.

Dimension	Reasoning	Score
Conciseness	The body is command-dense and assumes Claude's competence — it does not re-explain what firmware or flashrom is — with only minor operational prose signposts (e.g. "UART is the fastest hardware path") that could be trimmed.	4 / 5
Actionability	It provides many concrete executable commands (flashrom, openocd, dd, mitmproxy, U-Boot), but several require target-specific substitution (<model>, <device_ip>, <hex_key>) and the chip-off procedure is procedural steps rather than a script.	4 / 5
Workflow Clarity	Tiers are explicitly sequenced (0 to 4, cheapest/least invasive first) with an explicit validation and feedback loop in the SPI dump tier ("Verify both reads match", "MISMATCH — re-seat clip"), though the UART/JTAG/eMMC tiers lack comparable verification checkpoints.	4 / 5
Progressive Disclosure	Section structure is clear (Prerequisites, Tiers 0-4, Evidence, OPSEC, References) with a dedicated one-level-deep References section; the only gap is that the local reference "references/ch341a-soic-wiring.md" is cited but no references/ bundle directory exists.	4 / 5
	Total	16 / 20 Passed

Description

75%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.

The description is specific and distinctive, listing concrete acquisition methods with named tools, but it lacks an explicit "Use when…" trigger clause, leaving the "when to use" guidance only weakly implied. Adding a trigger sentence would lift completeness.

Suggestions

Append an explicit trigger clause, e.g. "Use when acquiring firmware images from IoT/embedded devices — firmware dumps, SPI/eMMC reads, UART/JTAG dumps, or OTA capture."

Include the natural phrase "firmware dump" verbatim alongside "firmware extraction" to match how users most commonly phrase the request.

Dimension	Reasoning	Score
Specificity	Names the domain and multiple concrete actions — "vendor portals, OTA interception, SPI flash dumping with flashrom/CH341A, eMMC chip-off, and UART/JTAG console dumps" — giving comprehensive coverage of the acquisition chain rather than generic language.	5 / 5
Completeness	The "what" is clearly answered (acquisition chain and methods), but there is no "Use when…" clause or equivalent explicit trigger guidance, which per the rubric caps completeness at 3.	3 / 5
Trigger Term Quality	Strong domain keywords appear (firmware extraction, SPI flash, eMMC chip-off, UART/JTAG, OTA, flashrom, CH341A), but the most natural user phrase "firmware dump" is only implied via "dumping"/"dumps" and a few common variations are absent.	4 / 5
Distinctiveness Conflict Risk	It carves a clear niche — IoT/embedded firmware acquisition via specific hardware paths — with distinct triggers and minimal overlap risk against other skills.	5 / 5
	Total	17 / 20 Passed

Validation

87%

Warnings & errors only

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

Criteria	Description	Result
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
Commit: 31e1c8e

Reviewed: 13 days ago

Table of Contents

Discovery Implementation Validation

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.