简介这份开源工具面向安全分析与逆向工程场景可帮助安全研究员、CTF选手在运行进程的内存中定位AES密钥支持128位、192位与256位密钥。工具基于C实现压缩包共10个文件以.h头文件、.cpp源码及Visual Studio工程文件.sln/.vcxproj为主并附带README说明整体仅20KB非常轻量。项目源码兼顾多平台适配内置Linux、macOS与Windows的系统接口头文件并包含测试头文件便于快速验证与二次开发。已有1632人学习下载适合有一定逆向基础、希望理解内存密钥扫描原理或将其嵌入自研工具的开发者参考。1. 项目概述这个工具到底解决什么问题先聊几句题外话。做安全研究、二进制分析或者嵌入式开发的人应该都遇到过这种场景手里拿到一个固件包、一个内存转储文件或者正在调试一个黑盒程序明明系统跑得挺正常但你想搞清楚它内部到底用了什么密钥来加密网络流量、配置文件或者固件分区。单纯的静态分析往往很痛苦加了壳、混淆、白盒加密之后字符串里搜不到AES或者key之类的线索IDA 翻半天也找不到关键函数。这个时候从运行过程中的内存数据里直接把密钥捞出来是一个挺实用的思路。aes-finder 就是干这个的。它是一款用于在运行过程中查找 AES 密钥的实用程序核心作用简单粗暴给定一个二进制文件、内存转储或者抓取到的进程镜像它会通过扫描和判断找出其中可能被用作 AES 密钥的数据块然后按候选优先级列出来。听起来是不是有点像在草堆里找针实际上也确实是在找针只不过这枚针有比较明显的模式特征可以利用关键是找到足够好的特征筛选规则。这个工具适合谁用呢如果你是做安全分析、恶意软件研究、固件逆向或者只是在调试一个只知道黑盒行为但拿不到源码的加密模块它都能派上用场。因为 AES 密钥本质上就是一段长度固定的字节只要你能抓取到密钥所在的那一片内存剩下的筛选工作可以交给程序来做。本文会从原理、实操、踩坑三个角度把这个工具讲透同时也会把它和其他类似的方案做对比方便你决定在什么场景下用最顺手。2. AES 密钥查找的核心原理AES全称 Advanced Encryption Standard是目前应用最广泛的对称加密算法。先说一下对称加密的含义加密和解密用的是同一把密钥。好处是性能好、部署简单坏处是只要密钥泄露一切加密都等于摆设。AES 支持的三种密钥长度分别是 128 位、192 位和 256 位换算成字节就是 16、24、32 字节。AES 还有一个特点是分组加密数据按 16 字节一组处理密钥的每一轮扩展子密钥也都有固定的结构。这些特性就给了内存扫描提供了依据。AES 密钥在运行过程中一般以两种形式存在一种是原始密钥本身另一种是已经通过密钥扩展算法生成好的轮密钥表。轮密钥表长度更加规整通常存储在连续内存区块中里面有明显可验证的关系。因此查找算法大致分两路走下面是两种主要方案的对比。查键思路原理特点适用场景原始密钥扫描按字节长度窗口扫描对每个窗口统计字节分布、熵值、可打印字符比例过滤不符合条件的候选明文密钥驻留内存时最有效速度快误报率尚可轮密钥表识别对内存中连续扩展密钥进行重组利用密钥扩展逆过程判断是否存在可逆关系密钥已经过扩展、原始密钥可能被释放的场景准确率高但计算量稍大3. 初版安装与编译准备讲完原理来看看实际怎么把这个工具跑起来。大多数类似工具会优先支持 Linux 环境aes-finder 也不例外。如果你用的是 Ubuntu、Debian 或者 Kali 这类 Linux 发行版直接拉源码编译比较省心。我自己的习惯是先在虚拟机里跑一遍确认没问题再放到专门的测试机器上分析样本。编译环境方面需要保证系统里有 gcc、make 和 cmake 这三个基础工具。Ubuntu 上可以直接用以下命令安装sudo apt-get update sudo apt-get install -y build-essential cmake git如果不想污染系统环境也可以用 Docker 起一个干净的构建容器但这里建议直接在宿主机编译因为后面分析内存转储时经常需要访问本地文件少了 Docker 的路径映射会省去不少麻烦。源码拉取和编译的流程如下git clone https://github.com/aes-finder 仓库地址.git cd aes-finder mkdir build cd build cmake .. make编译成功后会生成可执行文件aes-finder一般在build目录下。如果编译过程中报缺少某些依赖库可以检查一下是否装了libssl-dev这个库和 AES、SHA 等算法的计算有关很多安全工具都会依赖它。另外提醒一句如果是在 Windows 上用 Visual Studio 打开源码需要稍微改动一下平台相关的头文件但是官方一般没有做太多跨平台适配所以除非你有很强的理由否则最好还是用 Linux 跑。这一点在 README 里通常也会写明别踩这个坑。4. 如何用命令行快速扫描先拿一个测试文件来说说基本用法。假设你手头有一份从某个嵌入式设备里提取出来的内存转储文件文件名是router_fw_dump.bin你怀疑这个固件在启动后会把用于加密配置分区的 AES 密钥缓存在内存中。这个时候直接执行./aes-finder -f router_fw_dump.bin工具会按照默认参数去扫描文件里的每一个内存窗口然后输出候选密钥。默认情况下会扫描 16 字节和 32 字节两种长度的候选密钥。输出结果一般是一个列表每一行包含命中的偏移地址、密钥长度、候选密钥的十六进制形式以及一个基于熵值计算的概率评分。如果你想更精确地控制扫描条件有几个参数需要特别关注。第一个是熵值阈值默认通常在 6.5 到 7.5 之间。熵值概念有点抽象通俗说就是数据混乱程度。如果一段字节重复性很高比如全是0x00或者 ASCII 可见字符代表它不像是随机生成出来的密钥。真实的 AES 密钥应该是接近均匀分布、尽可能像随机数的字节串所以熵值越高越像密钥。你可以用-e 7.0这类参数把阈值拉高减少误报但同时也可能漏掉真正密钥。第二个重要参数是扫描步长默认按 1 字节滑动窗口扫描这种模式最彻底但速度慢。如果文件很大可以试试-s 4之类的对齐方式AES 密钥在内存里通常会有一定的对齐特性按 4 字节、8 字节甚至 16 字节对齐来做能大幅缩短扫描时间。这个参数需要结合实际情况权衡下面是我整理的计算参考。参数名称作用示例备注-f指定分析文件-f dump.bin必填-e熵值阈值-e 7.0越大筛得越严格-s扫描步长-s 8越大越快但可能漏检-l密钥长度-l 32可强制只查找 256 位密钥-v显示详细信息-v输出偏移与额外统计我实际用下来一份 100 MB 左右的内存转储文件默认参数扫描大概需要几分钟时间。如果加上-s 16 -e 7.5时间能压缩到几十秒以内输出的候选数量也会从几十条降到个位数。效率提升很明显但代价是可能漏掉那些没对齐存储的密钥。所以我的策略是先用快参数粗扫一遍再用慢参数扫一遍做复核两轮交叉确认。5. 结合内存转储的实操案例命令行基础用法学会之后关键是结合真实场景用起来。下面分享一个比较有代表性的案例在 Linux 系统下对一个正在运行的服务进程做内存转储然后再用 aes-finder 查找该服务在运行期间创建的 AES 密钥。第一步找到目标进程的 PID。假设我们要分析的进程名是app_server使用如下命令确认ps aux | grep app_server假设得到的 PID 是 2333。接着用gcore或cat /proc/2333/mem的方式收集该进程的内存数据。gcore是最直接的方案一条命令搞定gcore 2333执行完成后当前目录下会生成一个名为core.2333的文件。这个文件大小可能很夸张大几百 MB 甚至几个 GB 都有可能尤其是在 Linux 下默认会把进程的所有内存区间都导出来。如果磁盘空间紧张可以先用ulimit -c限制一下核心转储大小但注意过小可能导致转储不完整。拿到 core 文件后运行./aes-finder -f core.2333 -e 7.0 -l 16 -l 32这一步会比较耗时因为 core 文件中除了进程堆栈还包含很多文件映射段、共享库代码段等无关数据。扫描结果会有不少候选这时可以结合服务的源码或者已知的密钥结构在输出的偏移位置附近再配合dd截取一段内存用 Python 脚本二次验证该候选密钥是否真的能解密已知密文。验证思路可以用下面这段伪代码表示from Crypto.Cipher import AES ciphertext bytes.fromhex(...) key bytes.fromhex(...) mode AES.new(key, AES.MODE_GCM) plaintext mode.decrypt(ciphertext)如果你手头有已知明文和密文对做一次加解密比对就能最终确认候选密钥这一套下来整个搜索过程的准确率就能闭环验证。6. 常见问题与排查技巧实际使用过程中总会遇到一些稀奇古怪的问题。根据我自己的实践和身边朋友反馈的问题整理了一份排查速查表希望能帮你少走弯路。现象可能原因处理方法扫描结果为空熵值阈值设置过高候选都被过滤了调低阈值到 6.0 或 6.5重新扫描输出候选太多无法分辨扫描对象是整个 core 文件包含大量随机数据优先定位关键内存区域缩小文件范围后再扫找到的密钥无法解密密文密钥被包装层比如 key wrap 或密钥派生函数处理过检查密钥前是否有固定前缀尝试还原原始密钥程序崩溃或内存不足分析文件太大扫描算法占用过多内存先用工具拆分文件或使用更大的扫描步长结果全是可打印 ASCII 字符串未排除数据段中包含的中文字符串映射检查是否启用了可打印字符串过滤必要时关闭结合出现频率这里重点说两个问题。第一个是空结果问题。有些分析人员拿到的内存转储来自 Java 或 Python 这类带运行时环境的进程AES 密钥可能在 JVM 堆或 Python 堆里以对象形式存在周围还有其他对象头数据会导致整个密钥区域的熵值被拉低。这时候-e 7.0确实可能无结果建议降到 6.2 左右。有一个小技巧是先扫描自己写的一个测试程序提前知道密钥在内存中的形态再针对真实目标做参数调整。第二个常见问题是偏移地址的换算。aes-finder 输出的是文件内的绝对偏移而进程运行时的虚拟地址和文件偏移之间可能隔着页对齐的关系。如果需要把文件偏移映射回进程虚拟地址可以通过gdb的info proc mappings输出或者读取/proc/2333/smaps来做映射。这一步虽然繁琐但在做漏洞利用或者深度逆向时非常关键。再补充一个独家小技巧如果你要分析的对象是某个嵌入式设备的完整固件别急着拿整颗 flash 镜像去扫描先尝试用binwalk解包分离出内核、文件系统、bootloader 等部分。AES 密钥经常被存储在文件系统的配置目录里或者作为环境变量传入给应用层。先用文本搜索找到密钥相关字符串再结合 aes-finder 定位具体偏移能大幅提高效率也更容易理解密钥的分布规律。7. 密钥查找之外场景的补充与拓展aes-finder 用处并不局限于分析恶意软件或者做 CTF 题目。在不少合法的开发场景里它同样有参考价值。比如在开发嵌入式产品时工程师需要确认硬件设备上的 AES 密钥是否安全存储在安全元素或者信任根中。如果密钥在系统启动过程中被加载进普通 RAM那么一旦攻击者获得物理访问权限通过调试接口和内存转储就能取走密钥。用 aes-finder 做一次自查就能评估出产品在运行时的密钥暴露风险。再比如做大型系统性能优化的时候如果怀疑某个模块的加解密动作没有走硬件加速而是把密钥保存在了非预期区域也可以通过抓取运行中的内存来验证。虽然 aes-finder 本身没有提供诸如图形界面、预置的威胁分析报告之类的花哨功能它的定位始终是一个小巧、专注的命令行辅助工具但恰恰是这种专注让它很容易嵌入到你自己的分析脚本工作流里。我个人的经验是安全工具从来都是搭配组合使用效果最好。纯粹依赖单一工具去窥探整个系统的运行状态往往容易得出片面的结论。aes-finder 更擅长做“粗略定位”和“候选筛选”最终的精确定位和关键判断还是要靠分析人员自身的经验与上下文理解这一点值得每一位使用者记在心里。本文还有配套的精品资源点击获取