精华内容
下载资源
问答
  • iMessage-源码

    2021-03-31 16:21:22
    iMessage
  • iMessage的Web应用程序 它使用Mac应用程序与服务器通信并在收到新消息时发送它们。 服务器还可以与mac应用程序通信,以将消息发送到iMessage。 警告,这根本无法使用,并且缺少关键的安全功能。 它主要是作为一个...
  • iMessage debug工具

    2018-05-31 09:03:43
    获取白苹果机器码,使你的黑苹果成功仿冒白苹果,成功激活iMessage和FaceTime
  • Alfred的iMessage 2FA工作流程 在您最近的iMessage消息中找到两因素身份验证代码。 安装 双击.alfredworkflow文件安装工作流 您可以将工作流添加到类别中,然后单击“导入”以完成导入。 现在,您将在“工作流程”...
  • Flask iMessage服务器 注意:这是一个正在进行的工作。 很多都行不通。 我不擅长软件工程。 此存储库包含一个Flask Webapp,该Webapp允许用户通过HTTP发送和接收iMessage。 如果您想在Apple计算机上发短信,但又有...
  • iMessage-gifs iOS iMessage应用程序可共享用Swift 4编写的GIF 预习 内置 iOS 11.4 Xcode 9.4 特征 使用获取GIF 使用并使用处理HTTP Networking ,可以轻松地从API解析JSON对象 使用下载 使用UISearchBar搜索...
  • imessage_debug

    2016-11-09 17:09:36
    用于提取白苹果三码,注入黑苹果后即可无门槛登录iMessage,变成真正的白苹果! 先解压,将文件拖入中断运行。 如果提示permission denied, 需要在中断输入chmod a+x 然后拖入文件,回车,文件变为可执行状态。 运行...
  • 永久聊天iMessage导出 什么 该模块从iMessage chat.db数据库中读取数据,并为您提供的输出 去做 修复隐藏在iOS数据库中的一些附件路径
  • iMessage贴图.zip

    2019-09-23 12:04:29
    iMessage贴图.zip,An iMessage sticker set for when "you're holding it wrong" comes to mind
  • iMessage 群发

    2018-07-04 21:28:00
    Apple公司全线在mac os与ios两个操作系统上内置了FaceTime与iMessage两个应用。完美替代运营商的短信与电话。并且FaceTime与iMessage的帐号不仅仅与Apple ID 绑定,同时也与使用这Apple ID的手机号码绑定,这样的...

    Apple公司全线在mac os与ios两个操作系统上内置了FaceTime与iMessage两个应用。完美替代运营商的短信与电话。并且FaceTime与iMessage的帐号不仅仅与Apple ID 绑定,同时也与使用这Apple ID的手机号码绑定,这样的漏洞自然给无孔不入的中国的群发垃圾信息商们提供了后门。

    这样iPhone的iMessage时不时就能收到以邮件为发送者的垃圾iMessage,尤其是嘀嗒打车群发的最多,听说是厦门一家公司操刀的。针对iMessage的群发实现,新闻稿上说是花几分钟写个脚本就可以了。可惜我花时间研究了好几次,也没有实现大批量群发的实现,倒是把自己的Apple ID搞的电脑与手机不同步了。

    我研究怎么实现iMessage群发先是从XMPP协议开始的,因为Apple MAC os上的ichat是XMPP客户端,可以连接iMessage服务器,同时也可连接gtalk与weibo私信。但后面发现iMessage的服务器验证是加密,没办法实现非ichat XMPP客户端连接iMeesage服务器,那就自然没办法实现程序控制往iMeesage服务器批量发送信息。

    只能通过MAC OS或者iOS自带的程序往iMeesage服务器发送信息,那要实现群发,自然只能想办法去调用自带的这ichat客户端,在MAC OS系统上Apple公司提供一种叫Apple script的脚本来自动实现任务。可能通过tell application "Messages"就可以激活iMessage客户端自动发送信息。这样实现的群发的思路就很清楚了
    1.通过AppleScript实现批量注册itune帐号

    2.通过AppleScript实现自动取一个itune帐号群发100个APPle ID的iMessage

    set EMAIL to "EMAIL_DEL_DESTINATARI" -- el destinatari ha de tenir l'iMessage activat
    set MSG to "COS_DEL_MISSATGE"
    set N to the 1000 -- nombre de vegades que s'enviarà el missatge
    set APPLE_ID to "E:" -- la teva Apple ID que ha de tenir iMessage activat
    repeat N times
        tell application "Messages"
            send MSG to buddy EMAIL of service APPLE_ID
        end tell
    end repeat
    

     

    看来新闻稿没有说错,实现iMessage群发确实只要几分钟写脚本。但懂用使用iMessage的用户显然不是买iPhone装逼用的用户,你群发的iMessage除骚扰又能带来什么样的效果哟。

    后面在网上搜索到一个更详细的博客说明,转载如下

    iMessage介绍
    iMessage是苹果设备(iPad、iPhone、iPod touch)自带的免费信息发送应用。它的信息通过网络发送,不同于运营商短信。目前iMessage日活跃用户1.9亿,日发送约20亿条。

    iMessage优势
    iMessage与传统短信不同,具有以下优势:

    • 目标人群明确,均为苹果用户,消费能力较强
    • 文字数量不限,同时还可以添加表情和图片
    • 可以添加网址、下载链接等,用户可以直接通过手机访问
    • 不会被手机安全卫士拦截
    • 转发就像手机短信一样方便
    • 无发送成本
    • 送达终端的概率极高

    iMessage推送技术实现
    群发iMessage主要需要攻破两个技术难点,一个是iMessage账号的获取,另一个是群发iMessage。

    iMessage账号获取
    iMessage账号目前获取的方法主要是扫描手机号码。扫描手机号码可以通过代码自动扫描,也可以通过人工筛选。通过代码自动扫描本人暂未发现很好的方法,建议大家可以从以下两方面着手:

    • 1.编写AppleScript脚本控制Mac OS自带的iMessage客户端进行验证,类似于群发iMessage。发送一条iMessage之后,如果捕获到发送失败的异常则不是iMessage账号
    • 2.研究iOS系统中Message framework中的私有api,通过私有api进行验证

    要进行人工筛选,也可以通过Mac OS自带的iMessage客户端。方法是编写程序,将要验证的号码输出到文件中,以逗号分隔。再将文件中的号码粘贴到iMessage客户端的地址栏,iMessage客户端会自动逐个检验该号码是否为iMessage账号,检验速度视网速而定。其中红色表示不是iMessage账号,蓝色表示iMessage账号以及未检验的账号。如图:
    image
    检验过程中有可能会出现停止的现象,可以全选所有号码后,剪切再粘贴即可继续检验。

    iMessage群发
    检验完所有账号后,可以从中选取出iMessage账号进行群发。群发有两个方法,一个还是通过iMessage客户端,另一个是通过AppleScript脚本控制iMessage客户端发送。

    • 通过iMessage客户端发送,可直接将号码粘贴至地址栏,填写内容,发送即可。
    • 通过ApplseScript控制iMessage客户端的脚本如下:
      tell application "Messages"
      set csvData to read "/Users/xxxx/Desktop/test.csv"  
      set csvEntries to paragraphs of csvData
      repeat with i from 1 to count csvEntries
      set phone to (csvEntries's item i)'s text
      set myid to get id of first service
      set theBuddy to buddy phone of service id myid
      send "今天北京晴,气温13到27度;周二晴,气温11到26度,北风3-4级;周三晴,气温11到24度,微风<3" to theBuddy
      end repeat
      end tell

      以上代码可从一个csv文件中读取出iMessage账号,并通过iMessage客户端逐个发送iMessage消息。

    需要注意如下问题:

    • 1.由于该脚本是控制iMessage客户端进行发送,所以必须在MacOS 10.8以上(10.7系统中的iMessage Beta版本已无法使用)的系统中运行,同时开启iMessage程序。
    • 2.该脚本在发送iMessage时并不是后台发送,所以当发送量很大时,会导致iMessage客户端运行缓慢,甚至无法开启。可通过清空所有已发送的iMessage或注销账号解决。
    • 3.通过脚本发送的iMessage账号必须是在当前iMessage客户端中检验过的,否则会报“不能获得“buddy id "C0B35E7F-A0FB-49E1-BDD7-C867BC06D920:+86136xxxx0000"”。

    从上面转载的博文上可以看出来,这哥们主要是做了简单少数号码的尝试,没有真正大量群发过,但他在最后也提出了真正群发会遇到问题,三个问题解决方案如下:

    • 第一个问题用mac os系统或者黑苹果装10.8操作系统,会自带messages程序,这程序系统自带,千万不会发现打不开去删除Messages程序,删除就只能重装系统了。并且是先打开Messages程序,再启动apple script脚本,不然运行不正常。
    • 第二个问题,在发送过程中加入同步删除的代码,但同步一条一条删除时有时会失败,所以再增加发一定量后再批量删除一次的操作,正常的流程应该是打开Messages程序->循环号码库->读取一个号码->发送一条信息->等待1秒->删除此条信息->判断是否未删除的超过100条,是批量删除->循环号码库。这样就可以保证Messages程序不会去占百分一百多的CPU或者几个G的内存。
      tell application "Messages"
      set csvData to read "/Users/xxxx/Desktop/test.csv"  
      set csvEntries to paragraphs of csvData
      repeat with i from 1 to count csvEntries
      set phone to (csvEntries's item i)'s text
      set myid to get id of first service
      set theBuddy to buddy phone of service id myid
      send "今天北京晴,气温13到27度;周二晴,气温11到26度,北风3-4级;周三晴,气温11到24度,微风<3" to theBuddy
      delay 1 -延时一秒,不然取不到已发达的内容
      set FailNum to (get count chat)
      if FailNum>100 then
      repeat with j from 1 to FailNum
      set phone to (get name of chat (FailNum-j))
      set DelMsg to "iMessage;-;" & phone 
      if exists (text chat id DelMsg) then
      delete text chat id DelMsg
      end if
      end repeat
      end if
      end repeat
      end tell
    • 第三个问题,在messages程序的imessage帐号中设置用来群发的imessage帐号。就没有问题了。

     

    https://blog.csdn.net/zhaoxy_thu/article/details/9255165

     

    转载于:https://www.cnblogs.com/saytome/p/9265429.html

    展开全文
  • 阿尔弗雷德-工作流-imessage 用于从 iMessage 应用程序完成好友的 Alfred 插件 此插件是关键字触发的,将使用您的(部分)输入参数来匹配来自 Messages 应用程序的 iMessage 好友。 该脚本将匹配好友属性,例如名字...
  • 将动画PNG iMessage贴纸保持在500KB以下 随着iOS 10的发布,Apple在iMessage中引入了贴纸。 贴纸是可以发送或放置在消息,照片或其他贴纸上的小图像或动画。 用您自己的动画贴纸创建贴纸包很简单! 您需要和 。 ...
  • Android Wear上的iMessage 该项目使用AppleScript处理程序,使用Google Cloud Messaging将iMessages从Mac OS X推送到Android。 它还包括一个Node.js服务器,该服务器可以将语音回复发送回iMessage。 构建和配置 在...
  • iMessage For PC-crx插件

    2021-04-02 12:51:09
    适用于Windows的iMessage可用。 imessage是为Apple PC和iPhone用户开发的应用程序。 现在可以通过chrome应用程序在PC桌面上使用。 iMessage是由Apple Inc.开发并于2011年推出的即时消息服务。iMessage仅可在Apple...
  • iMessage App 创建

    2021-01-14 15:18:53
    iMessage App iMessage App 主要分以下 4 类。 贴纸包应用。这是一种由图片或动图组成的基本贴纸包,无需编写代码即可构建。开发者可以在 iMessage 版 App Store 上的“贴纸”类别和相关“贴纸”子类别中提供此类 ...

    iMessage App 

    iMessage App 主要分以下 4 类。

    贴纸包应用。这是一种由图片或动图组成的基本贴纸包,无需编写代码即可构建。开发者可以在 iMessage 版 App Store 上的“贴纸”类别和相关“贴纸”子类别中提供此类 App。

    贴纸包拓展。开发者可将贴纸包与自己的 iOS App 绑定起来。贴纸包会在 iMessage 版 App Store 中提供,类别和描述与 iOS App 相同。 

    iMessage App。App 中可以包含贴纸、文字、视频和音频。开发者可以编写代码来添加功能,比如 Apple Pay 和 App 内购买。类别可根据 iMessage 版 App Store 上的“贴纸”类别或其他相关类别中进行选取。

    iMessage App 拓展。iMessage extension 可以包含与独立 iMessage App 相同的功能,让用户无需离开“信息”就能访问 iOS App 的功能。

    注意:开发者必须使用最新版本的 Xcode 和 iOS,才能创建 iMessage App。

    创建 iMessage App

    创建 iMessage App 前,开发者首先需了解苹果对 App 名称、描述、屏幕截图和关键词的设置要求。

    应用图标

    开发者需要上传两个图标:一个用于 iMessage,另一个用于 iPhone 和 iPad。 用于 iMessage 的图标为矩形版本,格式为 1024x768 像素。用于 iPhone 和 iPad 图标格式为 1024px×1024px。

    注意:系统会对用于 iMessage 的图标进行调整,为其添加上椭圆形蒙版。所以,开发者不需要上传椭圆形图标,另外需考虑到外边缘上的元素会被椭圆形蒙版遮挡的因素。如果图标设计为白色或浅色背景,系统则会添加细线笔划以在 App Store 中更清新的显示。

    应用名称和描述

    应用名称和描述中可以使用“iMessage” 和 “Stickers”,但是要尽量避免重复使用。

    关键词

    关键词总共限制为 100 个字符,单词用逗号隔开,不要有空格。关键词可以使用“iMessage” 和“贴纸”。但是最好避免使用特殊字符,例如:#或@ - ,因为特殊字符不利于产品搜索。

    截图

    对于 iMessage App 和 iOS 扩展程序,开发者需为 iPhone 6 Plus 和 iPad Pro 提供单独的 iMessage 内容屏幕截图,每套屏幕截图最多可以上传 5 个。开发者可从 App Store Connect 的“我的 App”中,进行上传。

    App 预览

    App 预览是直接在 App Store 上吸引用户使用 iOS,macOS 或 tvOS App 的短视频,由于 App 预览在 iOS 11 和 macOS Mojave 上是自动播放,因此它们是帮助用户发现和了解 App 的关键。

    App 预览可以创建三个,有利于为用户展示更多 App 功能或特定内容。不过,只有 iOS 11 或更高版本的用户才能看到多个应用预览。

    App 预览适用于所有受众,因此它们必须适合 4 岁及以上的人群。避免令人反感的内容,暴力,成人主题和亵渎。应用预览内容上,不要拍摄与设备交互的人(例如肩上角度或手指轻敲屏幕),也不要使用应用预览来显示应用开发的幕后花絮。

    类别

    适用于 iMessage 的 App Store 有一个名为 Stickers 的新类别,它出现在 App Store for iMessage 的类别列表的顶部。贴纸类别还包含贴纸子类别。贴纸类别仅适用于独立的 Sticker Pack 应用和 iMessage 应用。开发者需要选择贴纸的主类别和子类别。

    如何选取适合的 App 类别,开发者可从以下几个方面考虑:

    • App 的用途。App 的主类别应该是最能描述 App 的主要功能或主题的类别。
    • 用户的意愿。了解 App 受众群体,考虑用户会通过什么类别找到你的产品。
    • 参考同类产品。寻找自己的同类产品,观察这些 App 属于哪些分类,可以作为自家 App 的类别参考。

    为 iMessage 制作贴纸

    开发者只需使用 Mac、Apple ID、贴纸图像和 Xcode,就可以轻松地为 iOS 上的信息 App 制作贴纸包。任何拥有 Apple ID 的用户都能免费下载 Xcode。

    图像

    贴纸包支持 PNG、JPEG 或 GIF 格式的图片文件,也可以是 APNG 或 GIF 格式的动图。尺寸可参考下图:

    图标

    开发者需要制作多种尺寸的贴纸包图标,以供 iMessage 版 App Store 和 iOS 使用。

    苹果给出比较全面的 Photoshop 模板以供开发者下载。开发者可据此创建所需尺寸的图标。(下载链接:https://developer.apple.com/design/resources/)

    构建贴纸包

    开发者还可将作品转变成适用于 iOS 上“信息”的贴纸包。苹果给出了“构建贴纸包”的详细流程,搜索该链接观看视频(https://developer.apple.com/videos/play/tutorials/building-sticker-packs/)

    升级贴纸包

    升级贴纸包即使用代码和 API 在贴纸包中增加 App 内购买项目等功能。从用户角度来说,iMessage 中贴纸丰富了用户的表达方式,有利于提升用户对 App 的好感。

    而开发者无需编写代码,就能构建贴纸。操作简单,同时也新增了盈利途径,何乐而不为?

    提交审核

    提交 App Store 的所有 iMessage App 和贴纸包都将根据一组技术,内容和设计标准进行审核。为避免产品被拒,开发者在提交 App 以供审核之前,务必确保它符合应用审核指南,并且测试过 iMessage 应用。

    发布日期

    开发者可将发布日期设置为“自动”,以便客户可以在批准后立即下载 App。当然也可以通过自行选择发布日期进行发布。

    展开全文
  • 使用 iMessage 发送随机 GIF 安装 确保安装了 Python 和“请求”库: : 用法 usage: sendgif.py [-h] [-t TAG] to positional arguments: to Phone number or email that supports iMessage. optional ...
  • imessage 发送软件As somewhat of a recluse, believe me when I say that text messages, instant messenger, and iMessage have relieved me of loads of anxiety and wasted time with short, meaningless voice ...

    imessage 发送软件

    As somewhat of a recluse, believe me when I say that text messages, instant messenger, and iMessage have relieved me of loads of anxiety and wasted time with short, meaningless voice chat. It's been a decade since these communication types have become popular so we've moved on from appreciate these technologies to trying to optimize them.

    有点隐士,当我说文本消息,即时通讯程序和iMessage减轻了我的焦虑感,并因短而无意义的语音聊天而浪费时间时,请相信我。 自从这些通信类型开始流行以来已经有十年了,所以我们已经从欣赏这些技术转向尝试对其进行优化。

    My family and friends are deep into the Apple ecosystem so I frequently receive texts via iMessage (or Message on Mac); at the same time, I'm within a Mac terminal much of my day,. At this point, it's a bit of a hardship (poor me!) to even open the Messages app, and I'd prefer to send messages via command line.

    我的家人和朋友深入Apple生态系统,所以我经常通过iMe​​ssage(或Mac上的Message)接收文本; 同时,我大部分时间都在Mac终端中。 在这一点上,即使打开“消息”应用程序也有点困难(可怜!),我更喜欢通过命令行发送消息。

    To send a message via command line, you can type the following:

    要通过命令行发送消息,可以键入以下内容:

    osascript -e 'tell application "Messages" to send "DWB and MooTools FTW!" to buddy "David Walsh"'
    

    I'd recommend creating an alias for this command, which would accept a user and a message.

    我建议为此命令创建一个别名,该别名将接受用户和一条消息。

    Command line wins are amazing time savers. Finding a way to accomplish tasks with your usual workflow will make you infinitely more efficient!

    命令行获胜可节省大量时间。 找到一种用通常的工作流程完成任务的方法,将使您效率更高!

    翻译自: https://davidwalsh.name/how-to-send-an-imessage-from-command-line

    imessage 发送软件

    展开全文
  • iMessage Privacy

    千次阅读 2013-12-30 16:03:34
    come from http://blog.quarkslab.com/imessage-privacy.html ...iMessage is probably one of the most trendy instant messaging systems. Apple presents it as very secure, with high cryptographic standards,


    [come from http://blog.quarkslab.com/imessage-privacy.html]

    iMessage is probably one of the most trendy instant messaging systems. Apple presents it as very secure, with high cryptographic standards, including end-to-end encryption preventing even Apple from reading the messages. Is this true?


    Presentation

    Here you can download our slides of the presentation we gave at HITBSecConf2013:

    http://blog.quarkslab.com/static/resources/2013-10-17_imessage-privacy/slides/iMessage_privacy.pdf

    Quick answers

    • What we are not saying: Apple reads your iMessages.
    • What we are saying: Apple can read your iMessages if they choose to, or if they are required to do so by a government order.

    As Apple claims, there is end-to-end encryption. The weakness is in the key infrastructure as it is controlled by Apple: they can change a key anytime they want, thus read the content of our iMessages.

    Also remember that the content of the message is one thing, but themetadata are also sensitive. And there, you rely on Apple to carryyour messages, thus they have your metadata.

    Now, you can read the article or jump to end of the article where we summarized it.

    1. Instant messaging eavesdropping

    For years now, every time a new instant messaging service has risen,lot of people ask questions about its security. RememberBlackBerry orSkype at the beginning, they claimed to be encrypted thus secure,impossible to eavesdrop. Years later, answers are coming fromeverywhere to deny that[1] [2]. For people working in the securityindustry, this is not a surprise. It is the role of a government toensure security of people, and governments need ways to eavesdropdangerous people. The question is more ethic than legal, and dealswith the power given to intelligence agencies.

    Recently, Snowden's leaks showed it was even worst than what manypeople imagined: crypto standard backdoored, collusion with majorcompanies, massive data collection, intrusion everywhere, ...Despite that context and the legitimacy for government to practicelawful interception, all companies involved tried to minimize theirrole, and used a simple excuse:we just followed the law.However, one company has claimed it was impossible for them toeavesdrop their own instant messaging, and thus they are unable tocollaborate with US government, even if requested to do so.

    After Snowden's leaks, Apple published a statement, called Apple’sCommitment to Customer Privacy. As questions were around for sometime on iMessage, Siri or Facetime, they clearly answered[3]:

    There are certain categories of information which we do not provide tolaw enforcement or any other group because we choose not to retain it.For example, conversations which take place over iMessage and FaceTimeare protected by end-to-end encryption so no one but the sender andreceiver can see or read them.Apple cannot decrypt that data.

    According to that statement, Apple can provide some metadata (whosends a message to who, the date, ...) but the content of aconversation would be excluded.We will show in this article it is not true. Apple can get access toencrypted message, despite end-to-end encryption.Does it mean they do it? Only Apple and some 3 letters agencies cananswer, we can not.

    Now, let's go into the details of our analysis.

    2. Lack of certificate pinning: so what?

    First thing first, we notice than pretty much all the traffic isencrypted. Good point.All communications to Apple's servers are made through a secure SSLtunnel. We do not need to know what protocol is used or how packetsare forged. The first thing we want to try when we see that is addinga certificate to perform a MITM. We were actually very surprised itworked as easily, which means there is no certificate pinning.We created a fake CA, and added it to the iPhone keychain. Then, wecould proxify communications much more easily. When a SSLcommunication arrives to the proxy, we generate a certificate signedby the newly added CA, and everything becomes unencrypted.

    Second surprise was actually bigger: we saw our AppleID and passwordgoing through this SSL communication. Yes, the clear text password...There can be a lot of good reason to send the password as cleartext,ssh does it for instance. But here, we dont see any reason for Appleto get our password.

    Firstly, it means that Apple can replay our password using for instanceour email also on many websites. Ok, Apple has no reason to do so. Butwhat of intelligence agencies?Secondly, it also means that anyone capable of adding a certificateand able to proxify the communications can get user's AppleID andpassword, thus get access to iCloud accounts, backups, buy apps, ....

    Here is an example of what we get:

    POST /WebObjects/VCProfileService.woa/wa/authenticateUser
    'content-length': 223,
    'accept-language': en-us,
    'accept-encoding': gzip,
    'content-encoding': gzip,
    'host': service.ess.apple.com,
    'accept': */*,
    'user-agent': com.apple.invitation-registration [Mac OS X,10.8.3,12D78,Macmini4,1],
    'connection': keep-alive,
    'x-protocol-version': 7,
    'content-type': application/x-apple-plist,
    'x-ds-client-id': t:3A5DC02C47249FC50EF0FF1B8CF3073C9EBD0668

    And here are content of posted data:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>password</key>
        <string>Icandoaproperkeynote</string>
        <key>username</key>
        <string>tim_c@icloud.com</string>
    </dict>
    </plist>
    We tried to play with the certificates for a while. We came up withiPhone Configuration Utility. This software is Apple's solution forenterprise to manage their iPhone. When this software is used for the1st time and a device is plugged, a CA is added to the device. MDMadministrators can do this transparently to enrolled devices

    The consequence is that in a company where iPhones are managed by IT,they want to setup a proxy and invisibly proxify communications from / tothe iPhone, thus gain access to very personal information.Note the certificate pinning is not performed at any layer, PUSH oriMessage, so various problems can happen here and there.

    3. The protocols: the client, PUSH & ESS servers

    In this part, we will describe the usual process, with all theprotocols and cryptographic steps involved.


    3.1 The client on the device

    Each device has its own certificate, which is 1024 RSA with a CN=<PushGUID> (obviously, GUID has to be replaced with device's GUID). Theclient is MobileSMS / Message.app, but this application also relies onother services. The 2 mains are:

    • apsd: the Apple PUSH server daemon, in charge of carrying the messages from Apple to the devices.
    • imagent: the background process for iMessage tasks, like keeping connection when app is closed, etc.

    When a message is sent to someone, Apple is in charge of transportingthe message. It means 2 things:

    • Given a destination address (an URi, it can be a phone number or an email for instance), Apple has a way to link it with all devices related to that URI (iPhones, iPads or OS X systems).
    • Once Apple knows all the devices involved, Apple brings the message to the proper devices.

    Let's start with the second point, the transport protocol, called PUSH.

    3.2 The PUSH protocol

    PUSH protocol [4] has been designed as a remote notification protocol overnetworks. It is used for iMessage of course, but also for FaceTime,GameCenter or by send party application when they want to notify of anevent. Think about Facebook, Whatsapp or any news applicationnotifying you than something just happened. Each time, it is based onthe very same protocol, PUSH.

    Here is how Apple defines it:

    Local and push notifications are great for keeping users informedwith timely and relevant content, whether your app is running inthe background or inactive. Notifications can display a message,play a distinctive sound, or update a badge on your app icon.

    PUSH behaves as a transport protocol, in charge of delivering apayload, whatever it is, to set of devices. Hence, iMessage itself isa payload in regard of the transport protocol.

    All PUSH communications are made in TLS to server port 5223 when itcomes to iMessage:

    • Hostnames are taken from [0, ..., 255]-courier.push.apple.com
    • The client certificate, specific to a device, which is explained right after.

    The client certificate

    The PUSH certificate is generated when the device is registered andactivated at Apple. During the 1st connection to Apple's server, acertificate request is sent toalbert.apple.com. This server runs acertificate authority, called Apple Iphone Device CA, in charge ofsigning every request.

    This certificate is very sensitive as it is the one in charge of ALLPUSH communications from the device: PUSH communications are securedwith it, with both client and server authentication.

    As such, this certificate is not directly involved in iMessage, butsince iMessage is carried over PUSH, it has a role to play anyway.


    The Push-Token

    From the PUSH layer, how it works is kind of magic known only byApple. From client side, here is what we see. First, we write amessage, and press thesend button. Doing so, the client requestsfrom Apple's ESS servers the information needed to send themessage. The ESS Server sends back 3 pieces of information:

    • A Push-Token, which is a unique identifier for a pair iDevice.
    • Two cryptographic keys we will describe right after.

    The Push-Token is computed by Apple when a device registers to theservice. The generation of the Push-Token is defined asopaque byApple since it is made server side, same goes for its preciseusage. For now, we see it as the registration of a provider and arouting information.

    As a provider because one needs to register itself as a iMessage provider,but also as a routing information because Apple needs to know where todeliver the messages. As a matter of fact, Apple fanatics usersoften have more than one device, and a iMessage must be delivered toall the devices at once.

    So, when the client sends one message, it actually sends as manymessages as the recipients has Push-Tokens, so that the message can bedelivered to each iDevice. These messages are sent to theApple PushNetwork Service (APNS) through a gateway on port 5223 as explainedearlier.

    For instance, on a OS X system, one can see:

    root@joker:~>> ps aux |grep apsd
    root 90 0.0 0.1 2467868 8052 ?? Ss Thu09AM 0:06.06 /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
    root 20295 0.0 0.0 2432768 588 s003 S+ 3:08PM 0:00.00 grep apsd
    
    root@joker:~>> lsof -p 90 |grep TCP
    apsd 90 root 9u IPv4 0x667b30bc14a94f93 0t0 TCP joker.lan:65158->17.172.232.179:5223 (ESTABLISHED)
    
    root@joker:~>> whois 17.172.232.179
    NetRange:       17.0.0.0 - 17.255.255.255
    CIDR:           17.0.0.0/8
    OriginAS:
    NetName:        APPLE-WWNET
    NetHandle:      NET-17-0-0-0-1
    Parent:
    NetType:        Direct Assignment
    RegDate:        1990-04-16
    Updated:        2012-04-02
    Ref:            http://whois.arin.net/rest/net/NET-17-0-0-0-1
    OrgName:        Apple Inc.
    OrgId:          APPLEC-1-Z
    Address:        20400 Stevens Creek Blvd., City Center Bldg 3
    City:           Cupertino
    StateProv:      CA
    PostalCode:     95014
    Country:        US
    RegDate:        2009-12-14
    Updated:        2011-03-08
    Ref:            http://whois.arin.net/rest/org/APPLEC-1-Z
    ...

    When the APNS servers receive that, PUSH magic comes into play. Thatis not described in the documentation, but we can assume, reading from[5] that Apple relies on a connection between the APNS and thedevices. Based on the Push-Token for each message, Apple is able toselect to what device a PUSH notification must be sent to.


    MITM at the PUSH layer

    What about attacking that PUSH layer? Attacking it means being inbetween the client and Apple' servers in order to read themessages. But since the communication relies on TLS, some efforts areneeded to provide certificates.

    There is a very convenient tool for that: PushProxy [6].It provides a simple API to mess with both received and sentmessages. Since a lot a prerequisites are needed to perform that on a realcommunication, we will work locally on the device itself for now.

    First, we need to add a root CA to the system's keychain, so thatproxy's certificates are trusted. That way, the real client will trustthe messages from the proxy. This is easy, but we also need tocommunicate with Apple. And as we said, the authentication is mutual,so we need either to inject a new certificate to albert.apple.com, orto use an already signed certificate.

    We pick the 2nd option:we extract the private part of the device's PUSH certificate and give itto the proxy. Last but not least, we need to redirect all connectionsto the proxy, which we did by modifying the/etc/hosts file of thedevice.

    We are now ready to see what is in the PUSH messages. So, the PUSHlayer of an iMessage payload looks like that (XX bytes are not set asthey depends on the content of the message):

    0a                    >> Message Type
    XX XX XX XX           >> Next Length
    04 00 04 XX XX XX XX  >> Identifier (4 bytes)
    01 00 14 XX .. .. XX  >> Topic Hash (20 bytes)
    02 00 20 XX .. .. XX  >> Push-Token (32 bytes)
    03 XX XX ...          >> iMessage payload

    Before going into iMessage payload, we need to give a briefexplanation on iMessage IDs.


    3.3 The iMessage IDs

    From now on, we will refer to iMessage simply as IM.There are a lot of information involved at the IM layer:

    • AppleID: as already explained, that is the very heart of an account for Apple.
    • URI: same format as an AppleID, which is either an email address or a phone number. One AppleID can have several URI. When it is an email, it is verified with a link to click. When it is a phone number, they are authorized only from the SIM card.
    • Push-Token: as explained earlier, it is used for iMessage to identify a device on which an URI is registered. As such, a Push-Token is unique for each URI used on a device.

    3.4 Sending an iMessage

    When a user wants to send an iMessage, he firstly provide one orseveral destination URI. Since the communication is end-to-endencrypted, it means either the devices directly exchange the neededkeys, or there is a key directory involved somewhere.

    There is actually such a directory, called ESS servers (dont ask uswhat ESS stands for, ask Apple). So, to retrieve the keys, the iDevicesends the following request to the server:


    GET /WebObjects/QueryService.woa/wa/query?uri=tel:+33123456789
    'Host': service1.ess.apple.com
    'Content-Type': application/x-apple-plist
    'x-id-cert': [Provision Certificate]
    'x-id-nonce': [Random Nonce with Timestamp]
    'x-id-sig': [Query Signed with Provision Cert.]

    In this example, the iDevice wants to retrieve the keys for URI"+33123456789".

    It is important to notice this request is signed with yet anothercertificate, calledProvision. This certificate is generatedclient-side, and signed by the authority calledApple IDS DS-ID RealmCA during iMessage authentication. It is valid for one month.

    The corresponding answer looks like:

    {
      'push-token': [PushToken]
      'client-data':
      {
        'show-peer-errors': True,
        'public-message-identity-version': 1.0,
        'public-message-identity-key': [Public Keys Buffer]
      }
    }


    It is actually a XML plist. We converted it to JSON to make it morereadable.In our example, there is only one identity returned. However, if thedestination URI have several devices and registered accounts under hisAppleID, the same information would be given for each of them.

    The answer contains the Push-Token, well-known now. But it alsocarries a buffer full of public keys:

    • One ECDSA (256-bit) used to verify the signature of messages sent by the destination URI on this device. That way, when the destination URI replies, we'll already have the ECDSA key to check the signature.
    • One RSA (1280-bit) used to encrypt iMessage sent to the destination URI.

    With both these keys, we can setup a secured (?) communication withthe destination URI, and all the related devices.


    3.5 The iMessage Payload

    We finish our explanation of the PUSH protocol by providing aniMessage payload. Now, we will see what this payload is made of.

    This payload is in an Apple specific format, called bplist(binary-plist). It is designed to embed serialized data asdictionary. Several kinds of data are defined, including the usualones:NSString, NSNumber, NSDate, NSArray, NSData andNSDictionnary,and so on.

    Here is an example of such a bplist:

    D:   True
    E:   'pair'
    P:   <variable length binary data> (iMessage payload, deflate compressed)
    U:   <128bit binary data> (iMessage UID)
    c:   100
    i:   <32bit integer> (messageId, same as in PUSH header)
    sP:  mailto:tim_c@icloud.com  (sender URI)
    t:   <256bit binary data> (sender Push-Token)
    tP:  mailto:mark_z@facebook.com (receiver URI)
    ua:  [Mac OS X,10.8.5,12F37,MacBookPro10,2] (sender OS and hardware version)
    v:   1

    The ua field is totally useless but is sent on every request, forApple statistics?

    Anyway, the P field is the IM payload. It is encrypted then compressed(yes, yes, encrypted first, compressed after). It is composed withthe following keys:

    (byte)     0x02          version?
    (short)    ciphertext    length
    (data)     ciphertext    RSA / AES-CTR data : ciphered with the RSA public key of the recipient
    (byte)     signature     length
    (data)     signature     ECDSA signature of <ciphertext> : computed with the ECDSA private key of the emitter
    In cleartext, the data is also a bplist, which we called innerbplist:

    p: array of URIs in the discussion group
    t: iMessage text (for iOS)
    v: version (1)
    x: iMessage html (attachments, and style - for OS X)

    Let's spend some lines on the RSA / AES-CTR data. This data is theactual message sent to the target (the URIs, the message itself,attachment if any). Let us describe how it is built:

    1. Let's call ibplist the cleartext data.
    2. A 16 random byte are generated to be the AES key.
    3. The data is encrypted with AES in CTR mode, giving AES(ibplist)
    4. The 128-bit key is put at the beginning of the output buffer

    5. The 128-bit key and 808-bit of AES encrypted data are ciphered withRSA-1280 using a public exponent of 65537 and PKCS1 OAEPpadding. It gives a 1280-bit buffer

    1. That buffer is then signed with the owner's ECDSA key.

    The RSA key used here is the one retrieved from ESS server, asmentioned above.


    Sending attachment with iMessage

    As most instant messaging service, iMessage allows to sendattachment. Most of the time, people are sending picture from theiriPhone. But any kind of file can actually be used.

    When an attachment is sent, it is actually stored on iCloud servers,on a dedicated repository. The attachment is encrypted with AES, andthe key is sent to the destination as payload in the iMessage,altogether with the link to the file. Since this is encrypted with thedestination RSA key, this is as safe as the RSA key itself.

    All this is performed with the <FILE> in the HTML message

    <file
       name="<name>"
       width="<width>"
       height="<height>"
       datasize="<size>"
       mime-type="<mime type>"
       uti-type="<uti type>"
       mmcs-owner="<identifier>"
       mmcs-url="<URL>"
       mmcs-signature-hex="<signature>"
       file-size="<size>"
       decryption-key="<key>"
    />
    

    Note that it seems to be OS X specific.


    Easter eggs or tricks

    • Adding a subject: there is an option to add a subject to the iMessage in the configuration panel. This is triggered with thes key and a text to the inner plist.
    • For IRC geeks, /me is working ... only on OS X. Send a message starting with "/me" and it will be displayed differently on OS X and iOS.
    • The existence of a URI is not verified in the discussion group, which means you can add fake URI. Of course, a real URI has to be in the list but you can then make believe to the destination you actually send an iMessage to Tom Cook for instance.

    4. MITM attacks

    iMessage is complex because it relies on PUSH and a lot of crypto isinvolved at all layers. In this section, we will study what are theconditions to perform a MITM attack on iMessage, now that we hopefullymade the protocol lessopaque.

    In order to do that, we will set an attacker in various positions:between the sender and Apple, between Apple and the receiver. If youwant a quick and dirty overview, you might want to have a look at ouroriginal paperwork describing the MITM.

    4.1 Test protocol

    As we have seen, the 2 main services for iMessage are the PUSH serversand the ESS ones. So, in order to perform any attack, we need toimpersonate these servers.There are lots of ways to do that, from ARP spoofing to injecting BGProutes (if you can), but we simply keep playing with /etc/hosts, asfor the PUSH proxy earlier.

    Here are the tools we used:

    • Python to be able to run following tools
    • PushProxy with Quarkslab’s imessage-mitm.py handler to intercept iMessages
    • Quarkslab’s ess-mitm.py to intercept and modify Apple ESS responses
    • A DNS proxy software. We used dnschef.

    From the crypto point of view, we added a root CA to the targetkeychain so that we are able to serve our own certificates with nocomplaint from the iDevice.

    From there, we have all our tools running locally, we are ready.


    4.2 One-sided MITM

    Here, the attacker is between the sender and Apple's server, onsender's iDevice. Let's call the senderDhillon, and the receiverBelinda. We will explain step by step how it is going on. An evil guycalledEvil, is in the middle.

    First, let's start with the emission of a message:

    1. Dhillon writes a message to Belinda.
    2. Dhillon's iDevice makes a request to ess.apple.com
    3. Evil intercepts that request:
    1. Evil requests from ess.apple.com Belinda's information (Push-Token, RSA and ECDSA keys)
    2. Evil replaces Bel's RSA and ECDSA keys with his own
    1. Dhillon sends his message to Belinda: it is encrypted with assumedBel's RSA (Evil's actually) key, signed with Dhillon's ECDSA key.
    2. Evil intercepts the IM payload:
    1. He can decrypt it with his own key
    2. He can alter it and recipher it with Belinda's real RSA key
    3. Since he is on the device, he can use Dhillon's ECDSA private key to re-sign the message.
    1. Belinda gets the message, it is properly signed and she can read it.

    As everyone can notice, a very strong requirement here is that theattacker, Evil, gets access to sender's ECDSA private key.

    Let's see now what is happening when Belinda is answering to themessage:

    1. Belinda writes a message.It is ciphered with Dhillon's RSA key, and signed withBelinda ECDSA key.
    2. The message is sent to Apple Push servers, then to Dhillon's mobile
    3. Evil intercepts that message:
    1. Evil can decrypt the message as he has access to Dhillon's RSA private key.
    2. Evil can change the message, and recipher with with Dhillon's RSA public key.
    3. Evil signs the modified message with his own ECDSA key as Dhillon's believe it is Bel's (see step 3.2 in the previous description).
    1. Dhillon receives the forged message:
    1. He checks the signature with Evil's ECDSA key (believing it isBel's): everything is fine.
    2. He decipher the message with his own private RSA key.
    Once again, in reception, there is a strong requirement: the attacker,Evil, needs to get access to the RSA private key

    4.3 Two-sided MITM

    Now, we are thinking big: we want to perform a MITM on Dhillon andBelinda at the same time. So, we assume now thatEvil is running hisMITM on both Dhillon's and Belinda's iDevice.

    As example, Dhillon is sending a message to Belinda:

    1. Dhillon writes a message to Belinda.
    2. Dhillon's iDevice makes a request to ess.apple.com
    3. Evil intercepts that request:
    1. Evil requests from ess.apple.com Belinda's information (Push-Token, RSA and ECDSA keys)
    2. Evil replaces Bel's RSA and ECDSA keys with his own.
    1. Dhillon sends his message to Belinda: it is encrypted with assumedBel's RSA (Evil's actually) key, signed with Dhillon's ECDSA key.
    2. Evil intercepts the IM payload:
    1. He can decrypt it with his own key
    2. He can alter it and recipher it with his own key.
    3. He signs with his own key too.
    1. The message is sent to APSN and delivered to Belinda's device.

    Since Evil is now on both side, things are symmetric here, so let's go:

    1. Evil receives the message on Bel's iDevice.
    2. Evil deciphers the payload with his own RSA private key.
    3. Evil encrypts the message with Bel's RSA public key.
    4. Evil signs the encrypted message with his own ECDSA key, since he provided this key toBelinda presenting it as Dhillon's.
    5. Evil delivers the message to Belinda
    6. Belinda checks the signature, which is ok and appears to be fromDhillon (since it has been signed with Evil's key, which isDhillon's ECDSA alleged key).
    7. Belinda deciphers the message.

    The main requirement here is for Evil to be, at the same time, inbetweenDhillon and Apple on on end, and Belinda and Apple at theother end. Still a strong requirement for most attackers, but we didn't needusers' private keys anymore!

    4.4 MITM by replacing Apple

    Let us perform an excise assuming an attacker is able to replace Appleto perform the MITM. This assume huge requirements:

    • Huge network control to redirect the traffic of the iDevice (through DNS or whatever).
    • Verified PUSH and ESS certificates, for each target.

    Clearly, not the many people have such capabilities. Maybe 3 lettersagencies... Who knows.

    How would it work? Like a classical MITM:

    1. Evil gives his RSA and ECDSA to Dhillon
    2. Evil gives his RSA and ECDSA to Belinda
    3. When Dhillon sends a message, Evil can read it, change it and resign it before passing it toBelinda
    4. When Belinda receives it, she deciphers the message with her RSA key, and check the signature withEvil's ECDSA key, even through she believes it is Dhillon's.

    Since, Evil is really in the middle, things are the same whenBelindaanswers to Dhillon:

    So, what are the requirements here:

    1. For that to work, he needs a valid CA in the devices of the targets.
    2. The attacker needs to redirect the traffic from both targets to himself.
    3. He needs to provide keys to each target impersonating the other end of the communication.

    Obviously, this attack is not realistic for the average attacker.


    4.5 MITM being Apple, or why end-to-end encryption is not enough

    Actually, not all attackers can fulfill the above requirements. Butnow, let's have a look at Apple's position there:

    1. For that to work, he needs a valid CA in the devices of the targets.

      > Apple has such a certificate.

    2. The attacker needs to redirect the traffic from both targets to himself.

      > Apple does not need to do that since all traffic is going anyway through the PUSH server.

    3. He needs to provide keys to each target impersonating the other end of the communication.

      > Apple owns the key server, ESS.

    So, definitely, Apple can perform the MITM, they just have to tamperwith the keys the send to the targets. Then, you remember howiMessages are encrypted: a RSA key encrypts an AES key.

    Since Apple can change the keys, Apple can then decrypt the AES key,and as a consequence, the content of the message.

    Remember Apple's statement:

    For example, conversations which take place over iMessage and FaceTimeare protected by end-to-end encryption so no one but the sender andreceiver can see or read them.Apple cannot decrypt that data.

    So, yes, there is end-to-end encryption as Apple claims, but the keyinfrastructure is not trustworthy, so Apple can decrypt your data, ifthey want, or more probably if they are ordered to.


    5. Preventing MITM from Apple or others

    There are actually not that many solutions. The main problem herecomes from Apple as they control the key infrastructure. So, the 2solutions are:

    1. Make the key infrastructure less opaque and more public
    2. Encrypt message with key not controlled by Apple.

    These 2 solutions are under active development. Stay tuned for moreinformation.


    5.1 iMITMProtect

    We have developed a simple Mac OS X application, iMITMProtectwhich hooks some functions involved on iMessage. The application isvery simple / stupid:

    • When Push-Tokens and keys are received, they are stored in a local database.
    • Each time a token or a key is received, we look up for the corresponding URI in the database, and check it is the same or not. If not, Houston, we have a problem.

    As soon as a jailbreak will be available, we will port it as a Cydiapackage.


    5.2 iMessage over-encryption

    If one considers iMessage as an insecure channel, the solution is toencrypt the data sent to that channel. Setting up such an encryptionis not easy, even without considering theGeneral Conditions of Use.

    We cant say more on that now, except it is tricky!


    6. Last words

    Apple's claim that they cant read end-to-end encrypted iMessage isdefinitely not true. As everyone suspected: yes they can!

    Suspecting is not knowing, and we hope to have dig enough in theprotocol to show how Apple could do it.

    But shall we continue to use iMessage? MITM attacks on iMessage areunpractical to the average hacker, and the privacy of iMessage is goodenough for the average user.

    If the informations being exchanged are sensitive to the point thatyou don’t want any government agencies to look into them, don’t.

    Apple, make a more transparent PKI and document the protocol, and itcould be considered the most practical and secure real-time messagingsystem available.


    Can Apple read your iMessages? A fast answer.

    Yes.

    You should skip this part if you dont want to spoil the details. Ifyou are in a hurry and just want the answers, this part is for you.We have analyzed iMessage, Apple's instant messaging service,wondering: how to eavesdrop iMessage.

    Here are the facts:

    • Involved cryptography is based on well-known algorithms (AES, RSA, ECDSA) with proper key sizes and implementation.
    • Code in charge of key generation is open source.
    • No certificate pinning is performed between client and PUSH servers (Apple's servers involved in iMessage).
    • Authentication between client and Apple's servers is protected with strong obfuscation and whitebox cryptography, preventing the development of 3rd party iMessage clients.
    • User password is sent clear-text through a secure SSL channel to Apple. This is clearly an issue for people using the same password at several places (mail, bank, whatever) as Apple knows this password.
    • No pinning + cleartext password means that if somebody manages to add a certificate in a device, he can perform a MITM, thus get the user's AppleID and password. That is the key to everything belonging to the user.
    • Bonus: if the device is connected to iPhone Configuration Utility, Apple's enterprise solution for management of iPhones, a trusted CA is added. Consequence is that all subsequent certificates signed by that CA will be trusted to create the SSL communication. It means all companies using that are able to retrieve their employee's AppleID and password by simply proxifying the SSL communication.
    • iMessage is carried over Push protocol, the very same protocol used but FaceTime, GameCenter or notification services.
    • PUSH is tunneled inside SSL to Apple's PUSH servers on port 5223.
    • Every Apple device is identified by a unique Push-Token.
    • When someone sends one message, the client looks for all Push-Tokens related to that destination (called an URI) to transport the message to every device where the URI is registered.
    • When one sends an iMessage, the client firstly connects to an Apple key server, called ESS, to get the target public keys.
    • The clients retrieves 2 keys:
    • One ECDSA (256-bit) used to verify the signature of messages sent by the destination URI on this device. That way, when the destination URI replies, we'll already have the ECDSA key to check the signature.
    • One RSA (1280-bit) used to encrypt iMessage sent to the destination URI.
    • The iMessage payload is actually a binary plist, designed to embed serialized data as dictionary.
    • The iMessage payload is encrypted with a random AES key, the key is appended at the beginning of the encrypted payload, the 1280 first bits are encrypted with destination RSA key.

    • Every message is signed with sender ECDSA key.
    • iMessage can be used to send attachment. They are stored on iCloud, encrypted with an AES session key as explained above.
    • Since Apple controls ESS servers, and all iMessages are routed to Apple's PUSH servers, Apple is able to perform MITM:
    • Apple sends fake public RSA / ECDSA key to the sender
    • Apple can then decipher, alter the payload of the message and sign it before sending to its final destination.
    • So, yes, there is end-to-end encryption as Apple claims, but the weakness is in the key infrastructure as it is controlled by Apple: they can change a key anytime they want, thus read the content of our iMessages.

    References

    [1] http://www.wired.co.uk/news/archive/2013-07/11/blackberry-inda
    [2] http://www.washingtonpost.com/business/economy/skype-makes-chats-and-user-data-more-available-to-police/2012/07/25/gJQAobI39W_story.html
    [3] https://www.apple.com/apples-commitment-to-customer-privacy/
    [4] https://developer.apple.com/notifications/
    [5] https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9
    [6] https://github.com/meeee/pushproxy



    展开全文
  • imessageIf you use iMessage, you’ve probably been roped into a group chat or two. It can often become confusing, so what can you do if you have a number of them going at once andcan’t tell them ...
  • iMessage 对话从 Mac 上的本地数据库导出到可读 JSON 文件的节点脚本。 用法:克隆 repo npm install . 编辑index.js的phone index.js node index.js
  • IMessage/400-开源

    2021-07-05 02:34:04
    iMessage400 是一个高速通信库,用于连接 AS400/iSeries ILE RPG 应用程序和基于 Java 的富客户端。 功能包括异步通信、实时更新、缓存和连接预缓存。
  • 客户端,以便在Android上提供iMessage的完全开源的实现! 特征 获取和发送消息 交货状态/读取状态 小组聊天! 这包括已命名和未命名的iMessage群组聊天(即,“人1”,“人2”,“人3”和“寿司大队”) 加载任何...
  • imessage 发送软件You’ve always been able to send static images to other people through iMessage, but you might not have known that you can also send animated GIFs as well. 您始终能够通过iMe​​ssage...
  • 使用Mac电脑的时候,Mac系统支持iMessage信息功能,如果打开开启以后,可以与其它设备相互收发iMessage信息。但是有的用户可能不喜欢在Mac上接收iMessage消息,那么下面就简单介绍下怎么关闭iMessage信息的方法。 ...
  • imessageThe app system in iMessage is really cool, letting you paste content directly into messages that once required several additional steps. If you’re choosy about which apps appear in iMessage, ...
  • 该源码是一个仿iOS8 iMessage图片选择器,源码BRNImagePickerSheet,BRNImagePickerSheet是一款模仿iOS8 Is iMessage的图片选择器。在选项列表视图中可以滚动显示待选图片。
  • 使用imessage推广Not only was iMessage the most heavily updated app in the iOS 10 release, but it got more than just a facelift. Now, tucked away in iMessage, is a whole app ecosystem just waiting for ...
  • 如果您是桌面上的OSX IMESSage UI和布局的粉丝,则此Chrome扩展名为Android消息Web 客户一个imessage主题。 将消息添加到桌面作为Chrome应用程序时甚至兼容! (为主题留下黑暗模式以正常工作) 必需的: Web ...
  • imessageApple’s iMessage is one of the most popular messaging platforms around, and it’s a great way for Apple to lock people into its ecosystem. As great as iMessage is, there may still be times ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,923
精华内容 2,769
关键字:

imessage