Jonathan Levin, (@Morpheus______), http://newosxbook.com/ - 08/31/2016
About
While doing massive searches for strings inside binaries all across the iOS filesystem, it struck me I've overlooked something really, really simple and stupid - Since AAPL graciously provides the full unencrypted filesystem as one jumbo archive, it would be MUCH faster to just search inside the OTA!
So what changed?
A super simple fix - when I enumerate the OTA (so that you can, say, extract a file with -e) I now search its contents using a simple memmem(3). If I find whatever is supplied as a search string (with the new -s) I print out the offset in the would-be-extracted file:
Why is this useful?
Because you can now do searches all across [Watch/Tv/i]OS filesystems just by keeping the OTAs archives (that is, post pbzx and xz) on your filesystem. WAY MORE EFFICIENT than doing a find . | xargs grep ... for Oh-So-Many reasons, not the least of which is SPEED - search completes in mere seconds.
This is especially useful for, say, entitlements...
Or, for symbols - since they have to be somewhere as TEXT, right...? so:
Or, for users of an XPC service (assuming not via dylib, though):
Or, for seeing who's hard coding a particular file:
Limitations
This only tells you which file in the OTA your string is found. No RegExps, just hard coded strings. If it tells you file is shared_cache or Mach-O, use jtool -F from that point. Unfortunately, that's very common for XPC clients (since they use some framework abstraction, but if you get the symbol wrapping it, the problem can be reduced to the symbol use-case.
...And, since you're probably wondering about MOXiI 2 (a.k.a *OSI, Volume III)
It's actually done. And exceeded 400 pages. Sick, but comprehensive. Being reviewed by my expert team, and - more importantly - tested on a jailbroken iOS 10 β 8, which already proved a few nasty surprises. Yes, it's coming, Yes, soon, and I mean, imminently. Just bear with me.