文章总结： 本文介绍在梆梆企业版加固APP渗透中，利用WebView加载H5特性绕过加固限制。通过Burp历史发现API接口对应的Web站点，访问后利用浏览器调试器查找前端路由触发请求，在JS加密函数处下断点，成功定位AES加密算法及密钥，从而解密数据包进行分析。 综合评分： 90 文章分类： 渗透测试,移动安全,逆向分析,WEB安全,实战经验

取巧获得web/app数据包加密算法和key

原创

进击的HACK

进击的HACK

2025年12月25日 07:50 江苏

文章简述 公司项目渗透测试，偶遇某梆企业版加固，拼尽全力无法战胜。

文章给出一个取巧的办法，在遇到采用webview框架的加密app的时候，可以通过浏览器寻找接口，debug找到密钥。

声明：文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途给予盈利等目的，否则后果自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！

摸鱼中，项目经理又笑嘻嘻的发过来一个app，说看看有没有漏洞，最好有产出。

摸鱼结束，先看看有没有加固。

哦吼，梆梆企业版。我马上问项目经理能不能给个测试包，没加固的那种。

项目经理哈哈一笑：“没有。”

安装apk，通过代理将数据包发送到burpsuite。 好消息是没有代理检测，坏消息是请求体和响应体都加密了。

同一个功能点发送两次相同的数据，请求体和响应体的加密数据没有变化，初步判断是 AES + base64编码。

尝试脱壳，失败。 尝试frida，有frida检测。 Florida和hluda-server都尝试了，也存在检测。

因为项目紧急，没有那么多的时候一步步分析。密钥找不到，很难做下去。 难道要nuclei、dirsearch、xray扫一遍，然后写个安全评估报告吗？

在我一筹莫展的翻阅burpsuite-proxy-history，看看能不能找一个信息泄露凑个洞的时候，意外在apk的js当中看到了API。

根据以往经验，很多公司为了前端适配和代码迁移，往往不是用 Java写的apk页面，而是通过webview加载JavaScript。

全局搜索加密的API，在js文章就有。

既然API都在js当中，那么思维发散一下，加密算法和key是不是也在呢？

说干就干，因为js没有混淆，搜索常用字符串 encrypt

和推测的没有偏差，就是 AES ECB Pkcs7。

ECB方法的AES是只有key，不需要iv的。

接下来是寻找 key，静态寻找key很难。看到眼睛生疼，视线模糊也没找到。需要换一种思路了。

有一种思路是把js dump下来，然后在本地运行，缺环境就补环境，然后调试。

当然这里有另一种思路。既然是执行js加密的，那么直接访问域名会不会存在网站呢？

API 是 /api/aa/bb/cc/dd/list URL是https://example/api/aa/bb/cc/dd/list 依次删除路径，看看能不能进入web页面 /api/aa/bb/cc/dd/list 不行

/api/aa/bb/cc/dd/ 不行

……

删到最后，把api也给删掉，终于进入了前端页面

是适配手机的，所以浏览器看着很怪

F12，修改为手机

但是没有点击的点，怎么让他发包然后debug呢？

别急，我们观察一下URL。https://aaa.example/#/

后面有一个 /#/ ，URL #后的path不会传给后端，只在前端执行。

后面有一个 /#/ ，很大可能是前端路由框架（如 Vue Router、React Router 等）。通常会在 JavaScript 代码中有路由配置文件或模块。在这些路由配置中，会明确指定#后面的路径与对应的组件或页面的映射关系。例如，在 Vue Router 中可能会有类似这样的配置：

const routes = [

{path:'/', component: Home },

{path:'/about', component: About },//...其他路由配置];

这里的path就是#后面可能出现的路径，通过查找这些路由配置可以知道哪些页面是有效

可以搜索关键词

routes

path:

然后把 path的值放在 /#/后面 我们接下来寻找一个访问之后就会向后端发送加密请求的路径，然后在 AES 加密处下断点，debug 比如 /#/register

e就是key

但 e 是 array 格式，不是字符串，有没有什么好办法呢？

其实，array 对象自带一个方法 toString() 我们可以在console打印

这样我们就拿到了key

试试能不能用

完美。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：进击的HACK 进击的HACK《取巧获得web/app数据包加密算法和key》