【人工智障/上】逆向工程與安全審計的 Agentic 自動化

人工智障的狂歡
遊戲規則的鬆動……
問題的開端
人工（非智障）的解法
逆向工程自動化
結語
附錄

人工智障的狂歡

群友們好！

最近，妳們和 AI（人工智障）玩得怎麼樣啊？俺相信許多群友已經是屬於那種離了 AI 就不會工作、不會研究、甚至不會考試的狀態了。

俺也是，上頭 (?) 天天沒事就強調「新質生產力」，說是要用 AI 把生產效率提高一個數量級。那俺的工作方式自然也是 AI 全開，無論是面向內部的開發演示，還是面向外部的寫稿話術，基本上都要在中間加一道 AI 流程。這麼一來，生產力提高是提高了，但是變現的瓶頸卻去到了其他的地方，俺這部門也沒能雞犬升天。

工作上對 AI 的濫用導致我下班後對 AI 極度厭煩，甚至導致我在私人時間完全不想做開發，最多就讓 AI 寫寫 blog 前端。有這時間觸摸那些一股「AI 味兒」的代碼庫，還不如讓我去和人類群友多玩幾局畫猜，或者多推幾把 Galgame；因此，俺的 blog 裏面也很少提及 AI 話題，而上次提到還是在去年 6 月，俺把 👉🏻IDA 反編譯出的代碼塞給 AI 解釋，說是要在 macOS 上重啓逆向工程之旅了 😁

同時，當別人在着了魔似地折騰 MCP，養龍蝦，燒 token 的時候，俺都在一旁看個樂呵。這些和俺一直在用的 GitHub Copilot（學生免費套餐）有何區別？給牠個 webfetch，Baomini 都能上網衝浪當包蜜，所以俺覺得這些浪潮就像是被程序員玩爛的東西進入了下沉市場。

遊戲規則的鬆動……

但是從今年開始，有一樣東西開始出現變化，讓我感到了一絲絲不適——AI 開始撼動網路安全的遊戲規則了。A畜家的 Mythos 說是把 Linux 內核和衆多開源軟件肏了個遍，史詩級漏洞天天爆，不過爆太多人麻了也就習慣了。可是另一邊，AI 也大大降低了網路攻擊的門檻，而且 AI 帶來的超額利潤也讓身爲目標的企業員工和個人開發者顯得更加肥美，於是供應鏈攻擊如排山倒海而來，首當其衝淪爲最大毒窟的是 npm，一時間人心惶惶，俺也趁此機會把 blog 的整個寫作環境封進了 Docker 保平安。

既然開發環境不可信任，那編程 Agent 自然也要謹慎對待，所以俺把 Opencode 也塞進了 Docker，防止他暴走的時候把我電腦給 rm -rf 一波帶走 😇 既然謹慎到了這種程度，那電腦上的第三方軟件是不是也不能放過呢？於是俺發現，再這麼追究下去，自己很快就要加入自由軟件基金會了。爲了方便，俺決定對開源軟件和一些信譽優良的軟件網開一面。

現在剩下的問題，就是俺該不該信任那些來歷不明的小開發者的軟件了。俺並不是想要把小開發者都一棒子打成木馬製造者，相反，俺自己也是小開發者，也知道自己的侷限性——開發水平一般，軟件用的人少，萬一有問題更難暴露。雖然俺心裏也相信願意無私貢獻代碼的都是好人，但是這些客觀存在的安全問題並不會因爲個人的感情而消失 😇

在第三方軟件的安全隔離這方面，相比於大大方方往裏進的那個系統，其他的 OS 都具備了一些自我保護的功能。Linux 上可以用 Docker、Flatpak、bwrap 甚至 SELinux 來實現沙箱化；macOS 也有 AppStore 沙箱和 sandbox-exec。但是要把所有第三方軟件塞進沙箱是一項巨大的工程。因此對於那些處於灰色地帶的軟件，俺的態度一直處於「用就不怕，怕就滾蛋」的進退兩難狀態。

現在的問題就來到了「如何確保第三方軟件安全運行」上面。俺當然可以把所有第三方軟件往 sandbox 裏面一封了之，然後假裝高枕無憂——但是這種方法回答不了一個根本問題：這個軟件到底安全嗎？又或者是說，作者到底做了些什麼？俺認爲就算是在沙盒系統上，安全審計仍然有其必要性。

以往，對一個閉源軟件進行安全審計，需要安全專家夜以繼日地幹上兩個星期。可是現在每個人的電腦上都有一個擁有無限知識，還精通各種電腦操作的東西。雖然它性能不及 Mythos 吧，但是和孱弱的人類比起來效率還是高多了，事已至此，髒活累活這塊俺是一點都不想繼續幹了。

Opencode，妳崛起吧……😁

問題的開端

衆所周知，本群是一個從美少女身上長出來的社區，每週的畫猜更是雷打不動的傳統。但是最大的問題恰恰是畫猜這個遊戲本身。該遊戲在前幾年靠着一個創新的「接龍模式」打破了原本傳統畫猜無聊的刻板印象，成功吸引到了大量的玩家。但是玩家群體的壯大並沒有逼着開發組去大力改善遊戲的穩定性，恰恰相反，他們把所有時間都花在了設計 UI 和氪金商店 (已破產)，而最基本的程序安全性是我在所有遊戲中見過的最爛的一個。

關於這一點，俺在 👉🏻博客玩家的困擾和遊戲玩家的煩惱提到過。具體來說，拋開那些嚴重的遊戲狀態管理 (state management) 的 bug 之外，這遊戲在網路通訊上使用全明文傳輸，如圖：

該遊戲在通訊中同時使用了 HTTP，UDP 和 ICMP 三種協議，並且完全不加密😰。這裏俺想要先破除一個誤解，很多人認爲不加密導致的最嚴重的後果就是被老習看到聊天記錄，但是後果絕不止於此。萬一遊戲的代碼對網路數據包的處理存在 bug，引起遠端代碼執行漏洞的話，網路上的任何一個攻擊者都能夠通過構造數據包來一瞬接管畫猜玩家的電腦，把所有的 OS 都變成那個系統。加密網路通訊阻擋的就是這一攻擊面，可惜🥦中並不存在這一層防禦。

俺實在不知道畫猜的開發者是喝了多少斤鴻茅藥酒才寫出這種華爲天才少年代碼，畢竟某人在做畢設的時候就已經知道要把 WebSocket 塞進 TLS 了。所以說，給 UnityWebRequest 加個 https://，很難嗎？給 Hazel 開個 DTLS，很難嗎？回答我！妳爲什麼要把所有玩家的電腦和遊戲數據放在網上裸奔？回答我！！

好啦，罵歸罵，但是爆破 C# 的內存做 RCE 的可行性非常低，哪怕遊戲被投餵惡意數據，最嚴重的後果就只是遊戲內容被篡改或者崩潰罷了。俺相信這一點也是畫猜開發者敢把這種代碼直接端上桌的自信來源，彷彿用了 C# 就像是進了保險箱了。但是其實，誰也保證不了 C# 不被爆破，大投毒時代，妳怎麼保證數據鏈流經的每一個第三方庫和函數都完美無瑕呢？所以俺已經在認真地考慮要把畫猜塞進隔離容器了。

前面鋪墊了那麼久，其實還沒到最雷霆的問題。真正的問題開端在於，畫猜的畫筆引擎太他媽難用啦！沒有壓感就算了，採樣率還奇低無比，導致所有線條畫出來都是僵硬的多邊形：

這時候有的群友就要說了：這是好事啊！美術老師都叫我多用直線，少用曲線，自信下筆，製造形狀，而畫猜設計成這樣，一定是在訓練妳的繪畫功底！那真的謝謝妳了，這畫筆的跟手程度，堪比從中環到中信大廈的 3G 遠程飛行訓練，三年這麼練下來直接給我練廢了。

即便俺繪畫水平一般，俺也希望能操作得舒服一點，而和我有相同想法的人似乎也不在少數。有一天，一個群友給我發了一條 👉🏻逼站的神必連結，說是有一個玩家製作的第三方畫猜插件，能極大提升遊戲體驗。

俺託人下載下來一看，是一個神必壓縮包，裏面有一個 Assembly-CSharp.dll，說是要把它覆蓋到遊戲目錄下。

Assembly-CSharp.dll 是 Unity 遊戲引擎編譯後的核心二進制文件，一般來說，遊戲的主程序邏輯全部都在裏面。考慮到 Unity 使用 C# (.NET) 進行開發，插件的作者應該是用 dnSpy 反編譯了整個 dll，再插入了自己的代碼後進行了重新編譯。

在軟件安全和逆向工程領域，大🔥們經常調侃「.NET 程序根本不需要開源，因爲微軟已經強行幫妳開源了😁」，而這主要是 .NET 的編譯機制導致的。.NET 二進制的內容是一種類似於 Jvav 字節碼的 IL 中間語言，由 .NET VM 執行，爲了實現反射和動態加載等高級特性，.NET 內部保留了大量元數據，只需要把 dll 往 dnSpy 裏面一拖，一瞬就能還原出一份一份一份，一模一樣，連變量名都原封不動的 C# 源代碼。

裝上這個充滿了逆向風味的插件後，俺試玩了兩局遊戲。雖然水平還是那樣吧，但是至少甩線不卡了啊！而且壓感筆觸甚至給了這張圖一點……風格化 😁 這是我能在🥦裏面看到的畫風嗎？

俺對這個插件很滿意，正準備把文件分享給群友的時候，才後知後覺地意識到這是個第三方軟件。俺應該對此稍微謹慎一點，於是隨手丟進了 dnSpy 看了一眼。不看還好，一看壞了，這啥啊！

原本的遊戲邏輯不知所蹤，取而代之的是一堆混淆過的類名，還有一堆控制流鋪平風味代碼。不過最刺眼的還是那句「This assembly is protected by an unregistered version of Eziriz’s ”.NET Reactor”! This assembly won’t further work.」😁

很顯然插件作者給插件加殼了，加的甚至還是盜版殼 😅 而一個加殼的軟件在安全審計上就是一個極其醒目的警告標誌。俺還敢把這玩意發給群友嗎？

人工（非智障）的解法

先聲明一點，俺並不是想一棒子打死所有加殼行爲，也不會蠢到把加殼和隱藏惡意代碼直接劃等號。恰恰相反，俺非常能理解小開發者和補丁作者們的考慮。程序一旦公開發佈就身不由己了，因此自己的作品要是遭到一些別有用心的人濫用、甚至被佔爲己有，也是毫不稀奇的。而小開發者們精力實在有限，無法和作惡者正面對抗，這就使得通過技術手段保護自己的程序成爲僅剩的選擇。

俺在很久以前參與過遊戲補丁的製作，整個工程耗費了組裏八個人一整個月的時間，而我們做出來的東西在性質上十分脆弱，屬於是那種極易被人拿去移植、二創甚至倒賣的東西，爲此俺額外花了一個星期去手撕了一套文件加密和校驗機制，讓破解變得非常不划算，從而保住了節操。所以俺大概是能和畫猜插件的這位作者感同身受的。不過還是那句話，個人感情和系統安全並不能混爲一談。

這個插件被一個盜版的 .NET Reactor 保護，而這個保護器由於過於出名，GitHub 上已經有大神寫出了 👉🏻一鍵脫殼機。俺嘗試了一下，確實是一鍵就把殼脫得連底褲都不剩了。所以說親愛的作者妳這 .NET Reactor 是加了個寂寞嗎？而且盜版殼還會在 14 天之後讓遊戲閃退，逼迫妳定期更新，這不是自找麻煩嗎，，，

脫殼後 dnSpy 成功解出了補丁裏面的所有函數。隨意翻看了一下代碼之後，俺發現了一個一直以來都很在意的部分：爲什麼畫猜總是 tm 掉線？

查詢調用鏈之後俺發現了畫猜開發者的天才少年班設計：通過狂 ping 來測試網路連通性，一旦 ping 不通了，哪怕 Hazel (UDP) 還連着，也要強行顯示已掉線。妳們難道不知道 Hazel 可以處理 disconnect 和 reconnect 事件嗎？妳說妳知道？那爲什麼還要脫褲子放 ping？回答我！！

逆向工程自動化

畫猜的代碼水平過於中級，看着看着拳頭硬了，害得我都忘了本文的目的是要對遊戲插件進行安全審計了。事已至此，對於這種可信程度也中級不堪的東西，還不如整個丟進 sandbox 甚至 Wine 裏面更省事。這篇文章寫完之後俺一定要這麼做。

但是考慮到還在用那個系統玩畫猜的群友們，爲妳們做安全審計是 my duty！所以接下來要討論一下威脅模型和審計的方向。

大投毒時代，惡意軟件的商業模式已經從過去的「勒索 + 破壞」轉向了「潛伏 + 盜取」。以前系統防護的重點是防止系統被拿到 root，而現在攻擊者最喜歡的東西是：

瀏覽器 Cookies
本地敏感文件：SSH key, .env, API token
供應鏈投毒權限：開發環境中的代碼包或者倉庫寫入權限
妳的裸照 (?)

而直接遠端植入病毒是很困難的，現在的攻擊方式已經轉向對合法軟件的供應鏈投毒。由於人們和 OS 對這些軟件帶有天然信任，一旦毒素被注入基本上就沒有任何機制能阻擋入侵了。此外，相比於主程序投毒，軟件的插件市場（尤其是 VSCode 那個）的審查更加寬鬆，成爲投毒的新溫牀。

本次的畫猜插件的風險在本質上就屬於插件市場那一類，利用人們的信任長驅直入。萬一惡意軟件以這種方式進入系統，接下來它該做的事情就無非是：

以普通用戶權限潛伏運行
動態加載惡意腳本
盜竊用戶 HOME 目錄下的敏感信息
通過某種方式上傳數據

所以面對這個時代的威脅模型，傳統的「殺軟攔截」做法已經不太夠用了。最根本的方法就是轉向手機 OS 那樣的零信任 + 強隔離的安全模型，但是這並非能一蹴而就的事情，畢竟就連 macOS 也沒能號召所有的桌面 App 進沙盒。

上述的威脅模型分析告訴了我們安全審計的方向，那這次就先嘗試檢查「動態加載」「開新進程」「讀取文件」和「網路上傳」的敏感操作。可是話說回來，遊戲的整個代碼庫有 6,000 多個 Class，插件作者也新增了 100 多個 Class，俺親自一個個查肯定是不現實的，必須要用機器才能對抗機器。

一個比較現實的做法就是同時脫殼遊戲 dll 和插件 dll，再反編譯對比他們的差異。檢查的時候主要看插件作者是否魔改了原有的函數，怎麼魔改的；還有插件作者引入了哪些新函數，都具有啥行爲。而調查行爲的方法就是查 .NET API 調用，因爲無論是讀取文件還是上傳數據都需要用到 API，只要用到 API 就會留下痕跡，俺只需要在敏感 API 上設卡攔截就行了。

接下來的工作就比較枯燥了，俺和人工智障討論了老半天，最後敲定安全審計流程如下：

表 1：安全審計流程

Step	Name	What it catches
0	Deobfuscation	Strips .NET Reactor/ConfuserEx protection
0b	Metadata Repair	Fixes broken metadata tokens from deobfuscation
1	Structural Diff	New/removed types, method count changes per class
2	String Extraction	New URLs, IPs, domains, file paths
3	API Call Surface	22-category scanning: networking, process, reflection, IL emit, deserialization, marshalling, remoting, WMI, DB, crypto, XAML, code compilation
4	IL-Level Method Diff	Opcode histogram, callee set, type refs, basic blocks (shared methods)
4b	New Method Deep Analysis	Callee graph, caller graph, reachability, dormancy, Reactor remnant detection (plugin-only methods)
5	Report	Cross-referenced findings across all steps, finding dashboard, Reactor auto-downgrade, AI executive summary

俺們除了標記敏感 API 以外，還檢查是否有引入新字符串，要是不懷好意之人要把數據上傳到 https://ex-tasty.com/evil，這個 URL 就會在字符串中暴露出來。如果字符串有加密，處理字符串使用的加解密算法，編解碼操作則會在 API 和 Type 掃描中暴露出來。

AI 還幫我編寫了全套的逆向腳本，可以把每一步的執行結果都寫進 JSON 裏面，最後再把整個流程詳細地寫進 SKILL.md 裏面，讓 agent 來主導整個流程。俺覺得 AI 自動化對比單純的自動化腳本的優勢就在於，AI 可以能動地對每一個步驟進行監視，並主動消除錯誤和疑惑；而最終的報告撰寫的部分也是 AI 的強項，牠可以根據自己的理解查詢資料、糾正偏差並給出建議。這樣的報告參考價值會比以往的機械生成報告高出太多。

對於插件的 3.0630 版本，AI 給出的審計結論如下：

👉🏻 點此展開

# .NET Game Plugin Security Audit Report

## Verdict: 🟡 **SUSPICIOUS**

## Executive Summary

This report presents the results of a five-layer security audit comparing the
**Draw &amp; Guess third-party plugin DLL** (3127 types) against the **original game DLL**
(3083 types). The analysis covers structural changes, string extraction, API
call surface scanning, IL-level method diffing of 16,673 shared methods, and
deep analysis of 452 plugin-only methods — cross-referencing findings across all
layers to eliminate false positives and deobfuscation artifacts.

**No active malicious behavior was detected.** The audit found zero reachable
code paths that exfiltrate data, execute external processes, or communicate with
unauthorized network endpoints. All URLs in the plugin are game-server endpoints
(acureus.com, drawandguess.com, playfabapi, Steam, Twitch, DeepL translation)
that are present in both the original and plugin DLLs.

The audit initially flagged reflection-based code generation (612 calls to
`DynamicMethod`, `ILGenerator`, `OpCodes`) as CRITICAL, along with 67 additional
reflection, marshalling, remoting, and native P/Invoke calls. Cross-referencing
with Step 4b's caller-graph analysis confirmed that **all of these are confined
to `Class24`** — a .NET Reactor runtime stub left behind by the deobfuscation
tool (NETReactorSlayer). Class24 is a `private` class appended at the end of the
assembly with zero game-code callers. Its contents (delegate trampolines, string
decryption loops, anti-tamper checks) are standard Reactor protection-layer
boilerplate and never execute in a deobfuscated build. All 62 Reactor-attributed
methods have been reclassified as `REACTOR_REMNANT` (informational only).

**Five real changes were detected in sensitive classes:**
`Bootstrap::Initialize` (+22 IL instructions), `Bootstrap::InitLogging` (+2),
`LobbyConnectionHandler::TryJoinByRoomCode` (+6),
`LobbyConnectionHandler::TryCreatePublicMatch` (+6), and
`LobbyConnectionHandler::.cctor` (-2). These are modest code changes consistent
with instrumenting initialization and lobby matchmaking for plugin features
(drawing tools, UI extensions, artbook integration). None introduce dangerous
API calls. The new type references (`LoadSceneMode`, `Func<bool>`) are standard
Unity idioms.

**22 SUSPICIOUS methods and 12 DORMANT_DANGER methods** were identified among
the 452 plugin-only methods. The SUSPICIOUS group (Class14–Class27,
`Class25`1`) have obfuscated class names and zero external callers — they are
additional deobfuscation artifacts similar to Class24, likely yield-iterator
state machines and compiler-generated closures from the post-Reactor cleanup.
The DORMANT_DANGER group (`PressureLineCreator`, `DrawableElement`) contains
internal cryptographic operations (likely for procedural line/pressure data
hashing or checksumming) but is not reachable from game code in the current
plugin build.

**Overall verdict: SUSPICIOUS** — not because of active threats, but because 22
obfuscated-named methods remain unclassified as dormant code. None are reachable
from game logic, and none contain networking, process execution, or file
exfiltration capabilities. The plugin's declared features (enhanced drawing
tools, undo/redo, pressure-sensitive lines, picker UI) account for all
reachable new methods. **If the SUSPICIOUS methods are confirmed as
deobfuscation artifacts by the plugin author, the verdict should be downgraded
to SAFE.**

### Audit Scope

- **3025** original types → **3069** plugin types (62 new, 18 removed)
- **16673** shared methods compared at IL level (+5207 new IL instructions)
- **65** plugin-only strings extracted (3036→3052 total)