Among the most well-attended talks at this year’s RSA Conference was one in which a new, open-source tool for reverse engineering called Ghidra was debuted and released publicly.
What made it so popular was who was giving it away – the National Security Agency's Senior Advisor for Cybersecurity Strategy Rob Joyce, who also held the position of Cybersecurity Coordinator in the Trump White House, as well as that of Chief of the NSA’s offensive division, the Tailored Access Operations Unit.
Joyce began by setting Ghidra in the context of other open-source software projects that have been developed and released by NSA over the years, including security enhancements for Linux and Android.
He drew laughs when he jokingly pointed out that many Android phone users are carrying around a “little bit of NSA” in their pockets, before adopting a more serious tone to aver that no such backdoors were baked into that, or any of NSA’s other free software, Ghidra included.
Moving on to address the next elephant in the room, Joyce declared that Ghidra was not meant to compete with, or supplant, what is widely regarded to be the most popular reverse engineering tool on the market, Hex-Ray’s IDA.
Nevertheless, it was hard not to notice that Ghidra was designed to address some common shortcomings in IDA, including the lack of an “Undo/Redo” feature, and the ability to work collaboratively on the same binary.
Ghidra also supports annotated difference comparisons and version tracking – both features which were highly desirable in NSA’s environment, but which also promise to make joint analysis by researchers in the private sector much easier.
Speaking of private sector researchers, for this edition of Around the Watercooler, we reached out to a number of our own reverse engineers for some initial impressions on the tool’s release.
The responses we received ran the gamut from highly detailed comparisons of Ghidra and IDA to concerns about application security, and even included comments on Ghidra’s look and feel.
Ghidra's Pros and Cons
One pair of researchers had this to say about Ghidra’s positives:
“Some features I find interesting and helpful in Ghidra:
- Project Management: IDA uses the sample/code bytes file as the starting point, in Ghidra you start with a solution to which add the executable and its dependents which can allow you to jump into the function call in a dependent library.
- Disassembly View:
◦ Instruction Info can be used as a processor instruction reference – information about the operands, instruction decoding, etc.
◦ Comments can be inserted inline in the Textual Disassembler to provide more information about how the current instruction modifies the state of the processor (Registers, Flags, Stack, etc.)
◦ Entropy computation of functions/Sections
- Structures: The struct construction is using offsets as well as types (i.e. HWND, HINSTANCE, LPCTSTR, etc.); Ghidra can parse a C header and add the detected types… very cool!
- Symbol Tree: APIs have already identified the parameters and their types are already populated; in IDA you need to run a plugin - you can also modify the API prototype if it doesn’t make sense (API from a user DLL).
- Decompiler Tree: It is possible to edit the textual decompiler by renaming functions, change prototypes, change variable names, etc.
- Function Editor: Available to change the calling convention, add custom conventions (same as IDA).
- Code Patching: Same as IDA using the Memory View.
- Searching: It appears the search function in Ghidra is much better than in IDA.
- XREFs: As powerful as IDA.
- Memory Map: Same as Segments Windows in IDA - one can add new segments.
- Scripting: Ghidra comes with a lot of scripts (200+) in both Java and Python (Jython).”
And they had this to say about Ghidra’s shortcomings:
“Some things to consider:
- IDA is written in C++, Ghidra is all Java
- IDA supports debugging, very useful when reversing
- IDA supports more file formats (file parsers/loaders)”
Another researcher expressed concerns about potential security vulnerabilities in the application itself, saying:
“In debugging mode, it opens a port on 0.0.0.0 which allows for remote code execution! Scary stuff. I hear they plan to patch it in the next release.”
On the whole, our reverse engineers felt as though IDA and Ghidra could best be used in tandem, and they did not expect one to replace the other:
“I think Ghidra will appeal currently to two specific use cases: 1) strong Java programmers who can easily extend it using the extensive SDK and documentation and 2) non-standard architectures where it has a built in decompiler. For mainstream Intel and ARM architectures, IDA and Hex-Rays remain a superior option, but for all other architectures Ghidra will either be the better option or at least a compelling alternative.”
All in all, it looks like Ghidra will find a soft landing among the reverse engineers at BlackBerry Cylance, particularly once the open-source community has a chance to thoroughly review, comment on, and improve it.
In the meantime we can, at the very least, share an appreciation for one aspect of Ghidra that the NSA developers seem to have nailed right from the start – one which immediately caught the eye of our former Director of Threat Intelligence, Jon Gross, whose sole reaction to news of the Ghidra release was: