我们很高兴今天推出 Reincubate Lookup。它回答了用户一直在问的一个问题：给定 Apple 设备的序列号或 IMEI，我们能否精确识别这台设备及其具备的能力？
- 在 eBay 上购买 iPhone 或 iPad 时，用户可能想确认设备规格（尤其是设备的机龄和存储容量）。有了商品信息中的序列号或 IMEI，就能确认规格，甚至确认这台设备出厂时是否被锁定。这是一个序列号查询示例，查询的是一台以运营商锁定状态出售的设备。
- 开发者经常需要在特定版本的 iOS 上测试自己的应用。想找到运行旧版 iOS 的二手设备，简直如同沙里淘金，但我们能够识别设备出厂时搭载的版本，从而排除一大批商品信息。
- 负责管理大批设备的系统管理员，从 MDM 工具中只能获得有限的规格和设备数据。企业和机构已经在使用 Reincubate Lookup 背后的技术来丰富他们的设备库存数据。
Reincubate Lookup，随时可以查询 Apple 序列号或 IMEI
过去一年里，客户和用户向我们的 API 发送了超过 1300 万次设备信息请求，这促使我们更进一步地深入。
Reincubate Lookup 的承诺很简单：给定 Apple 序列号或 IMEI，它就会提供准确、合乎道德且用户友好的数据。这个承诺的每一部分对我们都有特殊意义，每一部分之所以重要也都有一段故事。让我们来看一看。
用户友好
了解移动设备时，行话术语比比皆是，因此我们花了不少时间思考，如何以最合适的方式对它显示的信息进行排序、呈现和标注。有些数据点可能对部分技术用户有价值，但可能会让其他人感到困惑，我们没有展示这些数据点。
设备数据很有价值，而消费者又难以判断其可靠性，于是出现了许多提供这类数据的服务，并设置了一系列令人头疼、体验糟糕的机制来防止他人抓取数据。我们选择不使用恼人的验证码系统，并将 Lookup 打造得极其快速，无需任何中间加载页面。
奇怪的是，尽管这是关于移动设备的数据，类似的服务却很少有在手机或平板上也运行良好的界面。我们想要的是对移动端友好、对国际用户也友好的产品。
我希望我们把 Reincubate Lookup 的无障碍体验做得不错。它在 iPhone 和 iPad 上经过了大量测试，我们认为它的外观相当出色。它原生支持深色模式，会切换配色以减轻眼睛的疲劳。它不会要求你输入验证码，并提供 11 种语言版本。
Reincubate Lookup 的深色模式
准确
自 2017 年开始构建我们的设备标识符 API以来（并在去年夏天为 iPhone Backup Extractor 推出了对丰富设备元数据的支持），我们对这些数据有了许多认识，也发现了一些想要解决的难题。
我们最早了解到的一点是，坦率地说，Apple 标识符背后的数据有些混乱。Apple 自己也没有统一的标准型号标识符，内部命名也不一致。在某些情况下（说的就是你，iPhone 3G），同样的 ID 甚至会被不同的产品重复使用。
我曾在愉快的 WWDC 期间，希望从 Apple 的工程师和经理那里看到内部一致性的迹象，但就连他们也对此表示无奈。此外，Apple 关于型号识别的文档并不一致，几乎每一种标识符（主要有 12 种）都曾在他们的文档中的某处被称为“型号”。
Apple 使用的标识符也在随时间变化。序列号有三种不同的格式（很快会变成四种），UDID 有两种不同的格式。系列号过去一直以“M”开头，现在只以“A”开头，而一些 MPN 现在反而以“M”开头。诸如此类，不胜枚举。
网上已有不少查询工具，但稍加挖掘就能发现其中的错误数据。这通常是结构性的：这些工具（如 Everymac 的工具）是基于对标识符数据之间看似成立的关系的观察，直到某一天这些关系不再成立。有些工具掌握的数据足以识别这一点，因此查询会得到一系列可能的结果，而不是唯一明确的结果。另一些工具提供的数据看起来差不多对……但其实并不对。
结构性的数据问题并不是唯一的问题。许多此类系统的数据来源本身就有缺陷，它们依赖于抓取 Apple 的 GSX 服务、技术人员录入，或者（最糟糕的是）网上随便哪个疯子的数据录入。
为了把这件事做对，我们希望满足三项约束：
- 系统必须尽可能多地自动、独立地学习，因为任何需要定期录入、编辑或审核数据的做法，都会迅速过时。
We needed... a learning computer - 系统不得依赖未经授权或不可靠的数据。iPhone Wiki 有一些数据（我们也贡献了不少），但并不规范，也不完全准确。Apple 的 GSX API 也有一些数据，但同样不规范，其中一些数据还有非常奇怪的问题，并且也未获授权以这种方式使用。
- 系统产出的数据和结果必须是我们完全有把握的，而不是经常正确。因此，当无法给出唯一答案，或者答案的可能性很低时，系统必须明确说明。
合乎道德
不过，准确性并不是唯一的约束。我们很快就发现了业内这些数据的部分来源：由一批员工组成的网络，受雇秘密复制（窃取！）内部数据库中的数据。
在我们想出让 Reincubate Lookup 运转起来的办法之前，IMEI 数据实际上只有三个来源：
- 抓取 Apple 的 GSX API。这违反了 Apple 的条款，会导致 API 访问权限被撤销。有一个小行业专门转售 GSX 账户的访问权限，用坏了再设法获取新的。这行不通。
- 获取 GSMA 的 IMEI 数据库的授权。这个移动行业的行业协会掌握着所有 IMEI 信息的权威登记库，并对其类型分配码（TAC）数据库授权使用，这些数据库有助于识别设备。虽然这听起来很理想，但实际情况要复杂得多，而且该组织自己也只声称其“GSMA Device Map”数据有 95% 的准确率。更何况，其数据库并未为所收录的设备提供规范化的标识符。对它进行 TAC 查询，可能只会告诉你这台设备是 iPhone XS，这样的信息谈不上精细。
该组织似乎与它所代表的移动设备制造商在某种程度上处于对立状态：它一方面开展维护 IMEI 完整性的项目，另一方面又指出“the GSMA does not have the responsibility or powers to stop illegal TAC and IMEI activity”。这类数据登记错误相当常见，以至于他们大力推广其“不合规 TAC / IMEI 报告流程”。
实际上，这意味着需要考虑两套数据：一套是 GSMA 的、由厂商自行申报的数据，不完整也不准确，但至少理论上是准确的；另一套是通过检查移动设备建立起来的、准确且规范化的真实世界数据。我们不得不自己构建了一个包含 3,000 个 Apple 设备 TAC 的数据库，它比 GSMA 的更全面、更实用。 - 贿赂电信运营商的员工，让他们充当“数据间谍”。这与美国移动运营商向赏金猎人和疯子出售消费者位置数据的做法一样可憎，非法的“iCloud 解锁”服务用的也是同样的手段。
一些 IMEI 服务对此相当明目张胆地大肆宣传。我们在一家英国服务商的网站上发现了这则广告：
可疑的解锁服务是如何运作的
既然我们不打算采用上述任何一种方式，就必须另辟蹊径来获取所需数据：不用间谍，不用 GSX，不搞见不得人的手段。
答案本质上在于分析海量数据，理解这些数据之间的关联，并将其提炼为一组会随时间自动更新的事实。其中一部分数据是设备本身固有的，另一部分则可以通过分析经过匿名处理的数据查询推导出来。如果有足够多的查询形如“这台设备是 A 和 B，那它是否也是 C？”，我们就可以开始理解 A 和 B 是相关的。这与驱动我们 awdit 产品的技术如出一辙：有时只要看足够多的问题，就能生成答案。
当数据库中的查询量达到约 500 万次时，这种分析对几乎任何设备都开始奏效。如果数据不足以回答某个问题，Reincubate Lookup 会建议你用 iPhone Backup Extractor 看一看。它足够智能，能够深入挖掘，并把这个问题反馈给我们。
截至今天，我们已识别出近 9,000 个配置代码，涉及 2,350 个型号、127 个不同的生产工厂、304 个不同的分销地区，以及 3,000 多个 IMEI 类型分配码。
这就是我们构建 Reincubate Lookup 的来龙去脉，也是我们在构建过程中重视用户友好、准确和合乎道德的原因。希望你喜欢它，也希望它能为你带来价值。如果你想更深入地了解，Lookup 的所有数据都来自我们的 DeviceIdentifier API，我们很乐意看到大家基于它构建各种应用。
欢迎常联系：请告诉我们你的使用体验。
