重建天堂之門：從 32 位元地獄一路打回天堂聖地（下）攻擊篇：x96 Shellcode、天堂聖杯 ＆ 天堂注入器
WOW64逆向工程 在前一篇部落格文 重建天堂之門：從 32 位元地獄一路打回天堂聖地（上）深度逆向工程 WOW64 設計 筆者已經以逆向工程角度完整解釋了微軟這套幫助 32-bit 在原生 64-bit Windows 執行之架構的設計 若讀者尚未有研究過天堂之門相關基礎、建議先回到上一篇文通讀後再回來本文閱讀。而接下來我們會把焦點圍繞在接續著如何將上一篇的背景知識組合出一些有趣的利用手法 :) x96 Shellcode 這是我覺得最有趣的一個玩法XD 通過逆向工程 WOW64 架構後，發現了通過 cs segment 區段暫存器值 23h 或 33h、得以確認當下 Intel 晶片正在將 program counter 上的程式碼以 32-bit 或 64-bit 指令集解析。 因此藉由此區段暫存器值，我們也能創建出一個 x96 shellcode、亦即同時可當作 32-bit 也可當作 64-bit 的 shellcode！設計概念相當簡單，便是在 shellcode 開頭處 設計一個彈頭 ：判斷當前 cs segment 值若為 23h 則跳去 32-bit shellcode 執行、反之是 33h 則跳去 64-bit shellcode 接續著執行。 講得簡單，設計起來實務麻煩點其實是確保 x96 彈頭 payload 在 32/64-bit 下解析起來的邏輯是一致的，比方 shellcode 相對偏移定址問題、32/64-bit 的指令 alignment 不對稱，或者連 branch jump 指令 offset 在兩指令集上算法超過 2 bytes 也會有問題 等。 所以在上面 PoC 中可以看到，彈頭中所有的指令 opcode 都特別挑選過是在兩種架構上皆相同的、才可確保在兩指令集上邏輯按照預期執行，舉例： call $+5 同樣是 \xE8\x00\x00\x00\x00 其在 64-bit 下會以 8 bytes 長度推入 return address 上堆疊，而在 32-bit 下僅推入 4 bytes 長度上堆疊 \x81\x04\x24 其在 32-bit 下被視作 add ds: [esp], xxxx。而在 64-bit 下會被自動擴展為 add ds: [rsp], xxxx 而挑選使用 call $+5; ad
