Daemon Tools causes BSOD when installed over ZoneAlarm Extreme Security

[skyking]

Hello,

I work at Check Point Software Technologies, maker of the personal firewall ZoneAlarm.

There is an incompatibility between ZoneAlarm and Daemon Tools. Installing Daemon Tools after installing ZoneAlarm Extreme will cause the machine to BSOD.

You can get the latest beta version of ZoneAlarm from:

http://www.zonealarm.com/beta

Please make sure to download the ZA Extreme SKU.

The root cause is that you are unhooking kernel hooks, which is very dangerous because you dont know who else might be hooking. Instead you should just put the hooks in passthrough mode.

Here is the analysis of the BSOD:

Seems BSOD caused by driver SPTD that patches \Filesystem\Ntfs driver dispatch and fastio tables:
Analyzis:

At first !drvobj fails to get \Filesystem\Ntfs pointer, that is very strange, and probably caused by someone's attempt to modify kernel driver objects list:
0: kd> !drvobj \Filesystem\Ntfs
Driver object \Filesystem\Ntfs not found


Then lets check if ISWKL installed its hooks:
0: kd> ?? iswkl!g_prot_dev_info.ntfs
struct ProtectedDevice_
+0x000 name : 0x8c5d71b0 -> 0x5c
+0x004 object : 0x847ad9a0 _DRIVER_OBJECT
+0x008 mj_create_original : 0x845da1f8 long +ffffffff845da1f8
+0x00c mj_create_hook : 0x8c5d52e0 long ISWKL!NtfsMjCreate+0

Here I get pointer to \Filesystem\Ntfs - 0x847ad9a0 and to its original IRP_MJ_CREATE handler - 0x845da1f8
Lets look at IRP_MJ_CREATE this handler:

0: kd> u 0x845da1f8
845da1f8 8b542408 mov edx,dword ptr [esp+8]
845da1fc 8d4c2404 lea ecx,[esp+4]
845da200 50 push eax
845da201 8bc4 mov eax,esp
845da203 50 push eax
845da204 6808a05d84 push 845DA008h
845da209 b84c006a80 mov eax,offset sptd+0x1204c (806a004c)
845da20e ffd0 call eax

You can see that this code doesn't belong to Ntfs.sys driver, even more - it doesn't belong to any driver from list. But it perform jump to sptd+0x1204c.
Not lets check \Filesystem\Ntfs driver object structure, by the pointer we got from ISWKL:
0: kd> dt nt!_DRIVER_OBJECT 0x847ad9a0
+0x000 Type : 4
+0x002 Size : 168
+0x004 DeviceObject : 0x845033e0 _DEVICE_OBJECT
+0x008 Flags : 0x92
+0x00c DriverStart : 0x87a00000
+0x010 DriverSize : 0x110000
+0x014 DriverSection : 0x837f7db8
+0x018 DriverExtension : 0x847ada48 _DRIVER_EXTENSION
+0x01c DriverName : _UNICODE_STRING "\FileSystem\Ntfs"
+0x024 HardwareDatabase : 0x81d5ae68 _UNICODE_STRING "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM "
+0x028 FastIoDispatch : 0x87a3f940 _FAST_IO_DISPATCH
+0x02c DriverInit : 0x87af3b75 long Ntfs!GsDriverEntry+0
+0x030 DriverStartIo : (null)
+0x034 DriverUnload : 0x806d4adc void +0
+0x038 MajorFunction : [28] 0x87a9289f long Ntfs!NtfsFsdCreate+0

Lets now check its dispatch table:
0: kd> dds 0x847ad9a0+38 0x847ad9a0+38+(1b*4)
847ad9d8 87a9289f Ntfs!NtfsFsdCreate
847ad9dc 81a6c9d2 nt!IopInvalidDeviceRequest
847ad9e0 87a90379 Ntfs!NtfsFsdClose
847ad9e4 87a0e8fc Ntfs!NtfsFsdRead
847ad9e8 87a14425 Ntfs!NtfsFsdWrite
847ad9ec 87aa13a0 Ntfs!NtfsFsdDispatchWait
847ad9f0 87a0e72e Ntfs!NtfsFsdSetInformation
847ad9f4 87aa13a0 Ntfs!NtfsFsdDispatchWait
847ad9f8 87aa13a0 Ntfs!NtfsFsdDispatchWait
847ad9fc 87a80115 Ntfs!NtfsFsdFlushBuffers
847ada00 87a8175a Ntfs!NtfsFsdDispatch
847ada04 87a8175a Ntfs!NtfsFsdDispatch
847ada08 87a88948 Ntfs!NtfsFsdDirectoryControl
847ada0c 87aa062a Ntfs!NtfsFsdFileSystemControl
847ada10 87a7bcc8 Ntfs!NtfsFsdDeviceControl
847ada14 81a6c9d2 nt!IopInvalidDeviceRequest
847ada18 87a2809f Ntfs!NtfsFsdShutdown
847ada1c 87a20619 Ntfs!NtfsFsdLockControl
847ada20 87a9a314 Ntfs!NtfsFsdCleanup
847ada24 81a6c9d2 nt!IopInvalidDeviceRequest
847ada28 87a8175a Ntfs!NtfsFsdDispatch
847ada2c 87a8175a Ntfs!NtfsFsdDispatch
847ada30 81a6c9d2 nt!IopInvalidDeviceRequest
847ada34 81a6c9d2 nt!IopInvalidDeviceRequest
847ada38 81a6c9d2 nt!IopInvalidDeviceRequest
847ada3c 87aa13a0 Ntfs!NtfsFsdDispatchWait
847ada40 87aa13a0 Ntfs!NtfsFsdDispatchWait
847ada44 87a6c0cd Ntfs!NtfsFsdPnp

Looks like ntfs has clean dispatch table, not hooked by anybody. But we saw that ISWKL has its Ntfs IRP_MJ_CRAETE hook installed, and its original pointer points to some non-ntfs.sys code, that do jump to unknown sptd.sys driver. This means that in past, when ISWKL installed its hook over Ntfs, someone else (probably sptd.sys) already hooked it, but later uninstalled its hook by restoring dispatch table of \Filesystem\Ntfs, and thus discarding iswkl's hook.

Lets check now Ntfs' fastio table:
0: kd> dt nt!_FAST_IO_DISPATCH 0x87a3f940
+0x000 SizeOfFastIoDispatch : 0x70
+0x004 FastIoCheckIfPossible : 0x87a8371b unsigned char Ntfs!NtfsFastIoCheckIfPossible+0
+0x008 FastIoRead : 0x87a7caf7 unsigned char Ntfs!NtfsCopyReadA+0
+0x00c FastIoWrite : 0x87a83fda unsigned char Ntfs!NtfsCopyWriteA+0
+0x010 FastIoQueryBasicInfo : 0x87a8d8c6 unsigned char Ntfs!NtfsFastQueryBasicInfo+0
+0x014 FastIoQueryStandardInfo : 0x87a84ab5 unsigned char Ntfs!NtfsFastQueryStdInfo+0
+0x018 FastIoLock : 0x87a6f2ac unsigned char Ntfs!NtfsFastLock+0
+0x01c FastIoUnlockSingle : 0x87a6f5a1 unsigned char Ntfs!NtfsFastUnlockSingle+0
+0x020 FastIoUnlockAll : 0x87ac979e unsigned char Ntfs!NtfsFastUnlockAll+0
+0x024 FastIoUnlockAllByKey : 0x87ac9943 unsigned char Ntfs!NtfsFastUnlockAllByKey+0
+0x028 FastIoDeviceControl : (null)
+0x02c AcquireFileForNtCreateSection : (null)
+0x030 ReleaseFileForNtCreateSection : 0x87a1012c void Ntfs!NtfsReleaseForCreateSection+0
+0x034 FastIoDetachDevice : (null)
+0x038 FastIoQueryNetworkOpenInfo : 0x87a7c4d9 unsigned char Ntfs!NtfsFastQueryNetworkOpenInfo+0
+0x03c AcquireForModWrite : 0x87a0b245 long Ntfs!NtfsAcquireFileForModWrite+0
+0x040 MdlRead : 0x87ac907d unsigned char Ntfs!NtfsMdlReadA+0
+0x044 MdlReadComplete : 0x81a60b95 unsigned char nt!FsRtlMdlReadCompleteDev+0
+0x048 PrepareMdlWrite : 0x87ac92c4 unsigned char Ntfs!NtfsPrepareMdlWriteA+0
+0x04c MdlWriteComplete : 0x81c03aa1 unsigned char nt!FsRtlMdlWriteCompleteDev+0
+0x050 FastIoReadCompressed : (null)
+0x054 FastIoWriteCompressed : (null)
+0x058 MdlReadCompleteCompressed : (null)
+0x05c MdlWriteCompleteCompressed : (null)
+0x060 FastIoQueryOpen : 0x845da368 unsigned char +ffffffff845da368
+0x064 ReleaseForModWrite : (null)
+0x068 AcquireForCcFlush : 0x87a18b76 long Ntfs!NtfsAcquireFileForCcFlush+0
+0x06c ReleaseForCcFlush : 0x87a18add long Ntfs!NtfsReleaseFileForCcFlush+0

Here we can see that FastIoQueryOpen is not point to Ntfs' code. Lets look into it:


0: kd> u 0x845da368
845da368 b808a05d84 mov eax,845DA008h
845da36d 870424 xchg eax,dword ptr [esp]
845da370 50 push eax
845da371 68e20d6c80 push offset sptd+0x32de2 (806c0de2)
845da376 c3 ret
845da377 0000 add byte ptr [eax],al
845da379 0000 add byte ptr [eax],al
845da37b 0000 add byte ptr [eax],al


This code again goes to sptd, with using of quite hacky push/ret trick.

Lets now check all system stacks and find what sptd does right now:

So finally we have:
\Filesystem\Ntfs driver object dispatch table was hooked in past by sptd.sys driver, and this driver uninstalled its dispatch tabdle hook after iswkl installed its hook over its. Also sptd didn't uninstall Fastio hook. This looks like BSOD occured during sptd uninstalling its hooks. Hooks uninstallation is ALWAYS dangerous, but sptd does it, that most probably caused BSOD.
Little googling shown that sptd.sys is an Daemon tools' driver, which is CD/DVD ROM emulation software, that implies some rootkit technologies to hide itself from several common CD data protection software products.

[Blazkowicz]

Posted over at DuplexSecure forum (creator of SPTD driver), SPTD isn't a DT driver, it is only used:

Daemon Tools causes BSOD when installed over ZoneAlarm Extreme Security - DuplexSecure-Forum

Please check this thread for an answer of DuplexSecure and leave there additional information.

[ß]

This, or a very similar situation, is also probably the same cause for the StarForce BSODs.

[Terramex]

Not up-to-date, but probably still relevant:
Plague in (security) software drivers - www.matousec.com