[Enhancement] Add multi-architecture disassembly and analysis backends

Open
  • Is something wrong?
#11 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp
Domain
reverse-engineering

Research direction

Start with src/disasm/disasm.hpp and src/disasm/disasm.cpp, where the only decoder is X86_64InstructionDecoder and Capstone is opened in CS_ARCH_X86/CS_MODE_64, then read the machine check in src/main.cpp around lines 430-435. This needs an architecture registry first, so agree the design with the maintainer before writing code. Done means AArch64 and RISC-V backends produce the shared instruction facts, with checked-in fixtures and x86-64 output unchanged.

Written by the indexing model from the issue text.

Description

enhancement

Summary

Add architecture backends beyond ELF64 x86-64 so Caraxes can use its existing loader and analysis pipeline on AArch64, RISC-V, and eventually 32-bit ELF targets.

Current limitation

The project already parses ELF32/ELF64 metadata and reports machine names, but the executable analysis path is hard-coded to x86-64:

  • README.md:104-112 lists Linux x86-64 as a requirement.
  • src/disasm/disasm.hpp:47-50 exposes only X86_64InstructionDecoder.
  • src/disasm/disasm.cpp:17-18 always opens Capstone in CS_ARCH_X86/CS_MODE_64 mode.
  • src/main.cpp:430-435 rejects anything other than ELF64 machine 62.

This means an AArch64 or RISC-V ELF can be loaded for metadata inspection but cannot be disassembled, analyzed, or decompiled.

Proposed capability

Introduce an architecture/backend registry that selects an instruction decoder from the ELF class, machine, and endianness. Each backend should map its native instruction records into the architecture-neutral facts already consumed by the analyzer: instruction bytes, addresses, branch/call/return classification, direct targets, memory operands, and invalid-byte records. Architecture-specific operands and register names should remain available for backend-specific recovery logic.

The CLI should auto-select the backend from the ELF header, with an optional explicit override for raw byte inputs. Unsupported combinations should produce a precise error listing the supported backends rather than using the x86 decoder.

Acceptance criteria

  • Add at least AArch64 and RISC-V disassembly backends using the existing decoder abstraction/Capstone integration.
  • Allow disasm, functions, cfg, callgraph, xrefs, and report generation for supported non-x86 ELF files.
  • Keep x86-64 output and recovery behavior unchanged.
  • Add small checked-in byte/ELF fixtures for each backend, including direct branches, calls, returns, and memory operands.
  • Document backend support, architecture-specific limitations, and whether native C-like recovery is available per architecture.
Dominant language
C++
Stars
0
Forks
0
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TiElixir/caraxes

All issues in TiElixir/caraxes

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.