# A focused review of your firmware. Software-focused firmware security, from an accessible image to a selected component or release change. Each engagement is assessed for feasibility and fit. Hardware testing and complete IoT ecosystem assessments are outside the service. ## Firmware image review Initial pilot focus Build an evidence-led understanding of one accessible firmware release. **The question** What does this image contain, and which areas warrant closer investigation? **Potential scope** Image structure, architecture, component identification, startup configuration and selected management services. **Inputs** A customer-supplied, accessible firmware image, authorization to review it, product context and available technical documentation. Physical extraction from a device is not included. **Proposed output** A technical report with observations, supporting evidence, coverage limits and prioritized next steps. ## Focused firmware research Fit assessed per project Investigate a defined security question about software inside the firmware. **The question** Can a selected firmware component, suspected issue or documented software change be better understood through a bounded investigation? **Potential scope** A selected binary, source component or software security question within firmware, where my exploit-development background fits the target. **Inputs** A clear firmware-related question, the relevant binary or source material and agreed conditions for software-based validation. **Proposed output** Technical observations and supporting evidence, with verified conclusions separated from unresolved questions. ## Firmware release and fix review Separately scoped follow-on work Understand what changed and what the evidence supports. **The question** What changed between the supplied firmware versions, and does the available software evidence support a proposed fix? **Potential scope** Selected firmware component or configuration changes, and review of a proposed software fix within the original assessment boundaries. **Inputs** The relevant firmware versions, change context, prior findings and software inputs needed to reproduce the agreed checks. **Proposed output** A change summary or retest note. A different version alone does not demonstrate successful remediation. ## Agree the boundaries first. Hardware work is not offered. Device teardown, physical firmware extraction, debug-port testing, radio testing, fault injection and side-channel testing are excluded. Cloud, companion-app, network and full IoT ecosystem assessments are also outside the service. An offline review does not validate device behavior or hardware-backed protections. ## Define a realistic engagement. - Confirm scope, authorization and feasibility. - Agree evidence handling and deliverables. - Set the fee and schedule before paid work starts. - Define any walkthrough or retest in the proposal. Source: [Services](https://kedloc.com/services)