趣头条反作弊技术演进与思考

趣头条安全团队简介：负责趣头条所有业务线业务安全和基础安全，自主研发设备指纹、实时风控、风险识别等反作弊系统，以及WAF、漏洞平台、白盒扫描等基础安全平台，负责公司合规安全、网络安全、系统安全、数据安全和业务安全等。

趣头条App自发布以来，一直受到黑产和散户的不断攻击，反作弊在与黑产一次次对抗中，逐渐吸取经验教训，形成了符合自己业务特色的反作弊技术体系。本文将从实用性角度简要介绍一下趣头条反作弊的技术架构和SDK部分细节。

反作弊SDK

为什么要开发反作弊SDK？

第一，与业务解耦。很多公司的反作弊，是没有自己收集数据的，依赖业务数据来做分析，这样固然也能做反作弊，但业务数据量大，设备信息不全，用户行为繁多，数据格式无法统一，更有甚者，业务字段的变化可能完全不会通知反作弊团队，会导致策略失效。有了独立于业务的反作弊SDK后，不仅数据格式统一了，新增功能发版也更自由了，策略可控易维护。

第二，获取真实可信的设备环境。业务数据一般会直接调用系统接口取设备环境参数，但这些参数非常容易被Hook篡改，有大量专门的改机工具可以修改系统参数，所以要保护好系统参数，就要识别出这层修改，或绕过，或用其他办法来获取真实可信的设备环境数据，这就需要有独立的专业SDK。

第三，设备指纹。有了自己的SDK，就可以做唯一的设备识别了。在移动领域，不限于移动安全，设备指纹有着极其重要的地位，不仅用于反作弊，还用于业务数据统计和产品策略制定（如单一设备只能参加一次活动），还用于广告投放，渠道拉新等等。

很庆幸，我们一开始就走对了方向，坚持开发自己的反作弊SDK，经过数轮迭代，目前已经非常稳定，内部数十个App已经接入反作弊SDK，也就是说每出一个新App，首先需要接入的就是反作弊SDK。

在SDK防护方面，我们也做了相当多的工作，在保证兼容性的前提下，尽可能做到安全，提高被破解的门槛和风险。

首先，我们自定义了一套数据编码格式，即非JSON，也非Protobuf，兼顾了安全和编码效率，编码后的数据再经过压缩，变成更加紧凑的二进制。

其次，我们设计了自己的加密算法和签名算法，并用C实现，且做了混淆和加固。抓包拿到的报文，经过编码压缩加密后，是二进制，企图通过猜测碰撞的办法来破解加密算法，几乎是不可能的。

然后，核心参数，我们会在C层也获取一次，并和Java层相互校验，如果缺失C层参数或C层和Java层不匹配，那么就有理由怀疑用户使用了改机软件或非真实设备。

最后，我们会检测调试，调试状态下返回的报文和正常报文有差异。

当然SDK防护不限于此，总之，在多个点上安插我们的防护代码，加强SDK自身安全，提高门槛，并且做到风险可感知。

反作弊SDK完成了两项重要任务：

1. 结合服务端算法生成设备指纹和tuid（下文有详细介绍），依靠SDK对客户端环境很强的感知能力，加上强大的服务端算法，设备指纹的可以达到很高的准确度。
2. 上报客户端环境参数，我们采集的参数偏向于显性的，例如开机时间、音量、光感等等，是符合国家安全合规要求的，部分参数只有在用户同意的情况下，才会获取，而且单次回话中不会大量重复获取，依靠这些看似不起眼的参数，我们可以做很多策略来识别虚假设备，例如模拟器、越狱、参数聚集等等。

以模拟器为例，通过校验各种参数，我们开发了30多种识别模拟器的策略，严谨而准确。众所周知的，模拟器一般的CPU架构不是 ARM，而是 Intel 或 x86，通过这一特征，可以大幅缩小模拟器的识别范围，但有些手机CPU架构确实是x86，所以要结合其他参数来辅助判断。市面上大多模拟器，都有自己的一些特征，某些参数无法修改，或者一般用户不知道怎么修改，那么可以通过这些特征轻而易举地识别出这类模拟器，例如蓝叠模拟器的Wifi名字可能就叫BlueStacks。大多数模拟器，都有自己独特文件或进程特征，这些不易被篡改，识别准确度也很高，例如雷电模拟器进程中含有 com.android.emu.coreservice。还有些云真机默认的品牌和硬件参数，会暴露它的身份，如品牌为 Redfinger、CloudPhone 可能是红手指云手机、华为云手机，但这些参数可以轻易修改，这就需要其他策略来识别了。

设备指纹

唯一标记一台真实设备，在用户正常操作后，如重装App、重启设备、重装系统、备份还原等，能确保设备指纹不发生变化。注意，设备指纹不是银蛋，不是万能的，所以这里说的是真实设备、正常操作。对于虚假设备，我们只有策略或模型识别出假设备就可以了，不必保证设备指纹唯一。恶意用户异常操作也是一样，识别处理即可，无需在设备指纹算法上浪费太多精力，即便能保证唯一，意义也不大，回报率极低。当然，并不是说，只要用户稍微篡改一下设备参数，我们设备指纹就放弃抵抗了，这里有一个平衡，避免花大量时间和精力做强对抗，如果低成本能保证篡改后设备指纹依然唯一，那最好了，我们现在就能保证大多数情况下参数被篡改后设备指纹依然不变。

我们的设备指纹经过了多次算法尝试和技术的演进，每个版本都迭代了数十次。

第一版，单字段映射。

最初开始设备指纹的算法研究与实现时，Android 生态一片繁荣，设备参数如IMEI还基本可用，黑产也没有到疯狂的地步。我们的算法主要是以单字段映射为主，也就是ID Mapping。这个算法的好处是简单，容易理解，容易实现，遇到问题，也能轻易地排查找到原因。数据全部放在Redis中，做了高可用，并实时备份，以防Redis意外，数据不会丢，并能快速恢复。开始上线时，效果非常好，准确率高。期间，做过一次大迁移，通过数据双写，服务从一个云迁移到另一个云，数据没有一条丢失和错误，这得益于合理的方案和周密的计划。但这套系统用了不长时间，很快问题出现了。业务爆发式的增长，我们的设备指纹服务，设备量很快过亿了，由于ID类型一直在不停地增加，加一个，就是加一亿的数据，最终Redis Key 达到十多亿，一再扩容，但成本也急剧上升，再估算一下未来的业务增长趋势，成本将无法控制。同时另一个问题，也显现出来，随着设备的增多，单字段的冲突问题逐渐暴露出来了，多个设备被识别成一个，这也是完全不能接受的。

第二版，多字段映射。

在第一版中，冲突的问题，是绕不过的，于是，我们又重新思考了，最终决定，采用多字段映射，在解决冲突的前提下，依然能够保持简单。但Redis成本问题，已经无法胜任了。调研了一些数据库，没有找到合适的数据库，在各种权衡下，还是使用了MySQL，一张表建了10多个索引，就这样，在已知有风险的情况下，依然跑了起来。这个版本使用了很长时间，系统稳定，设备指纹准确率也提升了很多，在快速增长的业务需求下，依然保持了较高的可信度，误差很小。

但该来的问题还是来了，在一个安静清明节早上凌晨4点，系统报警了，MySQL CPU 过高。难以想象在系统低峰期，CPU 居然过高？后证实下来，是云服务共享导致的，立即切换了独享版。

平静了两个月后，系统再次报警了，这次是周六早上，排查下来，是DB超时错误。日志中的 SQL 重跑一遍后，很快发现了问题，居然有子查询返回上万条数据，是意料之外的。于是立即做了降级处理，最多返回100条。问题得到暂时的缓解。深入排查后，发现是设备参数的默认值导致的，上万设备某个参数都是一样的，于是对这些默认值做了特别处理后，系统又恢复正常。

但从这次事故中，我们还是感觉到MySQL的风险，数据量大，索引即将超过限制，没有扩展的余地，MySQL 毕竟是关系型数据库，不适合 KV 场景。于是，我们又花了大量时间，重新调研适合我们场景的数据库，尤其是 KV。在经过数月的评测研讨，最终有了结论，尝试一个新的数据库 Aerospike。
经过了漫长的数据迁移和对比实验，Aerospike终于被证实是可靠的而且适合我们场景的数据库。至此，DB问题终于被解决了。

第三版，基于自主优化的模型算法。

Android 生态接二连三地发生重大变化，尤其是IMEI 被禁用，OAID作为替代方案，还有国家安全合规要求，不能过多过早获取用户设备信息。虽然我们并不依赖某些设备参数，但隐私政策收紧的趋势已经很明显，必须提前做好准备。于是我们又开始计划新的设备指纹算法，形式不同往日，当前挑战比以往更大。复杂的问题允许相对复杂的解决方案，我们新的算法相对前面版本已经不再简单了，而是一个可以自主优化的算法，可以随时调整模型，能让后来生成的设备指纹越来越准。经过数月的对比实验，不仅证明了新算法的可行性，而且证明了新算法有天然的优势，准确率高于前一版本。

设备指纹是个细致活，通过一次次的优化，一个个的细节问题被发现被解决，踩过的坑都成为了我们光辉的历史，指导我们一步步把设备指纹做得更准确更稳定。

tuid

曾经，tuid是个极富争议的话题，外部环境不可控，并非所有人都能理解，所以不同的部门认知不同，对这个ID有不同的要求，要满足所有的要求，是不可能的，需要在平衡各种需求的情况下，尽力提升ID的准确性实时性。

tuid 是什么？tuid是 服务端设备指纹（即上文讲到的设备指纹）和客户端临时指纹的组合提取。新设备或App重装后，服务端设备指纹需要一次网络返回，在网络返回前，业务数据已经开始上报了，这时就需要一个ID来对应到这个设备，并且能和服务端设备指纹关联上。在设计设备指纹时，我们就预先考虑到这个情况，所以让客户端临时指纹和服务端设备指纹有很强的关系。这样，经过一定的算法和匹配，就能够从两个指纹中提取出一个共同的ID来，这就是 tuid。

首次提出tuid，是在AB实验中，由于IMEI冲突、改码、用户不给权限等等，造成通过IMEI等设备参数无法进行实验分流，得出的数据非常不置信。数据中心找到我们，希望能够提供一个相对稳定的ID用于实验平台。由于对实时性要求较高，单纯服务端设备指纹也满足不了要求，于是我们提出可以试一下客户端临时指纹+服务端设备指纹的方案，从两者当中提取出共同的 tuid，作为实验分流ID。实验平台经过尝试后，发现效果非常好。自此便开启了 tuid 的时代，但也只是单一平台小规模运用。

然而，IMEI等设备参数不可靠的问题，在业务线越来越严重，对比tuid或其他平台，108万的新增，使用IMEI作为口径，可以统计出127万新增，误差接近20%，同时各业务线不同部门数据更是难以对齐。在 ONE ID ONE DATA ONE SERVICE 的号召下，各部门尤其是数仓，迫切需要一个相对靠谱的ID来打通并对齐底层数据。

在对比了各个ID后，包括 QID、Android ID、UUID、tuid、IMEI、其他第三方ID，发现并不存在一个理想的ID，能满足所有场景，尤其是Android 环境不断变化的情形下，无法预知某个ID在未来几年的表现。但可以确定的是，在明确App打开前几秒，ID 可能不准的前提下，最接近理想的 ID 是 tuid，于是会议决定使用 tuid 作为 打通并对齐底层数据 的唯一ID。于是，tuid正式登上舞台。全业务线，所有数据体系大规模改造，全部使用 tuid。

随着数仓系统的改造，各种数据也逐渐对齐，指标也趋于稳定，IMEI 混乱的时代终于可以结束了，有了 tuid，数据第一次被算清楚了，这使所有部门看到了数据的准确，看到了数据的整齐，决策也有了信心。

但事情并没有那么顺利，在由谁计算新增的问题上，反作弊和数据中心的意见产生了分歧。反作弊提供了的 tuid 方案，而且有自己的设备指纹系统，已经实时标记了新增。但数仓的要求是，新增必须走数据中心来计算。走反作弊，优点是方案和实现统一在反作弊形成闭环，有现成的系统，缺点是有少量设备可能只在业务线上报，不在反作弊库中，新增会少。数据中心计算新增，优点是数据中心自己负责重要数据的产生和计算，自己负责高可用，不依赖其他系统，缺点是设备参数可能发生变化，在App打开前几秒，客户端临时指纹有一定概率和服务端设备指纹不一致，导致生成两个tuid，计算两次新增，也就是说实时数据产生了假新增，新增会多，但离线可以排除，日活影响不大。

各方沟通下来，最终还是确定了数据中心来计算新增。这就需要一套方案来消除或降低假新增比例。离线能够识别假新增，是因为反作弊同时上报了客户端临时指纹和服务端设备指纹，可以做映射。所以我们上线了一套tuid转换服务，解决实时数据有假新增的问题。这个方案成本很大，需要所有使用tuid的服务都做一次tuid转换的改造，部分业务线在网关层做了转换，后面的微服务就不需要转换了。这个转换过程99.9%是本地的，只有不到0.1%需要远程。假新增就在这0.1%中，转换后，实时的假新增比例控制在1-2%，这个值是稳定的，而且离线可以排除干净。

tuid改造完成之后，实时指标也越来越准确越来越稳定。

但自Android 8以后，Android 系统接二连三地发生了重大变化。首先 Android ID 不再是唯一的，同一设备对不同的App会返回不同的 Android ID。然后 Mac 地址随机，接着禁止获取序列号等等，其他参数也受到系统管制和权限的限制。好在我们的设备指纹系统不强依赖于这些参数，所以基本没受到任何影响。客户端临时指纹的稳定性虽受到挑战，但得益于tuid转换服务，tuid的依然能够保持相对稳定。

然而，随后而来的隐私合规和国家出台的一系列个人信息保护政策，对我们tuid冲击很大。我们获取的环境参数都是在合规范围内的，也不会获取敏感的用户个人信息，例如电话本、短信等等，所以这些要求，对我们没有影响。影响大的是，要在用户同意隐私协议之后才能获取环境参数，这对我们一向主张的实时性要求相冲突。我们要求反作弊SDK要尽早初始化，尽快拿到服务端设备指纹。但隐私协议的规定让我们不得不延迟初始化，这样带来了更多的设备没有拿到服务端设备指纹，而只能拿到客户端临时指纹，所以造成了假新增暴涨，最高达到18%，这是不可接受的。

必须有一套方案能够解决Android系统变化问题和反作弊SDK初始化较晚的问题，而且要低成本。理想情况是，客户端有个准确的不需要权限可以随用随取的不会变化的设备ID。但这只能个空想，过去不可能，现在国家安全的要求和Android系统的发展趋势都不允许有这样的ID来跟踪用户行为。

其实通过日常数据监控，我们已经发现客户端临时的设备指纹稳定性在缓慢变差，需要增强，tuid转换服务过于简单，数据不丰富。再进一步分析数据，发现假新增可以由其他环境参数，通过模型来修正，可修正比例高达 80%以上，再加上多种策略，大幅降低假新增比例，是完全可能，而且是确定可实现的。成本呢，我们已有的tuid转换服务，为我们搭好了架构，铺好了路，只要稍做调整即可。于是客户端临时指纹增强版，加上服务端tuid转换服务优化，方案定下来了。由于改造不太，实现很快落地了，效果和预估的一样，指标变化非常显著，加上网关层全面推进tuid转换，假新增从18%重回 1-2%。
​

回想一下，当初确定tuid转换方案的时候，确实遇到不少阻力，好在有领导层的支持，有大家的坚持，最终全面铺开了。现在看来，这个架构抗风险性很强。如果没有这个tuid转换服务，很难想象，隐私合规和Android系统的变化带来的挑战，我们如何才能应对。这个问题即便放到现在，也没有一套方案能够做得更好，我们没有，市面上也没有，甚至很少有公司考虑过实现客户端设备指纹的事情，虽然这是刚需。

tuid 的困难在于外部环境不可控。从小的方面讲，设备的碎片化可能导致任何意想不到的问题，从大的方面讲，国家政策，Android 系统重大更新，都是无法预测的。
tuid转换服务，就在客户端和服务端做了一个缓冲的桥梁，缩小甚至消除外界变化带来巨大影响。后续大环境发生变化，我们依然可以通过这个缓冲调整模型来应对。

上述从三方面介绍了反作弊SDK相关的技术和变革，反作弊SDK解决了反作弊遇到的挑战，同时也满足了业务苛刻的需求。对比业界优秀的设备指纹服务，我们的设备指纹达到了极高的准确率，双方的准确率均接近99.99%，在个别设备识别上各有千秋。独创的tuid方案，在业界首次解决了实时数据统计分析无可靠口径的难题。

趣头条反作弊从零开始，把一个个服务建立并完善，在真实的场景中磨炼，得到反馈，总结经验，吸取教训，沉淀出了一套完整的闭环的反作弊体系，已经成为中台核心组成部分。黑产技术在不断更新，反作弊技术也需要持续创新，并且要提前防御，尽可能避免与黑产持续强对抗。

E N D

目前，已有外部公司与我们合作，帮助他们解决黑产问题和业务上的数据问题，他们能够享受与我们内部业务无差别的服务，使用我们完整的反作弊技术，例如实时风控、风险识别、算法模型等等。如果您或您的公司在业务中遇到了困难或黑产攻击，可以联系我们， 我们愿意提供技术交流和服务试用。联系邮箱 [e-mail]。