偶写的文件AntiRookit

测试了几个，好像没问题，有兴趣的兄弟看看能不能过它！

牛，我看名字就在想，这ID怎么这么像风一般的男人啊，看了说明才知道，原来就是，佩服佩服

不知道干撒用的，不过好像比较占内存

引用第1楼poize于2007-10-29 14:58发表的  :
牛，我看名字就在想，这ID怎么这么像风一般的男人啊，看了说明才知道，原来就是，佩服佩服

不知道干撒用的，不过好像比较占内存

晕，检查有没有被Rookit的文件的啊，为了追求速度，可能是挺耗内存的，没怎么优化

...好东西收藏

自己分析硬盘扇区？风般男人果然是数据方面的专家。

RING3的，太好过了。。。。而且不能在XX上用~

不能扫到数据流。。。只支持NTFS。。。每次选一个扫描位置都要点4次确定。。。汗

用的PHYSICALDRIVE0~这样比较容易被XX~  还是用XXXXX比较爽

AK922应该能过，unreal也可以~~ 不用出手了~

XXXXXX

支持

支持风般

没什么特点

非NTFS、流遍历、N种猥琐的读盘方法， 这些代码都有写过，这个demo也是一时兴起，放出来和大家讨论一些想法而已，我孤陋寡闻，不知道还有谁这么做过。如果真要完善，肯定不会在这放出来的。

没过俺的beta2版, 只试了这个, 以前放的没试~

引用第14楼z.b.Azy于2007-10-30 21:57发表的  :
没过俺的beta2版, 只试了这个, 以前放的没试~

嗯，如果用了流、做了磁盘的HOOK，是过不了！
必须加上流扫描，和发irp的自己读盘，不过仔细想想要过我的还是能过，呵呵，irp也可以hook嘛，所以某君说得好，还是windows pe牛

还是XX FS结构隐藏比较好~让自己解析的统统崩溃去

引用第14楼z.b.Azy于2007-10-30 21:57发表的  :
没过俺的beta2版, 只试了这个, 以前放的没试~

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null.  This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this.  The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: 80e82838, The address of the queue entry whose flink/blink field is NULL
Arg2: 8055b1fc, The address of the queue being references. Usually this is one
    of the ExWorkerQueues.
Arg3: 8055b1c0, The base address of the ExWorkerQueue array. This will help determine
    if the queue in question is an ExWorkerQueue and if so, the offset from
    this parameter will isolate the queue.
Arg4: fc9c16fc, If this is an ExWorkerQueue (which it usually is), this is the address
    of the worker routine that would have been called if the work item was
    valid. This can be used to isolate the driver that is misusing the work
    queue.

Debugging Details:
------------------






WORKER_ROUTINE:
AK922+6fc
fc9c16fc 6a08            push    8

FAULTING_IP:
AK922+6fc
fc9c16fc 6a08            push    8

WORK_ITEM:  80e82838

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x96

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 804f880d to 80527da8

STACK_TEXT:  
fc8fa8e0 804f880d 00000003 fc8fac3c 00000000 nt!RtlpBreakWithStatusInstruction
fc8fa92c 804f93fa 00000003 80ea0438 80ea03c8 nt!KiBugCheckDebugBreak+0x19
fc8fad0c 804f9925 00000096 80e82838 8055b1fc nt!KeBugCheck2+0x574
fc8fad2c 804fbfeb 00000096 80e82838 8055b1fc nt!KeBugCheckEx+0x1b
fc8fad6c 80534da6 00000001 3b000001 00000000 nt!KeRemoveQueue+0x2e7
fc8fadac 805c5a28 80e82838 00000000 00000000 nt!ExpWorkerThread+0xd6
fc8faddc 80541fa2 80534cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  .bugcheck ; kb

FOLLOWUP_IP:
AK922+6fc
fc9c16fc 6a08            push    8

SYMBOL_NAME:  AK922+6fc

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: AK922

IMAGE_NAME:  AK922.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4726faa9

FAILURE_BUCKET_ID:  0x96_AK922+6fc

BUCKET_ID:  0x96_AK922+6fc

Followup: MachineOwner
---------

蓝蓝的屏幕白字冒，白字说明错误号……

Rookit这是啥？Rook  it ，欺骗它？