由于种种原因，这样做很不安全，如果读者曾经进行过内核编程你就会深刻体会为什么这样不安全。
内核进程结构定义（EPROCESS）随着OS更换甚至是Servicepack的更换而频繁地改变。这样造成的结果就是，直接访问这样的结构通常都很不安全。
由于KAV不适当地执行类型核实操作，因此很有可能将一个对象句柄传递给不同的内核对象——比如，mutex——于是因为mutex的内部结构（或者任何其它的内核对象）与进程对象的内部结构不兼容，KAV将导致系统崩溃。
对于上一个问题，KAV想用如下方法应对：它试图实时地找出包含进程名称的 EPROCESS结构成员的偏移地址。它所使用的算法是，每次从进程对象指针的开始提前扫描一字节，直到它发现用来识别初始系统进程名字的那个字节串。（这个例行程序在初始系统进程环境中被调用）。与杀毒软件、还有其他利用与进程关联的像文件名称的那些低端产品比起来，这种例行程序似乎很普通。
.text:F82209E0 KavFindEprocessNameOffset proc near ; CODE XREF: sub_F8217A60+FCp
.text:F82209E0 push ebx
.text:F82209E1 push esi
.text:F82209E2 push edi
.text:F82209E3 call ds:IoGetCurrentProcess
.text:F82209E9 mov edi, ds:strncmp
.text:F82209EF mov ebx, eax
.text:F82209F1 xor esi, esi
.text:F82209F3
.text:F82209F3 loc_F82209F3: ; CODE XREF: KavFindEprocessNameOffset+2Ej
.text:F82209F3 lea eax, [esi+ebx]
.text:F82209F6 push 6 ; size_t
.text:F82209F8 push eax ; char *
.text:F82209F9 push offset aSystem ; "System"
.text:F82209FE call edi ; strncmp
.text:F8220A00 add esp, 0Ch
.text:F8220A03 test eax, eax
.text:F8220A05 jz short loc_F8220A16
.text:F8220A07 inc esi
.text:F8220A08 cmp esi, 3000h
.text:F8220A0E jl short loc_F82209F3
.text:F8220A10 pop edi
.text:F8220A11 pop esi
.text:F8220A12 xor eax, eax
.text:F8220A14 pop ebx
.text:F8220A15 retn
.text:F8220A16 ; ---------------------------------------------------------------------------
.text:F8220A16
.text:F8220A16 loc_F8220A16: ; CODE XREF: KavFindEprocessNameOffset+25j
.text:F8220A16 mov eax, esi
.text:F8220A18 pop edi
.text:F8220A19 pop esi
.text:F8220A1A pop ebx
.text:F8220A1B retn
.text:F8220A1B KavFindEprocessNameOffset endp
.text:F8217B5C call KavFindEprocessNameOffset
.text:F8217B61 mov g_EprocessNameOffset, eax |
文章评论
共有 位CH网友发表了评论 查看完整内容