Watch as a vulnerability cybersecurity expert with 10 years of experience in the field becomes astonished by the reverse engineering powers of... GLM 5.3

**TL;DR：一位有 10 年经验的底层漏洞研究员用 AI（GLM5.3）在 16 分钟内完成了原本需要约一周的显示器固件逆向工程——从加密的 Dell 升级镜像中提取、解密并验证固件，作者由此担心逆向工程能力已经"商品化"。** ## 用 AI 黑进显示器，这件事让我有点害怕 一个以前我需要花一到两天、甚至一周才能完成的黑客项目，我真的只花了 15 分钟就用 AI 做完了。这件事开始让我有点害怕，我想解释一下我的思路。 首先设置一下场景：我要做的是入侵我自己的显示器。我知道你在想什么——等等，显示器也能被黑？是的，外设设备里有整整一个黑客的世界，显示器只是其中之一。显示器内部有一块固件（blob of firmware），用来处理 HDMI 命令、处理视频信号、处理可能存在的无线功能等等各种事情。 而我，作为一名底层漏洞研究员（顺便说一下，这是本频道的名字），想看看能不能在我楼上办公室的显示器——Dell S3422 34 寸显示器——上找到漏洞。我是一个 34 寸屏幕的爱好者，也许可以把这句从视频里剪掉。 ## AI 在漏洞研究领域的崛起 我知道你们可能已经看过新闻了——AI 在黑客技术上变得越来越强。我本人长期处于 AI 怀疑论者的行列，但每次我去实际测试这些模型——无论是 OpenAI 或 Anthropic 的前沿模型，还是像 GLM 和 Kimmy 这样的开源模型——它们在快速完成过去需要我花很长时间才能做的事情方面，变得非常非常强。 就像计算器彻底改变了人们做数学的方式一样，我真的认为 AI 将会彻底改变人们做漏洞研究的方式——凭借它自动化假设、在测试假设时快速得出具体结论的能力。 ## 目标：从固件更新程序中提取固件 当你去 Dell 的网站想要升级显示器固件时，流程非常简单：下载一个小的 `.exe` 文件，插上 U 盘，升级固件。 而我要做的是，深入研究这个 EXE，找到其中的固件本身，然后在那个固件中寻找潜在漏洞。通过利用这些漏洞，我可以在显示器上获得代码执行权限——我的目标就达成了。 ## AI 之前的做法：binwalk 递归提取 在 AI 时代之前，我以前会运行一个叫 `binwalk` 的小工具： ``` binwalk -Me ``` 这是对文件进行递归提取。我对这个 Dell 镜像运行这个命令，在 EXE 内部递归提取其中的文件来寻找其他文件。思路是：EXE 中将要刷入显示器的实际固件镜像，会藏在某个地方。 进入提取后的文件夹，你会看到各种东西掉了出来——这是预期行为。我们有一个自解压的 EXE，里面有一堆东西。其中两个特别突出的文件是： 1. **实际的升级文件本身**——包含我们显示器升级的型号和固件版本号 2. **Dell ISP library.dll**——这是在系统编程（In-System Programming）库，它应该包含用于上传和下载固件的函数，会告诉我需要在升级文件的哪个位置去寻找实际的代码 ## 遇到的第一个障碍：固件加密 现在事情开始变得更复杂了——而且 AI 真的只用了 16 分钟就完成了整个过程，我没有吹牛，我有时间线。 固件漏洞研究中一个常见问题是：固件通常是加密的。制造商可能不希望我窥探他们显示器内部的运作方式，所以他们加密了它。 你其实可以很快看出来——如果你用 binwalk 做一种叫做**熵分析**（entropy analysis）的操作，用 `-E` 参数运行，你会得到一个很酷的小图表：所有图表的边缘数值都是 **0.96**。这是一个高熵边缘，意味着二进制熵非常高，数据位的随机程度足以表明它是被加密的。这不太妙。我不知道这个文件的密钥，我猜密钥被加密后藏在显示器的某个地方。 ### 广告时间：Sentry 大家在新闻里都看到了，AI 正在让黑客越来越容易地攻破你的应用程序。使用 Sentry，你只需要将 Sentry 集成到你的代码库中，很多时候只需要一行代码，就能获得一个清晰的错误流——所有在代码库中冒出来的异常和错误都会显示出来。 进入某个 bug 后，你可以看到 bug 发生的确切时间、发生的环境。使用 **Sentry 的 MCP 服务器**，我可以结合 MCP 数据和代码库，让一个 AI 代理帮我 triage 这个 bug。AI 代理非常快速地将 Sentry 通过 MCP 服务器提供的遥测数据与本地代码库耦合在一起，在 15 秒内就发现：问题的根本原因是用户提供的 GitHub URL 包含子文件夹，而项目仓库无法处理这种情况，因此抛出了一个没有被正确捕获的异常。Sentry 不仅告诉你发生了什么，还会展示一个建议的修复方案。 从安全角度来看，我个人最大的担忧是**安全债务**（security debt）问题——随着 AI 代理带来代码量的增加，各种东西开始出问题。这些看起来不那么严重的 bug，可能会逐渐累积演变成真正的安全漏洞。新用户通过下方链接可以获得 $100 的 Sentry 额度。 ## 用 Ghidra 逆向分析加密函数 如果你在 NSA 的逆向工程框架 **Ghidra** 中打开这个库，你会注意到一个叫做 `encrypt_decrypt_method` 的函数。"卢克，你是我的唯一希望"——我们唯一的希望就是，在这个函数的某个地方，藏着加密和解密这些固件镜像的密钥，这些固件在被推送到显示器并刷入之前需要先加密。 打开二进制文件，进入这些函数中的某一个，你会看到一个叫做 `encrypt_decrypt` 的虚函数表。这就是逆向工程的过程变得**非常迭代、非常需要暴力测试和尝试**的地方——而 AI 让这一切变得可怕地简单。 在这个 encrypt-decrypt 方法的虚函数表内部，有**九个函数**，每个函数做的事情都不同，其中很多包含看起来像是随机数据的内容。我干这一行有一段时间了，我很快就能看出这里的 ASCII 数据通常是某种加解密算法的密钥。但如果你再往下滚动一点，情况就变得有点复杂了。 突然间，我们看到了大量的 for 循环，大量的随机结构用其他结构中的值来填充。不知不觉中，情况变得非常难以管理，非常难以理解这里到底在做什么。 这就是逆向工程。你可以像这样浏览一个二进制文件，盯着它看，最终你会弄清楚制造商的意图、写代码的人的意图。但这一切不是免费的，不会自动发生。你必须花大量时间进行迭代、猜测，做出有根据的假设和测试，试图减少你对程序心智模型中的噪声。 ## AI 如何加速逆向工程 AI 非常擅长缩小这个搜索空间。逆向分析这样一个加密例程的问题在于：加密可能开始或结束的文件偏移量并不总是显而易见的。因此，如果你在加密或解密过程中弄错了一个字节、一个字符，结果就会完全错误。这就是你需要对假设进行一些暴力测试的地方。 但通过使用 AI，我们可以让这一切快得多。我输入的全部内容是： > "Hey, I'm trying to find the firmware in this image, and I want to identify the HDMI command parsers in the firmware. The firmware is potentially encrypted." 就这些。我说的就这些。我让它运行了。 ## 时间线：16 分钟的奇迹 各位，这是时间线。我说 15 分钟，可能是标题党了——实际是 16 分钟。但按照我每天 8 小时的全职工作时间来算，这可能需要我花大约一周的时间。你可以说这是"技术水平问题"（skill issue），但不管怎样，它在 15 分钟内完成了。 AI 达到了我们之前所在的步骤——大约在 **13:51** 标记处，事情变得超级可怕： 1. 它启动了一个会话 2. 它找到了那个 **UPG 容器**——即包含实际镜像的升级文件 3. 它启动了 **Ghidra MCP**，将二进制文件提升为伪 C 代码（它在猜测制造商的 C 代码的最佳情况，因为我们实际上并没有那段源代码） 4. 它识别出了我们在 Dell ISP library 中发现的同一个函数 5. 它立刻注意到：**"等等。在函数 10012A60 中，有一个构造函数创建了一个密钥 blob。然后，这个另一个函数就是字面上的 decrypt，它使用该密钥 blob 中的数据对操作运行密码学数学运算。"** 6. 它提取了那些密钥，在**不到一分钟**的时间内，用 Python 写了一个解密 UPG 文件的脚本 7. **不到 40 秒**后，它运行了对该镜像的第一次解密，并说：**"是的，解密已确认。"** ## 验证：MD5 校验 作为任何一个做 AI 漏洞研究的人，你应该也跟我一样非常怀疑。我们怎么能这么确定？怎么能确定二进制文件真的解密了，而不是一堆高噪声的胡言乱语？ 接下来的这部分，AI 在 **45 秒**内就完成了。 ### 决定性的验证步骤 决定性检查是：解密后的镜像在偏移量 **0x1CD** 处携带了自己的 MD5 值。这个 MD5 是由 DLL 在明文基础上计算的——如果相应的 MAC 字段被清零的话。 它取输出的镜像，跳到偏移量 **0x1CD** 的位置。当它将这个字段清零并对整个镜像做 MD5 计算时，MD5 值就放在那里。它写了一个小脚本来检查这一点，然后直接说： > **"存储的 MD5 是这个，计算的 MD5 是这个。根据我查看不到 15 分钟的这个 DLL 的规范，它被正确解密了。"** 不是我——是 AI 说的。 ### 更多验证：熵分析、架构匹配、有效复位向量 不仅如此，它还对二进制文件进行了**统计熵分析**，显示某些模式中包含零和 FF，其字节密度符合从 flash 到 flash 的固件的预期，还有与该镜像相关的明文语义。 它还知道，它认为自己反汇编出的代码实际上与 **MSTAR 8051** 是一致的——这就是显示器内部的微控制器架构。而且，它在镜像的正确偏移位置包含了一个**有效的复位向量**（reset vector），这正是开始执行的地方。 你可以验证这些数学计算，可以进入镜像本身逐行查看，你会发现它解密出的内容不仅包含显示器的**有效型号编号**，还包含**具体的构建版本**，以及关于此的大量其他元数据。 ## 为什么这很可怕 但是你开始看到的真正令人害怕的东西是这些模式： - 这**完全就是胡言乱语**（gobbledygook），对任何阅读这段输出的人来说都是毫无意义的 - 但如果在一个原本不是重复模式的镜像中，你开始看到这些**重复出现的模式**——这表明这里存在某种数据结构，可能是一个**函数指针表**或其他对二进制文件来说具有结构性的东西 - 然后你开始看到这些模式：`0208????`、`0208????`。这可能是一个函数的前导码，或者是指令在其编码中的起始方式。这是该镜像是一个**格式正确的镜像**的一个非常好的指示 - 然后我们去到镜像的最底部，看到那些 **FF 模式**——这标志着这是一个 flash 镜像的结束，因为 flash 中零的位置实际上是高电平的 FF ## 这意味着什么 如果你们中有些人没跟上，很好。这个视频的目的不是教你们如何做逆向工程，也不是教你们我的思路。这个视频的目的是向你们展示：**去混淆、拆解那些设计不当的东西并找到其中问题的能力，现在已经商品化了。这是任何人都能做的事情。** 你可能会问：这到底有什么问题？如果这个东西的目的是保护 Dell 的知识产权，那么把加密方式直接提供给用户，这本身就是设计中的一个**固有缺陷**。 如果你要正确地做这件事，你的方式应该是：来自实际用户的 flash 文件在静态时就是加密的，它被刷入主板固件中的某个位置。然后从主板或微控制器的角度——在 ROM 中固化一个密钥，你无法从该 MCU 中提取——之后在主板上使用该密钥进行解密。用现在这种方式做，本质上是有缺陷的。 而且，任何有技能的逆向工程师都能在几天、也许一周内完成这件事，甚至更少。也许我在这里表现出的是技术水平问题，有些人可能只需要一天、两天。 ## 结论 GLM5.3 只用了 **15 分钟**就完成了这件事，据我最好的判断，结果看起来是正确的。 这对安全领域整体意味着什么？**更多的 bug。任何人都能做逆向工程。任何人都能找到漏洞。** 就这些，感谢观看。 Source: [Watch as a vulnerability cybersecurity expert with 10 years of experience in the field becomes astonished by the reverse engineering powers of... GLM 5.3](https://youtu.be/wIe3eDfGKUo)