来自法国的移动开发商Applidium之前成功对iPhone4S与Siri服务器的通讯协议进行了反向工程。之后他们发布了一些简要的通讯协议方面的技术解答，并展示了一些使用Siri的语音到文本转换的范例代码。
根据他们的研究，Siri的语音识别工作其实并不是在iPhone上完成，而是在苹果的服务器上进行的。也就是说，理论上可以让Siri识别来自任何设备的音频。用户使用iPhone4S对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中必须含有合法的唯一身份识别信息，否则服务器不会处理此请求，因为目前服务器只接受来自iPhone4S的请求。这对开发第三方Siri应用而言是个极大的挑战。
换句话说，任何Siri客户端在发送请求时都必须含有真实的iPhone4S身份识别信息。而一旦开发者将某个iPhone4S身份识别信息放到他开发的应用中并广泛传播，苹果很可能会屏蔽掉该身份识别信息，以此禁用那款应用。
现在还无法知晓苹果会如何对待未授权的第三方Siri客户端，我们怀疑会很快将它们拖进黑名单。在苹果这边来看，如果突然出现大量计划之外的设备来使用Siri无疑会加重服务器的负担，而在尚未准备扩展服务器之前，这将影响iPhone4S用户的使用体验。
因此我们可以进一步推断，苹果目前只允许iPhone4S使用Siri的原因并不是硬件限制。所以理论上今后是有可能在老款iPhone上看到Siri的。
除了设备身份识别方面的数据之外（每台iPhone4S仅有一个身份），个人开发者们可以自由使用Applidium的研究成果，开发自己的应用，前提是苹果不修改Siri的通讯协议。在之后的探索中，有可能发掘出更多Siri的功能，不仅限于语音到文本的识别。 Applidium无私奉献出的代码让上手变得简单了许多，虽说代码大部分还没有进行归档整理，不过已经很好懂了。
他们公布的范例Siri客户端代码是用Ruby写的。同时也提供了非常简单的命令行工具代码，来使用Speex库生成压缩音频数据，以便传送给苹果服务器。所有范例代码已经上传到了GitHub。
