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?
KTRW: The Journey to Build a Debuggable iPhone
11–20 of 26 posts
Re: KTRW: The Journey to Build a Debuggable iPhone
#12Earlier quoted context omitted.
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?
Re: KTRW: The Journey to Build a Debuggable iPhone
#13Earlier quoted context omitted.
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. Her…
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 de…
Re: KTRW: The Journey to Build a Debuggable iPhone
#14I 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…
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. Her…
Re: KTRW: The Journey to Build a Debuggable iPhone
#15Found 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.
Re: KTRW: The Journey to Build a Debuggable iPhone
#16Earlier quoted context omitted.
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 de…
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…
- 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.)
Re: KTRW: The Journey to Build a Debuggable iPhone
#17Where 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?
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.
[1] https://www.theverge.com/2019/8/8/20756629/apple-iphone-secu...
Re: KTRW: The Journey to Build a Debuggable iPhone
#18Found 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.
I imagine the thought process is totally different if you're doing security research, though.
Re: KTRW: The Journey to Build a Debuggable iPhone
#19Earlier quoted context omitted.
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…
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…
Re: KTRW: The Journey to Build a Debuggable iPhone
#20Earlier quoted context omitted.
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. Her…
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 de…
[0] https://github.com/radareorg/r2ghidra-dec [1] https://www.radare.org/r/ [2] https://cutter.re/