360注冊(cè)表操作原理分析 （前段閑的蛋疼才分析的，錯(cuò)誤的，大牛們請(qǐng)指出）
360為了有效的對(duì)注冊(cè)表進(jìn)行操作，繞過(guò)了RegXXXX函數(shù)的使用，自己封裝了一套API：BAPI.DLL 以及BAPIDRY.SYS來(lái)實(shí)現(xiàn)可靠的，有效的注冊(cè)表和文件操作;
調(diào)用流程如下：
（以BRegDeleteKey為例）
對(duì)BRegDeleteKey的封裝在Ring 3模仿了微軟的做法，BRegDeleteKey-->BRegDeleteKeyW之類的，
對(duì)于BRegDeleteKeyW則不再調(diào)用NtDeleteKey，而是利用了ZwDeviceIoControl向BAPIDRY.SYS發(fā)控制碼，自己驅(qū)動(dòng)去做NtDeleteKey做的操作；
關(guān)鍵在于360 Reg操作所用的方式：通過(guò)CmRegXXXX實(shí)現(xiàn)，360是如何可靠的獲取CmRegXXXX的地址的呢？如下：
1、通過(guò)打開(kāi)注冊(cè)表的鍵值，獲取注冊(cè)表類型的objectType
2、打開(kāi)兩個(gè)注冊(cè)表項(xiàng)，獲取對(duì)象以待后面用
3、對(duì)其中一個(gè)注冊(cè)表對(duì)象
nt!_CM_KEY_BODY
+0x000 Type : Uint4B
+0x004 KeyControlBlock : Ptr32 _CM_KEY_CONTROL_BLOCK
+0x008 NotifyBlock : Ptr32 _CM_NOTIFY_BLOCK
+0x00c ProcessID : Ptr32 Void
+0x010 Callers : Uint4B
+0x014 CallerAddress : [10] Ptr32 Void
+0x03c KeyBodyList : _LIST_ENTRY
.
里面的CM_KEY_CONTROL_BLOCK.
nt!_CM_KEY_CONTROL_BLOCK
+0x000 RefCount : Uint4B
+0x004 ExtFlags : Pos 0, 8 Bits
+0x004 PrivateAlloc : Pos 8, 1 Bit
+0x004 Delete : Pos 9, 1 Bit
+0x004 DelayedCloseIndex : Pos 10, 12 Bits
+0x004 TotalLevels : Pos 22, 10 Bits
+0x008 KeyHash : _CM_KEY_HASH
+0x008 ConvKey : Uint4B
+0x00c NextHash : Ptr32 _CM_KEY_HASH
+0x010 KeyHive : Ptr32 _HHIVE
+0x014 KeyCell : Uint4B
+0x018 ParentKcb : Ptr32 _CM_KEY_CONTROL_BLOCK
+0x01c NameBlock : Ptr32 _CM_NAME_CONTROL_BLOCK
+0x020 CachedSecurity : Ptr32 _CM_KEY_SECURITY_CACHE
+0x024 ValueCache : _CACHED_CHILD_LIST
+0x02c IndexHint : Ptr32 _CM_INDEX_HINT_BLOCK
+0x02c HashKey : Uint4B
+0x02c SubKeyCount : Uint4B
+0x030 KeyBodyListHead : _LIST_ENTRY
+0x030 FreeListEntry : _LIST_ENTRY
+0x038 KcbLastWriteTime : _LARGE_INTEGER
+0x040 KcbMaxNameLen : Uint2B
+0x042 KcbMaxValueNameLen : Uint2B
+0x044 KcbMaxValueDataLen : Uint4B
+0x048 KcbUserFlags : Pos 0, 4 Bits
+0x048 KcbVirtControlFlags : Pos 4, 4 Bits
+0x048 KcbDebug : Pos 8, 8 Bits
+0x048 Flags : Pos 16, 16 Bits
里面的HHIVE
nt!_HHIVE
+0x000 Signature : Uint4B
+0x004 GetCellRoutine : Ptr32 _CELL_DATA*
+0x008 ReleaseCellRoutine : Ptr32 void
+0x00c Allocate : Ptr32 void*
+0x010 Free : Ptr32 void
+0x014 FileSetSize : Ptr32 unsigned char
+0x018 FileWrite : Ptr32 unsigned char
+0x01c FileRead : Ptr32 unsigned char
+0x020 FileFlush : Ptr32 unsigned char
+0x024 BaseBlock : Ptr32 _HBASE_BLOCK
+0x028 DirtyVector : _RTL_BITMAP
+0x030 DirtyCount : Uint4B
+0x034 DirtyAlloc : Uint4B
+0x038 RealWrites : UChar
+0x03c Cluster : Uint4B
+0x040 Flat : UChar
+0x041 ReadOnly : UChar
+0x042 Log : UChar
+0x044 HiveFlags : Uint4B
+0x048 LogSize : Uint4B
+0x04c RefreshCount : Uint4B
+0x050 StorageTypeCount : Uint4B
+0x054 Version : Uint4B
+0x058 Storage : [2] _DUAL
里面的函數(shù)HvpGetCellMapped進(jìn)行hook,在而后分別對(duì)哪兩個(gè)打開(kāi)的注冊(cè)表項(xiàng)進(jìn)行若干的注冊(cè)表操作（調(diào)用前面獲取的NtRegxxx來(lái)完成），那么360為什么要hook那個(gè)函數(shù)膩，原因是，NtRegxxxx的若干操作會(huì)調(diào)用相應(yīng)的CmRegxxxx來(lái)完成，而CmRegxxx又會(huì)調(diào)用HvpGetCellMapped這個(gè)函數(shù)，F(xiàn)ake_HvpGetCellMapped的作用很簡(jiǎn)單：
假設(shè)對(duì)那個(gè)自己的測(cè)試鍵值調(diào)用了NtSetValueKey,在找個(gè)函數(shù)里可以找到如下代碼：
if (NT_SUCCESS(status))
{
status = CmSetValueKey(........)
}
這里就是和諧的CmSetValueKey,當(dāng)這個(gè)東西運(yùn)行，在這個(gè)函數(shù)里可以找到調(diào)用了HvpGetCellMapped這個(gè)函數(shù)，然而現(xiàn)在卻調(diào)用了Fake_HvpGetCellMapped這個(gè)函數(shù)，找個(gè)函數(shù)里面通過(guò)棧回溯機(jī)制，定位到上面那個(gè)圖的代碼對(duì)應(yīng)的
CALL CmpSetValueKey,(棧回溯是通過(guò)找個(gè)函數(shù)的第一個(gè)參數(shù)
作為回溯查找對(duì)象的，前面打開(kāi)自己的注冊(cè)表時(shí)保存了找個(gè)值，這樣就確定了CmRegxxxx的地址。