这可能是一个失败的原因，但我会问原因，老实说，我很好奇...
我们有一个客户想要为OS X创建一个替代的Messaging应用程序。他们基本上希望使用相同的帐户，聊天记录和所有内容，但提供与内置消息完全不同的UI(针对某些残障人士) 。应用程序。鉴于Messages.app的主要服务iMessage完全没有文档记录，因此创建自己的消息传递应用程序将非常困难，因此几乎不可能使用第三方代码来支持它。
经过初步研究，很明显，记录良好的AppleScript方法将提供可行但粗略的解决方案，缺少原始应用程序的许多功能(例如键入时的指示等)，更不用说它需要保留原始应用程序消息应用程序正在运行，这分散了用户的注意力。
到那时，我们开始更深入地挖掘并找到IMCore.framework。 IMCore基本上是Messages.app用于与各种服务进行通信的工具，它的引擎是imagent，它似乎是在管理数据并实际上与各种IM服务器进行通信的工具。 IMCore是一个私有(private)框架，使用它显然有一定的风险(并且会自动将其应用程序从App Store中排除)，但是我们的假设是，使用OS X，我们仍然应该能够实现此功能，并通过以下方式将应用程序分发到App Store之外:没有太大的困难。
我们开始尝试IMCore(同时对Messages.app进行反向工程以查看其用法)，并取得了一些进展。我们能够成功连接到imagent进程并执行一些配置操作，但是随后发现数据模型基本上是空的-即使我们无法访问任何用户数据，也无法与任何IM服务进行通信在用户的安全上下文中重新运行。
然后，我们注意到Messages.app具有一些非常奇怪的未记录的权利，例如com.apple.private.imcore.imdpersistence.database-access和com.apple.imagent。在这一点上，我们假设这些权利是我们无法与imagent成功通信所缺少的。我们已经尝试将这些权利添加到我们自己的应用程序中，并且能够成功构建它并对其进行代码签名，但是当程序启动时，它在启动时崩溃，并显示系统消息EXC_CRASH (Code Signature Invalid)(Xcode表示Terminated due to code signing error)。
我们可怕的假设是，Apple锁定了他们的私有(private)权利，因此，除非由Apple直接签名，否则系统将不会接受使用它们的二进制文件，但这显然是一个理论。另一个问题是，imagent如何知道我们的二进制文件是否具有这些权利？我们不能以某种方式欺骗这些权利吗？
正如我所说，感觉就像是一个失败的事业，但谁知道。我猜想在iOS上完成铁杆越狱工作的人可能有一个或两个主意-任何人？
最佳答案
我将回答我自己的问题，以提供更多信息，以防有人在意。归根结底，我们能够通过注入(inject)imagent流程并捕获权限验证功能，添加功能以使imagent允许我们的客户端进行XPC连接来越过这一障碍。
这为通过IMCore.framework与imagent进行全面，无限制的通信打开了大门，我可以确认是否实现了完整的iMessage功能。我们能够看到用户的iTunes帐户，发送和接收消息，从用户的数据库加载消息(以显示每次聊天的历史记录)以及几乎所有其他内容。该实现包括一个微小的系统守护进程，该守护进程在重新启动时(或在系统启动时)注入(inject)imagent，因此对于最终用户而言，使用标准的OS X安装程序进行安装非常容易。IMCore.framework非常易于使用，并且包含iMessage的每一个细微的元数据，包括另一端用户正在键入的通知，用于发送和接收附件的API，您可以为它命名!在OS X发行版之间似乎有所变化，但是我们能够使其在OS X版本上正常工作(我们测试了10.8至10.10)。
当El Capitan出现时，挑战就来了。 El Capitan中的新无根功能(系统完整性保护)可防止将我们的小技巧注入(inject)imagent，从而结束了该解决方案。 :-(当我们在task_for_pid进程上调用imagent时会发生故障。这失败了，并且基本上阻止了我们将代码注入(inject)该进程中。
因此，总的来说，这不是一个幸福的结局，但至少我们对应许之地有所了解。