KTRW: The Journey to Build a Debuggable iPhone | Hacker News Reader

KTRW: The Journey to Build a Debuggable iPhone

googleprojectzero.blogspot.com

77 pointsarchimag025 comments

I note that IDA Pro and LLDB are mentioned. How much penetration does NSA’s Ghidra have at this point, and is it expected to grow over time? I used IDA briefly in a past life and was really impressed with Ghidra, especially as an “open” offering.

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.

I don't know how many people are actually using it, but I've been to more then one con that has had a talk about using it. The talks focused on showing off features and/or trying to get people to use it.

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.

I've recently been using Ghidra for a personal project, after using IDA extensively in the past. My impressions so far:

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.

It's a bit of a gloomy view into the landscape of disassemblers, but I was very impressed that Ghidra managed to keep one of my temporary unsaved projects I had been working on (mostly) intact through a kernel panic. Oh, and there are certain things that Ghidra's UI is better than IDA's at: defining structures, for example. And I'd like to think it has less malware in it than pirated IDA…

Defining structures is one of the worst parts of Ghidra for me! But maybe I'm missing something.

- 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.)

I mean, it's not perfect; I just thought that IDA does many of the same things that Ghidra does wrong but with a somewhat less forgiving UI. You did hit on some of the issues I've had with Ghidra, though: I agree that the way to create structures requires a lot of overhead and while I don't deal with anything too large, I kind of wish that Ghidra would collapse runs of "undefined" and only expand them if you clicked on it or something like that. If it annoys me enough and I ever get the time I'll see if I can file a pull request for these things.

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…

Thanks for this comment - I never tried Ghidra thinking it’s the same non-undoable usability disaster.

> Ghidra's UI is better than IDA's at: defining structures, for example

IDA 7.4 introduced a new structure editor, arguably better Ghidra's. [1]

[1]: https://hex-rays.com/products/ida/7.4/index.shtml

IDA still doesn’t support ctrl+z for field renames. Which makes working in it an absolute nightmare (e.g. accidentally renaming a field at the beginning of the structure which will remove all mapping after it).

I felt the same way about Ghidra being slow and buggy sometimes but can really vouch for r2ghidra-dec[0] to integrate the decompiler into radare2[1] (and the cutter[2] qt gui). This combination feels really nice but I have to admit that I do not have any experience with IDA as a comparison.

[0] https://github.com/radareorg/r2ghidra-dec [1] https://www.radare.org/r/ [2] https://cutter.re/

Hmm, interesting. I’ll try it out when I get a chance!

FWIW, the general perception I get from the community is that IDA's decompiler is still the gold standard, though Ghidra's is much better than any of the competing alternatives. Personally, I've found it to be eminently usable for reasonable tasks.

Where does one go about obtaining the phones they describe early in the post? What is the availability and cost for phones of this kind?

More generally, what forums, irc channels, sites, etc. could I go to if I wanted to get into this community of researchers?

Pretty easy to find on twitter

https://mobile.twitter.com/jin_store

Thanks! Did you just outgoogle me, or might you have anything interesting to share about the market?

I know of these devices from reading other articles, not an expert :).

He's is well known if you every go down the rabbit hole of Apple internal devices, but he's by no means the only source of these.

From what I have heard in the past, Apple has only given them to specific researchers who they trust. It's very much a "We'll contact you" type of situation.

From a more grey perspective, the dev-fused phones do get stolen and sold around.

I don't think Apple has ever intentionally handed out dev-fused phones. However, they are planning to do something like that starting next year. [1]

[1] https://www.theverge.com/2019/8/8/20756629/apple-iphone-secu...

There has an article [1] about this been on the hn fp half a year ago.

[1]: https://news.ycombinator.com/item?id=19321270

Found the virtualization is in the cloud connection weird/scary.

Can't imagine running that sort of thing in the cloud. And that's even before considering the security aspects.

Are you talking about Corellium? That runs on custom hardware that is merely accessible through the web. And presumably you're not using it for your day-to-day web browsing or email…

Depends on your use case and threat model, really. The company I work for maintains a fleet of jailbroken phones. This is a difficult proposition to scale, so we're always on the lookout for alternatives, but we evaluated a major cloud emulation player and decided against it for reasons that had nothing to do with security.

I imagine the thought process is totally different if you're doing security research, though.

Nice of Google to spend so much time and effort finding security flaws in their competitors' devices.

For what it's worth, this isn't a security flaw.

Reply on news.ycombinator.com