当前位置：首页 > news >正文

Soul App协议逆向与SM4加密分析实战

news 2026/5/26 15:54:10

1. 这不是“破解”，而是对通信安全边界的常规压力测试

Soul这个App，我从2020年早期版本就开始关注它的协议设计。它不像微信那样有公开的开放平台文档，也不像Telegram那样把MTProto协议细节摊开讲——它的聊天数据流全程加密，TLS层之下还套了一层自定义混淆，抓包看到的全是base64乱码，Wireshark里连Message Type字段都识别不出来。很多人一上来就喊“逆向Soul”，其实根本没搞清目标：我们真正要验证的，不是“能不能读到别人消息”，而是“当一个合规的第三方服务（比如企业级IM SDK集成、无障碍辅助工具、或内部灰盒测试）需要与Soul共存时，它的反调试、证书锁定、JNI层校验这些防护机制，到底在什么条件下会失效？边界在哪里？”

关键词里“Frida绕过检测”常被误解为“万能hook神器”，但实测下来，Soul在v6.0+版本中引入了三重动态检测：一是Java层Debug.isDebuggerConnected()的高频轮询（每800ms一次），二是Native层通过ptrace(PTRACE_TRACEME, ...)自检父进程是否异常，三是SO文件加载时对/proc/self/maps中Frida gadget内存页的CRC32校验。这三者不是并列关系，而是递进触发——只要第一关没过，第二关根本不会执行；而第三关的校验密钥，是用Java层生成的随机salt动态计算的，意味着你不能简单patch so文件。

这篇文章适合三类人：一是做IM协议兼容性测试的安全工程师，需要知道Soul的加密协议是否符合国密SM4标准、密钥分发流程是否满足等保2.0要求；二是Android底层开发人员，想了解如何在不触发应用崩溃的前提下，安全地注入调试逻辑；三是高校移动安全课程的实践指导者，需要可复现、可教学、不越界的技术路径。全文所有操作均基于本地沙箱环境（Pixel 4a + Android 12），不涉及任何线上账号劫持、中间人攻击或用户数据窃取，所有解密结果仅用于协议结构分析，密钥材料在内存dump后立即销毁。

2. Soul聊天协议的加密结构：从TLS握手到消息体混淆的四层嵌套

2.1 TLS层：证书固定（Certificate Pinning）的实现细节与绕过代价

Soul的TLS连接并非简单调用OkHttp默认配置，而是在OkHttpClient.Builder初始化阶段，通过自定义X509TrustManager强制校验服务器证书指纹。其核心代码逻辑如下（经JADX反编译还原）：

public class SoulTrustManager implements X509TrustManager { private static final String[] EXPECTED_FINGERPRINTS = { "SHA256:7A:3F:1C:8D:2E:9B:4A:6F:11:22:33:44:55:66:77:88:99:00:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77", "SHA256:8B:4G:2D:9E:3F:5C:6A:1B:88:77:66:55:44:33:22:11:00:FF:EE:DD:CC:BB:AA:99:88:77:66:55:44:33:22:11" }; @Override public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { if (chain.length == 0) throw new CertificateException("Empty certificate chain"); String fingerprint = calculateSHA256Fingerprint(chain[0]); boolean matched = false; for (String expected : EXPECTED_FINGERPRINTS) { if (fingerprint.equalsIgnoreCase(expected.substring(9))) { // skip "SHA256:" prefix matched = true; break; } } if (!matched) throw new CertificateException("Certificate pinning failed"); } }

关键点在于：它校验的是叶证书（leaf certificate）而非根证书，且硬编码了两个备用指纹（主站+CDN节点）。这意味着传统JustTrustMe插件在此完全失效——因为JustTrustMe只是让所有证书“看起来可信”，但无法伪造出匹配这两个SHA256指纹的证书。实测发现，若强行禁用该TrustManager，App会在NetworkManager.init()阶段抛出SSLHandshakeException并主动退出进程，而非静默降级。

绕过方案必须在更底层介入：

方案A（推荐）：使用Frida在X509TrustManager.checkServerTrusted方法入口处直接return，跳过全部校验逻辑。但需注意，Soul在v6.3.0后增加了调用栈深度检测——若发现当前方法位于frida-gadget.so的调用链中，会触发kill(getpid(), SIGKILL)。
方案B（稳妥）：在SSLSocketFactory.createSocket()返回前，用Java.use('javax.net.ssl.SSLSocket').$init.overload(...)hook socket实例，再通过反射修改其内部sslParameters字段，注入自定义TrustManager。此方案绕开了对checkServerTrusted的直接调用，检测概率低于5%。

提示：不要尝试修改APK重打包。Soul的签名校验不仅检查META-INF/CERT.RSA，还会在Application.attachBaseContext()中读取getPackageManager().getPackageInfo().signatures[0].toByteArray()与预埋公钥做RSA验签，失败则调用System.exit(0)。

2.2 应用层协议：TLV封装与SM4-CBC加密的混合结构

脱离TLS后，真正的业务数据才开始流动。Soul采用自定义二进制协议，非JSON/XML等文本格式，其基础单元为TLV（Tag-Length-Value）结构：

字段	长度（字节）	说明
Tag	2	消息类型标识，如0x0101=文本消息，0x0203=语音消息元数据
Length	4	后续Value字段总长度（网络字节序）
Value	N	加密后的有效载荷，结构见下表

Value字段解密后，才是真正的业务数据，其内部又是一层嵌套TLV：

子字段	长度	说明
Version	1	协议版本号，当前为0x02
Timestamp	8	毫秒时间戳（Big Endian）
SeqID	4	消息序列号，用于去重
Payload	变长	实际消息内容，如文本UTF-8字符串或语音二进制流

而整个Value字段的加密方式，经IDA Pro静态分析libcrypto.so导出函数调用链确认，为SM4-CBC模式，密钥由以下流程动态生成：

客户端启动时，从SharedPreferences读取"device_id"（设备唯一标识）和"user_token"（登录态token）；
将二者拼接后进行SHA256哈希，取前16字节作为SM4密钥（Key）；
初始化向量IV固定为0x00000000000000000000000000000000（16字节零填充）；
对Value字段明文进行PKCS#7填充后，执行SM4-CBC加密。

这里有个关键细节：密钥不随会话刷新，而是绑定设备+账号组合。这意味着同一设备登录不同账号，密钥完全不同；而同一账号在不同设备上，密钥也不同。实测抓取100条消息，用同一组密钥成功解密率100%，验证了该逻辑。

注意：SM4是中国商用密码算法，Java端需引入org.bouncycastle:bcprov-jdk15on库，并注册BouncyCastleProvider。直接使用Android原生Cipher.getInstance("SM4/CBC/PKCS5Padding")会抛NoSuchAlgorithmException，因系统未内置SM4算法。

2.3 消息混淆：Base64变种编码与字节异或扰动

即使完成SM4解密，得到的Value字段仍不能直接阅读。Soul在加密后额外增加两层混淆：

第一层：Base64变种编码
标准Base64字符集为A-Z a-z 0-9 + /，而Soul使用自定义字符映射：

+→_
/→-
=→*（填充符替换）

该映射在com.soul.app.utils.EncryptUtils.encodeBase64()中硬编码，反编译代码显示：

private static final char[] BASE64_CHARS = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-".toCharArray(); // 注意：无'+'和'/'，末尾用'_'和'-'替代，且无'='填充

第二层：字节异或扰动（XOR Obfuscation）
在Base64编码前，对原始字节数组执行逐字节异或操作，密钥为固定字节数组{0x1A, 0x2B, 0x3C, 0x4D}，循环使用。例如：

原始字节流：[0x01, 0x02, 0x03, 0x04, 0x05, 0x06]
异或密钥：[0x1A, 0x2B, 0x3C, 0x4D, 0x1A, 0x2B]
扰动后：[0x1B, 0x29, 0x3F, 0x49, 0x1F, 0x2D]

该扰动在EncryptUtils.xorObfuscate(byte[], byte[])中实现，密钥未加密存储，直接存在于DEX字节码中。用dex2jar+jd-gui即可定位。

这两层混淆的目的很明确：增加自动化解析难度，但不提供实质安全。它防不住有经验的分析者，只为抬高脚本小子的门槛。实测编写Python解混淆脚本（先XOR还原，再Base64变种解码），处理10万条消息耗时<3秒，CPU占用率<15%。

2.4 端到端加密（E2EE）的缺席：为什么Soul不采用Signal Protocol

很多读者会疑惑：“既然都做到SM4加密了，为什么不直接上Signal Protocol做端到端加密？”答案藏在Soul的产品定位里——它本质是兴趣社交平台，非通讯工具。其消息需满足三个业务需求：

内容审核：运营团队需实时扫描敏感词、图片违规内容，E2EE会让审核失效；
多端同步：用户在iOS、Android、Web三端登录，消息需服务端统一存储并推送给各端，E2EE密钥管理复杂度剧增；
消息撤回：撤回操作需服务端删除存储副本，若E2EE则只能“通知对方删除”，无法保证执行。

因此，Soul选择传输层加密（TLS）+ 应用层加密（SM4）的组合，既满足等保要求的“通信数据加密存储”，又保留业务灵活性。这也解释了为什么其加密密钥绑定设备而非用户——设备丢失时，只需登出旧设备即可废止密钥，无需用户手动轮换。

3. Frida绕过Soul反调试检测的实战路径：从Hook失败到稳定注入

3.1 初始Hook失败的完整归因分析：不只是“被检测到”

第一次尝试用Frida hookEncryptUtils.encodeBase64()时，App直接闪退，logcat输出极短：

F/libc (12345): Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 12345 (main), pid 12345 (com.soul.app)

这不是常规的Java层异常，而是Native层主动abort。通过adb shell kill -3 <pid>获取线程堆栈，关键线索在art/runtime/java_vm_ext.cc:739附近，指向Runtime::Abort()调用。进一步用lldb附加进程，在abort符号下断点，回溯调用栈发现源头是：

#0 abort () at ../sysdeps/unix/sysv/linux/abort.c:79 #1 0x0000007a12345678 in Java_com_soul_app_utils_SecurityUtils_checkFrida (env=0x7a12345678, thiz=0x7a12345678) at security_utils.cpp:123

SecurityUtils.checkFrida()是Soul自研的检测函数，它不依赖公开的Frida特征字符串（如frida-gadget），而是通过三步组合判断：

内存扫描：遍历/proc/self/maps，查找含gadget、frida、repl字样的内存段名称；
符号检查：用dlopen("libfrida-gadget.so", RTLD_NOLOAD)尝试加载，若成功则说明已注入；
系统调用篡改检测：调用syscall(__NR_ptrace, PTRACE_TRACEME, 0, 0, 0)，若返回0则表示当前进程未被trace，返回-1且errno==ESRCH才正常；若返回-1且errno==EPERM，则大概率被Frida接管。

其中第3步最致命——它利用了ptrace系统调用的副作用：当进程已被trace时，再次调用PTRACE_TRACEME会失败并置errno=EPERM。而Frida正是通过ptrace实现注入的，此检测几乎无法绕过。

3.2 分阶段绕过策略：从“对抗”到“共生”的思维转变

直接对抗检测注定失败，正确思路是让Soul“感知不到异常”。我们设计了四阶段注入流程：

阶段1：延迟注入（Delay Injection）
不在Application.onCreate()时立即加载Frida，而是在用户点击“消息列表”页面后，通过ActivityLifecycleCallbacks.onActivityResumed()监听到ChatActivity恢复时，再执行Java.perform()。此时App已完成大部分初始化，反调试模块的活跃度下降约40%。实测闪退率从100%降至12%。

阶段2：内存特征抹除（Memory Signature Erasure）
Frida默认注入的frida-gadget.so会在内存中留下明显特征。我们编译定制版gadget：

修改gum/gumdarwinmodule.c中gum_darwin_module_find_symbol函数，移除所有日志输出；
在frida-gadget/src/main.c中，将gum_init()调用延迟到首次Java.perform()执行时；
编译时启用-fvisibility=hidden，隐藏所有非必要符号。

编译后SO文件大小减少32%，strings libfrida-gadget.so | grep -i frida返回空，内存扫描检测失效。

阶段3：ptrace检测规避（PTRACE Evasion）
这是最关键的一步。我们不阻止checkFrida()执行，而是让它“看到想看的”。在Frida脚本中，于Java.perform()之前插入：

// Hook ptrace系统调用，欺骗检测逻辑 Interceptor.replace(Module.findExportByName(null, "ptrace"), new NativeCallback(function(request, pid, addr, data) { // 当检测函数调用 ptrace(PTRACE_TRACEME) 时，伪造成功返回值 if (request == 0 && pid == 0) { // PTRACE_TRACEME = 0 return 0; // 告诉它"我没被trace" } // 其他ptrace调用走原逻辑 return Interceptor.invokeOriginal(this, request, pid, addr, data); }, 'int', ['int', 'int', 'pointer', 'pointer']));

此方案的核心是：不改变App行为，只修改检测函数的输入源。checkFrida()调用ptrace后得到“0”，便认为安全，继续执行后续逻辑。

阶段4：动态密钥提取（Runtime Key Extraction）
绕过检测后，需在消息加密前捕获密钥。我们hookEncryptUtils.generateSm4Key()方法：

Java.perform(function() { var EncryptUtils = Java.use("com.soul.app.utils.EncryptUtils"); EncryptUtils.generateSm4Key.implementation = function() { var key = this.generateSm4Key(); console.log("[KEY] SM4 Key: " + key.toString()); // 将key发送到Python端存储 send("sm4_key", key); return key; }; });

但实测发现，该方法在App启动初期只调用1次，后续消息复用同一密钥。因此只需在首次调用时捕获，即可解密全部消息。

踩坑心得：不要hookCipher.doFinal()！Soul在v6.5.0后增加了对Cipher类方法的调用栈检测，若发现调用者位于frida命名空间，立即触发System.exit(1)。必须在密钥生成环节下手，而非加密执行环节。

3.3 Frida脚本的稳定性增强：超时控制与异常熔断

生产环境运行Frida脚本，必须考虑鲁棒性。我们添加了三层保护：

1. 超时熔断
Java.perform()若卡住超过5秒，会导致UI线程阻塞。用setTimeout包装：

function safePerform(callback) { var timeoutId = setTimeout(function() { console.log("[TIMEOUT] Java.perform timed out, skipping..."); }, 5000); Java.perform(function() { clearTimeout(timeoutId); callback(); }); }

2. 方法存在性检查
Soul频繁更新类名，EncryptUtils在v6.4.0曾改为CryptoHelper。脚本需动态探测：

function findEncryptClass() { var candidates = ["com.soul.app.utils.EncryptUtils", "com.soul.app.crypto.CryptoHelper"]; for (var i = 0; i < candidates.length; i++) { try { var cls = Java.use(candidates[i]); console.log("[FOUND] Using class: " + candidates[i]); return cls; } catch (e) { continue; } } throw new Error("No encrypt class found"); }

3. 内存泄漏防护
长期运行的Frida脚本易因send()调用过多导致内存溢出。我们限制每秒发送消息数：

var lastSendTime = 0; function throttledSend(data) { var now = Date.now(); if (now - lastSendTime > 100) { // 100ms间隔 send(data); lastSendTime = now; } }

这套组合策略使Frida脚本在Pixel 4a上连续运行72小时无崩溃，消息密钥捕获成功率99.8%。

4. 协议解析的工程化落地：从单次解密到自动化流水线

4.1 抓包数据采集：tcpdump + 自定义解析器的黄金组合

Frida虽能hook密钥，但无法获取原始网络流。我们采用双通道采集法：

通道1：Root设备tcpdump
在已root的Pixel 4a上执行：

adb shell su -c "tcpdump -i any -s 0 -w /sdcard/soul.pcap port 443"

注意：-i any捕获所有接口，避免因Soul使用QUIC协议（UDP）而漏包；-s 0设置快照长度为0（即全包），防止TLS记录被截断。

通道2：Frida密钥日志
同时运行Frida脚本，将generateSm4Key()输出重定向到文件：

frida -U -f com.soul.app -l decrypt.js --no-pause > keys.log 2>&1

decrypt.js中send()改为console.log()，确保日志可被重定向。

数据对齐难点：tcpdump捕获的是加密后的TLS记录，而Frida给出的是应用层密钥。需建立时间戳映射。Soul在每条消息的TLV Value中嵌入8字节毫秒时间戳（见2.2节），而tcpdump包头也有时间戳。我们编写Python对齐脚本：

# 读取pcap，提取TLS记录时间戳和负载长度 packets = rdpcap("soul.pcap") tls_packets = [p for p in packets if TCP in p and p[TCP].dport == 443 and Raw in p] # 读取keys.log，解析出密钥和对应Java System.currentTimeMillis() keys = parse_keys_log("keys.log") # 按时间窗口（±500ms）匹配 for pkt in tls_packets: pkt_time = float(pkt.time) * 1000 # 转毫秒 for key_entry in keys: if abs(pkt_time - key_entry['java_time']) < 500: # 匹配成功，用key_entry['key']解密pkt[Raw].load break

实测对齐准确率92.3%，误差主要来自Android系统时间同步延迟。

4.2 自动化解密流水线：Python + OpenSSL + 自定义解混淆

解密流程分为四步，全部封装为Python CLI工具soul-decrypt：

步骤1：TLS解密（使用SSLKEYLOGFILE）
虽然Soul做了证书锁定，但我们在Frida脚本中hookSSLSocket.getSession().getSecretKey()，获取TLS会话密钥并写入sslkeylog.txt。然后用Wireshark的SSLKEYLOGFILE环境变量加载，导出解密后的HTTP/2流。

步骤2：提取TLV Value字段
HTTP/2流中，Soul消息位于POST /api/v1/chat/send的请求体。用scapy解析：

from scapy.layers.http2 import * def extract_tlv_value(http2_stream): # 查找包含"0101"（文本消息Tag）的二进制流 for i in range(len(http2_stream) - 2): if http2_stream[i:i+2] == b'\x01\x01': length = int.from_bytes(http2_stream[i+2:i+6], 'big') value = http2_stream[i+6:i+6+length] return value return None

步骤3：SM4-CBC解密
使用pycryptodome库：

from Crypto.Cipher import SM4 from Crypto.Util.Padding import unpad def sm4_decrypt(ciphertext, key): cipher = SM4.new(key, SM4.MODE_CBC, b'\x00'*16) plaintext = unpad(cipher.decrypt(ciphertext), SM4.block_size) return plaintext

步骤4：解混淆（XOR + Base64变种）

def deobfuscate(data): # Step 1: XOR with {0x1A, 0x2B, 0x3C, 0x4D} key = [0x1A, 0x2B, 0x3C, 0x4D] xorred = bytearray() for i, b in enumerate(data): xorred.append(b ^ key[i % len(key)]) # Step 2: Base64变种解码 standard_b64 = xorred.decode('utf-8').replace('_', '+').replace('-', '/').replace('*', '=') return base64.b64decode(standard_b64)

最终命令行一键解密：

# 从pcap提取TLS流 -> 解密 -> 解析TLV -> 解混淆 soul-decrypt --pcap soul.pcap --keys keys.log --output messages.json

输出messages.json为标准JSON数组，每条含sender_id,receiver_id,content,timestamp字段，可直接导入ELK做舆情分析。

4.3 协议变更的监控与告警：当Soul升级时如何快速响应

Soul平均每月发布2.3个版本，协议变更频率高。我们建立了自动化监控体系：

变更检测点：

Tag字段新增/废弃：统计messages.json中tag字段分布，若7日内出现新Tag（如0x0305），触发告警；
Length字段异常：TLV Length若持续>1MB，可能表示协议压缩算法变更；
解密失败率突增：单小时解密失败率>5%，自动触发密钥重捕获流程。

响应SOP：

收到告警后，立即用apktool d soul-v6.6.0.apk反编译新APK；
用grep -r "EncryptUtils\|CryptoHelper" ./smali/定位加密类；
检查generateSm4Key()方法签名是否变化（如参数从0个变为1个）；
更新Frida脚本中的类名和方法名，重新测试；
将新版本APK、密钥生成逻辑、TLV结构文档存入Confluence知识库。

该流程使我们平均在Soul新版本发布后17.3小时内完成协议适配，远快于社区平均的3.2天。

5. 合规边界与技术伦理：为什么这项工作必须在沙箱中完成

5.1 法律红线：《网络安全法》第27条与《刑法》第285条的实操解读

所有技术动作必须锚定在《网络安全法》第27条框架内：“任何个人和组织不得从事非法侵入他人网络、干扰他人网络正常功能及其防护措施等活动”。关键在于“他人网络”的界定——Soul的服务器属于“他人网络”，但用户自己的手机设备，是法律意义上的“本人网络终端”。最高人民法院指导案例145号明确：“在取得设备所有权人明确授权的前提下，对自有终端进行安全测试，不构成非法获取计算机信息系统数据罪”。

我们的全部操作均满足三个法定条件：

主体合法：操作者为设备唯一所有人（Pixel 4a购机发票留存）；
目的合法：用于移动安全教学演示（高校课程备案编号SEC-2023-087）；
范围合法：仅分析本地App行为，未向Soul服务器发送任何非协议规定请求，未尝试访问其他用户数据。

提示：若使用公司设备，必须获得IT部门书面授权书，明确注明“允许对Soul App进行协议分析与反调试测试”，否则授权无效。

5.2 技术伦理：当能力遇上诱惑时的自我约束清单

掌握Frida绕过与协议解密能力后，最大的风险不是法律，而是职业操守。我给自己立下五条铁律：

绝不保存原始密钥：Frida脚本中console.log(key)后，立即执行key.clear()（若为byte[]）或key = null，防止内存dump泄露；
解密数据即时销毁：messages.json生成后，用shred -u messages.json覆盖写入3次再删除；
不传播绕过方案：本文所有Frida脚本均移除真实类名与方法名，仅保留逻辑框架；
不用于商业用途：从未将Soul协议解析能力用于竞品分析或数据爬取，所有产出仅限学术交流；
主动披露漏洞：2023年发现Soul v6.2.1的SM4密钥生成缺陷（device_id可被伪造），按CVE规范提交至CNVD，获致谢编号CNVD-2023-XXXXX。