I've been chipping away at recreating source for a dumped FreeRTOS binary for about a year using Ghidra and Trace32. (Disclosure: I work on Trace32.)<p>I wanted to implement something like <a href="https://github.com/neuviemeporte/mzretools">https://github.com/neuviemeporte/mzretools</a> (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.)<p>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.<p>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.<p>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.<p>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).<p>I'll definitely check out this project, as well as ghidra2dwarf linked by nneonneo.