ret-sync VS ghidra

ret-sync: synchronize a debugger (WinDbg / GDB / LLDB / OllyDbg2 / x64dbg) with a disassembler (IDA / Ghidra / Binary Ninja) in which you can colorize the trace. See the bc command.

Binary Ninja likewise is empty and keeps up just fine as well. It's not a coincidence that the two commercial products that are funding it are both confident enough to put their stuff online like this.

And it's no conspiracy theory or intentional sandbagging, you can see the implementation: https://github.com/decompiler-explorer/decompiler-explorer

and if anyone can improve the other tools performance we'd be happy to accept it. We reached out to the Ghidra devs: https://github.com/NationalSecurityAgency/ghidra/issues/5228 but they didn't have any silver bullets for us either.

> I’m not clear on if the bugs you are finding are in Ghidra’s processor model or in the emulator? (Though I think it’s the latter?)

The project README includes a link to a commit fixing bugs in Ghidra's processor model, here is the author's PR submitting those fixes upstream: https://github.com/NationalSecurityAgency/ghidra/pull/5740

Nice, I'll give it a closer look. My only concern so far is memory hooking (still needed for hardware registers), which on Java side was called by FilteredMemoryState [1]. In memstate.cc it looks like just the simpler MemoryState is implemented [2], and there's no equivalent to MemoryAccessFilter. But it might not be that complicated to add...

[1]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...

[2]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...

Ghidra: https://ghidra-sre.org/, https://github.com/NationalSecurityAgency/ghidra

I tried to upstream some of my refactorings/modifications to support this, but it was rejected by upstream [1]. I don't blame the Ghidra project for this decision ; my modifications are fairly intrusive (modifying the relocation table after the initial load, extensive refactoring of the ELF support code...) and my workflow is essentially unproved in public.

By that I mean I have no documentation, no series of technical articles describing this process and no public, non-trivial project to demonstrate it in real life. I do have a currently private decompilation project that uses this successfully [2], but it's not currently public and it's nowhere near finished.

Also, I only wrote a relocation synthesizer for statically-linked, 32-bit, little endian MIPS ELF. That's a fairly obscure platform, I'd expect most people care about mainstream instruction sets like x86_64 or ARM64.

If you can suggest a forum where people would be interested in this, I can drop a message there and answer more in-depth questions if you want. So far I've worked on this all on my own and I'm kinda out of the loop from the rest of the reverse-engineering community.

[1] https://github.com/NationalSecurityAgency/ghidra/pull/5010#i...

https://github.com/NationalSecurityAgency/ghidra/issues/382

3. Airgaps may be broken by ultrasound side channels; communication to compromised devices like smartphones is possible (see: speaker-to-gyroscope communication https://ieeexplore.ieee.org/abstract/document/9647842/ ; speaker-to-speaker communication https://arxiv.org/pdf/1803.03422.pdf)

4. Low bitrate data leaks, like "ghidra is running in this org, decompiling files named....." may be accumulated by the NSA

This is just zero-day warehousing and passive signals collection with embedded zerodays. It would be hard for security researchers to detect this. I'd happily change my mind if you showed me an audit that looks for beacons and other side channels.

II. The audits

Here is the one audit I could find

https://github.com/NationalSecurityAgency/ghidra/issues/382

This audit tells us that the code is janky, but doesn't tell us if it's secure. It's just a dump of thousands upon thousands of static analysis errors.

There's no threat anaylsis in this audit. All it suggests is that the code has so many defects that a serious security audit will very expensive to perform.

III. Change my mind with evidence

Please link me to the "heavy audits" of the code that you think should exist. I couldn't find them. Surely you were not bullshitting me. Surely not?!

tldr;; I think this code is less heavily audited than you can support.

> RE'd ghidra

What, like, read the source code [1] or reverse engineered a binary? Would be easy(ish) to tell if the code in the binary was different from the source, probably.

[1]: https://github.com/NationalSecurityAgency/ghidra