diff --git a/docs/research/safe-device-research-method-2026-08-26.md b/docs/research/safe-device-research-method-2026-08-26.md new file mode 100644 index 000000000..1109d85ae --- /dev/null +++ b/docs/research/safe-device-research-method-2026-08-26.md @@ -0,0 +1,365 @@ +# Safe device and firmware security-research method + +Date: 2026-08-26 + +## Decision + +Use a four-stage, evidence-gated method: + +1. passive research on public artifacts; +2. authorized acquisition and offline analysis of firmware for an owned device; +3. narrowly approved, non-mutating interaction with that device; and +4. a separate campaign, approval, and recovery plan for every persistent or potentially + destructive action. + +Progress through the first three stages does **not** authorize the fourth. Flashing, +configuration or non-volatile-memory writes, arbitrary memory writes, signature-bypass +validation, fault injection, opening or soldering hardware, and any action with a +credible bricking or safety risk remain out of scope until separately approved. + +This note extracts the repeatable structure from +[Everything I own, owned](https://schlarp.com/posts/everything-i-own-owned/), then narrows +it using primary standards. It does not endorse the article's device-specific actions, +choose a device, or authorize interaction with any device or third-party service. + +## What is reusable from the article + +The useful seed is a short loop: obtain the manufacturer's firmware and updater, place +copies in an isolated reverse-engineering environment, inventory the update format and +protocol, map protocol surfaces and hidden functionality, cross-check static conclusions +against observed behavior, and preserve material that another researcher can validate. +The article also demonstrates why update tooling belongs in the scope: the updater may +reveal acquisition endpoints, container formats, transport protocols, integrity checks, +and device modes that the firmware image alone does not explain. + +The article is not, by itself, a safe operating procedure. Its examples cross materially +different boundaries: offline image analysis, benign device control, arbitrary file or +memory access, modified firmware installation, and signature-bypass validation. It also +describes an unattended session that produced an updater. Those activities must not +inherit one blanket authorization. NIST distinguishes examinations, which ordinarily +have little target impact, from hands-on testing, where even ordinary interaction can +cause an unexpected halt or denial of service. NIST therefore recommends that the rules +of engagement identify scope, allowed and prohibited activities, risk mitigations, data +handling, incident handling, and halt criteria before testing begins +([NIST SP 800-115](https://doi.org/10.6028/NIST.SP.800-115), sections 2.3, 6.2, 6.5, +and Appendix B). + +## The four authorization lanes + +| Lane | In scope | Explicitly outside the lane | Exit evidence | +| --- | --- | --- | --- | +| 1. Passive public research | Manufacturer support pages, public firmware and updater downloads, manuals, release notes, public source, standards, advisories, disclosure policy | Device traffic, undocumented endpoint enumeration, account or cloud testing, third-party device interaction | Source ledger, immutable downloads, hashes, version map, preliminary system and update map | +| 2. Owned-device acquisition and offline analysis | Normal vendor download/cache/export paths; a separately approved read-only capture from the owned unit; unpacking and static analysis of copies in an isolated workspace | Debug-port activation, desoldering/chip-off, writes, flashing, reboot-to-update, bypass attempts, execution of untrusted updater code on a trusted host | Acquisition record, preserved original, working copy, component/protocol map, hypotheses with confidence and provenance | +| 3. Non-mutating interaction | Exact approved reads or observations on the owned unit, isolated from unrelated hosts and accounts; descriptor queries, passive capture, and commands already shown not to change functional or persistent state | Unknown commands, fuzzing, POST/PUT/DELETE, arbitrary reads that may expose third-party secrets, configuration changes, reboots, memory access, firmware staging | Before/after state, raw transcript or capture, hypothesis result, no-change check, stop/incident record | +| 4. Persistent or destructive research | Only the exact newly approved action with a tested recovery path, operator present, and bounded success/stop conditions | Any adjacent action not named in the approval; unattended execution; widening from the owned device to vendor or neighbor infrastructure | Approval record, recovery rehearsal, full action log, pre/post images and state, restoration result, disclosure-ready evidence | + +“Owned” applies to the physical device, not automatically to vendor cloud services, +mobile-app backends, shared networks, other users' data, radio infrastructure, or bundled +third-party services. Those surfaces need their own authorization or a published policy +that clearly includes the intended activity. CISA describes a vulnerability disclosure +policy as the place that tells researchers which systems and types of testing are +authorized and what communication to expect +([CISA BOD 20-01 overview](https://www.cisa.gov/news-events/news/cisa-issues-final-vulnerability-disclosure-policy-directive-federal-agencies)). + +## Prerequisites before admitting a target + +Record answers before acquiring or interacting with a device. A “no” or “unknown” on an +ownership, scope, safety, recovery, or evidence question blocks the affected lane; it +does not block passive public research. + +### Authorization and boundaries + +- Who owns the exact unit, and who can authorize testing it? +- Is the unit used by another person, employer, tenant, customer, or regulated workflow? +- Which physical device identifiers, interfaces, host, lab network, accounts, applications, + and cloud services are in scope? Which are excluded? +- Does the vendor publish a security policy or disclosure channel, and does it authorize + any active work contemplated outside the owned unit? +- What exact operations are allowed in this lane? List prohibited operations just as + explicitly. NIST recommends naming authorized and unauthorized systems and leaving no + ambiguity about prohibited actions such as file creation or modification + ([NIST SP 800-115](https://doi.org/10.6028/NIST.SP.800-115), section 6.2). + +### Device and safety context + +- Can failure affect bodily safety, alarms, access control, medical care, power, heat, + batteries, motors, privacy indicators, or irreplaceable data? +- Can the device impersonate an input, network, storage, audio, or video device to its + host? Can it reach unrelated systems or accounts? +- Can all radios, cloud links, automatic updates, companion applications, and host access + be isolated without defeating the observation being studied? +- Is there a spare unit or an equivalent sacrificial unit? Is its hardware and firmware + revision the same? + +### Firmware and recovery context + +- Is the exact model, hardware revision, region, installed firmware version, updater + version, and update source known? +- Is there a vendor-provided firmware image and documented recovery procedure? Is the + recovery artifact pinned and available offline? +- Does the device support rollback, A/B images, recovery mode, or a protected recovery + image? NIST identifies authenticated updates, rollback, manual recovery, and automatic + recovery as distinct mechanisms; their presence must be verified rather than assumed + ([NIST SP 800-193](https://doi.org/10.6028/NIST.SP.800-193), sections 3.5.1–3.5.3). +- What power, cable, programmer, fixture, driver, and host requirements does recovery + have? Has the recovery path been rehearsed without modifying the research unit? +- What is the acceptable loss limit? If the answer is “the unit cannot be lost,” do not + admit persistent or bricking-risk work. + +### Evidence and disclosure context + +- Where will originals, hashes, updater logs, captures, notes, and sensitive findings be + stored? Who can access them, and how will secrets or third-party data be redacted? +- What synchronized time source and run identifier will join device, host, network, and + agent activity? +- What evidence is sufficient to validate or reject each hypothesis without crossing + into a riskier lane? +- Who will contact the vendor, through which channel, and what embargo or coordination + expectations apply? NIST recommends a formal process to receive, assess, manage, and + communicate vulnerability reports + ([NIST SP 800-216](https://doi.org/10.6028/NIST.SP.800-216)). + +## Stage 1: passive public-artifact research + +This lane may begin before choosing or possessing a device, provided it remains ordinary +retrieval of material intentionally published to the public. + +1. Create a source ledger containing URL, publisher, retrieval time, artifact name, + claimed model/hardware applicability, version, release date, license or terms notes, + and the retrieval mechanism. +2. Prefer the manufacturer's normal support and update channels. Save the firmware, + updater, release notes, manuals, driver packages, public source releases, disclosure + policy, and published recovery instructions. Do not guess private URLs, enumerate + buckets, bypass authentication, or automate at a rate that burdens the service. +3. Record the raw artifact's size and SHA-256 digest before unpacking it. FIPS 180-4 + defines SHA-256 as a Secure Hash Standard algorithm whose digest can detect later + change ([FIPS 180-4](https://doi.org/10.6028/NIST.FIPS.180-4)). A digest proves file + identity, not publisher authenticity; retain the TLS URL, signature, release note, or + other provenance independently. +4. Treat firmware, updaters, scripts, and documents as untrusted input. Analyze copies in + an isolated workspace without device access, personal credentials, trusted host + mounts, or unrestricted egress. +5. Build a preliminary map: image/container layers, processor and endianness clues, + filesystems, operating systems or RTOS components, boot stages, configuration and + non-volatile data, update packages, updater executables, transport interfaces, + integrity/authenticity mechanisms, recovery paths, and suspected debug surfaces. +6. Separate observation from inference. For example, “the package ends with 32 bytes” is + an observation; “the suffix is a checksum” remains a hypothesis until code, format + documentation, or controlled behavior supports it. + +Output is a versioned artifact corpus and a question list. It is not proof that an +installed device accepts an image, exposes a protocol, or is vulnerable. + +## Stage 2: authorized acquisition and offline analysis + +Use the least invasive source that answers the question: public vendor image first, +then an updater cache or documented export, then an approved read-only acquisition from +the owned unit. Physical extraction, debug-unlock sequences, chip-off, voltage or clock +manipulation, and any command that can alter storage are not part of this lane. + +For each acquisition: + +1. Record the unit identifier, model and hardware revision, installed version, source + interface, acquisition tool and version, exact command or UI sequence, operator, + timestamps, and observed errors. +2. Preserve the acquired original read-only, hash it, create a working copy, and perform + analysis on copies. NIST forensic guidance recommends documenting acquisition, + preserving originals, analyzing copies, and comparing message digests to verify the + copy + ([NIST SP 800-86](https://doi.org/10.6028/NIST.SP.800-86), sections 3.1 and 4.2.2). +3. Compare independently acquired copies where practical. Record byte differences rather + than silently normalizing headers, timestamps, per-device calibration, keys, or + configuration. +4. Recursively identify containers and components, but keep a derivation manifest from + every extracted object back to the original byte range and tool invocation. +5. Review both firmware and updater code. Trace package parsing, model/version checks, + cryptographic verification, transport framing, retry/resume, recovery, and the final + write boundary. NIST's IoT baseline treats update verification/authentication, + restriction to authorized entities, rollback, and configurable update behavior as + separate capabilities + ([NISTIR 8259A](https://doi.org/10.6028/NIST.IR.8259A), Software Update capability). +6. Enumerate attack surfaces from evidence: host-visible classes, network listeners, + wireless services, update/recovery transports, local buses, parsers, privileged + commands, debug functionality, trust anchors, and privilege boundaries. Do not turn + an inferred command into a device probe yet. +7. Cross-check critical claims using at least two independent forms of evidence when + available—for example, parser control flow plus a valid vendor package, or a command + table plus call-site behavior. Record contradictory evidence and confidence. + +The stage ends with a static system/update map, reproducible derivations, hypotheses, +and the smallest proposed interaction needed to resolve each uncertainty. + +## Stage 3: non-mutating interaction + +“Non-mutating” means the researcher does not request or expect a change to firmware, +configuration, non-volatile memory, user data, security state, device mode, host state, +or external services. Logging, counters, time, caches, and transient protocol state may +still change, so the approval must name acceptable incidental effects. + +Do not infer safety from a verb, endpoint, transport class, or nominal read command. +HTTP defines GET, HEAD, OPTIONS, and TRACE as safe by semantics, while also warning that +an implementation may still produce harmful side effects +([RFC 9110, section 9.2.1](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1)). +Unknown or vendor-specific commands therefore remain out of scope until static evidence, +documentation, or a sacrificial environment establishes their effect. + +Run one hypothesis at a time: + +1. Obtain an exact-intent approval identifying the device, interface, tool, command or + request, input bounds, expected response, acceptable incidental effects, runtime, + network profile, evidence capture, and stop conditions. +2. Isolate the device and research host from personal data, unrelated USB devices, + trusted networks, and third-party accounts. Disable routes that are not required by + the approved observation. +3. Capture a baseline: visible settings, firmware version, device mode, host enumeration, + open connections, storage/configuration digest where a supported read path exists, + and ordinary function. +4. Execute the single approved observation with the operator present. Preserve raw input, + output, timestamps, transport capture, tool version, and exit status. +5. Repeat the baseline and compare. Any unexplained change ends this lane and becomes an + incident or a proposal for a separately approved mutating test. +6. Update the hypothesis ledger as supported, rejected, or unresolved. Do not chain into + a newly discovered command or privilege level during the same approval. + +Examples that are **not** non-mutating by default include entering bootloader or mass +storage update mode, rebooting, staging an update, changing an LED or privacy indicator, +changing volume or display settings, authentication attempts, arbitrary memory reads or +writes, I2C/UART pokes, debug unlocks, and any request whose handler is not understood. + +## Stage 4: separately approved persistent or destructive work + +This is a new campaign, not a continuation prompt. Before admission, require all of the +following: + +- a validated finding or explicit research question that cannot be answered safely in an + earlier lane; +- a new exact-intent approval naming every write, image, address/range, transport, + expected reboot, and maximum duration; +- a clean-room reproduction package and hashes for original, candidate, and recovery + images; +- a recovery plan with known-good artifacts, compatible hardware, operator instructions, + and a rehearsed route that does not depend on the possibly corrupted firmware; +- a power and physical-safety plan, plus a sacrificial or replaceable unit when failure + can brick the target; +- interactive execution with checkpoints before each irreversible boundary; and +- a disclosure plan if the experiment could create transferable exploit knowledge. + +NIST frames firmware resiliency as protection from unauthorized change, detection of +change, and recovery to a state of integrity, and notes that firmware compromise can +leave a platform permanently inoperable or require manufacturer reprogramming +([NIST SP 800-193](https://doi.org/10.6028/NIST.SP.800-193)). A signed update, A/B layout, +or nominal recovery mode is therefore evidence to study, not permission to assume a +failed write is recoverable. + +Automation may prepare artifacts, verify hashes, parse captures, and pause at approval +checkpoints. It must not autonomously flash, write memory, disable signature checks, +exercise arbitrary buses, or improvise after an unexpected response. Every divergence +returns control to the operator. + +## Universal stop conditions + +Stop immediately and preserve evidence when any of these occurs: + +- target identity, ownership, authorization, or scope is uncertain; +- a command, endpoint, address, image, model revision, or write effect differs from the + approved intent; +- unexpected reboot, disconnect, boot-mode change, configuration drift, data change, + degraded function, heat, smell, swelling, power anomaly, motor motion, or safety alarm; +- communication reaches an excluded host, account, cloud service, radio peer, or another + person's data; +- the device exposes credentials, private keys, personal data, or evidence of prior + compromise not required for the hypothesis; +- logging, capture, time synchronization, hashing, or artifact storage fails; +- recovery prerequisites are missing or the recovery rehearsal no longer matches the + unit; or +- sufficient evidence already supports or rejects the hypothesis, so further impact adds + risk without evidentiary value. + +NIST's rules-of-engagement template calls for predefined halt criteria, an incident +course of action, a chain of command, and an explicit process for authorizing resumed +testing ([NIST SP 800-115](https://doi.org/10.6028/NIST.SP.800-115), Appendix B). Resume +only through that process; a model's suggestion, a generic “continue,” or prior approval +for a safer lane is not sufficient. + +## Evidence package + +Each research step should produce or update: + +- authorization and scope record, including lane and exclusions; +- device identity and lifecycle state; +- source/acquisition ledger and SHA-256 manifest; +- immutable originals and a derivation manifest for working artifacts; +- tool, environment, and dependency versions; +- hypothesis ledger distinguishing observations, inferences, confidence, contradictions, + and validation status; +- timestamped activity log containing exact commands/requests and raw outputs; +- before/after state and no-change check for device interaction; +- stop, incident, and recovery records; +- minimal reproducer and impact evidence for a validated finding; and +- redacted disclosure package with affected versions, prerequisites, expected/observed + behavior, security effect, remediation ideas, and uncertainty. + +NIST recommends a step-by-step assessor activity log containing time, assessor, source +system, target system, tool, command, and comments, plus secure storage of rules of +engagement, configuration, tool results, findings, and reports +([NIST SP 800-115](https://doi.org/10.6028/NIST.SP.800-115), sections 7.4.1–7.4.2). + +## Finding and disclosure threshold + +A suspicious string, hidden command name, missing-looking check, or reachable handler is +a Research Observation. Promote it only after evidence establishes reachability, +prerequisites, affected versions, and a reproducible security effect. Prefer the smallest +demonstration that proves the effect; do not perform persistence, stealth, data access, or +cross-account impact merely to make the report more dramatic. + +Before public release, contact the vendor through its published channel and coordinate +the technical details and remediation timeline. Preserve the unredacted evidence under +restricted access and publish only what users need to understand exposure and mitigation. +NIST SP 800-216 treats receipt, assessment, management, mitigation/remediation +communication, and public dissemination as parts of one vulnerability-disclosure +framework ([NIST SP 800-216](https://doi.org/10.6028/NIST.SP.800-216)). + +## Implications for ExploitHunter + +The eventual device workflow should encode the lanes as separate authorization states, +not prompt prose: + +- a Target record pins the physical unit, hardware/firmware revision, owner, interfaces, + included services, exclusions, safety class, and recovery readiness; +- every task and tool run names one lane and exact target identifiers; +- crossing a lane creates a new approval request rather than inheriting the earlier one; +- artifact acquisition, hashing, derivation, raw transcripts, and before/after state use + the existing artifact and evidence path; +- persistent-write tools are unavailable until recovery evidence and a matching approval + exist, and remain interactive; +- stop conditions create a durable incident/continuation artifact and revoke the current + run's ability to proceed; and +- promoted methodology becomes a searchable product skill only after it proves reusable + across authorized campaigns. + +The first device remains a later decision. Candidate selection should compare ownership, +replaceability, public firmware availability, offline analyzability, interface isolation, +recovery evidence, safety impact, disclosure channel, and the ability to obtain useful +evidence without entering lane 4. + +## Sources + +- Schlarp, [Everything I own, owned](https://schlarp.com/posts/everything-i-own-owned/), + August 23, 2026. Method seed and examples; not treated as an authority for safety. +- NIST, [SP 800-115: Technical Guide to Information Security Testing and + Assessment](https://doi.org/10.6028/NIST.SP.800-115), September 2008. +- NIST, [SP 800-86: Guide to Integrating Forensic Techniques into Incident + Response](https://doi.org/10.6028/NIST.SP.800-86), August 2006. +- NIST, [IR 8259A: IoT Device Cybersecurity Capability Core + Baseline](https://doi.org/10.6028/NIST.IR.8259A), May 2020. +- NIST, [SP 800-193: Platform Firmware Resiliency + Guidelines](https://doi.org/10.6028/NIST.SP.800-193), May 2018. +- NIST, [SP 800-216: Recommendations for Federal Vulnerability Disclosure + Guidelines](https://doi.org/10.6028/NIST.SP.800-216), May 2023. +- NIST, [FIPS 180-4: Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4), + August 2015. +- IETF, [RFC 9110: HTTP Semantics, section 9.2.1 Safe + Methods](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1), June 2022. +- CISA, [BOD 20-01 vulnerability disclosure policy + overview](https://www.cisa.gov/news-events/news/cisa-issues-final-vulnerability-disclosure-policy-directive-federal-agencies), + September 2020.