device_fingerprint、device_id、hmac生成
文章目录
- 1. 写在前面
- 2. 设备信息
- 3. 数美指纹
【🏠作者主页】:吴秋霖
【💼作者介绍】:擅长爬虫与JS加密逆向分析!Python领域优质创作者、CSDN博客专家、阿里云博客专家、华为云享专家。一路走来长期坚守并致力于Python与爬虫领域研究与开发工作!
【🌟作者推荐】:对爬虫领域以及JS逆向分析感兴趣的朋友可以关注《爬虫JS逆向实战》《深耕爬虫领域》
未来作者会持续更新所用到、学到、看到的经验与技术知识!包括但不限于:各类验证码突防、爬虫APP与JS逆向分析、RPA自动化、分布式爬虫、Python领域等相关文章
作者声明:文章仅供学习交流与参考!严禁用于任何商业与非法用途!否则由此产生的一切后果均与作者无关!如有侵权,请联系作者本人进行删除!
1. 写在前面
好久没更新文章了,随笔记录一下。APP端目前更新之后的风控貌似丝毫不下于Web
的强度,Web
端的话目前作者没有测试验证过,但是貌似是有一个xsce-tk
的参数。其他应该都是差不多的。APP
端作者用自己的sid
进行了测试,数据如下(仅供参考
):
NoteDetail: 不Sleep的情况下连续请求 >= 1500(次) 强制对账号进行下线处理
CommentDetail: 比较稳定,好像测试了几个过W+的Comment期间不Sleep未出现异常
部分例如主页
、作品列表
、搜索
测试就算是携带风控参一样对协议的行为有直接的管控!基本请求1~3
次就会出现频繁
或账号异常
采集的话目前大部分接口都只需要签名参数shield
。目前就算是个人使用的账号针对上面提到的接口一样只能请求几次,所以从风控对抗的研究角度来看某一些场景下是可以使用某版本游客的方案进行访问的。生成游客的sid
是可以访问上述提到的一些接口信息
上面请求头参数中,大致可以分风控参
跟签名参
。其实大部分的场景API
只需要用到签名参
就能够验签通过。但是往往很多平台或者APP它们请求头多的能够达到几十个参数,其中或多或少都会有设备信息、指纹信息..
等不为人知的埋点,用以甄别非正常用户的请求
2. 设备信息
首先为什么要生成设备信息,采集的场景中固定一个设备信息在持续的采集中,会出现风控异常。这个异常即对设备信息进行了检测,更新设备信息就会解除!这里除了自动到对应的接口生成hmac、device_id
信息外,就是手动提取了hmac
了,device_id
的话抓包获取对应的就行。Android
设备的话装一个MT管理器
到/data/data/com.xingin.xhs/shared prefs/s.xml
路径下获取即可,如下所示:
IOS
的提取方案是一样的,去到对应的文件拿就行。只是方式跟文件的路径有一些差异
这里我们需要借助filza
去到根目录。之后按照这个路径private/var/mobile/containers/shared/appgroup/group.com.xingin.discover/library/preferences
然后打开group.com.xingin.discover.plist
文件,如下所示:
除了上面提到的手动提取设备中的hmac
信息外,我们还可以通过激活的方式来自动生成,did
是一个uuid
算法生成的,而hmac
的话在/api/sns/v2/user/teenager/status
接口中请求获取,实现大致如下所示:
import uuiddef get_hmac():did = str(uuid.uuid4()).lower()headers = {'xy-common-params': '', # 自行获取'xy-platform-info': '', # 自行获取'x-mini-mua': '','x-mini-sig': '','x-mini-gid': ''}response = requests.get(url, headers=headers)hmac = response.headers['Xy-Ter-Str']return hmac
上面headers中x-mini-*
系列的参数mua
是必须要的,然后另外两个非必需(不带就是设备异常
),实际场景中的话这三个风控参最好都走动态是比较理想的,生成如下所示:
上面session
的话是游客接口出来的,了解过web
的应该很熟悉activate
接口,然后请求参数的话跟授权接口部分参数一样!主要就是idfa
跟idfv
,如下所示:
上述提到的游客
或hmac
生成都需要shield
签名请求才会成功
3. 数美指纹
62
位的device_fingerprint
参数它在旧版本中在某些场景是需要解决的,头部参数重是动态的!一长串如下所示:
20250418213816b9547c11c3cd5b9d3d7ae81a378503de00b51469a59b18af
前面一看就知道是时间
信息、中间则是device_id
进行MD5
后32
位字符,在拼接00
字符生成一个48
位字符,可以发现末尾还有14
位字符。这里则是shumei_sec_*_key_
关键字符拼接上面第一次得到的MD5
结果再次进行了一个MD5
得到了新的一串32
位字符。最后用之前48
位取最后这次加数美字符生成的前14
位得到完整的device_fingerprint
参数结果,如下所示:
最后,我们通过自动生成device_id
跟hmac
并激活。然后生成device_fingerprint
参数搭配shield
动态签名以及动态x-mini
系统的参数进行测试。来验证游客的sid
是否可以正常请求一些接口,如下所示:
正常我们个人的sid
信息请求主页信息基本都是会触发风控的,由此可见这个策略方案虽然可能在持续稳定的情况还需要更加深度的分析与研究,但是至少该方案是可以走通流程的