来自法国的移动开发商 Applidium 之前成功对 iPhone 4S 与 Siri 服务器的通讯协议进行了反向工程。之后他们发布了一些简要的通讯协议方面的技术解答，并展示了一些使用 Siri 的语音到文本转换的范例代码。

根据他们的研究，Siri 的语音识别工作其实并不是在iPhone 上完成，而是在苹果的服务器上进行的。也就是说，理论上可以让 Siri 识别来自任何设备的音频。用户使用 iPhone 4S 对 Siri 说话时，手机只是将音频录制下来，并通过 Speex 编码器进行压缩，然后通过一个特殊的 HTTP 请求把音频等信息打包传送给苹果服务器。随后服务器会返回一个经过 zlib 压缩的 plist 二进制文件，其中包含的就是答复数据。

Applidium 开发者们上手的途径比较简单，就是在本地网络中截取 Siri 从 iPhone 发送到服务器的数据，并进行分析。他们建立了一个假冒的 DNS 服务器，以此让 Siri 把请求发送到自己的服务器上。请求是经过 SSL 加密的，不过他们在 iPhone 中加载了他们自己的 SSL 根证书，这样便可以使用自己的服务器进行分析了。

在他们的服务器上，运行着一个非常简单的 HTTP 代.理脚本（用 Ruby 编写），能够将发送到苹果服务器的请求进行延迟，同时将输入和输出结果 echo 到 stdout 中，这样就能知道两边都在发送什么数据了。由于需要造出一个自定的 Siri 请求，他们首先要搞清楚信息格式。实际发送的请求比较特殊，并且包含和 HTTP 标准不一致的特征。苹果使用的是一种被称作 ACE 的 HTTP 请求方法，这种方法可以使用任意长度的数值内容，包含一个自定的用户代理字符串，将自己的身份定义为 Assistant。

请求的 header 部分也比较特殊，里面含有设备的唯一身份识别信息。 Applidium 的研究者发现，header 中必须含有合法的唯一身份识别信息，否则服务器不会处理此请求，因为目前服务器只接受来自 iPhone 4S 的请求。这对开发第三方 Siri 应用而言是个极大的挑战。

换句话说，任何 Siri 客户端在发送请求时都必须含有真实的 iPhone 4S 身份识别信息。而一旦开发者将某个 iPhone 4S 身份识别信息放到他开发的应用中并广泛传播，苹果很可能会屏蔽掉该身份识别信息，以此禁用那款应用。

现在还无法知晓苹果会如何对待未授权的第三方 Siri 客户端，我们怀疑会很快将它们拖进黑名单。在苹果这边来看，如果突然出现大量计划之外的设备来使用 Siri 无疑会加重服务器的负担，而在尚未准备扩展服务器之前，这将影响 iPhone 4S 用户的使用体验。

因此我们可以进一步推断，苹果目前只允许 iPhone 4S 使用 Siri 的原因并不是硬件限制。所以理论上今后是有可能在老款 iPhone 上看到 Siri 的。

除了设备身份识别方面的数据之外（每台 iPhone 4S 仅有一个身份），个人开发者们可以自由使用 Applidium 的研究成果，开发自己的应用，前提是苹果不修改 Siri 的通讯协议。在之后的探索中，有可能发掘出更多 Siri 的功能，不仅限于语音到文本的识别。 Applidium 无私奉献出的代码让上手变得简单了许多，虽说代码大部分还没有进行归档整理，不过已经很好懂了。

他们公布的范例 Siri 客户端代码是用 Ruby 写的。同时也提供了非常简单的命令行工具代码，来使用 Speex 库生成压缩音频数据，以便传送给苹果服务器。所有范例代码已经上传到了 GitHub。