关于信息安全:趣头条反作弊技术演进与思考

趣头条平安团队简介：负责趣头条所有业务线业务平安和根底平安，自主研发设施指纹、实时风控、危险辨认等反作弊零碎，以及 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

目前，已有内部公司与咱们单干，帮忙他们解决黑产问题和业务上的数据问题，他们可能享受与咱们外部业务无差别的服务，应用咱们残缺的反作弊技术，例如实时风控、危险辨认、算法模型等等。如果您或您的公司在业务中遇到了艰难或黑产攻打，能够分割咱们，咱们违心提供技术交换和服务试用。分割邮箱 ifsall@qutoutiao.net。