ARM v7 disassembler - OpenSource / Free? Windows?

[zitt]

As eluded to in a different thread... I recently attempted to find a free and/or opensource disassembler for the ARMv7 architecture(s).

Basically; what I'm trying to do is disassemble a Pinball machine binary. There are some indications at IDAPro may disassemble the rom files; but it isn't clear and they don't offer a free trial for testing ARM capability (only X86). My goals are to develop a "patch" which could turn on a specific (unused) transistor in the pinball machine for a specific game mode.

I glanced at darm... but didn't try to run it because it is over 6years old with no plans on it being maintained. That site recommended capstone and I tried in vain to get something to work under Winblows without success.

So; I turn to the community... What other options are their? With all the arm based microcontrollers; I find it hard to believe there isn't a good opensource alternative which might be able to run under windows and decode these roms. If Windows is a non-starter; I can try Linux under a virtual machine.

[lucazader]

The NSA open sourced one of their reverse engineering tools a few months ago.

From the little play around that i did with it, it seemed to support arm binaries etc.

Maybe take a look into it?
https://www.nsa.gov/resources/everyone/ghidra/

[smithnerd]

If you don't mind a steepish learning curve, then radare2 is very useful for reverse engineering.

https://www.radare.org/r/

Open source, cross-platform, all that good stuff. It's fairly well documented, but is a fast moving project, so expect things to break and interfaces to change. It used to support a wider variety of architectures than IDA, but I haven't compared them recently.

[amyk]

I glanced at darm... but didn't try to run it because it is over 6years old with no plans on it being maintained.

That's no reason to not use it... ARMv7 does not change.

[westfw]

Gcc’s objdump ?
Just disassembly, though.  No “reverse engineering assist”...

[devan]

I've used the evaluation version of hopper to analyze some STM32 firmware before. The UI was relatively intuitive, which I found helpful. In contrast, I found the radare2 UI to be incomprehensible, probably because there were many configurations options that are pertinent to x86 and desktop machines, but not for bare metal firmware.

The main advantage of a using a reverse engineering tool vs just a regular disassembler is that it's an interactive process that can incorporate user feedback. Where a disassembler has to just take its best guess as to whether something is code or data, a reverse engineering tool will let you mark something as code, show you the indirect address it dereferences, and then generate a flow control graph based on that interpretation.

[up8051]

>
What is the chip (manufacturer and part name)?
Did you have schematic of pinball machine?

[legacy]

If you have the money ... a lot of money (>>$25K), there are "reverse engineering assist" tools.
I have one on my laptop, and it's extremely useful for m68k and old MIPS (<< MIPS32) stuff.

I was lucky, I found the software installed with a valid license when I purchased the laptop. Well, precisely it was *the* reason why I picked up that laptop.

Paid 100 USD, just the software cost 25K. Anyway, armv7 is not considered "abandoned", so ... I don't know if someone will ever rid off the whole like I happened to see in the street markets in Japan 

[janoc]

I've used the evaluation version of hopper to analyze some STM32 firmware before. The UI was relatively intuitive, which I found helpful. In contrast, I found the radare2 UI to be incomprehensible, probably because there were many configurations options that are pertinent to x86 and desktop machines, but not for bare metal firmware.

Try Cutter:

https://github.com/radareorg/cutter

That's a frontend to radare2. It works quite well but trying to disassemble large binaries with it can be a bit slow.

[brucehoult]

Gcc’s objdump ?
Just disassembly, though.  No “reverse engineering assist”...

GNU binutils, not gcc :-)

Works exactly the same for dozens of different ISAs, which makes up for the lack of explicit reverse-engineering features in my book. You can always script it from Python or something if you want to build something higher level.

gdb worth a look too, maybe with actually the code running in qemu.

This stuff is mostly used on Linux/Mac/other Unixes, but Windows claims to be Linux compatible these days, and cygwin has been around for decades, so I'm sure there must be ports.

[janoc]

Gcc’s objdump ?
Just disassembly, though.  No “reverse engineering assist”...

GNU binutils, not gcc :-)

Works exactly the same for dozens of different ISAs, which makes up for the lack of explicit reverse-engineering features in my book. You can always script it from Python or something if you want to build something higher level.

gdb worth a look too, maybe with actually the code running in qemu.

This stuff is mostly used on Linux/Mac/other Unixes, but Windows claims to be Linux compatible these days, and cygwin has been around for decades, so I'm sure there must be ports.

The entire GNU toolchain exists for Windows, ARM has also the official ARM toolchain, I am pretty sure that one supports ARM v7 as well.

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain

[zitt]

Thanks to everyone for the responses to-date. Been busy with a lot of projects; but I'm going to take some time soon to digest the information supplied in the near future.

What is the chip (manufacturer and part name)?
Did you have schematic of pinball machine?

I haven't looked at the game specifically to confirm; but
https://www.manualslib.com/manual/1517409/Stern-Pinball-Ac-Dc.html?page=81#manual
seems to indicate an AT91R40008 being clocked at 40MHz.

[GromBeestje]

Try Cutter:

https://github.com/radareorg/cutter

That's a frontend to radare2. It works quite well but trying to disassemble large binaries with it can be a bit slow.

It took me a while to figure out how to open a binary firmare dump in Cutter. Opening an elf works fine when leaving everything on auto, but opening a binary dump made it crash. When opening a binary dump for a Cortex-M based microcontroller: set architecture to ARM, set bits to 16. Then it should work. For STM32 microcontrollers, also set the map offset to 0x08000000. (Or any value matching the firmware you're analysing, which could have some offset when the target has a bootloader)

[janoc]

Are you sure to use 16bits and not 32? Cortex-M is 32bit CPU ... Elf works with auto because it contains all the required information in the file - addresses, architecture, etc. When  using raw dump you must specify it yourself.

[nctnico]

The Cortex-M series use a 16bit instruction set (the thumb instructions set in ARM speak). Older microcontrollers often used the ARM7TDMI core which supports both the full blow 32bit instruction set and the 16 bit thumb. Using the thumb instruction set usually resulted in a huge space saving at the cost of a minor performance reduction.

[brucehoult]

The Cortex-M series use a 16bit instruction set (the thumb instructions set in ARM speak). Older microcontrollers often used the ARM7TDMI core which supports both the full blow 32bit instruction set and the 16 bit thumb. Using the thumb instruction set usually resulted in a huge space saving at the cost of a minor performance reduction.

Cortex-M use the 32/16 bit Thumb2 instruction set, except the M0/M0+ which use almost pure Thumb1 16 bit instructions with just a few system management 32 bit instructions. Choose Thumb2 or ARMv7-M for both. They don't support original ARM instructions at all.

ARM7TDMI uses ARMv4T which, as you say, has both original ARM 32 bit instructions and Thumb 16 bit instructions. Any given function normally uses purely one or the other although it's possible on some CPUs to play tricks such as ADDI PC,PC,#1 to switch to Thumb mode before executing the next instruction.

In the days when ARM7TDMI ruled, there was often only a 16 bit bus between CPU and memory, in which case Thumb was faster as well in almost all cases and you usually only switched to ARM mode for specialised instructions that the stripped-down Thumb mode didn't provide.

[janoc]

Ah duh, you are right, I have completely forgotten about Thumb. I was thinking about memory addresses and those are 32bit aligned.