Ghidra, NSA's reverse-engineering tool

IDA has always had a weirdly low price point given the bill rates of people who use it, and it's interesting to see that price being competed all the way down to free.

Good comparison might be Synopsys VCS. Prices are not published but I believe they are over $30k/cpu/year and for larger designs you really want a big sim server.

I'd like to hear the rest of this story, I was considering buying IDA Pro (though these days I'm having a lot of fun adding M68k support to Avast's Retdec)

Not necessarily nice, but it makes sense.

I don’t see how the perspective is odd. Having tools like Core Impact and the knowledge of how to use them well can propel you to a six figure income easily. On top of that these tools are also business expenses you can use for tax write offs.

They are certainly worth the investment. The only people who see the price as steep are those who cannot see any viable way to make a decent ROI off them.

Huh. I would be extremely surprised if the NSA were to include some kind of malicious or pseudo-malicious easter egg in the open source RE toolkit they're releasing. How dumb would they have to be to pull a move like that, and for what? The self interest just doesn't line up.

When I use IDA, almost all of my actual work in the tool itself is very "boring" RE stuff, because it does its job. I am not constantly fighting with it to get basic things analyzed propertly, or fighting a lack of supported features that prevent it from opening something, or a bad analysis engine that misses 80% of things I later reverse by hand. You could comparatively stitch something together with the tools in Radare to patch over this for the cases it doesn't handle. You might even call those "edge cases", but reverse engineering is 90% edge cases and 10% easy stuff. I'll already be done by then.

I should also be clear that part of the issue is that reverse engineering is a money game, one where money is easy to come by if you have the clients -- and as a result and a lot of the developers of those tools have more money/labor available than the Radare developers. That also means people who need this can simply throw money at a problem, like an expensive IDA license, and move on. That doesn't mean Radare developers are incompetent. If you gave them a lot of money -- like, enough to fund 5-10 core developers for a couple years -- Radare would dramatically improve extremely quickly, I'm sure. (This is one of the reasons why I suspected a true competitor to IDA would never come around as FOSS -- it takes a shitload of money to do that, and it's also something you can make a shitload of money from.)

But I'll say this: if you put me into a situation where I had to reverse something, I'd pay for an IDA license 10/10 times even if every Radare developer was at my command, and I'd probably still get it done faster (most RE tools I know of lack even the most basic, fundamental features IDA has had for years -- such as FLIRT -- that can dramatically improve reversing speed.)

The decompiler for instance is a precompiled binary (elf64 file on linux) wrapper in some java code. The C/C++/? code is not provided.

I wonder if it will make it's way to FLARE.

Microsoft has a "shared source" agreement with governments.

If you need some very specific small functionality by next monday for $1million, then that development can be arranged.

However, NSA could also reasonably want that their targets (who have extensive capabilities of their own, likely including insiders in various companies) can't find out that NSA needs that very specific small functionality by next monday. They may not care if that functionality becomes available to the general public sometime in the next year (preferably in a more general manner that covers the reasonable/common usecases instead of just the one NSA had at the moment), but leaking the information that you needed (and thus probably used) X at time Y often isn't acceptable.

At the very least, they'd need every single employee who works on that feature or can see that this feature was developed to be vetted by them i.e. to have a security clearance; and that also requires the company to have the appropriate processes and infrastructure for separate, secret codebases and builds that can't be seen by uncleared people. And that is something many companies can't or don't want to provide.

Shit... wrong site.

>In countries where copyright protection is available (which does not include the U.S.), contributions made by U.S. Federal Government employees are released under the License. Merged contributions from private contributors are released under the License.

https://github.com/NationalSecurityAgency/ghidra/blob/master...

I'd say, by learning to use IDA through a pirated version you create a possibility that one day you will use it for something more serious and you or your employers will pay for it.

One possible argument against that is that by learning how to use all IDA features through a pirated version, you erase the competitive advantage of people who can afford to pay right from the start and remove their incentive to pay.

To that I'd say you would be just levelling the playing field :)

Do keep in mind that many of these companies expect users to pirate their software. Indeed, piracy is ironically part of what has made Adobe such a big player - teenagers pirating software in highschool, and using it up until their first job, make it their go-to tool when they actually do enter a company. Often leaving the company with no choice but Photoshop!

For instance, one of the most useful aspects of a decompiler for me is the ability to recover high-level control flow, which Binary Ninja apparently doesn't support. Instead it gives you an IDA-like graph view (but with IL instead of assembly in the graph nodes); but at least in my experience using IDA without a decompiler, even moderately large functions tend to result in a spiderweb of a graph, and recovering the control flow by hand ends up feeling like a pointless brain teaser. (This condition being true short-circuits this set of comparisons, so it must be an ||... but it still ends up doing this other set of comparisons, which you can also get to from... wait, where was I again?)

It also doesn't seem to allow eliding temporary assignments. Here's a short sample from some random function (retyped by hand since I don't see a way to copy and paste):

    int32_t edx = arg4
    int32_t eax = esi
    eax_1, ecx_2 = sub_3c670(eax, edx)

    eax_1, ecx_2 = sub_3c670(esi, arg4)

Anybody use SEH or MSVCRT exceptions on x86? Well, there are non-inlined functions that adjust the stack pointer dynamically there. Binary Ninja can't capture that. To be fair, it's unlikely IDA can either- but IDA has a heuristic (read- hack) that treats those functions specially. Result? SP-analysis for all callers generally fails, and Binja becomes convinced that arguments are being passed in eax and ebp.

Ah, but you can just patch the LLIL for calls to those functions to adjust the stack. Oh, no, you actually can't patch LLIL that way- it's immutable after the lifter creates it. Now, you can write your own architecture hook, and there you can be your own lifter- you can call the real lifter, see if it emits a LLIL_CALL to a function you recognize, and if so just emit the stack adjustment LLIL instead. Ah, heh, but you can't- you can't call the real lifter, because it doesn't emit LLIL, it adds LLIL to an existing function, and you can't remove that IL later- it's append-only. And you can't recognize functions easily, because the things passed into your GetInstructionLowLevelIL callback don't include a BinaryView pointer- the thing you'd need to find out anything at all about other functions. You can sort of, kind of, hack around this by calling about five other functions... for every CALL instruction in every function in the binary. This is, ah, less than performant.

Ever reversed a Win32 binary that uses the Win32 API a lot? I hope you like defining structs by hand, because OH BOY are you going to be defining a lot of structs to do anything useful. And you also get to define DWORD, LPDWORD, LPVOID, and every other annoying Windows typedef by hand. (You can be clever and use libclang hackery on the Windows SDK and automate some of this. But you'll have to do it yourself.)

Then there's stuff like type propagation only going forwards inside functions- sometimes. The GUI occasionally deciding that all basic blocks should be laid out in one small square, on top of each other. (You have to reanalyze the function to fix this.)

Mind you, I love Binary Ninja- I bought my own dang commercial license, and renewed it! It's getting better, fast... but it's got its warts.

It is, but usually the best way to do is to make it look like a mistake that's very subtle and difficult to notice without careful testing and analysis, kind of like Apple's infamous SSL "goto fail". That's a classic example of a vulnerability that really could be either an honest mistake or a very insidious backdoor.

This is more like leaving the house's sliding glass door to the backyard wide open for everyone to see.

The upsides of people getting it who aren't willing to break the law outweigh the downsides of bad people getting it more easily. Probably. That's the best you can expect with security tools.