agentsclimarketplace

Reverse engineering arm binaries

Skill meltedinhex/analyst-ai-pack/skills/reverse-engineering-arm-binaries

Reverse engineers ARM/AArch64 malware by identifying the architecture and instruction set state (ARM/Thumb), parsing ELF/Mach-O ARM headers, and orienting analysis around the ARM calling convention. Activates for requests to reverse ARM binaries, analyze AArch64 malware, or handle ARM/Thumb instruction-set decoding.From its SKILL.md

Install
npx -y skills add meltedinhex/analyst-ai-pack --skill reverse-engineering-arm-binaries

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.7 KB, 487 tokens by cl100k_base, as published. Nobody here has run it

Reverse Engineering ARM Binaries

When to Use

  • You have an ARM (32-bit) or AArch64 (64-bit) binary — IoT/mobile/Linux malware — and need to identify the architecture, instruction-set state, and entry point before disassembly.
  • You need to handle ARM/Thumb interworking correctly.

Do not use an x86 mindset for calling conventions/registers — ARM differs. This skill reads the binary statically and executes nothing.

Prerequisites

  • The ARM binary (ELF or Mach-O), read inertly. Capstone optional for instruction decoding.

Safety & Handling

  • Read bytes statically; analyze on an isolated host (and emulate via QEMU separately if needed).

Workflow

Step 1: Identify architecture and format

python scripts/analyst.py identify sample.bin

Parses ELF/Mach-O headers to report ARM vs AArch64, endianness, entry point, and (for ELF) whether the entry is Thumb (low bit set in e_entry or $t mapping symbols).

Step 2: Set the correct disassembly mode

Disassemble AArch64 as A64; for 32-bit ARM, switch between ARM and Thumb per the entry/mapping symbols.

Step 3: Orient around the calling convention

Track arguments in r0-r3/x0-x7, return in r0/x0, and syscalls via svc with the syscall number in r7/x8.

Step 4: Proceed with analysis

Identify functions, strings, and syscalls; pair with emulation if dynamic insight is needed.

Validation

  • Architecture (ARM/AArch64) and endianness are read from the header.
  • The entry point and ARM/Thumb state are reported.
  • Disassembly mode matches the detected state.

Pitfalls

  • Missing Thumb state and decoding Thumb as ARM (garbage output).
  • Big-endian ARM (rare but real) mis-parsed as little-endian.
  • Statically linked musl/uClibc inflating the function set on IoT samples.

References

What ships with it: 3 files

4.0 KB alongside SKILL.md, 1 of them executable

references/

scripts/

Keep looking

Skills are one crate of 326,970. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.