共计 6828 个字符,预计需要花费 18 分钟才能阅读完成。
趣头条平安团队简介:负责趣头条所有业务线业务平安和根底平安,自主研发设施指纹、实时风控、危险辨认等反作弊零碎,以及 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 实现了两项重要工作:
- 联合服务端算法生成设施指纹和 tuid(下文有具体介绍),依附 SDK 对客户端环境很强的感知能力,加上弱小的服务端算法,设施指纹的能够达到很高的准确度。
- 上报客户端环境参数,咱们采集的参数偏差于显性的,例如开机工夫、音量、光感等等,是符合国家平安合规要求的,局部参数只有在用户批准的状况下,才会获取,而且单次回话中不会大量反复获取,依附这些看似不起眼的参数,咱们能够做很多策略来辨认虚伪设施,例如模拟器、越狱、参数汇集等等。
以模拟器为例,通过校验各种参数,咱们开发了 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。