1. 项目概述与核心思路最近在分析一些网络应用时经常会遇到数据被AES-ECB模式加密的情况。这种加密方式在HTTP通信中并不少见尤其是在一些对性能要求较高、但安全性设计上存在妥协的场景里。很多朋友看到抓包工具里一堆乱码似的密文就头疼不知道从何下手。今天我就来手把手带你写一个Python脚本咱们不搞复杂的密码学攻击而是用一种更“工程师”的思路——通过构造特定的请求来“窥探”和验证AES-ECB加密的规律从而理解其加密内容和潜在风险。这个项目的核心不是去破解一个未知的密钥那是违法的。我们的目标是在一个已知或假设使用AES-ECB模式的HTTP接口上通过脚本自动化地发送精心构造的请求观察和分析返回的密文来验证我们的猜想比如确认加密模式、推断数据块结构甚至发现一些因ECB模式固有缺陷导致的信息泄露模式。这更像是一次安全审计或协议分析的学习实践。你需要准备一个Python环境3.6以上均可以及requests和pycryptodome这两个库。整个过程我们会从抓包分析开始到脚本编写再到结果解读一步步拆解。2. AES-ECB加密原理与HTTP场景下的风险在动手写脚本之前我们必须先搞清楚我们要对付的“敌人”是什么。AES是一种对称加密算法而ECBElectronic Codebook电子密码本是它的一种工作模式。2.1 ECB模式的工作原理与视觉化缺陷你可以把ECB模式想象成用一本固定的密码字典来加密。假设你要加密一句话ECB会先把这句话切成一个个固定大小的块AES通常是16字节然后每个块独立地、用同样的密钥进行加密。块与块之间没有任何关联。这就导致了一个致命问题相同的明文块一定会产生相同的密文块。我给你看一个经典的“企鹅图”例子虽然我们不能展示图片但可以描述一张图片中大片颜色相同的区域比如黑色的背景在ECB加密后对应的密文块也是重复的。即使整个图片变成了乱码你依然能从密文块的重复图案中隐约看出原始图片的轮廓。在HTTP传输文本数据时这个缺陷同样存在。比如你的请求体里有两个完全相同的JSON字段值或者一段填充的空格它们在密文里就会呈现出相同的字节序列。2.2 为何HTTP通信中仍可能见到ECB既然ECB不安全为什么还会遇到原因有几个一是历史遗留系统开发得早当时没考虑那么周全二是为了追求极致的性能ECB模式可以并行加密解密速度最快三是在某些嵌套的加密场景中内部可能不经意间使用了ECB。作为分析者我们的任务就是识别出这种模式。在HTTP中加密可能发生在POST请求的Body里也可能在某个特定的Header值中。通常你会看到一串长度规整是16字节的倍数、看起来像Base64编码的字符串。注意这里必须划清界限。我们讨论的所有分析都基于授权测试或对自有系统的学习。未经授权对他人系统进行任何形式的渗透测试都是非法的。本脚本仅用于教育目的帮助你理解加密原理和协议分析的方法。2.3 我们的分析武器选择明文攻击CPA概念我们脚本的核心思想借鉴了选择明文攻击的概念。简单说就是我们能够向目标接口提交任意我们选择的明文数据然后观察返回的密文。通过系统性地改变明文内容比如逐步增加一个字符观察密文块的变化我们可以证实ECB模式的存在并推断出块大小、加密内容起始位置等信息。这就像通过不断调整输入来探测一个黑盒的内部结构完全是一种分析手段而非破解。3. 实战环境准备与初步探测现在让我们进入实战环节。假设我们已经通过抓包例如使用Burp Suite或Wireshark发现了一个可疑的API端点http://example.com/api/encrypted-data其POST请求体是一段Base64编码的数据解码后是长度规整的二进制乱码。3.1 工具安装与基础脚本搭建首先确保你的环境准备好了。pip install requests pycryptodomepycryptodome是Python下强大的密码学库我们将用它来演示加密过程以作对比。requests用于发送HTTP请求。我们先写一个最基础的脚本框架用于发送和接收数据import requests import base64 import json from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad # 目标URL (请替换为你的测试目标) TARGET_URL http://example.com/api/encrypted-data # 基础会话保持Cookie等状态 session requests.Session() def send_encrypted_request(encrypted_data_bin): 发送加密数据。假设接口接收Base64编码的密文。 encrypted_b64 base64.b64encode(encrypted_data_bin).decode(utf-8) headers {Content-Type: application/json} # 假设接口期望一个JSON其中某个字段是密文 payload {data: encrypted_b64} try: resp session.post(TARGET_URL, jsonpayload, headersheaders, timeout10) resp.raise_for_status() # 假设返回也是包含Base64密文的JSON return resp.json() except requests.exceptions.RequestException as e: print(f请求失败: {e}) return None def decode_response(response_json): 解码响应中的密文。 if response_json and encryptedData in response_json: encrypted_b64 response_json[encryptedData] return base64.b64decode(encrypted_b64) else: print(响应格式不符合预期或为空) return None # 示例发送一个虚拟的加密块这里先用空数据后续填充 if __name__ __main__: # 暂时用空数据测试连接 dummy_data b response send_encrypted_request(dummy_data) if response: print(连接测试成功响应:, response)这个框架建立了通信基础。但关键问题来了我们还没有密钥怎么构造encrypted_data_bin这就是重点——在真实分析中我们通常无法直接构造合法密文。我们的脚本更多是用于“接收”和“分析”从服务器返回的密文。因此接下来的核心是修改脚本使其能够系统性地提交不同的、可控的明文如果接口支持或者更常见的场景是我们拦截并修改客户端发出的原始请求替换其中的部分明文再观察服务器返回的密文变化。这通常需要配合代理工具如Burp Suite进行手动测试但我们可以用脚本模拟这个过程的思想。3.2 手动分析与脚本化思路结合在实际操作中更可行的路径是捕获一个合法请求使用抓包工具捕获一个客户端发送到TARGET_URL的完整请求记录下原始的密文Base64格式。假设加密模式根据密文长度是16的倍数和业务场景怀疑是AES-ECB。脚本化验证编写脚本不是为了直接向服务器发送密文而是为了自动化地分析我们捕获到的、或通过修改请求后得到的一系列密文寻找ECB模式的证据。因此我们需要调整脚本的核心功能为密文比对与分析。我们假设我们可以通过某种方式如修改客户端、代理重放获得多组不同明文对应的密文。脚本的任务是接收这些密文并进行比对分析。4. 核心脚本ECB模式检测与块分析让我们构建脚本的核心分析部分。我们将模拟一个场景我们拥有一个可以提交明文并返回对应密文的测试接口例如一个自己搭建的、用于学习的演示服务器。如果是对真实黑盒分析这部分逻辑则对应你通过代理工具手动修改请求并收集到的“明文-密文”对数据集。4.1 模拟一个已知的ECB加密服务用于演示为了完整演示我们先在本地模拟一个服务端这样就有可控的测试环境。# 文件simulated_server.py 演示用非主脚本部分 from flask import Flask, request, jsonify import base64 from Crypto.Cipher import AES from Crypto.Util.Padding import pad import os app Flask(__name__) # 用一个固定的密钥和IVECB模式不用IV这里仅为格式一致 KEY os.urandom(16) # 随机生成一个密钥模拟未知但固定的密钥 CIPHER_MODE AES.MODE_ECB def encrypt_data(plaintext): 模拟服务器的加密函数使用AES-ECB. cipher AES.new(KEY, CIPHER_MODE) # 确保明文长度是块大小的倍数 padded_data pad(plaintext.encode(utf-8), AES.block_size) ciphertext cipher.encrypt(padded_data) return ciphertext app.route(/api/encrypt, methods[POST]) def handle_encrypt(): 演示接口接收明文返回Base64编码的密文。 data request.json if not data or plaintext not in data: return jsonify({error: Missing plaintext}), 400 plaintext data[plaintext] ciphertext encrypt_data(plaintext) return jsonify({ status: success, ciphertext: base64.b64encode(ciphertext).decode(utf-8), note: This is a simulated ECB encryption server for demonstration. }) if __name__ __main__: app.run(port5000, debugTrue)运行这个simulated_server.py我们就有了一个本地测试端点http://127.0.0.1:5000/api/encrypt。4.2 主分析脚本编写现在编写我们的主分析脚本它将向这个模拟接口发送精心构造的明文并分析返回的密文。# 文件ecb_detector.py import requests import base64 from collections import defaultdict # 模拟服务器的地址 SIM_SERVER_URL http://127.0.0.1:5000/api/encrypt def get_ciphertext(plaintext): 向模拟服务器发送明文获取密文。 payload {plaintext: plaintext} try: resp requests.post(SIM_SERVER_URL, jsonpayload, timeout5) resp.raise_for_status() result resp.json() if result[status] success: # 返回Base64解码后的二进制密文 return base64.b64decode(result[ciphertext]) else: print(f服务器返回错误: {result}) return None except Exception as e: print(f请求模拟接口失败: {e}) return None def detect_ecb(ciphertext, block_size16): 检测一段密文中是否存在重复的块这是ECB模式的强指示。 if len(ciphertext) % block_size ! 0: print(f警告密文长度({len(ciphertext)})不是块大小({block_size})的整数倍。) return False blocks [ciphertext[i:iblock_size] for i in range(0, len(ciphertext), block_size)] unique_blocks set(blocks) if len(blocks) ! len(unique_blocks): print(f[!] 发现重复块总共{len(blocks)}个块有{len(unique_blocks)}个唯一块。) # 找出具体哪些块重复了 block_count defaultdict(int) for block in blocks: block_count[block] 1 for block, count in block_count.items(): if count 1: print(f 块 {block.hex()} 出现了 {count} 次) return True else: print(f[*] 未发现重复块。总共{len(blocks)}个块都是唯一的。) return False def block_size_detection(): 通过逐步增加明文长度探测加密算法的块大小。 print(\n 开始探测块大小 ) # 先发送一个空字符串或很短字符串获取基础长度 base_plain A base_cipher get_ciphertext(base_plain) if not base_cipher: return base_len len(base_cipher) print(f明文A的密文长度: {base_len} 字节) prev_len base_len for i in range(2, 65): # 尝试增加到64个A plain A * i cipher get_ciphertext(plain) if not cipher: continue current_len len(cipher) if current_len ! prev_len: print(f明文长度从 {i-1} 增加到 {i} 时密文长度从 {prev_len} 变为 {current_len}) block_size current_len - prev_len print(f[] 推测块大小为: {block_size} 字节) # 验证再增加一个块大小看长度是否再次跳跃 plain2 A * (i block_size - 1) cipher2 get_ciphertext(plain2) if cipher2 and len(cipher2) current_len block_size: print(f[] 验证成功再增加{block_size-1}字节密文长度再次增加{block_size}字节。) else: print(f[-] 块大小验证未通过。) return block_size prev_len current_len print([-] 在尝试范围内未探测到明显的块大小变化。) return None def ecb_analysis_with_controlled_input(): 使用可控输入进行深入的ECB分析。 print(\n ECB模式验证实验 ) # 实验1验证相同明文块产生相同密文块 print(\n1. 验证重复明文块) # 构造一个包含三个完全相同明文块的字符串每个块16字节即16个字符 # 例如使用48个A plain_repeat A * 48 # 3个块 cipher_repeat get_ciphertext(plain_repeat) if cipher_repeat: print(f明文: {plain_repeat[:16]}... (重复3次)) print(f密文(Hex前64位): {cipher_repeat[:64].hex()}) # 手动检查前三个块 block1 cipher_repeat[0:16] block2 cipher_repeat[16:32] block3 cipher_repeat[32:48] print(f 块1: {block1.hex()}) print(f 块2: {block2.hex()}) print(f 块3: {block3.hex()}) if block1 block2 block3: print([] 确凿证据三个相同明文块产生了三个完全相同的密文块这是ECB模式的典型特征。) else: print([-] 密文块不相同可能不是ECB模式或者有额外的混淆如盐值、IV。) # 实验2验证块独立性 - 在长字符串中插入特定模式 print(\n2. 验证块独立性插入已知模式) # 构造明文 15个B X 15个B Y 15个B Z # 目的是让X,Y,Z分别位于三个不同的块末尾观察它们是否只影响自己所在的块。 prefix B * 15 plain_pattern prefix X prefix Y prefix Z cipher_pattern get_ciphertext(plain_pattern) if cipher_pattern: blocks [cipher_pattern[i:i16] for i in range(0, len(cipher_pattern), 16)] print(f明文模式: {prefix}X{prefix}Y{prefix}Z) print(f生成的密文块数: {len(blocks)}) # 比较第一个和第二个块的前15个字节对应的部分应该都是15个B的加密结果 # 在ECB下它们应该相同。但因为我们插入的字符改变了块内容所以第一个块和第二个块整体不会相同。 # 更有意义的比较是如果我们发送15个B其加密结果应该等于上面每个块的前15字节加密结果。 # 让我们获取15个B的加密块作为参考 ref_cipher get_ciphertext(B*15) if ref_cipher: ref_block ref_cipher[:16] # 填充后是一个完整块 print(f参考块(15个B): {ref_block.hex()}) for i, block in enumerate(blocks[:3]): print(f 块{i1}: {block.hex()} - 与参考块{相同 if block ref_block else 不同}) # 在ECB下由于填充的存在15个B和15个BX的填充结果不同所以块会不同。 # 这个实验更多是展示如何设计输入来探测边界。 if __name__ __main__: # 步骤1探测块大小 bs block_size_detection() # 步骤2获取一个样本密文并检测重复块 sample_plain This is a sample plaintext that is long enough to have multiple blocks. sample_cipher get_ciphertext(sample_plain) if sample_cipher: print(f\n 分析样本密文 ) print(f明文: {sample_plain[:50]}...) print(f密文长度: {len(sample_cipher)} 字节) detect_ecb(sample_cipher, block_sizebs if bs else 16) # 步骤3进行受控的ECB验证实验 ecb_analysis_with_controlled_input()5. 脚本运行结果解读与问题排查运行上面的ecb_detector.py你会看到类似下面的输出。我们来逐段解读。5.1 块大小探测输出解读 开始探测块大小 明文A的密文长度: 32 字节 明文长度从 15 增加到 16 时密文长度从 32 变为 48 [] 推测块大小为: 16 字节 [] 验证成功再增加15字节密文长度再次增加16字节。发生了什么脚本从发送一个字符“A”开始。密文长度是32字节。然后逐步增加“A”的数量。当长度从15个“A”增加到16个“A”时密文长度从32跳变到了48增加了16字节。为什么这是因为AES的块大小是16字节。当明文长度达到块大小的整数倍时填充算法如PKCS#7会额外添加一个完整的填充块。15个字符时需要填充1个字节0x01刚好凑成一个块16字节加密后得到32字节两个块。16个字符时需要填充16个字节0x10变成两个块32字节加密后得到48字节三个块。这个跳跃的差值就是块大小。5.2 重复块检测输出解读 分析样本密文 明文: This is a sample plaintext that is long enough to have mul... 密文长度: 80 字节 [*] 未发现重复块。总共5个块都是唯一的。对于随机文本通常不会出现重复块。这很正常。5.3 受控实验输出解读 ECB模式验证实验 1. 验证重复明文块 明文: AAAAAAAAAAAAAAAA... (重复3次) 密文(Hex前64位): 7a5f8c1d4e3b2a0976... (示例值每次运行不同) 块1: 7a5f8c1d4e3b2a0976... 块2: 7a5f8c1d4e3b2a0976... 块3: 7a5f8c1d4e3b2a0976... [] 确凿证据三个相同明文块产生了三个完全相同的密文块这是ECB模式的典型特征。这是最关键的证据。48个“A”被分成3个块每个块都是16个“A”。在ECB模式下它们被独立加密由于密钥相同输出必然相同。脚本检测到了三个完全相同的密文块这几乎可以断定是ECB模式。5.4 常见问题与排查技巧实录在实际操作中你可能会遇到各种问题。这里记录几个典型场景和解决思路。问题1请求被拒绝或返回错误如502 Bad Gateway可能原因目标服务器对请求格式、头部、频率有要求。排查检查头部用抓包工具捕获一个合法请求完整复制它的Content-Type、User-Agent、Cookie、Authorization等头部到你的脚本的session.headers中。检查数据格式确认服务器期望的是application/json还是application/x-www-form-urlencoded或者是直接提交Base64字符串。我们的示例用了JSON封装但实际情况可能更简单或更复杂。降低请求频率在循环探测块大小时在请求间加入time.sleep(0.5)避免被当成攻击。问题2无法触发密文长度变化可能原因加密前数据经过了压缩或编码或者使用了流加密模式如CFB、OFB这些模式不会产生明显的块长度跳跃。排查尝试更长的明文比如从1到100字节。检查返回的密文是否是Base64编码的字符串确保你的脚本正确解码了二进制数据。如果始终不跳跃考虑可能不是分块加密模式或者是加密后还有额外的数据如签名、IV拼接在一起。问题3即使发送重复明文也未检测到重复密文块可能原因不是ECB模式可能是CBC、CTR等其他模式它们会使用初始化向量IV或计数器使得相同明文产生不同密文。加密前添加了盐值Salt或随机前缀一些实现会在明文前附加随机数据破坏明文块的对齐从而掩盖ECB的重复性。使用了认证加密AEAD如GCM模式密文包含认证标签且加密过程本身也不产生ECB特征。排查尝试分析更长的、高度结构化的重复数据比如{user:admin,user:admin,user:admin}看看密文中是否有短周期的重复模式。如果可能获取更多关于加密实现的线索如前端JS代码、SDK文档。问题4pycryptodome导入错误或安装问题可能原因环境冲突或安装不完整。解决确保使用pip安装pip install pycryptodome。如果之前安装过pycrypto需要先卸载pip uninstall pycrypto。在代码中导入语句是from Crypto.Cipher import AES注意C是大写。6. 进阶从分析到利用模式缺陷的理解通过脚本验证了ECB模式的存在我们能做什么这加深了我们对安全的理解。6.1 理解“语义安全性”的缺失ECB模式缺乏“语义安全性”。这意味着观察密文本身就能泄露明文的部分信息。我们的脚本实验已经证明了这一点内容相同的部分密文也相同。在一个HTTP API中这可能意味着如果每次请求的固定部分如{status:ok}产生固定的密文块攻击者可以识别出成功或失败的响应。如果用户令牌或ID在JSON中占据固定位置那么不同用户的相同字段如role:user可能会产生相同的密文块从而被归类。6.2 块边界对齐攻击Block Alignment Attack概念这是ECB相关的一种攻击思路。攻击者可以通过精心控制输入使未知数据如密钥、令牌移动到已知的块边界然后通过暴力猜测或字典攻击来破解。例如假设一个加密的Cookie格式是useradminroleadmin。如果我们能控制user参数的长度我们就可以让role的值从一个新块开始然后单独枚举这个块的密文。我们的脚本为这种分析提供了基础。你可以修改ecb_analysis_with_controlled_input函数设计更复杂的输入模式来探测加密数据中固定前缀的长度、用户可控数据的起始位置等。这需要更精细的操控和更多的请求。6.3 脚本的扩展方向这个基础脚本可以扩展为更强大的分析工具自动化枚举结合代理工具如Burp Suite的宏或插件将捕获的请求自动送入脚本进行重复块分析批量标记可疑请求。可视化工具将密文块用不同颜色表示相同的块用同一种颜色生成一个“密文图谱”直观展示ECB模式下的数据模式。这对于分析加密的图片或结构化数据特别有效。与CBC等模式对比增加对CBC模式的检测逻辑例如通过修改第一个密文块观察对后续明文块的影响CBC的“雪崩效应”。最后我想强调的是编写这个脚本的过程其价值远大于运行它得出的结果。它强迫你深入理解AES-ECB的工作原理、HTTP协议的数据传输、以及如何用程序化的思维去验证一个安全假设。在真正的安全评估中这类分析往往是手动和自动化结合需要耐心和创造力。希望这个“手把手”的旅程能让你下次再看到一堆HTTP密文时不再感到无从下手而是有了清晰的探查思路和趁手的工具。