What BootIntel can prove from boot logs.
BootIntel is evidence-first. It extracts structured device, software, network, auth, and boot-chain signals from UART and boot logs, then labels findings with confidence so teams can separate confirmed issues from review items.
Bootloaders
U-Boot, Barebox, CFE, common autoboot interruption prompts, signature/hash failure lines, boot arguments, network/USB boot paths
Operating Systems
Linux/OpenWrt/Buildroot, BusyBox, selected RTOS signatures including FreeRTOS, Zephyr, ThreadX, VxWorks, NuttX, RTEMS, MQX, and uC/OS
Software Inventory
Linux kernel, BusyBox, OpenSSL, Dropbear/OpenSSH, dnsmasq, hostapd, wpa_supplicant, uhttpd, nginx, lighttpd, FTP/TFTP, Samba, rpcbind/NFS, MQTT, SNMP, PHP
Hardware Signals
CPU/SoC strings, architecture, DRAM/flash size, NAND/NOR chip identifiers, MTD partition maps, RAM load addresses, USB device descriptors
Network Surface
Local/remote IPv4s, MAC addresses, interfaces, bootloader network variables, DHCP/BOOTP, URLs, service start/listen lines
Auth Surface
Login prompts, root shell prompts, automatic login messages, debug console and engineering-mode indicators
Confidence Labels
CVE Match Types
Known Limitations
- +BootIntel analyzes the log text it receives. Missing, truncated, encrypted, or heavily vendor-customized logs can reduce coverage.
- +CVE correlation is strongest when an exact component and version are present. Component-only or range-based matches need manual review.
- +Runtime exposure cannot always be proven from boot logs alone. Services observed during boot may still be firewalled or disabled later.
- +A clean result does not prove the device is secure; it means no supported high-signal indicators were observed in the submitted log.
- +Attack paths are decision-support outputs and should be validated only on authorized hardware and test environments.