FRaaS (Firmware Risk as a Service)

FRaaS

Inspiration

I’ve been an independent security researcher for two years, focusing on IoT and embedded device security. Day-to-day investigations repeatedly require the same manual steps: extract the root filesystem from a firmware image, map the services running on the device, locate interesting binaries, and triage those binaries for low-hanging vulnerabilities. I believed these universal, repetitive tasks could be automated to save time and standardize triage -> FRaaS is the result.

What it does

FRaaS (Firmware Risk as a Service) automates the initial and crucial stages of firmware analysis for router images. Given an uploaded firmware, FRaaS:

• Extracts and normalizes the root filesystem (supports detection/carving of SquashFS and common alternate FS containers).
• Builds an inventory of binaries, libraries and scripts.
• Decompiles Lua bytecode and flags potentially insecure Lua functions (e.g., os.execute, io.popen, dynamic load).
• Lists running services and extract their versions for some of them (dnsmasq, dropbear, openvpn,...)
• Extract hardcoded credentials.
• List protections on the Vendor-Specific binaries.

To my knowledge, there is no readily available online service that bundles these precise capabilities into a fast, audit-friendly workflow for firmware/IoT researchers.

How we built it

• Language & framework: Python backend (FastAPI) for the API and worker orchestration; Vue 3 + Vite + Tailwind for the frontend.
• Worker model: Redis + RQ workers for asynchronous analysis tasks (binwalk extraction, static binary inventory, Lua decompilation).
• Extraction & analysis: binwalk for carving/extraction, unsquashfs for SquashFS handling, LIEF/strings for binary metadata, and custom heuristics for vendor-affinity and service detection.

Challenges we ran into

• Robust extraction: Firmwares come in many container formats and nested layouts (TRX, uImage, lzma/xz blobs), so reliably locating and extracting the true rootfs required building a resilient multi-pass decision flow and heuristics for entropy & offsets.
• Bytecode & vendor quirks: Many devices ship Lua bytecode rather than readable scripts and vendors sometimes use custom build options, so decompilation and reliable parsing produced false positives that required tuning.

What we learned

This was my first full-stack product with a dedicated worker queue; I gained hands-on experience with asynchronous job orchestration (RQ), object storage integration, and hardened worker patterns for unsafe tool execution. It also highlighted how diverse firmware packaging can be and how much value can be delivered by automating the boring, repetitive parts of triage.

What’s next for FRaaS

• Emulation: Integrate QEMU-based emulation for selected user-space binaries to validate behavior and extract accurate runtime metadata (e.g., observed banners and versions) instead of relying solely on string fingerprints.
• Automated reversing: Plug an IDA MCP server to extract richer function/CFG metadata for vendor-specific binaries, and combine that with an assistive ML model to prioritize likely vulnerable functions.
• CVE enrichment & alerting: Keep a synced local cache of NVD/vendor advisories and provide continuous scanning for known exposures, with confidence scoring and remediation tips.
• Fuzzing targets: Automatically generate targeted lightweight fuzzing runs for exposed web/CGI endpoints and file parsers discovered during analysis.
• SaaS features: integration hooks (webhooks, Jira) for triage workflows.

Built With

• fastapi
• python
• redis
• vue