KTRW: The Journey to Build a Debuggable iPhone(googleprojectzero.blogspot.com) |
KTRW: The Journey to Build a Debuggable iPhone(googleprojectzero.blogspot.com) |
ETA: I ask because my other comment is about debuggable phone availability. IDA was always an extra gate for amateurs. I’m wondering how much access mere mortals have to the edgiest tools and information of this particular trade.
From a cost perspective, Ghidra has a decompiler (That works really well), and is free. I would imagine this will help with adoption. (Most other tools like Binary Ninja don't have a decompiler, as they are hard. Here is a project that takes the Ghidra decompiler and puts it into Radare https://github.com/radareorg/r2ghidra-dec ).
IDA is in a good position with all the existing documentation and tutorials, I think its just a question of how long it takes for Ghidra to get the same treatment.
The feature set is solid. I've been frustrated by a few minor things that are missing from Ghidra, but Ghidra also has several features that are missing from IDA, and other features are better designed than in IDA.
But the whole thing is crushingly slow, especially the parts written in Java. (The decompiler is written in C++ but is also slower than Hex-Rays.) That single difference would probably have been enough to make me give up and go back to IDA, if I didn't have an ideological commitment to open source. I can't stand slow programs.
The UI is poorly designed, even compared to IDA's... quirkiness. Lots of paper cuts.
On the other hand, unlike IDA, it doesn't randomly crash and lose your data! (It does sometimes throw random NullPointerExceptions, but those are caught and displayed in a dialog. Since it's Java you don't have to worry about memory corruption.)
Overall, I agree it's in a good position with respect to adoption, although it does have to compete with pirated IDA, as well as the other alternatives.
More generally, what forums, irc channels, sites, etc. could I go to if I wanted to get into this community of researchers?
From a more grey perspective, the dev-fused phones do get stolen and sold around.
[1] https://www.theverge.com/2019/8/8/20756629/apple-iphone-secu...
Can't imagine running that sort of thing in the cloud. And that's even before considering the security aspects.
I imagine the thought process is totally different if you're doing security research, though.
IDA 7.4 introduced a new structure editor, arguably better Ghidra's. [1]
- When I first tried Ghidra I couldn't set the size of a struct by editing the size field, so I had to go through an awkward process of creating an undefined byte and then duplicating it. However, that seems to have been fixed, so it's now better than IDA (where I always have to create a dummy field and move it to the end)...
- The structure editor displays offsets and sizes as decimal by default (!?); there is a menu option to display as hex but it's per-structure and not persistent. ...Oh, I looked in Tool Options and I guess you can change the default there. That's nice to learn. But that's dumb UI design; it should just remember whether you clicked the menu option, and the default should be hex anyway.
- Changes in the structure editor window don't take effect until you press the little save button, which doesn't even have a key binding by default. If you forget to save, and then you modify the same structure from elsewhere (e.g. from rename/retype field in the decompiler), the structure editor 'helpfully' asks you whether to keep its version (in which case you lose the change you just made) or discard edits and reload (in which case you lose the changes you had forgotten to save).
- Can't jump to a specific offset in a structure. Well, you can sort of do it using the search field that does a textual search across all columns, since offset is one of the columns. But then you can type 0x3e and potentially be taken to 0x3e0 because that starts with "0x3e". Also, unlike a true "jump to offset", you can't enter the offset in a different form, like decimal instead of hex, or a mathematical expression (0x10+0x20).
- Can't jump from a field reference in the decompiler to the corresponding field in the structure editor. There is a way to open the struct in the structure editor (without jumping to the field), but even that requires a right click.
- If you have a structure consisting mostly of undefined bytes (e.g. I know there are fields at offset 0x50 and 0x100 but don't know anything else about the struct), the fields list shows each undefined byte as its own row, making it hard to see what actually matters – the defined fields. However, IDA has the same problem.
- The type list view is awkward. Why do I have to right click and go through a submenu just to create a new structure?
- It's annoying that the structure editor is a pop-up window rather than being integrated into the main window.
And some of my other Ghidra complaints are more generally related to structures:
- Can't mark struct field references in the disassembly, as far as I can tell, only in the decompiler.
- Searching for references to struct fields requires waiting for Ghidra to re-decompile every function that references the field (though it does seem to have some smarts to determine which functions to look at).
- Struct constants in the listing view are handled awkwardly. (Also awkward in IDA though.)
Actually, overall I think you've pretty much nailed the issues with Ghidra: it's a bit slow and clunky, and its UI sometimes does the stupidest and most infuriating things, such as truncate instructions. But its saving grace (at least for me) is that usually it's easier to figure out how to do what I want in it. It might require a few extra clicks or confirmations but if even if I mess up I can usually rely on undo working right, while I would always be scared of messing something up permanently with IDA and not being able to go back…
[0] https://github.com/radareorg/r2ghidra-dec [1] https://www.radare.org/r/ [2] https://cutter.re/