本篇文章不是代码的堆砌，而是对我整个逆向工程思维过程的深度剖析。它记录了我如何从数学原理出发 ，通过现象观察 建立假设，在错误的道路（AES）上碰壁，最终通过取证分析 锁定真凶（RC4），并利用内存碰撞完成绝杀的完整逻辑链。
🕵️♂️ 黑盒逆向实录：基于内存取证的流密码破解深度复盘
1. 核心理论基石：流密码与异或指纹 (The Theoretical Foundation)
一切破解的起点，既不是代码也不是工具，而是对加密现象的物理观察。这是我们后续所有操作的唯一理论依据。
1.1 现象观察
我对比了抓包数据的明文（JSON）和密文（Base64解码后的二进制）,：
【背景与挑战 | The Challenge】
目标对象为一个 Flutter 开发的 Android 应用。由于 Flutter 采用 Dart AOT (Ahead-of-Time)
编译技术，其 libapp.so 包含大量自定义 VM 指令和混淆逻辑，导致传统的静态分析（IDA/Ghidra）
和动态 Hook（Frida）极其困难。我们在代码层面陷入了"寻找加密函数入口"的死胡同。
既然代码逻辑难以还原，我们决定绕过代码，直接对"数据"下手。
- 明文重构 (Plaintext Reconstruction):
利用我们掌握的已知登录账号和密码作为"关键词锚点"，在 4GB 的内存 Dump 中进行暴力搜索。这一步让我们成功定位到了内存中尚未加密的登录请求数据包，从而推断出了完整的 JSON 明文结构。- 算法画像 (Algorithm Profiling):
结合重构出的明文与抓包获取的密文，我们发现了一个关键特征：密文长度与明文严格一致，且修改明文某字节仅导致密文对应字节变化。这一物理特征直接排除了 AES-CBC 等分组加密，将嫌疑目标锁定在"流密码"（如 AES-CRT、RC4 或 XOR）范围内。
- 长度恒等 ：
len(明文) == len(密文)。这直接排除了 AES-CBC/PKCS7 等分组填充模式。 - 原子级对应 ：修改明文的第 NNN 个字节，密文也仅在第 NNN 个字节发生变化，其余位置纹丝不动。
1.2 数学推导
这种现象是流密码 (Stream Cipher) 的典型特征。无论底层算法名为何（RC4, AES-CTR, Salsa20, XOR），其数学本质统一为：
Ci=Pi⊕KiC_i = P_i \oplus K_iCi=Pi⊕Ki
- CiC_iCi: 密文第 iii 字节
- PiP_iPi: 明文第 iii 字节
- KiK_iKi: 密钥流第
- -iii 字节 (Keystream)
1.3 关键动作：提取"指纹" (Fingerprinting)
在不知道 Key 的情况下，我们可以利用已知明文攻击 (Known Plaintext Attack) 反向计算出密钥流。这是我们破解全过程的唯一校验标准 。
Ki=Ci⊕PiK_i = C_i \oplus P_iKi=Ci⊕Pi
操作：我们取前 16 字节的明文与密文进行异或，得到了最重要的线索：
指纹 (Fingerprint):
eabfac1c4696969c11352ada86d97630
深刻含义 ：这意味着，无论真正的算法是什么，真正的 Key 是什么，只要把它喂给算法，它吐出的前 16 个字节必须是这串指纹。
其实至此，我们已经可以收工了，因为我们已经拿到了加密字节流，我们可以不用管他什么算法，也不需要管他什么key了。直接拿字节流去加解密其他数据即可
代码如下
python
import base64
def get_keystream(plain_str, cipher_b64):
plain = plain_str.encode('utf-8')
cipher = base64.b64decode(cipher_b64)
# 提取密钥流
length = min(len(plain), len(cipher))
return bytes([plain[i] ^ cipher[i] for i in range(length)])
def decrypt_with_hex(cipher_b64, keyHex):
keystream = bytes.fromhex(keyHex)
cipher = base64.b64decode(cipher_b64)
length = min(len(cipher), len(keystream))
decrypted = bytes([cipher[i] ^ keystream[i] for i in range(length)])
return decrypted.decode('utf-8', errors='ignore')
def decrypt_with_stream(cipher_b64, keystream):
cipher = base64.b64decode(cipher_b64)
length = min(len(cipher), len(keystream))
# 解密：密文 XOR 密钥流 = 明文
decrypted = bytes([cipher[i] ^ keystream[i] for i in range(length)])
return decrypted.decode('utf-8', errors='ignore')
h = "eabfac1c4696969c11352ada86d976307d4712f26d210d16a0344b7bc2f50fe8e9b3d4a9f8f43a89d32d7cf9e4e176606fb1dc0ec7daecef5469f5131f461fefce27f06c2f0e500e5c427cde96455464306e6d30de08d1e9a352bee4f609f8723f692abcda5d3757e848288b98d3772eeb7f1ab1c6042d5ef9a117ecf2e4df08f6749b240ada70ebca3c8418f97fde67bebb456aee086586859c0ffcaeeb09ca80d7092b945ced8e0e9d34e634352bc7bf472ae28fb0498680696182c9ef808f15a9807e2e785e51f854faf79212d3677a2d441f35cebb5f07f7f0a86b0b9e02b816eacbc2207b931f7ec6bde637d760bfce27adef9ea7a05875a6e057fa034f41d528db0738c8d3229e37b86aaaa7a46a00906cb8b5aadf9254ecec045edd2d0ad25a0aaedd4fdcad88586ca51683f0d092a7c5062ca06b832c3ace61cf42f9888ebb06ef6b7ab5dcc3d39d4a113249003e17a286457e83819c919c1253fd9e5fb5190e732b70dc11f973b1076bcc17b4616c45249254bb1480a40260c77e4b1c3b555bbc7c2bafe59fa341a79d3282922a064d8b620f9e26947f4259c86930bed5e3dca2c25e91ddab643da0dd70eb515114fd7e2695d4deb868a3776dc06d27201b6194ffc07c817ead76dda4329820745f2a2b1de9a6e25852fcf75f21680cca3c48a350e9dd3d2b15ea90a67da047ec11fcbfc7da97a4380fac13a18a697a35ee8cfc67c61e7ca51718afbfafd414436ac6427d84cba50b5df712d10fc3e518ae55274ef31ae76d9368fafb534bf0233b7213a2770e8712c9a6d2ddd5f532c84e374d92b3fdf30bd74c7c54d96e2bf60a55bf4ab255c10c40ecb5e86edafa5c5fd13b86e7f4c48f77c8db1a987bffd4c3c9975aac6fb049a11dc77fee82f979e407a2475f660e4ba37d9495196b4811aeabcfec4f35694e3a25da76bceca2bf8d8c251acbefe096e06c5d27390f09f84fc1c9b35a260b170d38e4b8bdb71a9be8e1238d71fa2a92385007956a826b4672d663638ebcbbc42207c7bec97cabe6804331ae91e257aa5eb2364a8ba2751b3c14a1a7a8d502e440624d668a4ac2ffeb9ead9c49cc9f6faf9fa8644e44ee31bec4b77ee7748e441840d040a3675cd0575615e5a75cf57af2787c99c4cc8ec30b16a51b03ad4b34920f32810e28c189be91be91ea60ba9d6451f0a15a623fc9db960c130f1d20a9e7d92063ec302c440d5a9c4989648642e19048ffd0b64276486fa4ef21f0dfbaa8001a01622db61e51d78d35e9f68e5d6cb703bc892c39feb53dea8177f35b85b4062103e0739fd5b574980294e0b1098432f506edefcd9479f2e8820a69ed23912acbcfbccdcf3d9679d83840d08233f1074408e4ebabb8bb3793f94534d563c03120909bff4a0eddeb9fefb10507d75d5b4d9eb3ab941b889bf58b92e19797677ba949097d08dad9e6c3ab554ec29739794989299957bf366153276b8cc3343dc39c6362f888f31245dd5489eb179c6a3fe2b61af072ab4b15adb76518410c9eafb5eb4bb533bdc3769f447644a56ac08ee3bfeb2ff33a2b1cd99d38ebbcd4faadb953564ba30038b24ec9e7055188c5c5f0d1a488ac694f869ec2bcd66b16da547ada84b56817e5b141a508d15b5a98475fcbaa5ceb58d782b3d1adc77932b2ec4fb2aa85498ba173c898ac81d3eecd0c23d08aea6448c2d9191dfe9413a37dbd7717212707fb97bff6160d23d8f31008732f893fa31893b4e93ab9a5724c036f2c8a59fa4c67f5ee60fddf785c6c143d591e0c95f069c31c66673c729c87595053434866122b0310b2cde6ff47b91501443b9f028c1280f5c640ee08e5e451dc9dbc5dad44e923f99c6c48d18b593cc49714254d14be4b5a7f7165296f2f2f801f4a86ff41b54e33bf3b55a1878d20e642184698cec4e17a7115985264fb7d77cec7d4affc86e1fb7604a36c9fa63e9a0f34755b434ba84a8d0e29098f4b6efe21591ac2e364e1d5e0d1f9ce1c2912cc9a797512a0f01bc61e1baecb11125ab30aa68d3a461e93888ae3a4f87cd6c967d911acdc8194c00f907451af271fb371db2444c112136f368442f30906703419d44ba6d1d743fbe3b8b4bad0134160bdf63a50bd238eb8ce585cbd9aa052a992f7f4a1c09caff26819f6e5dd9c5dc5907abe84cf2d3c43bcd7251706f9f753c00ebed83fc113465ef9d1f3c38ccde14940b7554bfa3770de1ba391a5223bdcb824732bb76f6f130781e369c1d85f20c564129c15da11451508c473eaf8d8a6a24928f5e18c99dfbacf3993a52eb835a95d9b688ae6ef37579aa35a51be24307f5ba0399189e7e18c312da22665c7bc2ee768d76d6c711dfa904dee78d375dba21a04d271ac39bd91676ed6d306e186413468409cd4d1fa358a446caad7088714bb5e7b4bfd5655396b97b49fd99843ff9fe63a31c50863e1cedfc2be96c19c1d6384ea5942e7b677aab2db3b59fb10675064abe2a5f5e70a3791cce8f31dfd08ee01142a39cf001eba7fa155bbeb7f97020419c9a3c418bec8f4417c4cd5db9d7a251660065efdfa8c665a578ce82e972ce5fbeb1b9605b251e4d1946e40f4ed9cc3a9ed8af7fdfc7553089f49262adfe071e17cf99e11d6d81d14ccfad17c66ba66c892cfcfb17d6c65d9b5038c4c71dc0a06de301a6d800b1d559a974de5bfdcee45c18df7bb9ffd124b31a73f2d14939c9feb19bea7dac966fbce4a54a673de92164d15abb8d2e8f604ac1d33b6addfe9931c00293a37039a0b949df41ed7f1975e80b5908641210bfffce343b1363c28b47a30b1f4f6334ed7a4c585fa21b077cafb7c2394e66bbf3c079c5a9fa86a5c5e3d3f4f8b9b1666c8d49f7bf3872524af7171a3ee97a64d6c3f7d3ebd8bd5e0e2fd2eadfa6a885ad784e35a8bda8741723255307ec75313f68cae9bf81122527868262efb40b77e0dbed0361f169ac8504613518d5f84ed56a59873dd1a368139bc0b01a4cc3ab38f4ea2681a7306474161f80a3a37098005d503c985fd6aaca3beb9191a04afaf7ae1c54d15b1423c9473be0284cef9a2fcddd7f380e2406305ca2dc615abf708f739dac8c043f1a64931afa3d3b66a2e26ce24510f39def5e815375f30b8ecdfa4ada1612c844d0cd6ff88ba118145cc2f7b2cb2379fcfc25b4b7bef3cfe530a44b7d9c5b3e241569f6e479db091fedd1b836442dcffc7330f2966cdd9a3e3f785c1c1044ecdad744a28cef59525e189f912fe3dc50d086b720535894426a45d9e1de2e815a0526e8f869852d29c012672524f5cfde66a5ca51ede2d22f1fe640e525a994ef1ccc0577a7540d62f45b830062e4b951bceabd67a74e5f385a895bb8db8193d5ce8cdd066319b79fcbb988bd6e4ea1ee49d9dc29770d396e88d1779a84c936245125cd8d5f3463a003f2c20fa02a196f8ab3c8d48c3f70db6396d2fdd24cbb70f8946d728bc699ce6f9dff2601dd3005d22b3cf253d0981484a0119f30c9dcc363337abe75f367d70beed1cc6cdb9d007986266540abe6f3834ce75a03bac3657508d4402fcc41f05f73ed6fb73a94b5912d7378135cbc44475c7b9aada75d0c3bf8483924e4939c02d10659e7cbd5e1a6882df7975745c1d62d75badf3be7ab43cf11fcc0e6cf3c987c1febca254440804b77d58c5752e10d328fdf08771e6cfbb69e690944f78548f5f5dbc3d2d71c235b035998436c0086ed8db3d5029b5561a535faba75a7d5ad78fee45360810360d05cfc3bb03040f8b375ebced4d51ce211b6808005445e10bb0dd714158277673f2aab9f93b6e6d4bbfb640a7dc3d61c6c45d51b0adbc2d930654ff8b045e9d103881dd69ec5791b57ca4db3e95c1de5cad50ee38af8c3fc4688dd5d3bfc62985735febb0053ff89454c27c71d4ccd2db56e45009e745143aaa55061ab0bdd39b5fe9d0b7d927b98e7f40988a69f214362e33ec3a9018770f366068613eaeccd8d60fdf68b75f22a2c6bedbfb124bc76bcea73eaa363207dc951207ad85454c59f11b1e8dbdf6c1223acb871f586d23df65abc043ea6cd99c2e17a68f5d627d781ba50f10341758b60d6539befc014af4c43343b6b2f8dfc0dd3c1b987b7aa0e13fe0e6a0a69c5574d900929077a4a48ce6a3e629d5c73ed2afa8526dd3c3adb3eaf8dbeb27bf02d8533313f154752a43892d908f1b54b7de2ab17d82f42d3ad2392e611d4ad3a14231d45caaae50e02dff3ed2c773c114173e35f2bbdb1e2fcc94a769f9b0c407b330dce25537f171ebdc4cfc4067efc8fd00265807696c5f52cbf5fc8a3dbe381eeca5b986d16497064c85fa4f217b6502782488564b6567830170eca35eded7b58ab4ee58b64b0086189f073d12fbd64f798f83520434baedabb0fdf11874e9f2124c987ff76b63485739b9936aff28353b679dfa74e08b2bb1b1cebd394c64960bf4a903c803ab8a667b6bb058bedc215ea1786ac214e530079de1b7417fbc242f98cd972ff70616fc952836a91f028b4391e7f297744bd80b04292c1682346682cf99e357fb2a"
print()
# c2 = "kZ3IfTL3tKZ/QEa2qvsFRR4kd4EeAzdwwVg4Hu7XYo2awLXOndYAq49YS8zW2SoVWYPvOZuv2t1lX6lmKgRc2ZJSx1QfPwx7ZXdN58owbCZ1KE8c/HyjiMA394DUM9pCdydj+JkLegO5D3izouNHHttPKoH3JgF8nNNlg4CnsGyTdo1bAKdTgg=="
c2 = ("kZ3IfTL3tKYzFwb49awVUxg0YdBXVX9jxRhpFqeGfImO1vaT2qdP6rBIGZ2BhVRMTdSufKior4AwDNcpLzs=")
print("解密结果:", decrypt_with_hex(c2, h))但是，我们为了搞清楚里面的细节，以及完善我们正在写的算法推理助手工具，还是想一探究竟
2. 歧路与陷阱：AES-CTR 的思维定势 (The Detour)
2.1 错误的假设
基于 Android 开发的经验主义，我们先入为主地认为："现在的 App 肯定用 AES"。结合流密码特征，我们锁定了 AES-CTR。
2.2 为什么会失败？ (深刻教训)
我们尝试了 的内存碰撞，试图寻找 AES 的 Key 和 IV，但全部失败。复盘后发现，AES 算法存在两个刚性限制，导致它无法解释本案：
- 密钥长度的刚性 ：AES 强制要求密钥长度为 16 (128-bit)、24 (192-bit) 或 32 (256-bit) 字节。如果内存中的 Key 是 12 字节，AES 根本跑不起来。
- IV 的必要性：AES-CTR 必须有 IV（计数器初始值）。但我们在密文中找不到 IV，在内存中也找不到 IV。强行假设 IV=0 是赌博。
结论 ：当你的假设（AES）无法解释所有现象（无 IV、非常规 Key 长度）时，假设本身就是错的。
3. 破局点：内存取证与 RC4 确权 (The Breakthrough)
3.1 静态分析
我们在内存 Dump 中搜索字符串，发现了关键类名：
android.org.conscrypt.KeyGeneratorImpl$ARC4
3.2 为什么 RC4 是完美答案？
RC4 (ARC4) 完美填补了 AES 留下的所有逻辑漏洞：
| 特征维度 | 我们的观测现象 | AES-CTR | RC4 |
|---|---|---|---|
| 流模式 | 改1变1 | ✅ 符合 | ✅ 符合 |
| IV (随机数) | 无头部 IV | ❌ 必须有 | ✅ 不需要 |
| 密钥长度 | 未知 (可能是非标) | ❌ 严格固定 | ✅ 任意 (1-256字节) |
| 内存痕迹 | 发现 ARC4 类名 | ❌ 无 AES 线索 | ✅ Found ARC4 |
顿悟 ：真凶是 RC4。这意味着我们不需要找 IV，也不需要死守 16/32 字节长度，我们需要找的是一段任意长度的数据，它能生成我们的指纹。
4. 终极攻击：基于指纹的内存碰撞 (The Final Attack)
这是整个逆向工程的最高潮。我们编写了脚本，在 4GB 内存中"大海捞针"。
4.1 算法逻辑
- 过滤 (Filtering) ：利用
mmap和正则[^\x00]{5,}，瞬间剔除内存中 90% 的0x00空洞区域。 - 切片 (Slicing) ：对于每一个非空数据块（Blob），尝试截取各种可能的长度（5, 8, 12, 16, 32...）。
- 注：AES 脚本曾因死守 16/32 长度而漏掉了真凶。
- 碰撞 (Collision)：
ARC4(CandidateKey)→encrypt(ZeroBytes)KeystreamARC4(CandidateKey) \xrightarrow{\text{encrypt}(\text{ZeroBytes})} KeystreamARC4(CandidateKey)encrypt(ZeroBytes) KeystreamKeystream==?FingerprintKeystream \stackrel{?}{==} \text{Fingerprint}Keystream==?Fingerprint
4.2 结果验证
脚本运行后，迅速锁定了一处内存偏移：
- Key (Hex) :
4537745864504e7469357733 - Key (ASCII) :
E7tXdPNti5w3 - 长度 : 12 字节。
真相大白 ：正是这个 12 字节 的非标密钥，骗过了我们最初所有的 AES 扫描脚本。
5. 🛠️ 最终完整代码 (Python)
这是经过实战检验、集成了所有优化策略（正则加速、多进程、指纹校验）的最终工具。
python
import mmap
import os
import binascii
import re
import time
from multiprocessing import Pool, cpu_count, Manager
from Crypto.Cipher import ARC4 # 需要 pip install pycryptodome
from tqdm import tqdm
# ==========================================
# 1. 核心指纹配置
# ==========================================
FILE_PATH = "memory.dmp"
# [理论来源] 指纹 = 明文(前16字节) XOR 密文(前16字节)
# 这是我们在茫茫内存中识别 Key 的唯一信物。
TARGET_FINGERPRINT_HEX = "eabfac1c4696969c11352ada86d97630"
TARGET_FINGERPRINT = binascii.unhexlify(TARGET_FINGERPRINT_HEX)
# ==========================================
# 2. 搜索逻辑
# ==========================================
def check_chunk_rc4(args):
"""
工作进程：
1. 正则寻找内存中的非空数据块 (Blob)。
2. 对 Blob 进行变长切片 (Slicing)。
3. RC4 运算并对比指纹 (Collision)。
"""
filename, start_offset, size, target, queue = args
found_keys = []
try:
with open(filename, "rb") as f:
# mmap: 像操作内存一样操作大文件，避免爆内存
try:
mm = mmap.mmap(f.fileno(), length=0, access=mmap.ACCESS_READ)
except Exception:
return []
end_offset = start_offset + size
if end_offset > len(mm): end_offset = len(mm)
chunk_data = mm[start_offset:end_offset]
# 辅助常量：用于提取纯净密钥流
zeros_16 = b'\x00' * 16
# [Step 1: 过滤]
# Key 也是数据，通常不会包含 0x00。
# 利用正则跳过 0x00 空洞，性能提升关键。
pattern = re.compile(b'[^\x00]{5,}') # 假设 Key 至少 5 字节
last_report = 0
for match in pattern.finditer(chunk_data):
blob = match.group()
blob_abs_start = start_offset + match.start()
blob_len = len(blob)
# [Step 2: 变长切片]
# 我们的惨痛教训：不要死守 16/32 字节。
# RC4 Key 可能是任意长度，比如本案的 12 字节。
candidates = set()
# 策略 A: 尝试各种常见的 Key 长度
possible_lengths = [16, 24, 32, 12, 8, 10, 64]
for length in possible_lengths:
if blob_len >= length:
candidates.add(blob[:length])
# 策略 B: 也许整个 blob 就是一个字符串密码
if 5 <= blob_len <= 64:
candidates.add(blob)
# [Step 3: 指纹碰撞]
for key_bytes in candidates:
try:
# 核心验证逻辑：
# 如果 ARC4(Key, 全0) == 指纹，则 Key 正确。
cipher = ARC4.new(key_bytes)
keystream = cipher.encrypt(zeros_16)
if keystream == target:
# BINGO! 找到了
try:
key_str = key_bytes.decode('utf-8')
except:
key_str = "(binary)"
found_info = (blob_abs_start, f"Hex: {key_bytes.hex()} | ASCII: {key_str}")
found_keys.append(found_info)
# 立即通知主进程
queue.put(("FOUND", found_info))
break # 找到后跳出当前 blob
except:
pass
# 进度汇报
if match.end() - last_report > 16 * 1024 * 1024:
queue.put(match.end() - last_report)
last_report = match.end()
if len(chunk_data) - last_report > 0:
queue.put(len(chunk_data) - last_report)
mm.close()
except Exception:
pass
return found_keys
def main():
if not os.path.exists(FILE_PATH):
print(f"❌ 错误：找不到文件 {FILE_PATH}")
return
file_size = os.path.getsize(FILE_PATH)
num_cpu = cpu_count()
# 任务分片逻辑
CHUNK_SIZE_LIMIT = 128 * 1024 * 1024
tasks = []
offset = 0
while offset < file_size:
size = min(CHUNK_SIZE_LIMIT, file_size - offset)
tasks.append((FILE_PATH, offset, size, TARGET_FINGERPRINT, None))
offset += size
print(f"========================================")
print(f"🕵️ RC4 内存取证工具 (Final Release)")
print(f"目标: 寻找生成指纹 {TARGET_FINGERPRINT_HEX[:8]}... 的 Key")
print(f"原理: 正则过滤 -> 变长切片 -> 流指纹碰撞")
print(f"========================================")
manager = Manager()
progress_queue = manager.Queue()
real_tasks = [(t[0], t[1], t[2], t[3], progress_queue) for t in tasks]
pool = Pool(processes=num_cpu)
async_result = pool.map_async(check_chunk_rc4, real_tasks)
pool.close()
found_results = []
# 进度条
with tqdm(total=file_size, unit='B', unit_scale=True, desc="Scanning") as pbar:
while not async_result.ready():
while not progress_queue.empty():
msg = progress_queue.get()
if isinstance(msg, int):
pbar.update(msg)
elif isinstance(msg, tuple) and msg[0] == "FOUND":
offset, info = msg[1]
pbar.write(f"\n[!!!] CRITICAL HIT | Offset: {hex(offset)} | {info}")
found_results.append(msg[1])
time.sleep(0.1)
pool.join()
print(f"\n========================================")
if found_results:
print(f"🎉 破解成功！找到 {len(found_results)} 个 Key。")
print(f"🔑 最终 Key: {found_results[0][1]}")
else:
print("❌ 未找到 Key。请重新检查指纹或扩大搜索范围。")
if __name__ == '__main__':
main()6. 启示录 (Epilogue)
本次逆向最大的收获不在于代码，而在于思维模式的矫正：
- "指纹"是上帝视角：无论加密算法多复杂，只要是流密码，XOR 指纹就是它唯一的软肋。先算指纹，再谈破解。
- 警惕"标准陷阱" ：不要理所当然地认为所有开发者都会遵守 AES-128/256 的标准。在黑盒世界里，12 字节的 RC4 Key 这种野路子比比皆是。
- 内存不会撒谎 ：当算法逻辑卡死时，去内存里看看类名、字符串，往往能直接找到答案。4. 最后借此深刻理解完善下我的推理算法助手，成功解密找出key并解密出来，实现秒推，日后遇到同类问题无需如此复杂工程
