Coverage And Limitations

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

Confirmed
Multiple strong signals or an exact version/component match. Usually safe to prioritize without re-triage.
Probable
A strong single signal or version-range match. Review the evidence line and affected component before remediation planning.
Weak
Contextual or component-only signal. Useful for investigation, but not enough to treat as a confirmed vulnerability.

CVE Match Types

Exact version
The log exposed a specific component version and the CVE data maps to that version.
Affected range
The detected version appears inside a vulnerable range described by the CVE source.
Component match
The component was detected, but version detail was incomplete or ambiguous. Treat as manual-review.
Masked preview
Free preview can hide full CVE identifiers and evidence until the result is saved on an eligible plan.

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.
Coverage. Boot-Log Signals and Limits · BootIntel