介紹

     Cache技術廣泛應用於計算機行業的軟硬體領域。該技術既是人們對新技術探討的結果，也是對當前軟硬體計算能力的一種妥協。在瀏覽器中使用cache技術，可以大幅度提高web頁面的響應速度，降低資料傳輸延遲，提高web使用者的體驗。因此，客戶端在瀏覽網頁的過程中，會在本地快取許多檔案。隨著使用時間增長，本地快取的檔案日漸增多。對於使用者來說，檢視本地主機當前的快取檔案數目和種類成為一種迫切的需要。

    作為主專案的一部分功能，我們需要完成這樣一個瀏覽器快取檢視器。在網上偶然看到了一款這樣的軟體：IECacheViewer。這款軟體功能恰到好處，正是我們所需要的。奈何該網站上並未公佈其實現方式，因此只好以該軟體介面作為模板，自動動手一一實現其功能。尋尋覓覓良久之後，終於發現了兩種實現方式：（1）呼叫windows系統提供的API。這些API使用簡單，只需要迴圈呼叫即可獲取Cache資訊。但缺點是，該方法只能掃描當前系統中存在的cache檔案資訊。（2）解析index.dat檔案。index.dat檔案採用增量記錄方法，所有在系統中曾經存在過的cache檔案，在index.dat檔案中都有記錄。關於index.dat檔案是什麼，在參考資料中可以得到詳盡的答案。我們將在方法二中詳細剖析index.dat的結構。

方法一、呼叫系統API 

1. 相關的API:

 1 HANDLE FindFirstUrlCacheEntry(
 2   __in          LPCTSTR lpszUrlSearchPattern,
 3   __out         LPINTERNET_CACHE_ENTRY_INFO lpFirstCacheEntryInfo,
 4   __in_out      LPDWORD lpcbCacheEntryInfo
 5 ); 
 6 
 7 BOOLAPI FindNextUrlCacheEntry(
 8   __in          HANDLE hEnumHandle,
 
 9   __out         LPINTERNET_CACHE_ENTRY_INFO lpNextCacheEntryInfo,
10   __in_out      LPDWORD lpcbCacheEntryInfo
11 );
12 
13 BOOLAPI FindCloseUrlCache(
14   __in          HANDLE hEnumHandle
15 );
16 
17 typedef struct _INTERNET_CACHE_ENTRY_INFO  { 
18  DWORD dwStructSize; 
19  LPTSTR lpszSourceUrlName; 
 
20  LPTSTR lpszLocalFileName;  
21  DWORD CacheEntryType; 
22  DWORD dwUseCount;  
23  DWORD dwHitRate;  
24  DWORD dwSizeLow;  
25  DWORD dwSizeHigh;  
26  FILETIME LastModifiedTime;  
27  FILETIME ExpireTime;  
28  FILETIME LastAccessTime;  
29  FILETIME LastSyncTime;  
30  LPBYTE lpHeaderInfo;  
31  DWORD dwHeaderInfoSize; 
32  LPTSTR lpszFileExtension;  
33  union {    DWORD dwReserved;    DWORD dwExemptDelta;  };
34 } INTERNET_CACHE_ENTRY_INFO, *LPINTERNET_CACHE_ENTRY_INFO;

    FindFirstUrlCacheEntry()函式開始列舉Cache資訊。其返回一個控制代碼，該控制代碼用於所有後續的FindNextUrlCacheEntry()呼叫。FindCloseUrlCache()函式使用者關閉控制代碼，結束列舉過程。利用上述的三個函式，迴圈呼叫並將Cache資訊儲存在INTERNET_CACHE_ENTRY_INFO結構體中。INTERNET_CACHE_ENTRY_INFO結構體包含了當前Cache檔案的詳細資訊，如檔案大小、命中次數、訪問時間、修改時間、同步時間等。這樣，就可以完成IE Cache資訊的提取了。

方法二、 解析index.dat檔案

1. 檔案結構

    如果解析PE檔案一樣，在解析index.dat檔案之前，我們需要知道index.dat檔案的組織結構。網上並沒有找到index.dat檔案的結構說明，只能依著搜到的幾個結構體定義來檢視index.dat的結構了。大致示意圖如下：

    一個index.dat檔案以small header開始，該small header佔0x250個位元組，其結構定義如下：

    其中最重要的欄位是dwHashTableOffset，該欄位是DWORD型，在32位機器上佔4個位元組。dwHashTableOffset儲存了index.dat檔案中的第一個hash section的地址。nDirCount和DirArray欄位分別表示子目錄個數和子目錄名稱陣列。通常對於Cache來說，所有的快取檔案都放在一個目錄中，這兩個欄位作用不大。而對於Cookie來說，Cookies檔案可能分佈於多個子目錄中。跟在Small header後面的是full header。其具體作用不詳，定義如下：

    再來看Hash Section部分。每個hash section都有一個頭部，佔16個位元組。其定義如下：

hash頭部的dwSig欄位佔4位元組，是由“HASH”這個四個字母的ASCII碼填充的。nBlocks欄位表明本雜湊節佔用多少個塊，塊單位為0x80位元組。dwNext欄位指出下一個hash 頭部的開始地址，以index.dat檔案的起始地址為基準。nOrder則是當前雜湊節的編號。緊隨頭部的便是hash itmes了。一個hash item佔8位元組，前4位元組是雜湊值，後4位元組是Cache記錄在index.dat檔案中的偏移，也是以index.dat檔案的起始地址為基準。

2. 分析例項

    下面以我的機器上的index.dat檔案為例進行例項分析：

    根據第一個雜湊表的偏移地址(0x4000)，跳到0x4000處，如下：

    可以看到，hash頭部第一個欄位為：48, 41, 53, 48.為"HASH"四個字母。緊接著的四個位元組值為0x20，單位為塊，每塊大小為128位元組。值得注意的是，由於我使用的是小端機（little endian：大端高位在前，小端低位在前），因此需要轉換一下。第三個四位元組值為0x11000，是下一個hash section的頭部地址。第四個四位元組值為0，表明當前hash section的編號為0。我們再接著看0x4010位置的值。根據上述的結構定義可知，第一個四位元組是雜湊值，不用管它。接下來的0x1BA00才是最重要，它指明瞭hash條目在檔案中的偏移位置。注意相對的偏移基準。我們再跳到0x1BA00位置：

    這是一個URL型別。在index.dat檔案中，hash條目有多種型別，在參考資料中有說明，這裡不再贅述。不過，我們應當重點看看hash條目的定義結構：

    按著欄位大小一一提取即可。到這裡，完成了一次cache資訊的提取。我們接著要做的，是檢視下一個hash section。因此，再跳到0x11000處：

    當前編號為1，下一個hash section 在0x23000處。再跳到0x23000看看:

    果然，此時下一個hash section 的地址為0，表明這是最後一個section了。當前編號為2.由此可知，這個index.dat檔案中只有3個section。所有的hash條目都可以依此提取出來。值得注意的是hash section中存在著空洞。如遇到兩個欄位都為3或者1，表明這是一個空洞。如下圖所示，繼續檢視，仍然有hash條目存在。當遇到兩個位元組都是0xDEADBEEF，說明後面不再有hash條目了。

預覽效果

參考資料

程式碼

    View it on github.