作者: sudami

為了考研， 庸庸碌碌的過了半年。 現在終于出頭了， 現在又忙于畢業設計（軟件界面美化和驅動文件加殼）， 沒空學習內核知識 。 今天特把以前的一些想法發出來， 大家討論討論。

在網上找了一下， 談文件隱藏的不少， 說如何檢測隱藏文件的好像不多。 這里說說我關于隱藏文件（和注冊表）檢測的一些思路， 錯誤和不足希望大牛們指出。

我們知道現在一般隱藏文件的檢測方法有幾種， 一種是文件系統層即直接發irp到文件系統進行詢問， 一種是直接對磁盤的數據進行分析。 當然后者應該說是比前者更安全。 但相信你看過mj0011大牛的《基于IO Packet隱藏文件和注冊表， 過磁盤解析和總線解析》(當然你用他公布的代碼可能不一定成功， 因為其中有些小bug)， 其實這也不是安全的， 怎么辦？前有azy大牛的ak922， 后有mj0011大牛的總線過濾。 那我們只好夾縫中求生存了， 呵呵。

入正題， 我們知道就windows ntfs系統而言， 第一方法自己構建的irp包其實走的線路是NtfsFsdDirectoryControl NtfsCommonDirectoryControl NtfsQueryDirectory在后面就是走NtfsRestartIndexEnumeration和NtfsContinueIndexEnumeration等等到ReadIndexBuffer到NtfsMapStream到CcMapData， 通過CcMapData得到相應FileObject的Cache地址， 然后進行解析。 其中Cache的具體地址為在CcMapData最后一個參數里。

這是我用syser分析中的兩分截圖， 分析過NTFS文件系統的話當你看到FILE0和INDX字樣的時候一定很是熟悉， 文件的解析就從這里開始了。 其實在這做分析， 比直接讀磁盤數據分析要簡單點， 代碼如下：

復制內容到剪貼板

代碼:

VOID ListDir (LPBYTE pDir, UINT uAlcSize)

{

LPINDX pIndx;

LPINDXATTR pIndxAttr;

DWORD dwRes;

BYTE pRuns[0x200];

pIndx = ( LPINDX ) pDir;

pIndxAttr = (LPINDXATTR)( pDir + ( 0x18 + pIndx->wHeadSize ) );

if ( 'I' != pIndx->bDirID [0] 'N' != pIndx->bDirID [1] 'D' != pIndx->bDirID [2] 'X' != pIndx->bDirID [3] )

{

return ;

}

while ( TRUE )

{

if ( ( (ULONG)( pIndxAttr ) - (ULONG)(pIndx) ) >= pIndx->dwUseSize )

{

if ( 0 == uAlcSize - ( pIndx->dwAllocSize + 0x18 ) )

break;

else

{

uAlcSize -= ( pIndx->dwAllocSize + 0x18 );

pIndx = ( LPINDX )( (LPSTR)pIndx + ( pIndx->dwAllocSize+ 0x18 ) );

if ( 'I' != pIndx->bDirID [0]

'N' != pIndx->bDirID [1]

'D' != pIndx->bDirID [2]

'X' != pIndx->bDirID [3] )

{

return;

}

pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndx ) + ( 0x18 + pIndx->wHeadSize ) );

}

}

if ( 12 > pIndxAttr->dwMFTIndx )

{

pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndxAttr ) + pIndxAttr->wcbSize );

}

else

{

if ( FALSE == (0x01 & pIndxAttr->bFileNSpace ) )

{

pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndxAttr ) + pIndxAttr->wcbSize );

continue;

}

KdPrint(("File Name is:%ls\n",pIndxAttr->wzFileName));

pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndxAttr ) + pIndxAttr->wcbSize );

}

}

return;

}

當然這段代碼只是求個驗證， 并不完善。 因為其實直接讀取內存數據， 我測試了能檢測出AK922了， 另外mj0011的總線過濾沒有做Cache的工作， 當然也能檢測到。

下面說說怎么獲得Cache地址， 兩種方法。 一是你自己得到FileObject然后用CcMapData去獲得， 做過文件過濾驅動的話這應該比較簡單。 另一種就是做Hook， 從中獲得。 既然是做檢測文件隱藏， 那么你可以先正常的枚舉， 然后根據獲得的Cache地址讀取數據分析和開始的進行對比。

該方法的優點：

這種方法是直接讀取Cache中的數據， 不走IofCompleteRequest， 得到的數據比直接Irp來的安全。 你可能要說我不能對Cache中的數據進行修改來進行隱藏嗎？其實這在AZY的另一篇文章《掛接緩存管理器CcMapData（）實現文件XXX》中提過。 我是有可以成功， 但系統也就無法定位到該文件進行正常的工作， 還不如直接刪除來隱藏來的好。 當然強大的LZ同學們肯定有你的好方法。

該方法的缺點：

同樣這也要做文件系統的解析， 很麻煩。 我用的是和我在《NTFS文件解析系統的簡單分析》中提到的解析索引列表來讀文件名一樣的方法。 其實這樣并不好， 應該索引列表中的文件名有時是短名， 有時甚至有些字符還不錯誤的。 這也是mj0011《基于IO Packet隱藏文件和注冊表， 過磁盤解析和總線解析》代碼中過濾不嚴導致隱藏失敗的一個小bug。 所以用他來枚舉文件不大準確。 真正準確的應該是在MFT30屬性中獲得的文件名。

當然其實注冊表的獲取同樣也是走CcMapData， 所以他能夠檢測基于ZZZEVAZZZ公布的注冊表隱藏的方法。

文章就寫到這里， 最后謝謝你的觀看。