Overcoming OS X and Jailbroken iOS private Apple entitlements

Question

This one is probably a lost cause, but I'll ask cause I'm honestly just curious...

We have a client that wants to create a replacement Messaging app for OS X. They basically want to use the same accounts, chat history, and everything, but provide a completely different UI (for people with certain disabilities) to the built-in Messages.app. Creating their very own messaging app would not fly given that the primary service in Messages.app, iMessage, is completely undocumented and so supporting that with 3rd party code would be nearly impossible.

Upon initial research, it became obvious that the well-documented AppleScript approach would provide a workable but crude solution, missing many features from the original app (such as an indication while typing, etc.), not to mention that it requires keeping the original Messages app running which is distracting to the user.

At that point we started digging a little deeper and found the IMCore.framework. IMCore is basically what Messages.app uses to communicate with the various services, and its engine is imagent, which is what appears to manage the data, and actually communicate with the various IM servers. IMCore is a private framework which obviously is somewhat risky to use (and automatically excludes their app from the App Store), but our assumption was that with OS X we should still be able to implement this and distribute the application outside of the App Store with not much difficulty.

We started experimenting with IMCore (while reverse-engineering Messages.app to see how it's used), and made some headway. We were able to successfully connect to the imagent process and perform several configuration operations, but then discovered that the data model is basically empty -- we're not able to see any of the user's data or communicate with any IM services even though we're running in the user's security context.

Then we noticed that the Messages.app has some very curious undocumented entitlements such as com.apple.private.imcore.imdpersistence.database-access and com.apple.imagent. At this point we're assuming that these entitlements are what we're missing in order to successfully communicate with imagent. We've tried adding those entitlements to our own app and were able to successfully build and codesign it, but when the program is launched it crashes on startup with the system message EXC_CRASH (Code Signature Invalid) (Xcode says Terminated due to code signing error).

Our fearful assumption is that Apple locked their private entitlements so that the system won't accept a binary that uses them unless it is signed directly by Apple, but this is obviously a theory. The other question is, how does imagent know whether our binary has these entitlements or not? Couldn't we somehow spoof these entitlements?

As I said, feels like a lost cause but who knows. I'm guessing people who have done hardcore jailbreak work on iOS might have an idea or two -- anyone?

Answer 1

I'm going to answer my own question to provide a bit more information in case anyone cares about this. At the end of the day we were able to cross this barrier by injecting into the imagent process and trapping the entitlement verification functions, adding functionality so that imagent will allow the XPC connection for our client.

This opened the door to full, unlimited communications with imagent through IMCore.framework, and I can confirm that full iMessage functionality was achieved. We we were able to see the user's iTunes account, send and receive messages, load messages from the user's database (to show the history for each chat), and pretty much everything else. The implementation included a tiny system daemon that injected imagent whenever it was restarted (or when the system booted up), so it was very easy for an end-user to install using a standard OS X installer program.

IMCore.framework is fairly easy to use and includes every tiny bit of metadata for iMessage, including notifications that the user on the other end is typing, the APIs for the sending and receiving of attachments, you name it! It seems to change a bit between OS X releases, but we were able to make it work across OS X versions (we tested 10.8 through 10.10).

The challenge came when El Capitan showed up. The new rootless feature (System Integrity Protection) in El Capitan prevents from injecting our little hack into imagent, which put an end to this solution. :-( The failure happens when we call task_for_pid on the imagent process. That fails and basically blocks us from injecting our code into that process.

So overall not a happy ending, but at least we got a taste of the promised land.