C# unsafe 深度探秘：棧緩衝區溢出與內存直接操控

在托管的 C# 世界裡，unsafe 關鍵字打開了一扇通往底層內存的大門。本文通過兩個極簡實驗，演示如何繞過 CLR 邊界檢查，直接讀寫棧內存，修改局部變量、甚至竄改方法返回值——純教學目的，展示托管語言的底層本質，切勿用於生產代碼。

前置知識：棧幀佈局

方法調用時，棧上依次分配：

1. 方法參數
2. 返回地址
3. 保存的基址指針 (EBP/RBP)
4. 局部變量（按聲明順序，通常向低地址增長）

stackalloc 在棧上分配非托管內存塊，返回指針。CLR 不檢查指針越界——這就是突破口。

實驗一：無限循環——覆寫循環變量

static unsafe void Main() {
    int* p = stackalloc int[1]; // 僅分配 1 個 int (4 字節)

    for (var i = 0; i < 30; i++) {
        Thread.Sleep(200);
        Console.WriteLine(i);
        p[i] = 0; // 故意越界寫入
    }
    Console.ReadLine();
}

現象：循環變為無限循環，輸出 0,1,2,3,4,5,0,1,2,3,4,5...

原理：

• p 指向棧頂附近的 4 字節區域
• i 緊鄰其上（高地址方向）
• p[6] 正好覆蓋 i 的內存位置（視編譯器佈局而定，實測 i=6 時被覆蓋）
• p[i] = 0 等價於 i = 0，循環重置

實驗二：竄改返回值——搜索並修改

static unsafe void Main() {
    Console.WriteLine(ChangeResult()); // 輸出 10000，而非 123
    Console.ReadLine();
}

static unsafe int ChangeResult() {
    int result = 123; // 預期返回值
    int* p = stackalloc int[1];
    int i = 0;

    // 向高地址掃描，尋找值為 123 的內存單元
    while (true) {
        if (p[++i] == 123) {
            p[i] = 10000; // 覆蓋為新值
            break;
        }
    }
    return result; // 實際讀取已被修改的內存
}

關鍵點：

• 編譯器將 result 分配在棧上
• 掃描循環定位到 result 的內存地址
• 直接修改內存，return result 讀取的是已被篡改的值

更危險的可能：控制執行流

棧幀中還保存著返回地址（指向調用者下一條指令）。若能精確定位並修改它，可實現：

• 任意代碼跳轉 (ROP 攻擊基礎)
• 繞過授權檢查
• 注入 Shellcode（需繞過 DEP/ASLR）

現代防禦機制使此極難利用：

• GS / Stack Canary：函數序言/結語插入隨機 Cookie，返回前驗證
• DEP (NX)：棧不可執行
• ASLR：模塊基址隨機化
• CFG / CET：間接調用目標驗證

為什麼 C# 允許 unsafe？

1. 互操作：調用非托管 DLL、COM 組件、系統 API
2. 高性能：避免陣列邊界檢查、指針運算優於索引（如圖像處理、加密、序列化）
3. 底層系統編程：OS 內核、驅動、運行時本身開發

安全紅線

• 生產代碼嚴禁 手寫越界指針邏輯
• 代碼審查 必須標記 unsafe 區塊，嚴格把關
• 靜態分析：Roslyn Analyzer、SonarQube 規則檢測 stackalloc、指針運算
• 沙箱隔離：插件系統、腳本引擎運行於受限 AppDomain/進程

結語

C# 的 unsafe 不是漏洞，是受控的危險能力。理解棧緩衝區溢出原理，能讓你更深刻地體會托管語言的安全邊界、編譯器優化行為、以及為什麼現代 OS/運行時要層層設防。知攻擊，更懂防禦；懂底層，寫代碼才心中有數。