It is open source software and it can reverse engineer programs from a lot of different systems.
Some people may be worried about installing a piece of software on their computer that comes from the NSA. I don't think that there are real reasons to worry. One of the tasks of the NSA is defending against cyber attacks. Having more people with good tools helps the defense. Also, you can be pretty certain that some security people have been closely looking at the sources to see if it contains any suspicious features. Besides, if the NSA really wants to install some software on your computer, they can probably do it themselves without your involvement.
I was quite suspicious of it when it was first announced, but an open source RE tool is probably the stupidest place to put a backdoor. Author considerations aside, it’s a great tool, and does pretty well with decompiling.
I would be curious to know if anyone has audited this for malicious code, or how one would go about doing that in the first place. Is that kind of software auditing a use case for Ghidra? A demo of using Ghidra to audit Ghidra would be interesting I suppose.
I don't think there is anything fishy here, although I don't think the NSA can just install anything on my computer, even if I were based in the US. There is a lot of bluffing when it comes to cyber security.
These are all true statements. Greetings from Seattle, Washington, USA! No need to cc them on this post. No one should kid themselves with what NSA is working on. No one should also kid themselves with what they aren't capable of.
I can think of one concern about downloading and installing it, the NSA might be interested in who uses it. No need for anything malicious in the code, they just watch to see who downloads it.
probably makes sense. I see in the government level a lot of open positions for reverse engineers.. having its own tool, helps, at least, to save money in licensing (assuming they are using or planning to use Ghidra to do that)
If you want to harness the power of Ghidra decompiler but without the need of installing Java - Rizin[1][2] and Cutter[3][4] (Rizin's Qt GUI) integrate Ghidra's decompiler part that is written in C++ (libdecomp) as plugin - rz-ghidra[5]. We work currently on improving the integration and the quality of output.
For anyone confused (as I was) rizin is a fork of radare2. I don't have anything constructive to say other than I'm confused why the project was forked.
I used this again just the other day with the cantor.dust plugin. My rev.eng skills are dull and were never great to begin with, but for anything below a real APT with obfuscation, runtime decoding and unpacking, Ghidra is an equalizer. Between this and Chef from gchq, someone with devops skills can probably skill up to an entry level threat analyst level in a few weeks or months. The tooling available today is really good.
If people are worried about running systems backdoored by NSA, they probably shouldn't use things like electricity either. It's a threat actor you can't really do anything about.
I haven't used Ghidra that extensively, but it worked well when I was using it to assist in modding Minecraft Pi. The big point in its favor for me is that its free and supports ARM32, while IDA's free version only supports x86.
For you it is obviously not news, but for other people it probably is. For me, HN is about learning something new, not just for learning about something that happened in the last 24 hours.
I did a double take seeing Ghidra in a headline because just yesterday I was watching a video of someone going through WannaCry with Ghidra. I had never heard of it before yesterday. https://www.youtube.com/watch?v=Sv8yu12y5zM
I used Ghidra for the first time to hack my robot vacuum.
Some months later I used it to reverse engineer the on-board software of a satellite running on a SPARCv8 CPU. It worked great in both cases, can recommend.
I like Ghidra more than IDA. Having "proper" type support is nice - IDA's struct and type annotation support always felt very hacked together and hard to use. Ghidra's typing and decompiler is good enough that I don't even have to look at the disassembly listing for most functions, and struct autogenerating is wonderful.
Unfortunately, Ghidra handles vtables and OOP very poorly still. You have to do a lot of by-hand annotations for virtual calls, even with 3rd party analysis scripts, while IDA's C++ usually Just Works. This is the main pain point, imo. The other main thing is that IDA has been used by the reverse engineering community for so long that there's a massive body of tutorials and StackOverflow answers for it, and a much larger corpus of 3rd party plugins. It's not a big deal for me, personally, but if you already have a good workflow for IDA it's probably not worth it to switch. For beginners I'd recommend Ghidra instead, though, because a free and open source tool with good official documentation and UX is worth its weight in gold (although I've heard BinaryNinja is extremely good nowadays).
* Affordable for sane people (aka, free)... This of course pushed Hex-Rays to finally make a cheaper version of IDA, but it's massively hobbled and useless for uncommon architectures.
* Almost as good architecture coverage. Missing a few big ones for automotive RE still - SuperH is still hit and miss, and no real C167. But the user-contributed Tricore is really quite impressive.
* Decompiler works across all architectures.
* Debugger is still sketchy, but has progressed extremely quickly.
* Preferable UI (IMO), and better struct handling.
* Decent plugin interfaces but fewer available plugins.
IDA:
* Still slightly better decompilation and disassembly for x86-64. Doesn't get as "lost" in vtables and big switches.
* Much better C++ construct support.
* More plugins and scripts available off the shelf.
* Still a few architectures which Ghidra doesn't have yet.
* Debugger is more stable and works a bit better.
For most architectures I would not start using IDA today as a hobbyist, but if I had a good IDA workflow or was joining a company where it were the gold standard, I wouldn't feel compelled to move over.
Ghidra is a very cool utility. I used it to disassemble StarGlider for DOS - a very old fav - to figure out how the game worked. Together with the DosBox debugger I managed to create my own hack so I could play the game without being killed the whole time.
CyberCHEF is another great tool coming from a “spying” agency. I dont see how GCHQ could really benefit from it as there is even a local version for those who would want to keep their data from going over the wire.
[+] [-] NotSwift|4 years ago|reply
Some people may be worried about installing a piece of software on their computer that comes from the NSA. I don't think that there are real reasons to worry. One of the tasks of the NSA is defending against cyber attacks. Having more people with good tools helps the defense. Also, you can be pretty certain that some security people have been closely looking at the sources to see if it contains any suspicious features. Besides, if the NSA really wants to install some software on your computer, they can probably do it themselves without your involvement.
[+] [-] tracedddd|4 years ago|reply
[+] [-] ShepherdKing|4 years ago|reply
[+] [-] raxxorrax|4 years ago|reply
Still it might be quite a useful tool.
[+] [-] ozfive|4 years ago|reply
[+] [-] rapjr9|4 years ago|reply
[+] [-] pelasaco|4 years ago|reply
[+] [-] cies|4 years ago|reply
Running Linux with very few binblobs, I expect they will not be able to.
Running any OS published by $tax_evading_big_corp, I expect they can.
[+] [-] xvilka|4 years ago|reply
[1] https://rizin.re
[2] https://github.com/rizinorg/rizin
[3] https://cutter.re
[4] https://github.com/rizinorg/cutter
[5] https://github.com/rizinorg/rz-ghidra
[+] [-] vesche|4 years ago|reply
[+] [-] ktpsns|4 years ago|reply
[+] [-] motohagiography|4 years ago|reply
If people are worried about running systems backdoored by NSA, they probably shouldn't use things like electricity either. It's a threat actor you can't really do anything about.
[+] [-] homarp|4 years ago|reply
[+] [-] ackbar03|4 years ago|reply
[+] [-] technics256|4 years ago|reply
[+] [-] anonymousiam|4 years ago|reply
Was pleased to discover a few years later that they had open sourced it.
They're up to v10 now and it's so much better than IDA Pro/HexRays that it's probably going to put them out of business.
[+] [-] TheBrokenRail|4 years ago|reply
[+] [-] robthebrew|4 years ago|reply
[+] [-] beefcafe|4 years ago|reply
https://htmlpreview.github.io/?https://github.com/NationalSe...
[+] [-] NotSwift|4 years ago|reply
[+] [-] dqv|4 years ago|reply
[+] [-] comandillos|4 years ago|reply
Some months later I used it to reverse engineer the on-board software of a satellite running on a SPARCv8 CPU. It worked great in both cases, can recommend.
[+] [-] rejectedandsad|4 years ago|reply
[+] [-] chc4|4 years ago|reply
Unfortunately, Ghidra handles vtables and OOP very poorly still. You have to do a lot of by-hand annotations for virtual calls, even with 3rd party analysis scripts, while IDA's C++ usually Just Works. This is the main pain point, imo. The other main thing is that IDA has been used by the reverse engineering community for so long that there's a massive body of tutorials and StackOverflow answers for it, and a much larger corpus of 3rd party plugins. It's not a big deal for me, personally, but if you already have a good workflow for IDA it's probably not worth it to switch. For beginners I'd recommend Ghidra instead, though, because a free and open source tool with good official documentation and UX is worth its weight in gold (although I've heard BinaryNinja is extremely good nowadays).
[+] [-] bri3d|4 years ago|reply
* Affordable for sane people (aka, free)... This of course pushed Hex-Rays to finally make a cheaper version of IDA, but it's massively hobbled and useless for uncommon architectures.
* Almost as good architecture coverage. Missing a few big ones for automotive RE still - SuperH is still hit and miss, and no real C167. But the user-contributed Tricore is really quite impressive.
* Decompiler works across all architectures.
* Debugger is still sketchy, but has progressed extremely quickly.
* Preferable UI (IMO), and better struct handling.
* Decent plugin interfaces but fewer available plugins.
IDA:
* Still slightly better decompilation and disassembly for x86-64. Doesn't get as "lost" in vtables and big switches.
* Much better C++ construct support.
* More plugins and scripts available off the shelf.
* Still a few architectures which Ghidra doesn't have yet.
* Debugger is more stable and works a bit better.
For most architectures I would not start using IDA today as a hobbyist, but if I had a good IDA workflow or was joining a company where it were the gold standard, I wouldn't feel compelled to move over.
[+] [-] bovermyer|4 years ago|reply
[+] [-] lnyng|4 years ago|reply
[+] [-] asddubs|4 years ago|reply
https://en.wikipedia.org/wiki/King_Ghidorah
[+] [-] flcl42|4 years ago|reply
[+] [-] justshowpost|4 years ago|reply
[+] [-] dominicjj|4 years ago|reply
[+] [-] biscotte_|4 years ago|reply
[+] [-] one_shadow|4 years ago|reply
[deleted]
[+] [-] gnunez|4 years ago|reply
[+] [-] asddubs|4 years ago|reply