device_fingerprint、device_id、hmac生成

【🏠作者主页】：吴秋霖
【💼作者介绍】：擅长爬虫与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信息请求主页信息基本都是会触发风控的，由此可见这个策略方案虽然可能在持续稳定的情况还需要更加深度的分析与研究，但是至少该方案是可以走通流程的