Page 1 of 1

Tools used by the author

PostPosted: Wed Jun 10, 2015 10:36 pm
by halprin
Hey there Jonathan,

I was curious what (software) tools you use to help you research the information for the book (including the second edition). I'm especially curious of how you research the undocumented parts of Mac OS X.

For example, do you use
* otool
* jtool
* strings
* IDA Pro
* Hex-Rays decompiler
* etc...

Re: Tools used by the author

PostPosted: Wed Jun 10, 2015 11:13 pm
by morpheus
Hi,

* otool - on rare occasions, such as disassembling x86_64, which jtool can't do (because it's too much work to implement) and in some occasions when I find a bug or unrecognized opcode in jtool. It's nice to see otool is improving, and I'm getting the sense that it's because someone @AAPL was using my tools :)

* jtool - all the time. I built this tool "around" my reversing, and so it has a ton of less known argument combinations that make sense to me, and options such as working with the shared library caches, and decompiling functions (e.g. panic, SecTask*) which are of interest. I'm working on making at least the latter public, as I'm adding symbolication features through external files (eventually I hope to support DWARF). Whenever I find a particular obstacle, I basically build a workaround into Jtool for it. It's one of those tools which started out as a simple Mach-O lister (jtool -l/-h/-f/-L, that is), but disassembling sent me down a slippery slope.

* strings - nope. jtool -d __TEXT.__cstring is better. Also prints offset. In fact , jtool supports dyldinfo and pagestuff emulation as well.

* IDA Pro - nope. Costs an arm and a leg.

* Hex-Rays decompiler - nope. Costs even more. And you don't get the insights you get from an automated decompiler the way you'd get it from working it yourself. Plus decompilers aren't that good. I did try them around 6.1, and wasn't impressed.

* etc...

So there's also joker - which is built out of the jtool source , and used specifically for symbolicating ARM32 kernels (as Apple keeps stripping symbols and every kernel is different). I used that in a recent writeup.

For runtime analysis I use procexp, which - more than a top variant, it can single out processes. and I have a KDebug Viewer which I'm hoping to release soon.

For invasive tasks like injection I use core-ruption. which I'll finally make fully public with MOXiI 2. I think. Can't promise.


Thanks for asking :)