Hi.
Feedback is ongoing,
it blue screens very well on Windows 8 RTM 9200. Some of the crashes while navigating through the tabs, some when you try to do something. I can't post dumps, they mostly randomly points into Win64AST.sys but instead I'll attach last BSoD Windbg analyze (happened at callbacks tab).
Overall your tool is incompatible by design with PatchGuard. This make this tool somehow not useful - lets say windbg + scripts can do the same. Turning off PG can solve this, but this is stupid, if we're talking about x64.
Service Tables are protected by PG - unhooking them will lead to BSoD. Remove this feature, it is useless on x64.
Hide/Unhide processes - this list also protected by PG - BSoD will be raised when PG watchdog will attempt to check integrity of this list. Remove this feature, it is useless on x64.
The same about inline (you mean splicing I guess?) hooks. PG will not tolerate unhooking. Remove this feature, it is useless on x64.
Well, short summary.
Remove everything that can trigger PatchGuard, otherwise - no thanks.
Best Regards,
-rin
EP_X0FF wrote:Bug Check 0x109?PatchGuard desu.
Feedback is ongoing,
it blue screens very well on Windows 8 RTM 9200. Some of the crashes while navigating through the tabs, some when you try to do something. I can't post dumps, they mostly randomly points into Win64AST.sys but instead I'll attach last BSoD Windbg analyze (happened at callbacks tab).
Code: Select all
Some constructive criticism regarding your tool features.*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff8800f6beae0, Address of the instruction which caused the bugcheck
Arg3: fffff8800d6d0db0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
FAULTING_MODULE: fffff8037fa1c000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 509dd98d
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - <Unable to get error code text>
FAULTING_IP:
Win64AST+4ae0
fffff880`0f6beae0 488b5d00 mov rbx,qword ptr [rbp]
CONTEXT: fffff8800d6d0db0 -- (.cxr 0xfffff8800d6d0db0)
rax=0000000000222494 rbx=fffffa80031a2040 rcx=0000000000000000
rdx=0000000000000000 rsi=fffff8800f7507a0 rdi=00000000c0000010
rip=fffff8800f6beae0 rsp=fffff8800d6d17b0 rbp=0000000000000000
r8=fffffa800112ab00 r9=000000000000000e r10=0000000000000801
r11=0000000000000000 r12=0000000000000404 r13=0000000000000000
r14=fffffa80035898a0 r15=fffffa80035898a0
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
Win64AST+0x4ae0:
fffff880`0f6beae0 488b5d00 mov rbx,qword ptr [rbp] ss:0018:00000000`00000000=????????????????
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x3B
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000318e00000010 to fffff8800f6beae0
STACK_TEXT:
fffff880`0d6d17b0 0000318e`00000010 : 00000000`00000000 00000000`00000001 00000000`00000040 00000000`c0000010 : Win64AST+0x4ae0
fffff880`0d6d17b8 00000000`00000000 : 00000000`00000001 00000000`00000040 00000000`c0000010 fffff880`0f6bfff2 : 0x318e`00000010
FOLLOWUP_IP:
Win64AST+4ae0
fffff880`0f6beae0 488b5d00 mov rbx,qword ptr [rbp]
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: Win64AST+4ae0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Win64AST
IMAGE_NAME: Win64AST.sys
STACK_COMMAND: .cxr 0xfffff8800d6d0db0 ; kb
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
---------Overall your tool is incompatible by design with PatchGuard. This make this tool somehow not useful - lets say windbg + scripts can do the same. Turning off PG can solve this, but this is stupid, if we're talking about x64.
Service Tables are protected by PG - unhooking them will lead to BSoD. Remove this feature, it is useless on x64.
Hide/Unhide processes - this list also protected by PG - BSoD will be raised when PG watchdog will attempt to check integrity of this list. Remove this feature, it is useless on x64.
Code: Select all
As test I tried hide one process and in result 4(four) have been highlighted in red. Strange behavior isn't it?CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d892c816f2, Reserved
Arg2: b3b7465ee547af63, Reserved
Arg3: fffffa8002c92940, Failure type dependent information
Arg4: 0000000000000004, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
The same about inline (you mean splicing I guess?) hooks. PG will not tolerate unhooking. Remove this feature, it is useless on x64.
Well, short summary.
Remove everything that can trigger PatchGuard, otherwise - no thanks.
Best Regards,
-rin
