Cool tool!
I wrote something for reverse-engineering code, as a consultant years ago. They had a radio module but the manufacturer had lost the source code.
So the tool was called Golem. It had tables for defining opcode to assembler pattern matching, that could be written for any machine (instead of just the one I was cracking).
It worked iteratively. You ran it over the binary once, it produced arbitrary labels from jump-points. You could annotate that output by changing the labels to something human-readable (e.g. Loop-back, Main, TimerISR etc) and add comments.
The next iteration would read that back in to build a symbol table, rescan the binary and re-output. But this time it would understand that the symbols were always on opcode boundaries, distinguish data table from code entry points (because you marked them) etc. So it would do a better job of staying in sync with the code.
Once I was done with that project (and had re-compilable source for the radio module) I put it away and never thought of it again.
You were on your way to cloning IDA Pro, Ghidra, Binary Ninja, or Hopper Disassembler. To varying degrees, sometimes as a pay-extra option, those tools can produce source code.
They are not at all mostly Intel disassemblers, though some of them have freeware versions (to suppress competition) or time-limited demo versions that are purposely limited. They are very much designed around humans adding clues: you can declare function parameters, struct types, enumerations, and the meaning of various offsets in code. They are interactive GUI tools, continuously updating automated analysis as the user assists by providing clues to the analysis engine. Ghidra and Binary Ninja can be simultaneously multi-user, storing the database on a server for collaboration.
So the tool was called Golem. It had tables for defining opcode to assembler pattern matching, that could be written for any machine (instead of just the one I was cracking).
It worked iteratively. You ran it over the binary once, it produced arbitrary labels from jump-points. You could annotate that output by changing the labels to something human-readable (e.g. Loop-back, Main, TimerISR etc) and add comments.
The next iteration would read that back in to build a symbol table, rescan the binary and re-output. But this time it would understand that the symbols were always on opcode boundaries, distinguish data table from code entry points (because you marked them) etc. So it would do a better job of staying in sync with the code.
Once I was done with that project (and had re-compilable source for the radio module) I put it away and never thought of it again.