aeondave/renode
offensive-tools/rev/renode/SKILL.md
Auth/lab ref: Renode board and SoC simulation for MCU/RTOS firmware, UART/GPIO/peripheral modeling, GDB remote debugging, REPL platforms, and RESC scripts.
$ install --global
skillsauthnpx skillsauth add aeondave/malskill renodeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 24, 2026, 3:58 AM37.5s1 file scanned
SKILL.md
- name:
- renode
- description:
- Auth/lab ref: Renode board and SoC simulation for MCU/RTOS firmware, UART/GPIO/peripheral modeling, GDB remote debugging, REPL platforms, and RESC scripts.
- license:
- MIT
- compatibility:
- Renode on Linux/macOS/Windows; target support depends on available platform descriptions and modeled peripherals.
- version:
- 1.0
- category:
- tool
Renode
Renode is the first public tool to try when firmware behavior depends on a modeled MCU board, RTOS peripherals, UART, GPIO, timers, storage, or multi-core SoC state.
Use Renode when
- the artifact is MCU/RTOS firmware and a board or close SoC model exists
- UART/GPIO/timer/storage/network peripheral behavior matters
- QEMU lacks the exact board, or CPU-only emulation hangs on MMIO
- you need deterministic virtual time and GDB remote debugging
- you can write or adapt a
.replplatform description for the minimum needed peripherals
Do not treat CPU stepping as board parity. Prove the peripheral behavior relevant to the objective.
Core objects
.repl: platform description; CPUs, memory maps, buses, UARTs, GPIOs, timers, and peripherals..resc: Renode monitor script; creates machines, loads platforms, loads binaries, configures analyzers, starts emulation.- Monitor: interactive command surface for machines, sysbus, peripherals, memory, UART analyzers, and GDB server.
- Robot Framework: useful for validation harnesses that assert UART/peripheral output; keep it as test infrastructure, not the only evidence.
Minimal monitor flow
mach create
machine LoadPlatformDescription @platforms/boards/<board>.repl
sysbus LoadELF @firmware.elf
showAnalyzer sysbus.uart0
machine StartGdbServer 3333
start
Useful commands:
peripherals
sysbus WhatPeripheralIsAt 0x40000000
sysbus ReadDoubleWord 0x40000000
sysbus WriteDoubleWord 0x40000000 0x1
sysbus.cpu Step
pause
quit
For raw binaries, set load address and reset vector deliberately; ELF is safer when available because it carries sections and entry point.
Custom platform guidance
When no board exists:
- Build the smallest
.replfrom known CPU, RAM/flash, and MMIO ranges. - Add UART first if console output is needed.
- Add timers/interrupt controller before assuming RTOS scheduler failure.
- Stub unknown peripherals only enough to pass non-target checks.
- Label the result as partial parity and list unmodeled peripherals.
Sources for modeling clues: vendor datasheet, SVD, linker script, map file, DTB, SDK headers, strings, disassembly xrefs to MMIO addresses, and logic/UART captures.
GDB
machine StartGdbServer 3333
Then connect with the matching toolchain:
arm-none-eabi-gdb firmware.elf
(gdb) target remote :3333
Use GDB to prove reset handler, RTOS task creation, peripheral driver paths, memory state, and breakpoints on fault handlers.
Evidence
- exact
.repl/.rescor monitor command sequence - board/profile source and any custom modeled/stubbed devices
- UART transcript, GPIO/peripheral read/write, memory state, or GDB breakpoint
- whether proof is instruction execution, runtime boot, peripheral parity, or system parity
Failure pivots
- no UART: wrong UART instance, firmware uses semihosting/RTT, clocks not modeled, or boot never reaches init
- stuck in default handler: missing IRQ/timer/peripheral model
- fault after reset: wrong load address, vector table, stack pointer, Thumb bit, or memory map
- GDB oddities on multicore boards: start/select the correct CPU-specific GDB server
Related Skills
aeondave/unicorn
development
VerifiedTrustedCommunity
Auth/lab ref: Unicorn Engine CPU-only emulation for shellcode, decryptors, custom VM handlers, instruction tracing, memory hooks, and register-level experiments.
11SKILL.mdUpdated Jul 24, 2026
aeondave/qiling
development
VerifiedTrustedCommunity
Auth/lab ref: Qiling OS-layer binary emulation for PE/ELF/Mach-O/UEFI/shellcode with rootfs, syscall/API hooks, filesystem mapping, and runtime patching.
11SKILL.mdUpdated Jul 24, 2026
aeondave/qemu
databases
VerifiedTrustedCommunity
Auth/lab ref: QEMU user-mode and full-system emulation for cross-arch binaries, firmware, kernels, disks, serial consoles, networking, and GDB stubs.
11SKILL.mdUpdated Jul 24, 2026
aeondave/neuromatrix
tools
VerifiedTrustedCommunity
Drive the NeuroMatrix reverse-engineering emulation MCP server: create sessions, discover backend tools via list_catalog/get_tool/run_tool, choose Unicorn/Qiling/QEMU/Renode lanes, upload large binaries through the artifact data plane, manage detached jobs, use session workspaces, expose guest endpoints, collect emulator evidence, and avoid false support claims for kernels, firmware, MCU boards, Windows/macOS assets, ESP8266, and Renode profiles.
11SKILL.mdUpdated Jul 24, 2026