前言：
• 传统的接口在传输的过程中，是非常容易被抓包进行篡改，从而进行中间人攻击。
• 这时候我们可以通过对参数进行签名验证，如果参数与签名值不匹配，则请求不通过，直接返回错误信息，从而防止黑客攻击或者大大增加了黑客攻击的成本。
• 白帽子在挖洞的时候也经常会遇到这种情况，大多数不会逆向的白帽子则会放弃这些有着攻击成本的接口。大多数也会有这样子的想法，这些个接口都加了防护了，说明厂商对这个接口挺重视的，肯定做了安全检测，自然是不可能有洞可捡了。反过来想，厂商正是因为加了防护从而对代码疏忽了，所以这些地方恰好就是挖逻辑漏洞的突破口。
平台：aHR0cHM6Ly93d3cudnVsYm94LmNvbS8=
厂商：某企业src
正文：
开局一个搜索框
输入值抓包，接口携带了一个sign参数。
技巧
此处有两种方法逆向找出对应的加密点
搜索sign，网站里面出现了很多sign关键词，不利于我们进行逆向分析
从查看请求发起的相关进程(脚本)去进行发包跟栈
进入发包的地方打断点。
回溯跟栈，找找有没有比较显眼的关键词。
大概跟了几个栈找到了sign关键词，但是并不确定这个地方的sign参数是不是我们发包的那个sign参数，打下断点盲测一下。
再次发包的时候，断点断住了。这个sign参数是一个f对象的一个函数，并不是一个sign参数值。而我们想要找到的是sign参数值，经过猜测，这个断点能够在携带sign参数的那个发包时断住，就肯定与sign参数有关。直接进入函数内部查看。
映入眼帘的是一个f函数，将断点断到返回值的地方，查看一下返回值是什么呢。
在控制台打印一下返回值。很眼熟，很像我们发包的时候携带的参数
分析一下f函数，看看sign参数在哪里生成的。
sign是在5790行被赋值的。
可以看出sign参数是appSignKey，keyword，noncestr，serverTimestamp，source，timestamp拼接之后传进了s函数生成的。除了appSignKey是代码生成的，其余都是发包里面携带的明文。
appSignKey参数
从f函数里面代码可以分析出，appSignKey是由n赋值的，n又是由c经过一段三元表达式生成的。c是一段字符串，直接上手扣代码。
生成n的三元表达式用到了arguments，直接到浏览器复制arguments
var c = "10f6cf80184377cd5487b4746a8a67da17540449fa40b408f13ccdd3d3059cb394c0e1569043eed2" arguments = { "0" : { "keyword" : "A型胸腺瘤" , "source" : 1 , "serverTimestamp" : 1706072080923 }, "1" : "4bTogwpz7RzNO2VTFtW7zcfRkAE97ox6ZSgcQi7FgYdqrHqKB7aGqEZ4o7yssa2aEXoV3bQwh12FFgVNlpyYk2Yjm9d2EZGeGu3" } var n = arguments . length > 1 && void 0 !== arguments [ 1 ] ? arguments [ 1 ] : c console . log ( "appSignKey--->" + n ) ole . log ( n )
sign参数
有了appSignKey参数，就可以与发包参数拼接传进s函数。
appSignKey = 4bTogwpz7RzNO2VTFtW7zcfRkAE97ox6ZSgcQi7FgYdqrHqKB7aGqEZ4o7yssa2aEXoV3bQwh12FFgVNlpyYk2Yjm9d2EZGeGu3 & keyword = A 型胸腺瘤& noncestr = 20565646 & serverTimestamp = 1706072080923 & source = 1 & timestamp = 1706081268690
看一眼就知道是md5加密，完结撒花。
结尾：
部分数据代码已做脱敏处理。
此文章仅供技术交流使用，如有侵犯权益，联系我删除。
