Smart TVs, set-top boxes and Android terminals ship a chip vendor's board support package, its kernel and a long list of apps and services. Every update arrives as an OTA payload that needs checking. FDIE unpacks the payload and the boot image, shows what the firmware contains and flags debug access, secrets and known vulnerabilities before your customers' security teams do.
The challenge
Board support packages tie a device to the kernel the chip vendor shipped, sometimes years old. Its known vulnerabilities come with it.
ADB, serial consoles and debug tools are essential during development and dangerous in a shipped TV or terminal. They are easy to leave enabled in a release build.
Smart TVs and set-top boxes are consumer connectable products under UK PSTI and ETSI EN 303 645. Terminals with payment features and a radio fall under EN 18031 part 3 in the EU.
How FDIE helps
FDIE unpacks Android OTA payloads and boot images with its own readers, reads the kernel's version and disassembles ARM and AArch64 programs. Android sparse images are read in our tests but not yet measured on a vendor's image, and anything that cannot be read is listed as a coverage gap.
Device checks read init scripts and configuration for ADB, UART and USB serial shells set to start, debug tools left in the image, telnet and FTP, and services the product does not need. It reads the image; it is not a test of a running device.
The kernel and every identified component are matched to NVD and OSV and ranked with CISA KEV and EPSS. Function use says whether your programs call the vulnerable function, and a device check fails on a high or critical vulnerability in the kernel.
Connect the repositories of your launcher, apps and companion app and the code engine reads them too, Android manifest settings included. Their findings sit beside the firmware's in the same product, so one release view covers the device and the software you wrote for it.
How it works
Upload the OTA payload or the firmware image, import it from a GitHub or GitLab release, or let CI send each build.
FDIE unpacks the payload and the boot image, reads the kernel and the programs and runs the device checks.
Close debug access, remove secrets and work through exploited flaws in the kernel and components.
Export the SBOM, the evidence for consumer rules and signed reports, and compare each new OTA with the last.
Know the split
FDIE analyses the firmware, not the device. Knowing the split tells you what to fix before the lab and what to prepare for it.
Rules by market
Smart TVs and set-top boxes are consumer connectable products under UK PSTI, in force since 29 April 2024. In the EU, EN 18031 part 3 covers radio equipment with payment features until the EU CRA applies in full on 11 December 2027.
Voluntary code for consumer IoT, Release 2.0 of November 2025
Article 14 reporting since 11 September 2026; the rest from 11 December 2027
Applies since 1 August 2025
In force since 29 April 2024
Since 1 January 2020
Voluntary consumer IoT baseline, September 2022
Version 3.1.3 of September 2024
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
The kernel and every component found, in CycloneDX 1.6 or SPDX 2.3.
UK PSTI, ETSI EN 303 645 and EN 18031, from the image and from what you record.
A signed PDF of checks, findings and fixes for the release.
What changed since the last update, with patch states for each vulnerability.
Your team's reasons a vulnerability does not affect the device.
New flaws in a supported device's components, by email, chat or webhook.
OTA payloads and boot images. Android sparse images are read in our tests but not yet measured on a vendor's image, and anything that cannot be read is listed as a coverage gap.
No. FDIE analyses the firmware image. Apps and services on the running device stay with your testers.
Yes. Analyse both and compare them: components added, removed, upgraded and downgraded, with vulnerabilities, findings and device checks side by side.
For the firmware, yes, and the app holds EN 18031 part 3 for radio equipment with payment features. Payment certification itself stays with its own labs.
No. The image alone gives components, vulnerabilities, checks and secrets. Connecting your app repositories adds code findings to the same product.
A 45-minute call with our team. Bring one firmware image.