(no title)
PennRobotics | 9 months ago
I wanted to implement something like https://github.com/neuviemeporte/mzretools (the tool for reversing F15SE, a DOS game) but I would need to port all of that tooling to an Arm cross-compiler and accept it will never produce a 1:1 binary in my case. (There's evidence the original was built with IAR which I will not be buying solely for a hobby project.)
Ghidra (especially after using BSim to load all of the NXP demos and some TI library code for adjacent ICs) is extremely useful at getting the entire structure: library functions, data types, tasks, queues, I2C/USB comm, pin setup, data locations, etc. You can re-code the flash part easily, but SRAM/stack is all zeros. The code that fills SRAM uses pointer math and some loops and is generally unreadable on its own. I tried the Ghidra simulator, but it didn't work out of the box on Arm microcontroller code.
Trace32 makes it easy to load the raw binary into an Arm simulator and step through all the way to the IDLE task, but there's no high-level listing. You just have to detect if you're in a loop and look at the loop address in Ghidra to see what holds you back. Without a simulation model (which I do not have---at least not outside of work) you have to manually jump past a few spots where the board waits for an acceptable status flag from a clock source, etc., and then manually call SysTick_Handler once, but the SRAM is eventually filled with appropriate data. Once you have a stack, you can start picking out which FreeRTOS macro parameters were set and figuring out the size and type of vendor-created structures which then streamlines further Ghidra analysis. Beyond that, you can't use RTOS awareness without symbols, so unless you write a script to import these from Ghidra, a more insightful view of the binary remains out of reach.
The analysis has been a LOT of looking back and forth between the simulator (which shows a hex address and machine code) and the Ghidra decompilation listing; it is a bit like getting Don Quixote verbally read to you, one letter at a time. Anytime there's a I2C_Master_Transmit(), you need to comb through datasheets for DSP settings and the various I2C-linked chip registers. It's a USB product (with multiple endpoints) so I use Wireshark and Python to check the decompiled USB application code and identify valid packet data that are never sent by the vendor software.
DWARF can be imported and exported in Trace32, so exporting symbols created in Ghidra as DWARF would vastly simplify my workflow (as would having a real model of the NXP chip and/or dumping the bootloader binary and secrets from a production device).
I'll definitely check out this project, as well as ghidra2dwarf linked by nneonneo.
bobmcnamara|9 months ago
I miss how everything is in its place.
I miss the number of times I've wondered if some functions could be combined and toy delight they worked wonderfully.
Just writing in to say I'm a fan.