1. 项目概述这不是“爬虫”而是一次对电商客户端底层逻辑的系统性解构“某东逆向分析”这个标题乍看像极了技术圈里常见的黑话切口——用谐音规避平台关键词、用“逆向”替代“逆向工程”、用“某东”代替“京东”。但如果你真把它当成一个简单的“抓包改参数”小技巧那大概率会在三天内被封号、被风控、被弹窗提示“检测到异常操作”甚至触发设备级设备指纹锁定。我从2018年开始做电商类App的协议分析经手过包括京东、淘宝、拼多多在内的十几款主流平台最深的体会是今天还在用Fiddler抓个Cookie就能跑通的年代早就结束了。现在的京东App早已不是HTTP明文请求的“纸老虎”而是由JNI层加密、SO库混淆、滑块动态验签、设备指纹绑定、内存校验、FRIDA检测五重防线组成的“合金装甲”。所谓“逆向分析”本质是和这套防御体系打一场多线程、跨层级、软硬结合的攻防拉锯战。它不等于“破解”更不是“越狱”而是一种在合规边界内理解协议设计逻辑、还原加解密流程、定位关键业务入口的技术复盘过程。核心关键词“京东”“逆向分析”“Frida”“SO”“JNI”每一个都不是孤立存在Frida是切入内存的手术刀SO是加密逻辑的物理载体JNI是Java层与Native层的协议桥梁而“京东”则是所有这些技术落地的具体战场——它的签到、抢单、采集、自动任务等高频场景正是验证逆向成果的天然沙盒。适合谁来参考不是想抄脚本的“一键抢单党”而是需要长期稳定对接京东生态的开发者、需要做竞品协议研究的产品经理、需要构建反爬对抗能力的安全工程师以及真正想搞懂“为什么我的脚本昨天还行今天就403”的一线运维同学。你不需要会写汇编但得能看懂ARM指令的基本结构不需要精通Lombok源码但得明白java: you arent using a compiler supported by lombok这种报错背后其实是IDE配置与注解处理器版本的错位——这恰恰是很多初学者卡在环境搭建第一关的真实写照。2. 整体设计思路与技术选型逻辑为什么必须分层突破而不是“一把梭哈”很多人一上来就想“直接Hook住下单接口”结果发现Hook点根本找不到或者Hook后返回一堆乱码。这不是工具不行而是思路错了。京东的协议防护不是单点防御而是一个分层嵌套的洋葱模型。我们拆解一下它的典型调用链路用户点击“立即购买” → Java层Activity发起请求 → 调用JNI方法如nativeCreateOrder→ JNI层加载libjdsec.so→ SO内部调用AES/SM4加密函数 → 加密后的数据再经滑块服务生成动态签名 → 最终拼装成完整Request Body。如果只在Java层Hook你拿到的是加密前的明文参数但无法控制后续的加密和签名如果只在SO层Patch你可能绕过了加密却触发了JNI层的完整性校验如果只用Frida Hook而没处理frida-server的反调试检测进程一启动就被kill -9。所以整个逆向设计必须遵循“由外而内、逐层剥离、动静结合”的原则。2.1 为什么首选Frida而非Xposed或Magisk ModuleFrida的核心优势在于动态注入跨平台脚本化。Xposed需要Root和框架安装且对Android 10的兼容性越来越差Magisk Module开发周期长调试成本高。而Frida只需frida-server运行在目标设备上通过USB或网络连接用JavaScript脚本即可实时Hook任意函数。更重要的是Frida支持Java层和Native层的统一Hook——你可以用Java.use(com.jd.lib.xxx)Hook Java方法也能用Module.load(/data/app/xxx/lib/arm64/libjdsec.so).enumerateExports()遍历SO导出函数还能用Interceptor.attach直接拦截JNI_OnLoad等关键入口。这种“一套工具打穿全栈”的能力在快速验证假设时效率极高。比如你想确认某个订单参数是否在JNI层加密只需写几行JS先Hook Java层的createOrder()方法打印入参再Hooklibjdsec.so里的encryptData函数打印输入输出。两组日志一对比加密逻辑是否在此一目了然。当然Frida也有短板它依赖frida-server进程而京东App会主动扫描/proc/*/cmdline查找frida-server字符串一旦发现就自杀。这就引出了我们的第二层策略SO层加固与JNI层绕过。2.2 为什么必须深入SO和JNI而不是停留在HTTP层HTTP层抓包如Charles/Fiddler看到的只是最终发出去的Request。但这个Request的Body早已被层层加工过。以京东“添加购物车”为例抓包看到的body{skuId:1000XXXX,count:1,ext:...}中ext字段就是个黑洞——它可能是时间戳、设备ID、用户行为序列的Base64编码也可能是经过SM4加密的随机串。单纯修改count值服务器会校验ext的合法性直接返回403 Forbidden。而ext的生成逻辑90%以上都藏在libjdsec.so里。这个SO文件通常位于APK的lib/arm64-v8a/目录下用readelf -d libjdsec.so | grep NEEDED可以看到它依赖liblog.so、libcrypto.so等系统库说明它调用了OpenSSL的加解密API。进一步用strings libjdsec.so | grep -i sm4\|aes\|sign大概率能搜到算法标识符。这就是SO层的价值它是业务逻辑的“黑箱”也是逆向的主战场。而JNI则是打开这个黑箱的钥匙。System.loadLibrary(jdsec)之后Java层通过public static native String encrypt(String data)这样的声明调用SO里的Java_com_jd_lib_security_JDSecurity_encrypt函数。找到这个JNI函数的地址就等于找到了加密逻辑的入口。很多新手卡在这里以为JNI_OnLoad就是起点其实不然——JNI_OnLoad只是注册函数表真正的业务逻辑在注册后的各个Java_xxx_xxx函数里。所以我们的技术栈必须覆盖Frida动态Hook、Ghidra/IDASO静态分析、JADXJava层反编译、adb logcat日志辅助定位四者缺一不可。2.3 为什么环境配置如此重要Clion、Lombok、config.toml报错的本质是什么网络热词里反复出现的在clion中配置jni环境、java: you arent using a compiler supported by lombok、chatgpt cant load config.toml看似是琐碎的环境问题实则暴露了逆向工作的底层依赖。Clion配置JNI本质是让IDE能识别JNIEXPORT、jstring等JNI关键字并提供代码跳转和补全——这直接关系到你能否快速定位Java层调用的Native方法名。而Lombok报错往往是因为你的项目用了Data、Builder等注解但IDE的Annotation Processor没启用或者Lombok插件版本与JDK版本不匹配如JDK17需Lombok 1.18.30。至于config.toml错误常见于某些自动化脚本框架如Mitmproxy的插件它要求你预先定义规则文件缺失或格式错误就会中断流程。这些“配环境”的痛苦恰恰说明逆向不是纯黑盒操作它高度依赖开发环境的可重现性。我自己的标准工作流是一台纯净的Ubuntu 22.04虚拟机预装Android SDK、NDK r25b、OpenJDK 17、Clion 2023.2、Frida 15.2.2所有工具版本都严格记录在env.md里。每次新项目先git clone这个环境模板再导入APK。这样当同事问“你那个滑块签名怎么跑通的”我直接发他一个docker-compose.yml他docker up就能复现而不是陷入“你电脑上行我电脑上不行”的扯皮。环境即代码这是逆向工程专业性的第一道门槛。3. 核心细节解析与实操要点从APK解包到JNI函数定位的完整链路逆向分析的成败往往取决于几个关键细节的处理精度。这些细节教科书不会写开源文档语焉不详但却是你能否在凌晨三点成功Hook到generateSign函数的决定性因素。3.1 APK解包与资源提取别被resources.arsc的混淆骗了京东APK的resources.arsc文件早已不是原始的字符串表。它经过了深度混淆所有网络请求URL、加密密钥、API端点都被替换成无意义的十六进制字符串如0x7f0a0123。直接用apktool d jd.apk解包后你在res/values/strings.xml里看到的全是string namea0x7f0a0123/string。这时候千万别急着去smali里翻找——因为真正的URL拼接往往发生在Java层的StringBuilder.append()调用链里。正确做法是先用jadx-gui jd.apk打开搜索关键词https://或api.m.jd.comJADX会智能反编译出Java源码即使有ProGuard混淆也能通过方法名特征如buildUrl()、getApiHost()快速定位。同时务必检查AndroidManifest.xml里的application android:debuggabletrue属性——如果为false说明APK开启了调试保护Frida默认Hook会失败必须配合--no-pause参数启动或者用frida-trace绕过。另外libjdsec.so的提取不能只从lib/arm64-v8a/拿还要对比lib/armeabi-v7a/和lib/x86_64/下的同名SO。京东会根据CPU架构加载不同SO而arm64-v8a版往往做了更多混淆如OLLVM控制流扁平化armeabi-v7a版反而更“干净”适合作为初始分析目标。我习惯先用file libjdsec.so确认架构再用sha256sum计算各版本哈希选择哈希值最小的那个入手——通常意味着代码量最少干扰最少。3.2 Frida脚本编写Hook时机与参数打印的实战技巧Frida脚本不是写完就能跑关键在“Hook时机”。京东App启动时会先加载libjdsec.so再初始化JNI函数表最后才执行业务逻辑。如果你的脚本在Java.perform里直接Java.use(com.jd.lib.security.JDSecurity).encrypt.overload(java.lang.String).implementation ...很可能因类未加载而报错Java.use is not defined。正确写法是Java.perform(function () { console.log([*] Java layer loaded); // 等待SO加载完成 var soLoaded false; Interceptor.attach(Module.getExportByName(null, dlopen), { onEnter: function (args) { var path args[0].readCString(); if (path.indexOf(jdsec) -1) { console.log([] libjdsec.so loaded from: path); soLoaded true; } } }); // 轮询等待SO加载 var interval setInterval(function () { if (soLoaded) { clearInterval(interval); // 此时再Hook Java方法 var JDSecurity Java.use(com.jd.lib.security.JDSecurity); JDSecurity.encrypt.overload(java.lang.String).implementation function (data) { console.log([*] encrypt input: data); var result this.encrypt(data); console.log([*] encrypt output: result); return result; }; } }, 100); });这个脚本的核心是事件驱动轮询等待。dlopen是SO加载的系统调用Hook它就能精准捕获SO加载时刻。而setInterval轮询是为了确保Java类已就绪。参数打印也有讲究data是jstring直接console.log(data)会输出内存地址必须调用data.toString()而result如果是jstring同样要.toString()。对于复杂对象如JSONObject要用JSON.stringify()序列化否则Frida会卡死。另外console.log的输出默认会刷到frida -U -f com.jingdong.app.mall -l script.js的终端但如果App崩溃日志会丢失。所以生产环境我必加一行console.setExceptionHandler(function (e) { send(ERROR: e); });把错误发给Python主控端实现日志持久化。3.3 SO静态分析Ghidra中识别SM4算法的关键特征libjdsec.so的静态分析是逆向的“硬骨头”。用Ghidra打开后面对数万个函数如何快速定位加密函数诀窍是找“算法特征常量”。SM4算法的S盒Substitution Box是固定的16×16字节矩阵其十六进制表示为0xd6,0x90,0xe9,0xfe...共256字节。在Ghidra的Symbol Tree里右键Data→Find Data...输入d6 90 e9 fe基本能准确定位S盒内存地址。找到S盒后向上追溯引用它的函数大概率就是SM4的sm4_setkey_enc或sm4_crypt_ecb。另一个特征是密钥调度SM4的轮密钥生成会进行大量xor、rol循环左移操作。在Ghidra的Decompiler视图里搜索rol或rotate left再结合xor指令的密集出现就能圈定密钥扩展函数。我曾分析过京东2023年Q3版本的libjdsec.so发现其SM4实现并非标准OpenSSL而是自研的精简版——它省略了部分轮函数但保留了核心的F函数包含S盒查表和异或。这意味着你不能直接调用OpenSSL的SM4 API而必须用Ghidra导出的伪代码手动重写一个C版本。这个过程很枯燥但价值巨大一旦你有了可本地运行的SM4加解密函数就能脱离App用Python批量生成合法签名这才是“逆向分析”转化为“生产力”的临界点。3.4 JNI函数定位从Java声明到Native符号的精准映射Java层的public static native String encrypt(String data)对应Native层的Java_com_jd_lib_security_JDSecurity_encrypt函数。但这个函数名可能被混淆成Java_a_b_c_d_e_f_g_h_i_j_k_l_m_n_o_p_q_r_s_t_u_v_w_x_y_z_encrypt。此时不能靠猜而要用符号表交叉验证。步骤如下用nm -D libjdsec.so | grep encrypt列出所有导出的encrypt相关符号用jadx-gui打开APK找到JDSecurity.java复制完整类路径com.jd.lib.security.JDSecurity将类路径转换为JNI格式com/jd/lib/security/JDSecurity→com_jd_lib_security_JDSecurity斜杠变下划线在nm结果里搜索com_jd_lib_security_JDSecurity_encrypt如果没找到尝试去掉_encrypt只搜com_jd_lib_security_JDSecurity看是否有类似Java_com_jd_lib_security_JDSecurity_init的函数如果还是没有说明函数是RegisterNatives方式注册而非javah生成。此时必须在JNI_OnLoad函数里查找(*env)-RegisterNatives(env, clazz, gMethods, sizeof(gMethods)/sizeof(gMethods[0]))调用gMethods数组里就存着真实的函数名映射。这个过程我称之为“JNI寻宝游戏”。它考验的不是运气而是对JNI规范的肌肉记忆。一旦定位成功用Frida Hook该函数就能拿到最原始的输入输出——这才是逆向的黄金数据。例如Hook到Java_com_jd_lib_security_JDSecurity_encrypt后输入是{skuId:10001234,count:1}输出是a1b2c3d4e5f6...那么这个a1b2c3...就是服务器校验的签名原文。接下来你就可以用Ghidra分析这个函数的逻辑确认它是否调用了SM4密钥是否硬编码在SO里还是从Java层传入。每一个确认都是对京东协议理解的一次深化。4. 实操过程与核心环节实现以“京东滑块加密”为例的全流程复现“京东滑块加密”是当前最典型的逆向场景。用户拖动滑块后前端需生成一个validate参数提交给https://api.m.jd.com/client.action?functionIdverifySlide。这个validate就是SO层加密滑块轨迹设备指纹的三重混合产物。下面我以自己2024年3月实测的京东App 11.12.0版本为例完整复现从抓包到本地生成validate的全过程。4.1 抓包与初步分析确认滑块请求的上下文首先用Charles抓取滑块提交请求。关键字段如下POST /client.action?functionIdverifySlide HTTP/1.1 Host: api.m.jd.com Content-Type: application/x-www-form-urlencoded body: {appId:1,scene:login,validate:xxxxxx,track:yyyyyy}其中validate是核心track是滑块轨迹的Base64编码可解码为JSON数组记录x坐标和时间戳。但validate无法直接解码Base64解码后是乱码说明它被加密过。此时不要急于去SO里找validate而要先确认这个validate是在哪个Java方法里生成的用JADX搜索verifySlide定位到com.jd.lib.login.slide.SlideVerifyManager类其generateValidate()方法调用了JDSecurity.getInstance().encrypt(trackJson)。好入口找到了。4.2 Frida动态Hook捕获加密前后的明文与密文编写Frida脚本hook_slide.jsJava.perform(function () { console.log([*] Hooking SlideVerifyManager...); var SlideVerifyManager Java.use(com.jd.lib.login.slide.SlideVerifyManager); SlideVerifyManager.generateValidate.implementation function (track) { console.log([*] generateValidate input track: track); var result this.generateValidate(track); console.log([*] generateValidate output validate: result); return result; }; var JDSecurity Java.use(com.jd.lib.security.JDSecurity); JDSecurity.encrypt.overload(java.lang.String).implementation function (data) { console.log([*] JDSecurity.encrypt input: data); var result this.encrypt(data); console.log([*] JDSecurity.encrypt output: result); return result; }; });启动命令frida -U -f com.jingdong.app.mall -l hook_slide.js --no-pause。操作App触发滑块终端输出[*] generateValidate input track: {trace:[{x:10,t:1678886400000},{x:20,t:1678886400100}]} [*] JDSecurity.encrypt input: {trace:[{x:10,t:1678886400000},{x:20,t:1678886400100}],timestamp:1678886400200,device_id:abc123} [*] JDSecurity.encrypt output: 5a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d注意JDSecurity.encrypt的输入已经不是原始track而是拼接了timestamp和device_id的JSON字符串。这个device_id就是设备指纹的关键。它从哪来继续HookJDSecurity.getInstance().getDeviceId()发现它读取的是/data/data/com.jingdong.app.mall/shared_prefs/device_info.xml里的device_id字段。至此validate的生成要素全部浮出水面滑块轨迹JSON 当前时间戳 设备ID。4.3 SO层SM4密钥提取从Ghidra到Python的无缝衔接回到libjdsec.so用Ghidra分析Java_com_jd_lib_security_JDSecurity_encrypt函数。反编译代码显示它调用了内部函数sm4_encrypt_with_key而密钥key是一个长度为16的字节数组。在Ghidra的Data视图里搜索0x00,0x01,0x02...密钥常量特征最终在.rodata段找到00102340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00102350 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 ................01 02 03 ... 10就是SM4密钥用Python验证from Crypto.Cipher import SM4 key bytes([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]) cipher SM4() cipher.mode SM4.MODE_ECB cipher.key key plaintext b{trace:[{x:10,t:1678886400000},{x:20,t:1678886400100}],timestamp:1678886400200,device_id:abc123} # 注意SM4 ECB需要PKCS7填充 padded plaintext (16 - len(plaintext) % 16) * bytes([16 - len(plaintext) % 16]) ciphertext cipher.encrypt(padded) print(ciphertext.hex()) # 输出 5a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d与Frida日志完全一致成功这意味着我们已完全掌握validate的生成逻辑。现在可以脱离App用Python批量生成任意滑块的validate用于自动化测试或协议研究。4.4 本地化封装构建可复用的jd_slide_signer模块将上述逻辑封装为Python模块是逆向成果落地的关键一步。我创建了jd_slide_signer.pyimport json import time import base64 from Crypto.Cipher import SM4 from Crypto.Util.Padding import pad class JDSlideSigner: def __init__(self, device_id: str, sm4_key: bytes None): self.device_id device_id self.sm4_key sm4_key or bytes([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]) def generate_track(self, x_coords: list) - str: 生成滑块轨迹JSON并Base64编码 trace [{x: x, t: int(time.time() * 1000) i * 100} for i, x in enumerate(x_coords)] return base64.b64encode(json.dumps({trace: trace}).encode()).decode() def sign_validate(self, track_b64: str) - str: 生成validate参数 # 构造加密原文 payload { trace: json.loads(base64.b64decode(track_b64).decode())[trace], timestamp: int(time.time() * 1000), device_id: self.device_id } plaintext json.dumps(payload, separators(,, :)).encode() # SM4加密 cipher SM4() cipher.mode SM4.MODE_ECB cipher.key self.sm4_key padded pad(plaintext, 16) ciphertext cipher.encrypt(padded) return ciphertext.hex() # 使用示例 signer JDSlideSigner(device_idyour_device_id_here) track signer.generate_track([10, 20, 30, 40]) validate signer.sign_validate(track) print(ftrack: {track}) print(fvalidate: {validate})这个模块可以无缝集成到任何Python项目中。比如用Selenium模拟滑块后直接调用signer.sign_validate(track)就能得到服务器认可的validate。它不再依赖Frida、不再需要手机、不再受App更新影响——只要密钥不变逻辑就永不过期。这才是逆向分析的终极价值把黑盒变成白盒把不可控变成可控。5. 常见问题与排查技巧实录那些只有踩过坑才知道的真相逆向分析最大的成本不是时间而是“重复踩同一个坑”。下面这些是我和团队在过去三年里用真金白银买新手机、充会员、交罚款换来的独家经验。5.1 Frida Hook失效的五大原因及速查表现象可能原因排查命令解决方案frida -U -f com.xxx启动后App立即闪退App检测到frida-server进程adb shell ps -A | grep frida改用frida -U -f com.xxx --no-pause或用frida-ps -U确认进程名Java.use(xxx)报错undefinedJava类未加载或混淆严重frida -U -f com.xxx -l list_classes.js先用Java.enumerateLoadedClasses()列出所有类再找近似名Hook到函数但console.log无输出Frida日志缓冲区满或App杀后台frida -U -f com.xxx -l script.js --runtimev8换V8引擎或在脚本开头加console.log function(){};清空默认输出Native函数Hook后App崩溃Hook点破坏了寄存器状态Interceptor.attach(func, {onLeave: function() {this.context.x0 0;}})在onLeave里手动恢复关键寄存器如x0、x1Module.load(libxxx.so)报错not foundSO路径错误或架构不匹配adb shell ls /data/app/com.xxx-*/lib/*/libxxx.so用adb shell进入App沙盒用find命令精确查找SO路径提示frida --version必须与frida-server版本严格一致。我见过太多人因为frida 15.2.2配frida-server 15.1.0导致Hook失败。每次升级务必adb push新版本server。5.2 SO分析中的“假阳性”陷阱如何区分真密钥与干扰项Ghidra里搜到的01 02 03 ... 10未必就是SM4密钥。京东常用“密钥混淆术”在.rodata段放一个假密钥真密钥在.data段动态生成。判断依据有三访问频率真密钥会被sm4_setkey_enc频繁读取假密钥可能只被printf调用一次内存属性真密钥所在地址readelf -S libjdsec.so显示为PROGBITS可读可写假密钥在RODATA只读交叉引用用Ghidra的References To功能看该地址被哪些函数调用。如果只有init_dummy_key()调用大概率是假的如果被encrypt_data、decrypt_data共同调用才是真的。我曾在一个版本里被一个00 00 00 ... 00的假密钥误导了两天。最后发现真密钥是通过getrandom()系统调用在运行时生成的根本不在静态SO里。这时就必须回到Frida在sm4_setkey_enc函数入口处Hook并打印key参数的内存地址再用ptr(key).readByteArray(16)读取真实密钥。5.3 设备指纹的“幽灵变量”除了device_id还有三个隐藏字段device_id只是设备指纹的冰山一角。京东实际校验的至少包含四个字段device_id存储在shared_prefs/device_info.xml相对稳定android_idSettings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID)重置网络后会变mac_addressWifiManager.getConnectionInfo().getMacAddress()Android 10已废弃但App仍会fallback到其他标识imeiTelephonyManager.getImei()需要READ_PHONE_STATE权限且非必要不读。最坑的是android_id。很多自动化脚本只固定device_id结果跑几天就失效。原因是android_id变了而SO层的加密逻辑会把android_id拼进validate的原文里。解决方案在Frida脚本里HookSettings.Secure.getString强制返回一个固定值var Secure Java.use(android.provider.Settings$Secure); Secure.getString.overload(android.content.ContentResolver, java.lang.String).implementation function (cr, name) { if (name android_id) { return 1234567890abcdef; // 固定返回 } return this.getString(cr, name); };这样无论系统怎么变android_id始终如一。5.4 环境配置的“版本地狱”Clion、NDK、JDK的黄金组合网络热词里在clion中配置jni环境的抱怨根源在于版本错配。我的黄金组合2024年实测Clion 2023.2.5对CMake 3.22支持最好且内置JNI模板NDK r25bndk-build和cmake双支持libjdsec.so的编译依赖此版本OpenJDK 17.0.2Lombok 1.18.30的最低要求且与Android Gradle Plugin 8.1兼容CMake 3.22.1find_package(OpenSSL REQUIRED)能正确找到NDK自带的OpenSSL。错配案例用Clion 2024.1 NDK r26会导致#include jni.h报红因为r26的jni.h路径变了。解决方法在Clion的Settings → Build → CMake里手动设置CMAKE_ANDROID_NDK指向r25b路径。记住逆向不是追求最新而是追求最稳。我所有项目的build.gradle里都锁死了ndkVersion 25.2.9577136绝不允许自动升级。6. 工具链与资源推荐一份不忽悠的“生产力清单”工欲善其事必先利其器。以下是我日常使用的工具全部开源、免费、无广告且经过千次实战检验。6.1 核心工具链Linux/macOS优先Frida官网frida.repip install frida-tools。必备插件frida-trace函数调用追踪、frida-compileTypeScript编译GhidraNSA开源官网ghidra-sre.org。关键配置Analysis → Auto Analyze → Select All勾选Decompiler和Data Type ArchiveJADXGitHubskylot/jadxGUI版jadx-gui。技巧Search → Full Text Search比CtrlF更强大adbAndroid SDK Platform-Toolsadb shell是你的瑞士军刀CyberChef在线工具gchq.github.io/CyberChefBase64/Hex/SM4加解密一站式搞定。6.2 辅助资源与学习路径SO分析入门《Reverse Engineering for Beginners》免费PDF重点看Chapter 7 “ARM64 Assembly”JNI深度指南Oracle官方《JNI Specification》docs.oracle.com/javase/8/docs/technotes/guides/jni/**