(There's an outstanding bug which breaks ELF files - but being open-source, I'm sure it will be fixed soon) IDA Pro, despite costing many thousands of dollars, gets confused when you try to assemble something as basic as 'mov rdi, rdx' in 64-bit code. Ghidra has a (mostly functional) patching interface which understands assembly. This is really big - the API surface of the entirety of Ghidra is pretty massive so the scripting opportunities are similarly exciting. However, Ghidra's Python is actually Jython, which gives it access to the entire state of the system (minus the decompiler, which is native code - but you can interact with all the code that drives the decompiler). Ghidra and IDA both use Python for scripting. Ghidra's UI is marginally worse than IDA because it's implemented in Java Swing (compared with IDA's Qt). In theory it could decompile a custom architecture if you implement your disassembler backend thoroughly enough. IDA will only do x86, 圆4, ARM and AArch64 (and you pay for all of those separately). Ghidra will decompile code from a dozen different architectures. Semi-automatic struct inference rocks, and it comes with a big type library. Ghidra's type system is nice, and in some ways nicer than IDA's. Many of these require much more work to undo than simply reverting the change you made. Being able to make changes without worrying about your IDB accidentally becoming unusable is huge.Ĭontext: in IDA, certain changes you make can inadvertently wipe out a lot of work - for example, undefining a function (U) can erase all your annotations in a single keystroke defining a return type incorrectly can completely mess up callers, sometimes to the point where they won't even decompile properly making a typo to an array size argument can obliterate the stack and every variable annotation you made on it, etc. Ghidra also appears to have a functioning Undo operation, which IDA seems to still not have.

Ida pro hex rays