ARM Translator Implementation

[voteblake]

This project is very, very, relevant to my interests.

I see from the blog post you are using Capstone as the disassembler, which implements the ARM architecture. I'd like to take a stab at an implementation of ARM - at least for ARMv6 in Thumb mode (my current target).

I will use this issue to track an attempt at adding a module in falcon/lib/translator to map the Capstone ARM instruction API to Falcon IL.

If you've thought of this already and have ideas of where it might go wrong please chime in! I'm just familiarizing myself with the codebase now.

[endeav0r]

Well this is super exciting news.

1. The translators are completely stateless, and I don't have a way to do stateful translation. What this means is I don't have a way to switch between normal ARM and thumb mode.

2. It looks like I didn't have architecture-specific stuff built into the Elf loader. All relocations will be treated as x86 relocations. This will be bad.

Other than that, nothing springs to mind. I would like to answer any questions you have as you come across them. I'm in the Binary Ninja slack as "endeavor", and I'm also in irc on freenode by the same name.

[voteblake]

Thanks for bringing up the stateless translator issue. My impression is that it will be a stickier challenge than the Elf loader.

For now I'm going to focus on pure-Thumb mode translator implementation. rustc only implements Thumb mode for bare metal (no-std) targets. Disassembling this output is my current use case for tooling like this.

As I learn the codebase I will try to understand where mode-switching could be handled in the future, as that will be a requirement for any B(L)X instructions.

[m4b]

Re 2. I've wanted to extract the dynamic relocation code in dryad for quite some time and have one part of the puzzle (other part is static relocation directives) for a cross-platform relocator crate. (The actual relocation code is in linker.rs)

It would be useful for a number of reasons.

Note the dryad code assumes native endianness and same machine so would have to be refactored but I think would be easy to pass a machine target into a function or struct that knows how to relocate the directive for the platform.

Dunno. Something like that

[endeav0r]

Yeah, a "link and relocate multiple binaries" crate would be absurdly useful.

[m4b]

Btw you shouldn't need state to new track of thumb mode iirc. It's in thumb mode if the least significant bit is set, e.g. It's odd. The CPU just interprets it as thumb if the instruction address is odd is all.

I hack something like this in cargo-sym, but I think capstone likes to switch modes for the disassembler or is more efficient if you keep track, not sure

[endeav0r]

It looks like nothing ever came of this, so I'm going to go ahead and close the issue.