Router and gateway firmware carries a Linux system, a web admin interface, CGI scripts and a long list of network services, often from a chip vendor's SDK or OpenWrt. Operators, ITSAR labs in India and EN 18031 in the EU look at exactly these. FDIE shows you what they will find, from the image and from your source.
The challenge
Telnet, UPnP, TR-069 remote management, SNMP and the web admin page all listen on the network. Services the product does not need are the first thing attackers and labs look for.
CGI scripts and Lua or LuCI handlers pass form fields to shell commands. Command injection in these handlers is behind many published router flaws.
Operators ask for an SBOM and test results before they deploy a model, and in India ITSAR certification is mandatory for IP routers and Wi-Fi CPE. Both take time you do not have at the end of a project.
How FDIE helps
SquashFS, UBIFS and vendor wrappers such as TRX and uImage are read with FDIE's own readers, and file systems behind Seama, Netgear CHK and TP-Link headers are found. Programs for MIPS, ARM and AArch64 are disassembled, and components come with their versions and known vulnerabilities.
Device checks read init scripts, configuration and the programs present: telnet and FTP left on, services the product does not need, a web server running as root, management over plain HTTP, product details before sign-in and no brute-force protection. With the source or build tree connected, rules also read OpenWrt UCI, Dropbear, dnsmasq and firewall settings.
In compiled programs, FDIE traces untrusted input such as web form fields, NVRAM values and network data to risky calls, and reports each path as a lead with its confidence for your team to confirm. Connect the source and the code engine reads shell and CGI scripts, Lua and LuCI, ucode handlers and the device's web pages.
The app holds NCCS ITSAR for IP routers and for Wi-Fi CPE as two frameworks. Device checks decide running without system privileges and integrity checks at boot, and give part of the evidence for removing default accounts, brute-force protection, secure updates, unused services, HTTPS and input validation. For products sold in the EU, the same checks give evidence for EN 18031.
How it works
Upload the firmware or let CI send it, and connect the repository or build tree if you have it.
The image is unpacked and disassembled, and the code engine reads the CGI, Lua, ucode and configuration files.
Confirm input path leads, turn off services you do not need and fix failing checks.
Export the ITSAR evidence, the SBOM and signed reports, and gate each build in CI.
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
In India, ITSAR certification is mandatory for IP routers and Wi-Fi CPE: since 1 July 2024 for models not yet certified, and since 1 October 2024 for certified models that change hardware or software. EN 18031 shows radio equipment meets the Radio Equipment Directive until the EU CRA applies in full on 11 December 2027.
Certification mandatory since 1 July 2024
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
Version 3.1.3 of September 2024
For industrial components such as gateways
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
Provisions for IP routers and Wi-Fi CPE, decided, helped or left to you.
Every component in CycloneDX 1.6 or SPDX 2.3.
A signed PDF of checks, findings and fixes for the release.
Web admin and CGI findings, and upgrade pull requests your team merges.
Ship or hold for every build, with the reasons.
New flaws in a supported router's components, by email, chat or webhook.
Yes. It reads the file systems and vendor wrappers OpenWrt images use, such as SquashFS and TRX, and with the build tree connected it reads OpenWrt's configuration and LuCI code too.
No. They are leads, each with its confidence and the path the engine followed, for your team to confirm with the code or a test.
Not as a live test. FDIE lists the services and programs in the image, matches their components to known vulnerabilities and flags services the product does not need. A TR-069 session with your ACS needs the running router, which stays with your testers.
No. The test lab or certification body still decides. FDIE shows what is in your firmware and prepares the evidence, so you fix problems first and submit with fewer surprises.
Yes, for the firmware. Gateways on ARM, MIPS, PowerPC or x86 are read the same way, and the app holds IEC 62443-4-2 for industrial components.
A 45-minute call with our team. Bring one firmware image.