1. 项目概述与核心思路拆解最近在安全研究领域一个常见且极具价值的课题就是对移动应用App的登录流程进行安全分析。这不仅仅是出于好奇更是为了理解现代应用如何保护用户数据以及其安全机制的强度。我这次的目标是逆向一个具体App的登录接口完整还原其从请求发起、数据加密到服务器验证的全过程。整个过程会用到抓包分析和动态Hook两大核心武器最终目标是清晰地看到明文密码是如何一步步变成网络传输中那串“天书”的。这个项目适合对移动安全、协议分析或逆向工程感兴趣的开发者、安全研究员甚至是对自己所用App安全性存疑的进阶用户。通过它你不仅能学会一套实用的分析流程更能深刻理解“前端加密”在实战中究竟意味着什么。很多App宣称的“加密传输”其实并非铁板一块其强度高度依赖于加密算法的实现和密钥的保护方式。我们的工作就是像侦探一样层层剥开这层外壳。整个逆向工程的核心思路可以概括为“动静结合”。静态分析阅读代码固然重要但对于经过混淆、加固或核心逻辑在Native层的应用往往事倍功半。因此我采用的策略是首先通过抓包确定网络交互的入口和出口锁定关键的数据字段然后通过Frida进行动态Hook在应用运行时“窥探”或“篡改”关键函数的输入输出从而直接定位到加密算法的具体实现逻辑。这是一种从外到内、从现象到本质的高效分析方法。2. 环境与工具链准备工欲善其事必先利其器。一套稳定、高效的工具链是逆向分析成功的基石。下面我会详细列出本次分析用到的核心工具、配置要点以及我踩过坑后总结的最佳实践。2.1 抓包环境搭建代理与证书抓包是逆向的“眼睛”我们的第一要务就是能看到App发出的所有网络请求。对于HTTPS流量这涉及到中间人攻击MitM的基本原理我们需要让App信任我们自己的CA证书。1. 代理工具选择Charles 与 Fiddler我主要使用Charles它的界面直观映射Map Local/Remote、断点Breakpoints和重写Rewrite功能对分析流程异常友好。Fiddler也是一个经典选择特别是在Windows平台它的脚本扩展能力很强。两者择一即可我偏好Charles的稳定性。关键配置步骤安装根证书在Charles中Help - SSL Proxying - Install Charles Root Certificate将证书安装到“受信任的根证书颁发机构”存储中。这是让系统信任Charles的关键。启用SSL代理Proxy - SSL Proxying Settings添加一个通配符配置如*:*端口443。这样Charles会解密所有HTTPS流量。配置代理记住Charles的代理端口默认8888。在测试手机或模拟器的Wi-Fi设置中手动配置代理服务器为运行Charles的电脑IP端口为8888。在设备上安装证书用手机浏览器访问chls.pro/ssl下载并安装Charles的证书。对于Android 7.0及以上及iOS必须将证书安装到“系统级”或“VPN和应用”信任区域否则App可能不认用户级证书。这是第一个大坑。注意很多现代App尤其是金融、社交类应用会启用“证书锁定”Certificate Pinning。一旦检测到通信链中的证书不是它预期的比如我们的Charles证书就会直接断开连接或报错。遇到这种情况抓包工具会显示SSL handshake failed。这时就需要后续的Frida出马来绕过这个保护。2. 备选方案Packet Capture 或 HttpCanary如果代理方式因证书锁定失效可以尝试在已Root的Android设备上使用Packet Capture这类无需配置代理的抓包工具。它们利用系统的VPN服务在本地实现流量劫持有时能绕过简单的证书检查。但对于强校验的App依然可能失败。2.2 动态分析利器Frida 环境配置当抓包看到的是加密后的数据或者根本抓不到包时就需要深入到应用运行时内部去观察。Frida就是一个“注入式”的动态分析框架它允许我们将自己的JavaScript脚本注入到目标App的进程中去Hook钩住任何我们感兴趣的Java/Objective-C/Native函数。1. 安装Frida在电脑服务端上安装Frida工具包和Python库pip install frida-tools同时需要根据你的测试设备架构arm, arm64, x86等下载对应的frida-server二进制文件。这是运行在设备上的守护进程。2. 部署与运行Frida-server将下载的frida-server推送到Android设备的/data/local/tmp/目录。赋予可执行权限chmod 755 frida-server。在设备的adb shell中运行它./frida-server 。保持这个shell窗口开启或者使用nohup让它在后台运行。3. 基础连接与验证在电脑上打开另一个终端运行frida-ps -U如果能看到设备上运行的进程列表说明连接成功。-U参数代表连接到USB设备。4. 常用工具与脚本frida-trace快速追踪函数调用非常适合初次探索。例如frida-trace -U -i “open” com.target.app可以追踪该App的所有open函数调用。Objection基于Frida的运行时移动安全评估工具集成了很多常用命令如绕过SSL Pinning、内存搜索等能极大提升效率。pip install objection objection -g com.target.app explore # 在 objection 会话中直接运行 android sslpinning disable 尝试绕过证书锁定。环境踩坑实录端口冲突Frida默认使用27042端口确保该端口未被占用。如果连接失败可以尝试frida -H 设备IP:端口指定端口。版本匹配frida-server的版本必须与电脑上安装的frida和frida-tools的版本严格一致否则会出现协议错误。这是最常遇到的问题。设备Root/越狱在Android上充分使用Frida通常需要Root权限iOS需要越狱。对于非Root设备可以考虑使用“重打包”的方式将Frida Gadget嵌入到APK中但过程更复杂。3. 抓包分析定位登录请求与加密参数环境准备好后我们开始第一阶段的侦查抓包。目标是找到登录请求并初步判断其加密特征。3.1 启动抓包与触发登录打开Charles确保代理已开启且设备配置正确。清空Charles的会话记录然后在手机上打开目标App进行登录操作。在Charles的会话界面你应该能看到一系列HTTP/HTTPS请求。关键识别点域名/路径寻找与登录、认证相关的域名或URL路径常见如/login,/auth,/user/signin,/api/v1/token等。请求方法通常是POST因为登录需要提交表单数据。请求体格式查看Content-Type如果是application/json那么请求体是JSON格式如果是application/x-www-form-urlencoded则是键值对格式。JSON格式更为常见。找到疑似登录的请求后重点查看其请求体。你期望看到的是username和password但实际看到的很可能是类似这样的东西{ “username”: “testUser”, “password”: “a7f3d8c1e5b2...一串很长的、固定或变化的密文” “timestamp”: “1646389200000”, “nonce”: “abcdef123456”, “sign”: “sha256_of_some_params” }或者密码字段名可能被混淆成pwd,encryptedPassword,cipher等。3.2 分析加密特征与模式看到加密后的密码我们需要初步判断其加密模式这能为后续的Hook提供方向。固定密文如果同一个密码每次登录生成的密文都完全一样那很可能使用的是对称加密如AES ECB模式或简单的哈希但哈希不可逆通常用于签名而非加密密码本身。更可能是使用了静态密钥的加密。变化密文如果同一个密码每次生成的密文都不同那说明加密过程引入了随机量。这可能是对称加密的CBC/CFB等模式使用了随机IV初始化向量。RSA非对称加密使用了服务器的公钥每次加密结果自然不同。先对密码进行某种处理如拼接时间戳、随机数再哈希或加密。其他参数密切注意像timestamp时间戳、nonce随机数、sign签名这样的字段。它们通常用于防重放攻击和请求完整性校验。签名sign往往是对所有请求参数按特定规则排序后进行哈希计算如MD5, SHA256得到的值。这个签名算法也是逆向的重点之一服务器端会校验它。实操心得在Charles中善用“Compose”功能。你可以手动重放Repeat登录请求并修改请求体中的参数观察服务器的响应。例如你修改sign字段的一个字符如果服务器返回“签名错误”那就证实了sign字段的作用。你也可以尝试只发送明文密码看服务器是否接受通常不会这能帮你确认加密是发生在客户端还是服务端现代App基本都是客户端加密。4. Frida Hook 实战定位关键加密函数抓包告诉我们“是什么”Frida则要告诉我们“怎么做”。现在我们需要在App运行时找到那个将明文密码变成密文的函数。4.1 确定Hook目标Java层还是Native层移动App的代码主要分两层Java/Kotlin层Android / Objective-C/Swift层iOS大部分业务逻辑在这里。加密可能直接调用系统API如Cipher.getInstance(“AES”)或第三方库如CryptoJS的Java移植。Native层C/C核心、高强度的加密算法或自研算法为了安全和性能可能会放在so库Android或dylib/frameworkiOS中。侦查策略先Java后Native大多数App的加密仍在Java层实现。我们先从Java层入手。搜索关键字符串使用Frida的搜索功能或使用objection命令android hooking list classes和android hooking search classes来查找包含“crypto”, “aes”, “rsa”, “encrypt”, “decode”, “cipher”, “security”, “md5”, “sha”等关键词的类名。Hook 系统加密API这是一个非常有效的入口。直接Hook Java的javax.crypto.Cipher类的doFinal方法或者java.security.MessageDigest的digest方法。当App调用这些方法进行加密或哈希时我们就能截获输入和输出。4.2 编写Frida脚本Hook加密函数假设我们通过猜测或搜索发现了一个可疑的类com.example.app.security.EncryptUtils其中有一个方法public static String encryptPassword(String plainText)。下面是一个基础的Frida脚本模板用于Hook这个方法Java.perform(function () { // 定位目标类 var EncryptUtils Java.use(“com.example.app.security.EncryptUtils”); // Hook 目标方法 EncryptUtils.encryptPassword.implementation function (plainText) { // 打印调用栈帮助理解函数调用链 console.log(“[EncryptPassword] Call Stack:”); console.log(Java.use(“android.util.Log”).getStackTraceString(Java.use(“java.lang.Exception”).$new())); // 打印传入的明文密码 console.log(“[EncryptPassword] 明文密码: “ plainText); // 调用原函数获取加密结果 var encryptedResult this.encryptPassword(plainText); // 打印加密后的结果 console.log(“[EncryptPassword] 加密结果: “ encryptedResult); // 将结果返回不影响程序正常运行 return encryptedResult; }; console.log(“[*] Hook com.example.app.security.EncryptUtils.encryptPassword 已植入”); });将上述脚本保存为hook_encrypt.js然后使用Frida CLI注入到目标进程frida -U -f com.target.app -l hook_encrypt.js --no-pause-f表示启动App-l加载脚本。如果App已在运行可以用-n指定进程名。脚本进阶技巧重载方法处理如果encryptPassword有多个重载如参数不同需要使用overload来指定。EncryptUtils.encryptPassword.overload(‘java.lang.String’, ‘java.lang.String’).implementation function (a, b) {...}Hook构造函数有时密钥会在对象初始化时设置。可以Hook类的构造函数$init。修改返回值在implementation函数中你可以不调用原函数而是直接return “my_fake_cipher”;用于测试服务器对错误密文的反应。文件输出将日志写入手机文件便于分析大量数据。var file new File(“/sdcard/frida_log.txt”, “a”); file.write(“[LOG] “ data “\n”); file.flush();4.3 追踪与参数关联找到签名生成函数用同样的方法我们需要找到生成sign签名的函数。通常这个函数会接收一个包含所有参数的Map或JSONObject或者拼接好的字符串。寻找策略搜索搜索类或方法名包含 “sign”, “signature”, “md5”, “sha”, “getSign” 等。从结果反推我们已经从抓包知道了sign的值。可以尝试Hook所有可能的哈希函数MessageDigest.getInstance(“MD5”).digest()打印其输入和输出的十六进制字符串与抓包中的sign值进行比对。如果匹配就找到了。参数拼接逻辑找到签名函数后重点观察其参数拼接顺序。是keyvaluekeyvalue格式吗是否过滤了某些字段如sign本身是否在拼接后加了某个固定的“盐值”salt这个逻辑必须完全还原否则自己生成的签名永远对不上。5. 算法还原与验证通过Frida Hook我们可能已经拿到了明文、密文、密钥如果密钥硬编码在代码中以及签名算法的输入输出。接下来就是还原算法。5.1 分析加密算法与模式如果Hook到了Cipher.getInstance查看传入的参数如“AES/CBC/PKCS5Padding”这直接指明了算法、模式和填充方式。如果Hook到了密钥查看密钥是如何生成的。是固定的字符串还是从服务器动态获取亦或是通过某种密钥派生函数如PBKDF2从用户密码派生如果涉及RSA需要找到公钥。公钥可能是硬编码的Base64字符串也可能从服务器接口获取。Hook住加载公钥的地方。5.2 使用Python还原算法在电脑上用Python的加密库如pycryptodome,cryptography重新实现我们分析出的加密和签名逻辑。这是最终的验证步骤。示例还原一个AES-CBC加密假设我们从Frida日志中得知算法AES/CBC/PKCS7Padding(在Python中PKCS7和PKCS5在AES中通常等同处理)密钥“0123456789abcdef0123456789abcdef”(32字节AES-256)IV“abcdefghijklmnop”(16字节从请求的某个字段或固定值获得)明文密码“myPassword123”from Crypto.Cipher import AES from Crypto.Util.Padding import pad import base64 def encrypt_password(plain_text, key_hex, iv_hex): key bytes.fromhex(key_hex) iv bytes.fromhex(iv_hex) if iv_hex else bytes(16) # 如果没有IV使用全零 cipher AES.new(key, AES.MODE_CBC, iv) # 注意编码和填充 plain_bytes plain_text.encode(‘utf-8’) padded_bytes pad(plain_bytes, AES.block_size) encrypted_bytes cipher.encrypt(padded_bytes) # 查看密文格式可能是Base64或Hex ciphertext_b64 base64.b64encode(encrypted_bytes).decode(‘utf-8’) ciphertext_hex encrypted_bytes.hex() return ciphertext_b64, ciphertext_hex key “0123456789abcdef0123456789abcdef” iv “6162636465666768696a6b6c6d6e6f70” # “abcdefghijklmnop” 的hex plain “myPassword123” b64_result, hex_result encrypt_password(plain, key, iv) print(f“Base64密文: {b64_result}”) print(f“Hex密文: {hex_result}”)运行这个脚本将输出的密文与抓包中看到的password字段值进行比对。如果一致恭喜你成功还原签名算法还原同理用Python按照Hook到的拼接规则和哈希算法如MD5、HMAC-SHA256重新计算sign与抓包数据比对。5.3 完整流程模拟与测试将还原的加密函数和签名函数整合到一个脚本中并模拟整个登录请求的构建过程获取当前时间戳timestamp。生成随机字符串nonce。使用还原的加密函数对密码进行加密得到encryptedPassword。将所有请求参数包括username,encryptedPassword,timestamp,nonce等但不包括sign按规则拼接成字符串signStr。使用还原的签名函数如hashlib.md5(signStr.encode()).hexdigest()计算sign。将参数组装成JSON或表单格式用requests库发送POST请求。如果服务器返回了登录成功的响应如包含token或session那么你的逆向工作就取得了圆满成功。6. 常见问题、对抗手段与进阶技巧在实际操作中你绝不会一帆风顺。App的开发者会采用各种手段增加逆向难度。6.1 常见问题排查表问题现象可能原因排查思路与解决方案Charles抓不到任何HTTPS包1. 证书未正确安装或信任。2. App使用了证书锁定。1. 确认手机已安装并信任Charles根证书系统级。2. 使用Frida Objection尝试禁用SSL Pinning (android sslpinning disable)。3. 尝试使用Packet Capture等VPN式抓包工具。Frida无法附加到进程1. 设备未Root/越狱。2. frida-server未运行或版本不匹配。3. App有反调试/反Frida检测。1. 确认设备环境。2. 检查frida-server进程和版本。3. 尝试使用-f参数在App启动时注入而非附加。4. 使用Frida的隐身模式或修改Frida特征进行对抗。Hook系统加密API无输出1. App使用自定义JNI或纯Native加密。2. 混淆导致类名/方法名改变。3. Hook点不对如Hook了错误的重载。1. 转战Native层Hook使用Interceptor.attachHooklibcrypto.so中的函数如AES_encrypt。2. 尝试Hook更底层的函数或通过参数特征如字符串搜索定位。3. 使用frida-trace进行大规模追踪。加密结果每次不同但密钥固定使用了随机IV如CBC模式或盐值。通过Hook找到IV或盐值的来源。它可能是一个固定的字段也可能是随机生成后放在请求的另一个参数里服务器需要用它来解密。签名永远无法匹配1. 参数拼接顺序错误。2. 有未发现的隐藏参数。3. 签名前对参数值进行了额外的URL编码或转换。4. 使用了动态盐从服务器获取。1. 仔细分析Hook到的签名函数输入字符串与自己的拼接结果逐字符比对。2. 使用“差分测试”修改一个参数看签名变化推断规则。3. Hook网络请求库如OkHttp的RequestBody查看最终发出的原始数据。6.2 对抗手段与应对策略代码混淆类名、方法名变成无意义的a,b,c。应对不要依赖名称而是通过行为特征来定位。例如搜索调用Cipher.getInstance或MessageDigest.getInstance的代码位置。或者Hook所有java.lang.String的getBytes方法观察哪些输入最终产生了密文。反调试/反注入App会检测调试器或Frida的存在。应对使用修改过的、特征不明显的Frida。或者使用“等待”策略在App启动完成、反检测逻辑执行后再注入脚本。算法白盒化/VM化将核心加密算法用LLVM或自定义虚拟机保护起来。这是最难对付的情况。应对可能需要深入分析自定义字节码或LLVM IR或者尝试从内存中dump出解密后的代码片段。这属于高级逆向范畴。密钥动态获取密钥不是硬编码而是登录前从某个接口获取有时还是一次性的。应对Hook获取密钥的接口并在加密时使用这个动态密钥。这意味着你的模拟登录脚本需要先请求“密钥接口”。6.3 个人实操心得与建议保持耐心与记录逆向是一个反复试错的过程。详细记录每一个步骤、每一个猜想、每一次测试的结果成功或失败。使用笔记软件或Markdown文档。由易到难先从一些简单的、没有强保护的App练手建立信心和流程感。不要一开始就挑战头部金融或社交App。理解业务逻辑逆向不只是技术活。思考一下开发者的意图为什么用这种加密为什么加这个参数理解业务逻辑能帮你更快地猜对方向。工具组合使用不要只依赖一种工具。Charles/Fiddler Frida IDA Pro/Ghidra用于静态分析Native库 JADX/GDA用于反编译Android Java代码组合使用效率倍增。合法性边界所有分析请在你自己拥有完全控制权的设备和应用或明确授权测试的应用上进行。切勿对他人资产或未授权目标进行逆向分析这不仅是道德问题更可能涉及法律风险。技术的目的是学习和提升防御能力。逆向工程就像解谜当你通过抓包和Hook一步步将黑盒里的逻辑还原成清晰的代码时那种成就感是无与伦比的。它不仅锻炼了你的技术能力更让你对软件的安全构建有了更深层次的理解。希望这份详细的流程和心得能为你打开移动应用安全分析的大门。