Windows 和 Unix 系統上的記憶體轉儲和核心分析

資訊科技數位 » recursos » Windows 和 Unix 系統上的記憶體轉儲和核心分析

當作業系統發生恐慌或崩潰時，了解發生了什麼的唯一方法是獲取核心記憶體轉儲並進行分析。這些轉儲文件捕捉了系統在故障發生瞬間的內部狀態，對於偵錯複雜錯誤、調查安全事件或進行取證檢查至關重要。

雖然聽起來很“底層”，但記憶體轉儲分析並非核心開發人員的專屬領域。系統管理員、支援工程師甚至安全審計人員如果掌握了合適的工具、不同類型的轉儲文件以及基本的解讀技巧，也能從中受益。我們將帶您了解在 Windows、Unix/Linux 和 BSD 系統上使用 WinDbg、crash、kgdb 和 LiME 等工具進行記憶體轉儲分析的整個過程。

什麼是核心記憶體轉儲？為什麼值得分析它？

核心記憶體轉儲（通常稱為核心崩潰轉儲或簡稱崩潰轉儲）是一個文件，其中包含系統發生嚴重故障（例如Unix/Linux 中的核心崩潰或 Windows 中的藍色畫面死機 (BSOD)）時記憶體的完整或部分副本。

實際上，這種類型的轉儲會保存核心內部結構、呼叫堆疊、進程上下文和已載入的驅動程式。因此，災難發生後，可以進行類似於調試運行中系統的災後分析，而無需承受在生產機器發生故障時進行操作的壓力。

深入研究內核轉儲的原因多種多樣：從調試看似隨機的錯誤和間歇性崩潰，到調查系統是否被惡意篡改，或者崩潰是否可能在磁碟上留下敏感資訊的痕跡。

除了完整的核心轉儲之外，還可以對單一進程進行轉儲（經典的核心轉儲），這在我們想要將問題限制在特定應用程式或檢查對電子郵件或訊息用戶端等服務的機密性的影響時非常有用。

Windows 系統中記憶體轉儲的類型及其用途

在 Windows 系統中，當發生 STOP 錯誤時，作業系統本身會產生不同類型的轉儲檔案。每種類型的轉儲檔案包含的資訊詳細程度不同，因此根據問題和磁碟空間限制了解所需的轉儲檔案類型至關重要。

用戶環境和許多伺服器中最常見的格式之一是 小型記憶體轉儲（minidump）它是佔用空間最小的，通常位於 %SystemRoot%\Minidump，以及樣式文件 MiniMMDDYY-01.dmp.

這個小型轉儲包含非常具體但重要的資訊：STOP 錯誤代碼及其參數、故障時載入的驅動程式清單、停止的處理器的上下文 (PRCB)、涉及的進程和執行緒的上下文 (EPROCESS 和 ETHREAD 結構) 以及該執行緒的核心模式呼叫堆疊。

由於這些基本結構，即使使用小型轉儲文件，通常也可以確定是哪個驅動程式或模組導致了崩潰，但如果問題源於崩潰時正在運行的線程之外，並且可用的上下文資訊有限，則不一定能夠追蹤整個過程。

Windows 還可以產生核心記憶體轉儲和更大的完整轉儲，其中包含部分或全部實體記憶體。這些轉儲對於底層分析、取證調查以及驅動程式或系統本身的高階調試尤其有用。

使用 WinDbg 和 KD 在 Windows 中配置和開啟記憶體轉儲

要在 Windows 系統中使用系統轉儲，第一步是正確配置啟動和復原選項。在控制台的進階系統屬性中，您可以選擇在系統發生故障時要產生的轉儲類型，例如「小型記憶體轉儲 (256 KB)」以及轉儲的儲存路徑。

該系統還需要啟動磁碟區上至少幾兆位元組的頁面檔案來寫入轉儲檔案。在現代版本的 Windows 系統中，每次崩潰都會建立一個新文件，並在配置的資料夾中保留歷史記錄，以便輕鬆查看過去的事件。

產生轉儲檔案後，有多種方法可以驗證其正確性。 Dumpchk.exe 是一個經典的實用程序，它允許您檢查檔案的基本完整性並列印摘要資訊。對於更進階的分析，可以使用Windows 偵錯工具，包括 WinDbg（圖形介面）和 KD（命令列版本）。

從微軟網站安裝偵錯套件後，這些工具通常會位於類似C:\Program Files\Debugging Tools for Windows這樣的資料夾中。從那裡，您可以打開命令提示符，並使用 WinDbg 或 KD 載入轉儲文件，透過 -z 參數指定文件。

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

符號路徑可以指向具有本機快取功能的符號伺服器，例如：

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

二進制路徑通常是這樣的 C:\Windows\I386 或者，也可以是我們將產生轉儲檔案的版本對應的系統執行檔複製到的資料夾。這一點很重要，因為 小型轉儲檔案並不包含所有二進位檔案。只有對它們的引用，因此調試器需要能夠找到它們。

Windows核心崩潰轉儲的基本分析

使用 WinDbg 或 KD 載入核心崩潰轉儲檔案後，分析核心崩潰轉儲檔案的過程與事後偵錯非常相似。幾乎所有人運行的第一個命令都是`!analyze`，它會啟動自動分析並產生初始報告。

命令 !analyze -show 顯示 錯誤檢查程式碼及其參數而 !analyze -v 它能產生更詳細的輸出：可疑模組、呼叫堆疊、上下文訊息，以及在許多情況下，關於可能原因或診斷步驟的建議。

為了補充該分析，.bugcheck命令會再次列印錯誤代碼和相關參數，可以與Microsoft 的錯誤檢查代碼參考進行比較，以找出每個值的確切含義和典型原因。

命令 lm N T （列出模組）可讓您查看 已載入模組列表，包括其路徑、位址和狀態這有助於確認自動分析識別出的驅動程式是否實際存在於記憶體中，以及其版本。當我們懷疑存在與核心互動的第三方驅動程式或安全元件時，此列表尤其有用。

如果需要，我們可以建立一個批次檔來簡化轉儲檔案的載入。該檔案接收轉儲檔案的路徑，並使用對應的參數啟動 KD 或 WinDbg。這樣，我們只需要編寫一個包含文件位置的簡短命令，腳本就會處理其他所有事情。

使用 WinDbg 取得深度核心轉儲。

對於核心模式記憶體轉儲，WinDbg 還支援處理多個檔案和會話。可以透過命令列使用-z 參數開啟轉儲文件，也可以透過圖形介面使用「文件」>「開啟記憶體轉儲」選單或快速鍵Ctrl+D開啟。

如果 WinDbg 已在被動模式下打開，只需在「開啟崩潰轉儲」對話方塊中選擇文件，指定路徑或瀏覽磁碟即可。載入完成後，在某些情況下，您可以使用“g”（運行）命令啟動會話，或直接執行初始分析命令。

除了經典 !analyze建議熟悉以下內容： 調試器命令參考部分本文檔介紹了所有可用於讀取內部結構、檢查記憶體、解釋堆疊等的命令。其中許多技術既適用於即時會話，也適用於離線轉儲。

WinDbg 還允許您使用 多路並行轉儲我們可以在命令列中新增多個 -z 參數，每個參數後面跟著不同的檔名，或使用命令新增目標。 .opendump調試多個目標有助於比較重複出現的故障或連鎖事件。

在某些環境下，記憶體轉儲會被打包成 CAB 文件，以節省空間或方便傳輸。 WinDbg 可以直接開啟 CAB 檔案。 .cab 內部包含轉儲文件，既可以使用 -z 選項，也可以使用其他方式。 .opendump雖然他會讀 它只會提取轉儲文件中的一個，而不會提取其他文件。 它們可以放在同一個包裹裡。

Unix 和 Linux 中的崩潰轉儲：實用程式、工具和要求

在Unix和GNU/Linux系統中，理念相似，但工俱生態系卻大相逕庭。大多數類別Unix核心都提供了在發生災難性事件時保存記憶體副本的功能，這種副本稱為核心轉儲或核心崩潰轉儲。

儘管這些轉儲檔案的主要用途仍然是核心和驅動程式開發，但它們也具有明顯的安全性意義。崩潰可能是由程式錯誤引起的，但也可能是由惡意操作失敗、試圖操縱系統元件或拙劣地利用競爭條件造成的。

在配置良好的 Unix 系統中，日常崩潰並不常見，但一旦發生，建議部署轉儲基礎設施，例如 Kdump、LKCD 或其他可以捕獲系統記憶體的解決方案。然而，必須權衡轉儲的診斷價值和其中包含高度敏感資料的風險。

在 Linux 系統中，用於此類分析的最全面、最廣泛使用的工具之一是crash，它最初由 Red Hat 開發。該實用程式實際上已成為檢查核心轉儲以及分析運行系統的實際標準。

崩潰可能會對系統的即時記憶體造成損害。 /dev/mem 或者，在 Red Hat 及其衍生發行版中，使用特定設備 /dev/crash即便如此，通常的做法是向該工具提供由諸如此類機制產生的轉儲檔案。 轉儲, 產生轉儲文件, 磁碟轉儲 或像架構特定的轉儲檔案那樣 s390/s390x 或 xendump 在虛擬化環境中。

崩潰的作用以及VMlinux在Linux中的重要性

創建崩潰實用程式的部分原因是為了克服使用方面的限制。 直接在 gdb 上運行 /proc/kcore除此之外，對該記憶體偽映像的存取可能受到限制，此外，某些核心編譯選項使得如果我們只有壓縮的可執行二進位文件，就很難正確解釋內部結構。

要讓 crash 工具正常運作，需要兩個關鍵要素：一個包含偵錯符號（通常使用類似 -g 的標誌）的已編譯 vmlinux 文件，以及核心轉儲檔案本身。這兩個要素結合起來，使得該工具能夠將記憶體位址對應到函數、結構體和程式碼行。

區分很重要 vmlinux 和 vmlinuz在大多數系統中，只有 vmlinux 可見，它是核心的壓縮可引導版本。崩潰需要符號解壓縮後的 vmlinux；如果沒有它，嘗試載入轉儲檔案時就會出錯。 /dev/mem 我們將遇到以下類型的錯誤 找不到已啟動的核心－請輸入名稱清單參數.

雖然可以手動提取 vmlinuz，但這個過程並非總是簡單直接。實際上，重新編譯核心以同時獲得 vmlinux 和 vmlinuz 通常更為便捷。在管理環境較為複雜的場景下，為每個已部署的核心版本維護一個單獨的 vmlinuz 軟體包是最佳實踐，尤其適用於這種情況。

一旦滿足要求，對轉儲文件運行 crash 工具就相對簡單：只需指定相應的 vmlinux 和轉儲文件，該工具就會打開一個交互式會話，您可以在其中探索內核結構、列出進程、查看調用堆棧並提取取證信息。如果想要深入了解，可以查閱專門的文檔，例如著名的 crash 技術白皮書。

/dev/mem 的限制及 Linux 中的初步方法

在使用特定工具之前，許多管理員歷來都嘗試過獲取記憶體轉儲。 直接從設備讀取數據 /dev/mem這種方法看似簡單：使用類似這樣的工具。 記憶體轉儲 （這會將該設備的輸出輸出到標準輸出）或從中拉取 dd if=/dev/mem of=volcado.mem.

然而，現代核心提供了諸如以下編譯選項： CONFIG_STRICT_DEVMEM這將嚴重限制從用戶空間訪問 /dev/mem通常情況下，讀取操作會在讀取到一小塊資料（例如 1 MB）後被截斷；或者，在最壞的情況下，該交互過程中的錯誤可能導致… 內核恐慌 立即重啟機器。

從安全角度來看，這種保護措施完全合理，但這迫使我們尋找其他方法來獲取可靠且完整的轉儲，而不能完全依賴那些不再像以前那樣容易獲得的通用設備。

因此，目前的趨勢是依賴特定的模組或整合的崩潰轉儲基礎設施，而不是簡單地嘗試使用用戶空間工具“抓取記憶體”，因為這些工具並非設計用於與現代核心保護策略共存。

LiME取證：Linux和Android中的記憶體擷取

在取證領域， LiME（Linux Memory Extractor，Linux記憶體擷取器）是一個非常強大的替代方案。它是一個內核模組，專門用於以可控的方式捕獲易失性內存，並且不受/dev/mem的限制。 LiME運行在核心空間，因此可以更直接地存取RAM。

LiME 隨其原始程式碼一起分發，並針對以下目標進行編譯： 正在使用的內核頭文件編譯過程會產生一個模組 .ko 這取決於它將被載入到的核心版本。編譯完成後，我們可以使用諸如以下工具進行驗證。 file 確保已正確產生與我們的架構對應的 ELF 模組。

要使用 LiME，只需加載該模組即可。 insmod 從根目錄並傳遞適當的選項，例如透過指定一個 使用 TCP 和原始格式的網路轉儲目標:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

同時，在接收轉儲檔案的機器上，我們使用類似這樣的工具監聽已設定的連接埠。 nc將輸出重定向到檔案：

nc <IP_origen> 4444 > volcado.mem

幾分鐘後，具體時間取決於記憶體容量和網路效能，我們將得到一個大小與來源系統實體記憶體相符的檔案。這是一個完整的記憶體轉儲文件，我們可以使用取證工具，甚至可以使用 strings 或其他實用程式對其進行分析，作為查找有用字串的第一步。

進程轉儲和資料外洩風險

完整的核心轉儲資訊非常豐富，但如果我們只對特定進程感興趣，它就顯得過於冗餘了。在這種情況下，採用……就顯得非常合理了。 單一進程轉儲 使用諸如 gcore 在 Unix/Linux 系統中。

這些按進程轉儲的檔案要小得多，也更容易管理，並且允許您將分析重點放在特定應用程式上，例如訊息用戶端（例如 Skype）或電子郵件用戶端（例如 Thunderbird），透過探索記憶體字串，可以相對容易地找到明文密碼、會話令牌或聯絡人資料。

從開發角度來看，這些核心轉儲檔案有助於定位程式錯誤、記憶體洩漏或服務中的不一致狀態。然而，從安全角度來看，當這些轉儲檔案被定期產生並儲存在其他使用者可以存取的位置（無論是在系統本身還是在共享網路資源上）時，問題就出現了。

例如，如果使用者安排了一項任務 cron 攻擊者透過定期捕捉敏感進程的轉儲檔案並將其保存在全域可讀目錄中，為洩漏關鍵資訊打開了一扇巨大的大門。在許多審計場景中，分析這些文件可以讓攻擊者恢復資訊。 憑證、聯絡人清單、通訊記錄和其他私人數據 以相對較低的努力。

因此，在對 Unix 系統進行任何嚴肅的審計時，建議花幾分鐘時間檢查是否產生了轉儲（完整或部分），它們存儲在哪裡，它們具有什麼權限，以及是否有任何自動化進程將內存副本留在未經授權的用戶可訪問的範圍內。

使用 kgdb 對 FreeBSD 中的轉儲檔案進行事後分析

在 BSD 世界中，尤其是在 FreeBSD 中，事後分析的方法包括 啟用系統崩潰轉儲功能，並使用偵錯符號編譯核心。這是透過核心配置目錄控制的，通常位於 /usr/src/sys/<arq>/conf.

在對應的設定檔中，可以透過類似這樣的行啟用符號產生：

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

修改配置後，必須重新編譯核心。某些物件將會被重新產生（例如： trap.o由於建置檔案的更改，目標是獲得一個核心。 與出現問題的程式碼相同，但添加了必要的偵錯訊息建議使用以下指令比較新舊尺寸。 size 確保二進位檔案中沒有發生任何意外變更。

安裝完包含符號表的核心後，我們可以按照官方文件中的說明，使用kgdb檢查轉儲文件。並非所有符號表都完整，某些函數可能缺少行號或參數訊息，但在大多數情況下，這些資訊足以幫助我們追蹤問題。

雖然不能絕對保證分析能夠解決所有事件，但在實踐中，這種策略在很大一部分情況下都相當有效，尤其是在將崩潰轉儲與對系統最近更改的良好審查相結合時。

分析和記錄內核錯誤的最佳實踐

無論作業系統是什麼，核心轉儲分析通常最終都需要參考技術文件、知識庫、專業論壇，甚至核心原始碼本身來解釋訊息、錯誤代碼和不熟悉的符號。

在 Linux 系統中，依賴官方原始碼樹、內建文件和社群資源非常有幫助。許多核心錯誤訊息都可以追溯到它們所在的具體文件，這有助於理解特定 BUG() 或 WARN() 錯誤觸發的上下文。

在 Windows 系統中，微軟的文件、知識庫 (KB) 和技術論壇提供了錯誤檢查程式碼的詳細解釋、故障排除建議和已知錯誤模式。將這些資訊與 `!analyze -v` 命令產生的報告結合，可以製定合理的緩解方案。

只有將所有崩潰轉儲資訊與對作業系統和故障發生的具體環境的透徹理解進行交叉比對，才能真正體現其價值。唯有如此，才能製定出持久有效的解決方案，更重要的是，才能防止同樣的問題在未來再次發生，避免造成更嚴重的後果。

核心轉儲分析歸根結底是一門科學與技巧的結合：它需要合適的工具、預先配置（符號表、轉儲選項、安全儲存）以及豐富的堆疊、結構和錯誤程式碼解讀經驗。掌握這些技術不僅能幫助我們調試複雜的故障，還能顯著提升我們所管理系統的安全性和彈性。