基于Cache的隱藏文件（與注冊表）檢測的一些思路

作者: sudami

為了考研， 庸庸碌碌的過了半年。 現(xiàn)在終于出頭了， 現(xiàn)在又忙于畢業(yè)設(shè)計（軟件界面美化和驅(qū)動文件加殼）， 沒空學(xué)習(xí)內(nèi)核知識 。 今天特把以前的一些想法發(fā)出來， 大家討論討論。

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

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

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

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

復(fù)制內(nèi)容到剪貼板

代碼:

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;

}

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

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

該方法的優(yōu)點：

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

該方法的缺點：

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

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

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