embedded_linux_audit

Deep analysis of a target through the client API — kick off Ghidra rootfs decompilation jobs, review decompiled C output, list live gdbserver sessions, attach GDB to running processes, and pull firmware dumps (SPI/NAND/eMMC/option ROM) for offline analysis. Use when the user wants to reverse a binary, root-cause a crash, debug a process on-device, or extract firmware.

Orchestrate hardware-interface fuzzing campaigns (WLAN, ethernet, Bluetooth HCI, CPU instructions) on a connected ELA device via the client API, including ela_kmod delivery through the module-builds route, and collect crash artifacts. Use when the user asks to "fuzz" a device or interface, or to follow up on fuzz-crash findings. Destructive-adjacent — always confirm scope with the user first.

Read back and analyze collected ELA artifacts through the client API uploads routes — grade linux-audit findings, review U-Boot environment and Secure Boot posture, EFI variables, TPM PCRs, netstat exposure, dmesg, and fuzz results — producing a prioritized findings list. Use after /ela-collect, or whenever the user asks "what did we find", "analyze the uploads", or "triage <device>".

End-to-end automated security audit of one or more embedded Linux devices through the ELA client API — orchestrates fleet discovery, baseline collection, artifact triage, optional fuzzing/deep-dive, and the final report. Use for "audit this device", "run a full assessment", or any request that spans more than one phase of the ELA workflow.

Run the baseline security evidence collection sweep on a connected ELA device via the client API — linux audit rules, U-Boot env/image scan, dmesg, netstat, kernel config, EFI vars, TPM state, filesystem checks — uploading everything to the server. Use when the user says "collect", "baseline", "sweep", or "audit <device>", or when a device has no artifacts yet.

Enumerate and manage ELA devices through the client API — list connected terminal sessions, set device alias/group, check what artifact types a device has uploaded, and smoke-test live control. Use this first, before any other ela-* skill, or whenever the user asks "what devices are connected", "is <device> online", or "what data do we have".

Produce the final security assessment report for an ELA engagement — pull all evidence for the in-scope devices from the client API uploads routes, merge findings from triage/fuzz/deep-dive phases, map coverage against the manual checklist, and write a structured markdown report. Use when the user asks for "the report", "write up findings", or at the end of an engagement.