A new disassembler coming soon?

[3dsboy08]

Apparently, a "new" disassembler made by the NSA (lol) named "GHIDRA" is going to be released at the RSA conference in ~2 months for free.

Its made in Java, and seems to have a fully functioning decompiler. Not much more details were released other then that, but it seems interesting as a competitor to IDA.

https://www.rsaconference.com/events/us19/agenda/sessions/16608-come-get-your-free-nsa-reverse-engineering-tool

Edited January 4, 2019 by 3dsboy08
fix spelling mistake

[whoknows]

ref - 

https://www.engadget.com/2019/01/06/nsa-releasing-code-reverse-engineering-tool

 

[atom0s]

Here's an apparent pic of the tool in action. No idea how old this pic would be in terms of features and so on for it.

[Progman]

It would be interesting to know why the main window does not have "GHIDRA" in the title.  And also interesting to at least see maybe the analysis menu or a decompilation.  So far I wonder if it is just another interactive disassembler which based on the screenshot can hardly be compared to IDA.  Well we wait a couple more months :D.

Probably they are trying to get some goodwill releasing a dated but reasonably relevant tool which has some unique advantages since they will be the first intel outfit to do it, can contribute to academia with a research paper, and show they are not always in sabotage mode.  As well given the dumps, probably they refocused their efforts and energies.  I used to assume they had a near perfect decompiler which could even handle self-modifying code.  I am still quite certain this exists but its very upper echelon stuff by those who intensely all surveil each other with invasive subvocal monitoring not stuff that could be leaked by your average contractor.  We just get to see some mid level breadcrumbs occasionally at best.  Anyway the system has a nasty defensive mechanisms and maybe its easier to get some RE slaves to do the dirty work than make and hide "perfect" tools.  We can only speculate about a lot of the ruling class secrets but rest assured money has never kept them in power since Ancient Egypt and on - they always kept reasonably large technological advantages hidden up their sleeves.

Edited January 21, 2019 by Progman

[zdox]

check here https://edwardsnowden.com/docs/doc/media-35684.pdf at p.20

[Progman]

Snowden should tweet something about this release hopefully

[mnemonic72]

Any download links for this GHIDRA software yet? A lot of discussion but I can't see any links (sorry if I missed it).

[GaBoR]

We'll have to wait until the 5th of March.

[atom0s]

The newest/public version is not released yet, but there were versions of it in parts of the various NSA leaks to wikileaks. You can find the old versions if you dig enough, but best to just wait for this public release since its not too far away now.

[kao]

@atom0s: care to give me a hint? All I could find were some screenshots and manuals, not the actual binaries.

[akkaldama]

https://ghidra-sre.org/

[Loki]

• Github — source code (will be available soon)
• Download GHIDRA 9.0 — software package, slides, and exercises
• Installation Guide — basic usage documentation
• Cheat Sheet — keyboard shortcuts
• Issue Tracker — report bugs

 

[atom0s]

After getting to play with this a bit now on the updated version, this is my personal opinion on it.

To start, I don't feel this even comes close to competing with IDA or BinaryNinja for the time being. This is not to say it is junk/useless, it is just still very early on to really recommend it or suggest it so far. Feature-wise, it is not really on par with the competition it is up against currently, making it a hard recommendation to give.

Given that it is also so new to being public now, I wouldn't recommend it to others with the fact that it is going to rapidly change starting now. The amount of new eyes and hands on it are going to have countless ideas, suggestions and pull requests come pouring in, even more so when it fully open sources in the near future. That said, there is not going to be much consistency with it for a while until a more solid framework/core of the application has been completed.

I was looking forward to the newer decompiler, however it feels like nothing more than a modified version of Snowman ported to Java. It feels rather weak and lacking compared to HexRays. While it does work, it has similar output and results to Snowman which in my opinion are fairly low-end / junk results. So there is a lot of room for improvement there.

UI wise, I feel the disassembler has a lot of wasted white space and over-kill tabbing for certain information (ie the PE header data) making it a bit annoying to look at. A lot of times, these tools are ran in VMs with limited screen space or lower end resolutions, and I feel Ghirda makes very poor use of the space it has, mainly in the disassembler window.

I am keeping my hopes up though since this is planned to be fully open source in the near future. I really hope the community can get behind it and help improve it vastly.

[atom0s]

Something else to keep in mind while using this tool too:

 

[Xyl2k]

and we have also first drama with IDA devs
http://web.archive.org/web/20190306164430/https:/twitter.com/taviso/status/1103095898320470016

[Loki]

If I were Ilfak I'd give Tavis a free license..... the guy is brilliant at what he does and the screen shots from IDA on his feed would justify it.

As it is, they have one of the world's best vuln hunters saying that Ghidra is good enough for what he does #youdonegoofed

[kassane]

Ghidra Docs - API

http://ghidra.re/online-courses/

Ghidra Scripts - Github

Ghida community - Collection

Edited March 14, 2019 by kassane
new content

[atom0s]

Had some more time with Ghidra last night to compare speed to IDA. So this is a small comparison to IDA 7, default settings, minimal plugins loaded (none that should affect load times) and Ghidra also stock settings, default analyaze options.

Target Executable: A game .exe close to 200MB in size, no protection, no packer, no special tricks/obfuscation or anything.

IDA: Took about 15-20mins to load into IDA and be considered ready. (The initial autoanalysis has been finished.)

Ghidra: Still analyzing, 9 hours later.

Be it poor coding, poor optimization, or just the fact that its coded in Java, Ghidra is extremely slow when compared to IDA in this regard. For simple/small targets like malware samples, it may be fine to use on a daily basis, but for larger scale targets like full applications, games, etc. this is definitely going to need work to be considered a viable option to use at all. For this thing to still be going 9 hours later is a bit ridiculous. 

[evlncrn8]

maybe it got stuck on some specific opcode ?

[atom0s]

2 hours ago, evlncrn8 said:

maybe it got stuck on some specific opcode ?

It finally finished after about another 4-5 hrs of time. 

Compared another step between IDA and Ghidra as well which is letting each tool decompile a function using standard options.

IDA decompiled a specific function in my test target within about 2 minutes, used around 250mb of RAM while doing its work.

Ghidra failed to decompile the function with default settings due to timing out, then again due to RAM amount required. After bumping its stock settings up for its decompiler sub-process, it is still running (trying to decompile the same function IDA did in about 2 minutes) after around 10 minutes and using over 2gigs of RAM with just the decompiler process it spawns.

So far, it has some fun features and gimmicks but I would honestly not recommend this as a daily tool for anything larger than a few mb in size. It is extremely slow and poorly handles larger files.

[deepzero]

What kind of files are you feeding it? 2 minutes to decompile one function in an analyzed binary seems pretty excessive...

[atom0s]

1 hour ago, deepzero said:

What kind of files are you feeding it? 2 minutes to decompile one function in an analyzed binary seems pretty excessive...

I'm using a GameMaker Studio compiled game which generally compiles all the game assets and custom scripting stuff into the binaries. The script language its custom and creates a bunch of internal functions compiled into their own byte code, so the script functions tend to become fairly large to deal with all the game assets that use them. A simple/small function will decompile fast, but I wanted to test on things more in depth to give both IDA and Ghidra a fair comparison instead of just telling them both to decompile a function that's 30 opcodes long and is instant to say who did it faster. 

Since my focus is game hacking I wanted to give it a more real-world example to work with, especially now with games that have huge binaries most of the time.

With my testing so far, IDA comes out ahead by a long shot. Ghidra works, but is extremely slow. The function I decompiled earlier did finish after a while, the results are somewhat similar to IDA as well, so their decompiler isn't too shabby, but definitely has room for improvement. The biggest concern and issue for me though is the speed, it is far to slow for me to want to use it yet on anything serious.

[atom0s]

Just to clarify as well, I'm not saying Ghidra is bad or to not use it. Sorry if what I'm saying is coming across like that, that isn't my intention or what I mean to imply. 

I do actually like Ghidra and I am happy to see something finally be on par with IDA's feature set. Given that Ghidra is new and has a small team of like 2? people, there is a lot of room for improvement. And the better part is that they do plan to open source it fully, which is nothing but even better for it. 

Something I do foresee though with it becoming open source is that people will port it to a different language because of how slow Java is in general. I'd guess we'll see a C# port at some point or eventually a C++ port depending on how decides to tackle it which I'm all for seeing happen.

Overall, it is a nice tool and I'm glad to see it happen, I just hope to see it get better over time, especially with speed improvements. 

[Loki]

User experience is important - you need a tool that gives a steady workflow. For now it feels like something that sits alongside other options (like IlSpy and dnSpy have relative merrits) rather than a full replacement.

Hopefully the open source community will indeed plug some of the gaps - it's a solid base to start from though.

[atom0s]

9.0.1 was released recently: https://ghidra-sre.org/releaseNotes.html