数盟是一家反作弊服务商主要技术和专利包括数盟可信ID（即设备指纹识别技术）、虚拟机识别、反作弊服务等。其中可信ID是其作为防刷单的主要技术手段

该项目是『數盟可信id的获取』的样本。由于商业合作才可以拿到一般在市面上鲜于见到。该样本出自一家接入过数盟解决方案的第三方公司APP通过逆向的技术拿到了样本。

由于key是app唯一的每次初始化请求会记一次（即结算一次），所以请手下留情！

『数盟ID』：可信ID技术由数字联盟自主研发用于准确描述移动设备，每个编码对象获得一个唯一的、不变的标识ID可信ID能帮助APP公司在不同场景下确认设备唯一性，识别修改設备及复用、虚拟机刷量等行为可以反作弊、防刷单，并通过数字联盟生成的设备ID和客户账户体系的关联实时有效识别小号恶意注册等行为，并精确识别历史版本用户、弱账户APP的换机状态等

可信ID不随任何非硬件信息变化而更改，是真正唯一、真实、安全、高可用的移動设备指纹识别技术

经过我的调研，发现该id并不依赖于传统的设备ID如imei、mac地址、android_id等。在xpose劫持的情况修改imei等参数并不会导致该ID修改。C方法拦截未测试

在app第一次启动会初始化ID，并上传至数盟服务器()因为考虑到计费统计，所以可信ID的获取至少需要网络访问的权限
如下图所示获取88位可信ID：

程序只有在第一次启动才会执行计算ID和计费的操作。

那么问题来了我们怎么应对防刷单策略，可信ID就真的这么安全么

对不起，这个问题我不能回答但是根据上述的调研结果，传统的作弊手段（通过修改设备imei、mac地址、android_id等信息）显然已经达不到目的更別提采用虚拟机了。

但是如果hook数盟ID的获取方法 Main#getQueryID() ，仔细分析下其实这只是欺骗了接入方服务器。在结算时一定会被识别出欺骗

下面看┅下数盟通信模型和设计，当然这只是我的臆测我应该会这么去做。也许读者也可以提出更好的模型

数盟的通信模型.png

通信和校验的过程如下（以下APP指接入数盟ID的Android应用）：

1. APP在主进程中初始化，并注册传感器监听；
2. 运行过程中在登录接口（假如薅羊毛或刷单的接口）通过.so中getQueryID方法获取smid并加入到通用参数中打包上传APP服务器（app-s）；
3. 注意在调用本地方法getQueryID的时候，会做两件事：一个是网络访问的权限校验一个是获取smid后上传数盟服务器（sm-s）。注意这一切是在native中做的；
4. sm-s收到smid会回调给app-s通知新ID到来（当然已经在本地服务器check之后）；
5. 此处，我们先忽略竞争與冒险的情况确保4处的回调过程发生在3之前，即app-s先收到回调的smid A在收到APP发送的smid B比较这两个参数是否一致，如果一致说明客户端没有作弊否则就视为作弊；
6. 剩下就是结算的策略了，实时结算或者走结算周期等

这一些列步骤看似每一步都有很大漏洞，但是冷静我们来一个個排除！

• 拦截APP和数盟服务器之间的通信方法：hook Nativie。
  我一开始就是这么想的但是native会校验https证书链，从而达到了防代理的作用那么是否可以通过native层hook（如Cydia）绕过这一层防护，达到网络劫持的目的前提是，.so中无hook框架的检测
• 基于IDA的.so调试和静态分析
  这是一条看起来最靠谱但又非常鈈靠谱的方法了。调试的过程很不乐观这可能需要高人指点。但是如果能被轻易破解估计数盟不会拥有7亿的设备ID了，这是一条巨大的產业链

限于目前的技术手段以上是能够想到的方法。

总结面对数盟ID的情况，刷单最直接的方法就是破解遵循[

]分享并保持客观立场本站不承担此类作品侵权行为的直接责任及连带责任。您有版权、意见、投诉等问题请通过

联系我们处理，如需商业授权请联系原作者/原網站