Category Archives: Tips

A quick review of Mac OS X and iOS Internals – To the Apple’s Core

The question that most people want to be answered is if this is the book to replace the venerable Mac OS X Internals by Amit Singh. In my opinion it’s complementary with some good updates and interesting tips.

I wasn’t expecting to buy this book so soon due to some Twitter comments and to printing issues, with at least one chapter missing and replaced with another from a book. A project I’m working at antecipated my waiting. I haven’t read the whole book yet but some six or seven chapters both from the introductory part and the more advanced one. The writing style and edition quality are good, which is a benefit from a single author. This contrasts for example with IOS Hacker’s Handbook, where the edition quality is poor and the writing styles so different (too many authors, not much edition work). There are printing errors here and there, with swapped outputs, messed up structures, some missprinted words. Nothing that puts in question the overall quality.

The main reason why I think it’s not a replacement to Singh’s book is that content feels short in many places. Some subjects are briefly introduced and then not developed. I would describe it as a good overall and updated (this is a very positive point!) introduction to Mac OS X internals. The iOS component is mostly brief references to differences or missing stuff (it’s a tough work here since its source is not published!). There is a lot less code and listings compared to Singh’s. One thing I like a lot are its diagrams and figures, simple and clear.

An update to Singh’s book is being done by Gwynne Raskind (website and email) although the release date is probably late 2013. One must wait to see if the new version will take the number 1 spot. This one is a good addition to your library and if you are new to OS X internals it’s probably a good place to start and then buy Singh’s book if you want to go deeper. Congrats to Jonathan Levin, (good) book writing is not easy 🙂


My first Hackintosh!

I really like my non-unibody Macbook Pro (awesome keyboard!) but the 3GB ram limit that I have makes it almost impossible to work with virtual machines, Mac OS ones in particular.
I don’t have a need for another laptop and possibilities were between buying a Mac Pro or build my own Hackintosh. Against the Hackintosh is the fact that my patience for small problems doesn’t exist anymore. I just want something that works and does what I need – time is money. That’s the biggest advantage of a Mac Pro – no frills experience.

Initially I was considering an iMac 27″ but I was annoyed by the fact that it wasn’t upgraded to Ivy Bridge. The lame upgrade on the Mac Pro line also annoyed me. I’m starting to hate this whole Apple secrecy. I need a new computer and my decisions can’t be based on rumors. Cognitive dissonance at its best.
Continue reading

How to compile GDB for iOS!

One obstacle that I faced long time ago and came again into spotlight is how to recompile gdb for iOS. It is not useful to fix the arm disassembler and then not be able to compile. As far as I know there isn’t any documentation available or an easy method to accomplish this – Saurik’s build environment is not public (?) and Apple sources do not compile directly. Darwinbuild project works great for OS X but it’s a question mark for iOS.

Darwinbuild it is! After some failed hacking last Friday (progress was great and it was near completation), I decided to try to fix the loose end today. Success was finally achieved.
This post contains almost all the information that you need to recompile gdb yourself. There is something that you will need to complete by trial & error. Let’s start the fun!

The reference post on darwinbuild usage is this one, written by yours truly. You should follow it and modify accordingly with the information provided here. My OS X version is still Snow Leopard but you should have no problems with Lion.
The image size should be 2GB, and you should use the build # 10K540. When you execute the “darwinxref edit”, use the following information:

environment = {
RC_ARCHS = "armv7 armv6";
RC_OS = macos;
RC_PRIVATE = /private;
RC_RELEASE = SnowLeopard;
RC_TARGET_CONFIG = iphoneos;

Word of caution: be careful with copy & pasting this because of the “” (if you get an error while saving from darwinxref edit).

The next step is to edit the darwinbuild database. It’s located at “.build/xref.db”, inside the Build10K540 folder you should be located at. You need to change the gdb version to the latest one, 1708 instead of 1344. Execute the following sql statement to verify it:

SELECT * FROM properties WHERE project="gdb" AND property="version";

and then update the field:

UPDATE properties SET VALUE="1708" WHERE project="gdb" AND property="version";

Start compilation with “darwinbuild -nochroot gdb”. Version 1708 will be downloaded. When configuration/compilation starts, abort it with ctrl-c.
You will need to create a link (there is probably a more elegant solution to this!). Go to the usr/lib folder inside the iOS SDK. There you need to make a link from “crt1.10.6.o” to “crt1.o”.  Small example from my system:

lrwxr-xr-x  1 root  wheel     6 Apr 14 04:12 /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/crt1.10.6.o -> crt1.o
-rw-r–r–  1 root  wheel  2720 Aug 30  2011 /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/crt1.3.1.o
-rw-r–r–  1 root  wheel  4584 Aug 30  2011 /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/crt1.o

Next step is to modify the file “BuildRoot/SourceCache/gdb/gdb-1708/src/gdb/macosx/macosx.defs”. Here you need to replace the import for exc.defs. Change:



#import "/Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/mach/exc.defs"

(modify your path accordingly)

Last step for now is to modify the Makefile. We need to modify it so the ARM cross-compiling tools are used. It’s located at BuildRoot/SourceCache/gdb/gdb-1708/Makefile. To make it easier, you have my Makefile as a reference (all files at the end). I left the places that you need to modify tagged with FIXME. Your task is to change the paths.

Now you are ready to compile and start the trial and error process. This time, compile with “darwinbuild -nochroot -nosource gdb”. This will not unpack again the source package and will keep our previous changes.
The compilation process will start and hopefully you will observe lots of output, which is a good sign! Near completation, errors regarding missing includes will start to appear. Your task is to manually copy them from OS X “/usr/include” to the iOS SDK “usr/include” folder (in my case /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/). The only modifications that you will need to do are to edit some files and change the import location to relative paths (or absolute if you prefer). Not elegant, but it works! When you reach the missing architecture includes, you can use the ones from i386. Sorry for not having a complete file list – I was hacking this without great hope that it would work heheheh.

And that’s it! After you fix the missing includes and defs, the compile should successfully finish and you have your shiny recompile gdb. You can also apply my gdb patches (recommended!). Before starting to compile everything, just go to the SourceCache folder, apply the patch and compile.
Follow the steps from the reference post to copy the compiled binary, apply the necessary entitlements (reference), upload to your device and enjoy 🙂

If you don’t feel adventurous enough then I include a fat binary (armv6 and armv7) with my patches. You just need to add the entitlements.
Pancake (from Radare) created a package for this version. Add to your repo list and install it from there. Thanks to pancake for his work 🙂

Any question or problem you run into leave a comment so everyone else can benefit from the (potential) solution.

Have fun,



Hash: SHA1
SHA256(Makefile.gz)= 9aa69bc9b5a77a682c5bc74435440f26e839c0b216861f64a1af4f5a6432dfaf
SHA256(gdb-arm-apple-darwin.gz)= 7c3744c1be024a28c594c0ad90d75f0d187c5e53d9cb09d0183bba19b7415e6d
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -

Update: List of added/modified include files (I forgot about the power of find :X)

How to create IDA C/C++ plugins with XCode

This is just a simple post about using XCode to create IDA C/C++ plugins. Nothing fancy here 🙂
For great references about IDA SDK plugin writing check out The IDA Pro Book by Chris Eagle and tutorial.

XCode 3.2.6 is the reference. The resulting project loads and compiles without any issues into XCode 4. Why not doing this in 4? Human brain is misterious (3.x still loads by default on my system :-X).

Let’s start…
Load XCode and start a New Project. Use the BSD C Library template, Dynamic type (found in the Framework & Library group). Choose whatever name you want for your plugin (we can rename the binary later).

Next step is to edit project settings. Go to “Project” menu, “Edit Project Settings”. Select the “Build” settings and go to the “Linking” options group. At the “Other Linker Flags” insert “-lida”. Next go to “Search Paths” options group. You need to set the path to the IDA SDK header files (the idasdk/include folder) in the “Header Search Paths” and the path to IDA library (libida.dylib). You can copy this from IDA application into the SDK folder or just point it to the IDA application folder. It’s your call!

The last step here is to add a preprocessor macro. Add “__MAC__” into “Preprocessor Macros” at “Preprocessing” group. You can also define this at your source file. The symbols “__EA64__” and “__X64__” might be useful. Check install_linux.txt at the SDK for their meaning. Probably you should add these at the source file together with the “__LP64__” to distinguish between 32 and 64 bits builds.

To finish this you may want to configure the target options. Since it’s a very simple project you can use the “Project”, “Edit Active Target xxxx” menu. Select the”Build” settings and go to “Packaging” group. Modify the “Executable extension” to “pmc”, remove/change the “Executable Prefix”, and configure the “Product Name” if you wish so.

Now add your plugin code (files should be C++ type), compile and install the plugin (you can configure XCode to execute this step when it finishes compilation – add a new copy files build phase).

If you don’t want to use XCode you can use this Makefile (original from tutorial). Adapt it to your own needs. It’s configured for producing 32bits binaries only.

CFLAGS=-arch i386 -D__IDP__ -D__PLUGIN__ -c -D__MAC__ -I/path/to/idasdk/include $(SRC)
LDFLAGS=-arch i386 --shared $(OBJS) -L/path/to/libida -lida --no-undefined -Wl
        $(CC) $(CFLAGS)
        $(LD) $(LDFLAGS) -o formsample.pmc

And that’s it!


Apple Sandbox Guide v1.0

Here it is a version I consider good enough  to come out of draft status. I have added more information – one thing I was especially interested was to match the available operations in the SBPL syntax with the system/kernel functions that they control. This helps to better understand what is the impact of each operation. Appendix B features the lazy IDC script I used to extract this information from the sandbox kernel module (then I had to match with xnu kernel sources).
I tried to provide examples for all operations and make notes of some problems/features where available. Also added a few more references about this subject. The book “Enterprise Mac Security: Mac OS X Snow Leopard” has a pretty good chapter dedicated to this.

I hope it’s useful for you. I have been using it as reference while developing some custom profiles.


Apple Sandbox Guide v1.0.pdf
SHA256(Apple Sandbox Guide v1.0.pdf)= c6ae8502a48f09a6309a9485e9bf7794389e969fd9ab65c46d805307a9a1cb8e
SHA256( 0831910e4d2a92253e5b64e92ec0f27e1408b926253eca9eee3f9918036077c0

Apple’s Sandbox Guide v0.1 – early draft release

After quite a few hours typing and testing stuff, here it is a very early draft of my attempt to document Apple’s sandbox implementation.
The most difficult part in writing technical documentation or business plans is to get the first draft more or less ready. It’s even worse when there’s not much information about the subject. But here it is something with already quite some significant content.
In this draft I don’t like the writing style – it’s still very confuse and boring. The layout of the reference section is also a bit confuse.

What I would like to hear from you is about the content and the direction I took. If it is useful this way, if it can be (easily) understood, how can it improve, what to add more, etc.
Leave a comment, write a mail, or send me a tweet. Any feedback is appreciated! This is not an easy task 😉


Apple Sandbox Guide v0.1.pdf
SHA256(Apple Sandbox Guide v0.1.pdf)= a7e966d03014938af92df5a9f9eb5cfbabf01d3c22dacb701768af2aaca1866d

An improved version 0.2 is now available. Layout is improved and more content added. Still missing the mach operations. File-write-data appears to be buggy (or I am missing something…).

Apple Sandbox Guide v0.2.pdf

SHA256(Apple Sandbox Guide v0.2.pdf)= a22e5baf0e88413077fdf0b421920c02f02bfae7b897ba49fb6ae5709b3e460d