Overcome OS X and Jailbroken iOS Apple Private Rights

Question

This is probably a lost thing, but I will ask because I'm honestly just curious ...

We have a client who wants to create a messaging application for OS X. They basically want to use the same accounts, chat history and everything, but provide a completely different interface (for people with disabilities) to the built-in .app messages. Creating your own messaging application will not take into account the fact that the primary service in Message.app, iMessage, is completely undocumented, and therefore supporting that with third-party code will be practically impossible.

After the initial research, it became apparent that the well-documented AppleScript approach would provide a workable but rude solution, missed by many features from the original application (for example, typing, etc.), not to mention the fact that this requires keeping the application running Messages that distract the user.

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

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

Then we noticed that Message.app has some very interesting undocumented rights, such as com.apple.private.imcore.imdpersistence.database-access and com.apple.imagent . At this stage, we assume that these rights are what we lack to successfully communicate with imagent . We tried to add these rights to our own application and were able to successfully build and encode it, but when the program starts, it crashes when launched with the EXC_CRASH (Code Signature Invalid) system message (Xcode says Terminated due to code signing error ).

We fear that Apple will block its private rights so that the system does not accept the binary code that uses them if it is not signed directly by Apple, but this is obviously a theory. Another question: how imagent to know whether our binary data has these rights or not? Could we somehow deceive these rights?

As I said, he feels like a lost cause, but who knows. I guess people who did jailbreak hardcore on iOS might have an idea or two — anyone?

Answer 1

I am going to answer my question in order to provide a little more information if someone cares about it. In the end, we were able to overcome this barrier by introducing an imagent process and capturing rights-checking functions, adding functionality so that imagent allow the XPC connection for our client.

This opened the door for full, unlimited communication with the image through IMCore.framework , and I can confirm that the full functionality of iMessage has been achieved. We were able to see the iTunes user account, send and receive messages, download messages from the user database (to show the history for each chat), and almost everything else. The implementation included a tiny system daemon that introduced an imaginary each time it was restarted (or at system startup), so it was very easy for the end user to install the standard OS X installer.

IMCore.framework pretty easy to use and includes every tiny bit of metadata for iMessage, including notifications that the user on the other end prints, APIs to send and receive attachments, you name it! It seems to have changed a bit between OS X versions, but we were able to get it to work on OS X versions (we tested 10.8-10.10).

The challenge came when El Capitan appeared. The new rootless (System Integrity Protection) feature in El Capitan prevents our little hack from being injected into imagent , which put an end to this solution. :-( Failure occurs when we call task_for_pid in the imagent process. This crashes and basically blocks us from entering our code into this process.

In general, not a happy ending, but at least we have a taste of the promised land.