PXLSecurity LTD., Sofia, Bulgaria Offensive security since 2014[email protected]
ENBG

Firmware / Embedded / Product security

Firmware & embedded penetration testing.

Test the firmware you ship and the device that runs it. Reverse engineering, QEMU emulation and hands-on hardware testing, with reproducible findings, practical fixes and an included remediation retest.

Request a scoped proposalExplore the sample report

Start with an image, a device or a release. NDA available before you share sensitive material.

PXLSec / LABTRUST BOUNDARIES
Follow the boundary.Firmware, emulation and hardware interfaces connected to a central processor.IMAGE.binUART / JTAGQEMUUPDATECPU

IMAGE / REVERSE ENGINEERING

What does the shipped image expose?

Unpack filesystems and binaries. Trace secrets, service configuration and security-sensitive code paths. Separate component matches from verified vulnerabilities.

EMULATION / DYNAMIC ANALYSIS

What happens when the code runs?

Emulate supported components or the system where feasible. Instrument execution and validate behaviour; document where peripherals or the environment limit fidelity.

DEVICE / HARDWARE INTERFACES

Which controls hold on the hardware?

Inspect UART, JTAG/SWD and flash access as applicable. Test boot, update and runtime boundaries on the agreed devices, with invasive techniques separately authorised.

Firmware to hardwareOne assessment, explicitly scoped
Evidence before assumptionsReproducible impact and limitations
Retest includedWithin the agreed scope and window

PRODUCT SECURITY

A firmware image is a starting point. The product is the target.

A key in a filesystem, a shell reachable through a debug port or an update accepted without the right checks can cross very different security boundaries. We investigate what each observation actually permits in your product and deployment.

We combine static analysis, reverse engineering, emulation and testing on real devices according to the target. Source-assisted reviews, device-to-cloud paths and companion applications can be added explicitly. Access to one device does not authorise testing every connected system.

PRODUCT TYPES

Devices and products we test.

From a connected home to a charging station: we scope the firmware, interfaces and trust boundaries of the product you actually ship.

  • Smart home devices

    Connected hubs, smart locks, thermostats, switches and sensors. Firmware, onboarding, local control and the trust placed in companion apps or cloud services.

  • EV chargers & charging controllers

    Charge-point firmware, management interfaces, credentials, update mechanisms and charger-to-backend communication, including OCPP where used and in scope.

  • Network & edge appliances

    Routers, access points, firewalls and edge gateways. Embedded services, management access, configuration, updates and device identity.

  • Industrial gateways & controllers

    Industrial IoT gateways, protocol converters and embedded controllers. Device-level firmware and interface testing in an agreed laboratory or representative test environment.

  • Building automation

    Building-management controllers, HVAC interfaces, connected meters and access-control panels. Local privileges, stored secrets, management protocols and update trust.

  • Cameras & connected security devices

    IP cameras, recorders, intercoms and readers. Firmware, debug access, authentication, exposed services and the boundaries around recordings or device administration.

Each engagement defines the exact models, hardware revisions and firmware builds. Cloud platforms, mobile apps and wireless protocols are included when agreed; testing a device does not imply authorisation to test a live building, charging network or industrial site.

TESTING SCOPE

What we can test

  • Firmware & binaries

    Filesystems, native binaries, embedded Linux, bootloaders and security-sensitive application logic. MCU/RTOS targets are scoped by architecture and access.

  • Emulation & runtime

    QEMU-based analysis where feasible, instrumentation and targeted input testing. Findings distinguish emulated behaviour from device-confirmed results.

  • Boot & updates

    Signature enforcement, package handling, version/rollback policy and recovery paths. Hardware-rooted claims require appropriate device access and evidence.

  • Secrets & identity

    Embedded credentials, keys, certificates, device provisioning and the permissions those identities receive.

  • Hardware interfaces

    UART, JTAG/SWD, flash readout and boot configuration, depending on the device. Destructive work is agreed before testing.

  • The connected product

    Management interfaces, protocols, companion apps and cloud APIs when expressly included in the engagement.

ENGAGEMENT OPTIONS

Three ways to scope the work.

Choose the access and release decision you need to assess. Each proposal defines targets, methods and deliverables.

01

Firmware image assessment

You provide the image or update package. We analyse the artefact, investigate the relevant binaries and validate findings using the access available.

Good starting point: a release candidate or a supplier image.

02

Device & firmware pentest

We work with the actual device as well as its software: extraction, physical interfaces, runtime, boot and update trust boundaries.

Good starting point: a product release or a device-level security question.

03

Release assurance

Begin with a baseline assessment, then review agreed releases for meaningful changes, new exposure and the fixes to reported findings.

A recurring engagement with a defined product family, release allowance and research effort.

From first artefact to verified fix.

  1. Scope & prepare

    Agree the product, builds, attacker starting points, supplied hardware, access and safe test conditions.

  2. Extract & understand

    Map interfaces and trust boundaries. Unpack, reverse and emulate where useful; record the limitations.

  3. Prove & report

    Validate the findings in the available environment and separate demonstrated impact from untested consequences.

  4. Fix & retest

    Debrief engineering, prioritise remediation and repeat the agreed checks against corrected builds.

Cover of the synthetic sample firmware penetration test report

SAMPLE DELIVERABLE / ENGLISH PDF

See the evidence, not just the severity.

Request the full illustrative firmware deliverable by email: executive summary, coverage, five detailed findings, remediation and a retest plan. The PDF is in English.

  • Scope & attacker assumptions
  • Static / emulated / device evidence
  • Reproduction & limits
  • Remediation & retest criteria

Synthetic laboratory example. Not a real client assessment or an executed test. No actual customer, device vendor or credential is disclosed.

Email me the firmware sample

DELIVERABLES

What your engineers receive.

  • Executive risk summaryWhat was demonstrated, which prerequisites matter and the decisions needed before release.
  • Reproducible technical findingsAffected build and component, evidence provenance, reproduction steps and the exact boundary crossed.
  • Coverage & limitationsWhat was tested, what resisted the agreed checks and what could not be concluded from emulation or available hardware.
  • Remediation & retestPractical changes, a technical debrief and confirmation of the reported fixes within the agreed window.

FAQ

Questions before you send a device.

Can you start with a firmware image only?

Yes. An image or update package can support filesystem, binary, secrets and configuration analysis. Dynamic validation depends on the architecture, packaging, encryption and available execution environment. We state what an image-only review cannot prove.

Do you emulate firmware with QEMU?

Yes, where the architecture, kernel/userspace and peripheral requirements allow useful emulation. We may emulate a process, selected components or a fuller system. Emulation is not a substitute for device validation when the claim depends on hardware or boot configuration.

Can you extract firmware from a physical device?

We can scope extraction through available debug or memory interfaces, boot/recovery paths and board-level work. Success is not assumed. Readout protection, encryption, packaging and destructive access requirements affect the approach.

Will testing damage our hardware?

Some board-level techniques can alter or damage a unit. We agree permitted techniques, expendable units, recovery options and stop conditions in writing. No destructive work is implied by an image assessment.

Is source code required?

No. Binary-only and source-assisted engagements are both possible. Source, symbols, build information and documentation can improve coverage; the proposal records what is available.

What does release assurance include?

A baseline followed by agreed releases, change analysis, targeted testing and retest. Product families, release allowance, included effort and response windows are defined; it is not unlimited research or a guarantee that every release is vulnerability-free.

Is the sample report a real customer report?

No. The linked English PDF contains a fictional laboratory product and synthetic evidence, marked throughout. It demonstrates report structure and technical depth without claiming a real engagement.

What do you need to prepare a proposal?

A non-sensitive product description, architecture/OS if known, available images or devices, important interfaces, the testing objective and release deadline. Use the enquiry form for scoping only. We arrange NDA and secure transfer before you send firmware, keys or credentials.

Tell us what you are building.

An image, a device or a release programme. We will agree what to test and what evidence you need.

Request a scoped proposal[email protected]

NDA and secure handover

Do not upload firmware, passwords or keys through the public enquiry form. We agree a secure channel and device-handling arrangements.

How we protect your information