从G-code到RCE：Prusa MK4S 3D打印机安全研究全记录

背景与动机：一个业余安全爱好者的逆向之旅

我从来没写过一行Cortex-M汇编代码。这是实话。我白天做平台工程、SRE和数据库方向的自由职业，安全研究是下班后的业余爱好。这些年我参加过不少CTF，后来被LiveOverflow的视频勾起了对逆向和pwn的兴趣。更早之前我在客户的Web应用里做过主动扫描，有过几个真实发现，但固件和硬件是另一回事，之前我从没碰过。来源：Dixken

挑上Prusa MK4S的理由很简单，它是我自己的机器，运行的是当时最新的签名固件6.5.7（build 6.5.7+12836）。工具方面我也没下什么血本，Opus 4.8逆向工具加一个自己攒的fuzzer。起点选在G-code解析和Prusa Connect两处，理论依据是那条朴素的经验，用户输入从哪进来，漏洞通常就在哪。后来在USB和FAT路径、transfer-recovery代码，以及MMU和EEPROM上找到的小缺陷，都印证了这个方向没有选错。来源：Dixken

2024年8月，我花了一整周时间在这台MK4S上。当时我的预期很朴素，找到几个能上报的bug就收工。一周后我坐在电脑前，手里有14个findings和一条完整的RCE利用链，足够写一篇长博客了。那也是我第一次意识到，固件安全研究不一定需要多深的基础。来源：Dixken

关键发现：14个漏洞、23个缺陷与一条RCE攻击链

成果比预期大得多。一周下来，14个独立安全问题，拆开算约23个具体缺陷。攻击链的终点是打印机的主控制器执行了我通过网络发过去的代码，完全的远程代码执行，RCE。从G-code解析和Prusa Connect两个入口出发，最后汇成一条完整的利用链，中间穿过了USB、FAT、断点续传恢复代码，还有MMU和EEPROM上那些小缺陷。来源：Dixken

让我印象最深的其实是方法本身。我没有一上来就用现成的二进制分析工具瞎翻，而是把固件自带的解析器代码单独编译到host上，跑AddressSanitizer。这样一来，任何崩溃都落在Prusa的代码里，不会是我写的胶水代码背锅。然后我搭了一个小型的Cortex-M模拟器，在模拟器里喂那些解析路径。G-code解析和Prusa Connect是重灾区，但漏洞散得到处都是，每个我碰过的输入路径都多少有点发现。来源：Dixken

所有发现都报告给了Prusa，我也为全部findings请求了CVE编号，目前还在等待分配。如果有人知道怎么加快CVE的分配流程，我乐意听听。这个过程比我想象中要慢一些。来源：Dixken

修复与反思：Prusa官方回应及作者的判断

Prusa的反应比我预想中利落。所有发现都在Buddy固件>7.0.0中修复了，我们协调了公开发布时间，这篇文章和官方安全公告同时上线。如果你在文末的受影响打印机名单里，现在就去更新固件。这是作者在文章开头就写清楚的话，我也把这句话放在这里。来源：Dixken

我注意到一个细节。Prusa的官方公告说全部修复了，而作者仍然强调用户必须主动更新。这两件事不矛盾，但放在一起看，漏洞的实际影响面可能比官方声明更广。我不确定这是否意味着Prusa低估了某些问题，还是只是谨慎起见让用户自行确认。也许两者都有。来源：Dixken

更值得说的是这个判断。一个业余爱好者，一周时间，基础工具，攻破了一台主流3D打印机。消费级固件安全存在认知盲区，这台打印机就是例子。固件把G-code和网络请求当成用户输入处理了，但那些输入从来没被当作不可信数据认真对待过。安全研究这件事，业余爱好者同样可以做，小厂设备同样值得挖。我这次没写一行Cortex-M汇编，也把机器打穿了。我不知道如果换成熟悉ARM汇编的人会不会更快，但肯定更顺手。来源：Dixken

原文：

Never gonna print you up · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月3日