Firmware Hardware Assessment

Firmware and hardware assessment

A visible debug pad is not usable debug access. Matching flash reads prove a repeatable acquisition, not authentic firmware. A signature block or downgrade string does not prove enforcement. Keep each conclusion tied to the exact unit, artifact, action, and evidence.

When to Use

• Planning, conducting, reviewing, or handing over an authorized hardware or IoT penetration test.
• Use only within explicit authorization and the stated rules of engagement.

When NOT to Use

• Do not treat this skill as permission to access, test, or change a target.
• Do not convert missing evidence into a clean result or a stronger claim.

Workflow

1. Record model, serial, hardware revision, reported firmware, and whether each device is sacrificial and authorized for damage.
2. State allowed action classes, in-scope external systems, and constraints. Treat voltage, power state, fixtures, and irreplaceable calibration as safety boundaries, not informal notes.
3. Bind photographs, measurements, logs, captures, and analysis to a device. Keep secret values out of summaries and report attachments.
4. Record each acquired artifact with its SHA-256, source, acquisition, and evidence. Preserve repeated reads as separate artifacts.
5. Derive acquisition consistency from artifact hashes. Matching reads establish repeatability only from the first recorded read onward.
6. Compare vendor and installed images by partitions and normalized content. Record per-device configuration and calibration before interpreting unequal whole-image hashes.
7. Inventory one device surface per unit, then components, debug interfaces, storage, firmware images, update mechanisms, local and network services, radios, and external systems.
8. Cover device identity, acquisition integrity, debug access, firmware analysis, credential material, update trust, communications, integration, supply chain, and physical safety. Preserve planned, blocked, delegated, and inconclusive work.
9. Use finding only for an executed, evidenced case. Limit claim scope to the tested unit unless evidence from additional devices supports a broader claim.
10. Delegate companion applications, vendor cloud, brokers, update services, and production systems. Discovery does not authorize contact.

Interpretation rules

• A password prompt is a positive control for that interface, not proof of password strength or restricted post-authentication privilege.
• A locked root account says nothing about other support identities.
• A recovered private key proves extractability from that artifact. Fleet-wide reuse needs evidence from more than one unit.
• An apparent signature block is an indicator until verification code, trust anchor, signed regions, and failure behavior are established.
• An update error string does not prove rollback prevention.
• Interface pads prove physical presence. Pinout, lifecycle state, fuses, authentication, and effective access remain separate questions.
• Firmware version labels do not prove byte equivalence.

Rationalizations to reject

• "The hashes differ, so the installed firmware was tampered with." Device configuration, calibration, logs, and writable state can explain the delta.
• "Two reads match, so the firmware is authentic." They prove acquisition repeatability, not origin or trust.
• "JTAG pads exist, so JTAG is enabled." Usability depends on pinout, electrical state, lifecycle controls, and authorization to interrogate it.
• "The package is signed, so updates are secure." Enforcement and coverage of every security-sensitive field still need evidence.
• "The credential is in one unit, so the whole fleet shares it." A single-device observation cannot establish provisioning behavior.
• "A sacrificial fixture makes destructive work authorized." Written action scope and explicit damage authorization are both required.