re-arm

Reverse engineer ARM Cortex-M/A firmware including Thumb disassembly, AAPCS conventions, and MMIO register analysis.

64|9|Updated Aug 17, 2026
One-click install
npx skills add https://github.com/dslsdzc/rev-skills --skill re-arm-dslsdzc
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: re-arm
Source: https://github.com/dslsdzc/rev-skills/tree/main/.claude/skills/re-arm
Command: npx skills add https://github.com/dslsdzc/rev-skills --skill re-arm-dslsdzc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Analyzing bare-metal ARM firmware is error-prone: Thumb mode bits corrupt function addresses, linker veneers masquerade as business logic, and MMIO peripheral regions get misread as data. This Skill provides a structured workflow for reverse engineering non-Android ARM binaries (Cortex-M/A) with correct architecture detection, entry-point location, and calling-convention recovery. ## Core Features & Use Cases - Architecture & Entry Detection: Confirm ARM vs AArch64, endianness, and float ABI via readelf, then locate Cortex-M vector tables (MSP, Reset handler) or Cortex-A boot code. - Thumb/ARM State Handling: Resolve LSB=1 Thumb function addresses, identify linker veneers beyond BL range limits, and fix base-address mismatches between link and load addresses. - AAPCS & MMIO Analysis: Recover AAPCS32/AAPCS64 calling conventions (including hard-float vs soft-float) and cross-reference peripheral registers in the 0x4000xxxx MMIO region against datasheets. - Use Case: You extracted an STM32 firmware blob with binwalk. Use this Skill to find the vector table, rebase the image in Ghidra, and trace GPIO/UART register accesses to reconstruct hardware behavior. ## Quick Start Analyze this ARM Cortex-M firmware binary: locate the vector table and reset handler, fix the load base address, and identify all MMIO peripheral register accesses.

Frequently Asked Questions about re-arm

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reverse engineer ARM Cortex-M firmware?▼

Start by confirming architecture and endianness with file and readelf, then locate the vector table at offset 0x0 where the first entry is the initial MSP and the second is the Reset handler. Load the binary into Ghidra with the correct Cortex variant and rebase before decompiling.

How to find the entry point of bare-metal ARM firmware?▼

For Cortex-M, read the vector table: offset 0x0 holds the initial stack pointer and offset 0x4 holds the Reset handler address. For Cortex-A, check the reset vector at 0x00000000 or 0xFFFF0000 and follow the boot sequence through stack setup to main.

Why does ARM disassembly start mid-instruction at function addresses?▼

Thumb function addresses have the least significant bit set to 1 as a mode indicator, not a code byte. Clear the bit with address & ~1 before using it as a function start, otherwise disassembly begins one byte off and produces garbage.

Ghidra vs IDA for ARM firmware analysis?▼

Ghidra includes built-in ARM processor modules covering Cortex-M0 through M7 and Cortex-A variants, switching Thumb/ARM disassembly automatically via TMode. IDA commercial editions support ARM32/ARM64 with Thumb, while Freeware architecture support varies by release.

Can qemu emulate bare-metal Cortex-M firmware?▼

qemu-user cannot run bare-metal Cortex-M code since there is no OS or syscall layer. Use qemu-system-arm with a board model like mps2-an385 for Cortex-M3, or Unicorn-based emulation for instruction-level execution of raw firmware.

When should I not use this ARM analysis workflow?▼

Skip it for Android native libraries, which follow the Android-specific analysis path, and for generic AArch64 Linux userland programs covered by general binary analysis. It also does not apply to RISC-V or x86 targets.