Page 1 of 5 12345 LastLast
Results 1 to 15 of 64

Thread: Ring 0 anti-debugger code in Daemon Tools?

  1. #1
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5

    Ring 0 anti-debugger code in Daemon Tools?

    I was unpleasantly surprised when I just downloaded the latest Daemon Tools version from the official website.

    First of all, the software now contains (opt-out) spyware. Secondly, and most important in this context, the following message is shown during install:

    This program will install SCSI Pass Through Direct (SPTD) layer on your computer.
    WARNING - SPTD is not compatible with kernel mode debuggers (SoftICE, WinDBG etc.)!
    Please cancel setup if you plan to use kernel debugger on this machine.
    So, this software makes the machine unusable for any kernel debuggers, not so nice, and very intrusive...

    Is there any valid reason for this, or is it just a very intrusive anti-debugger protection inside their driver?

    Has anyone looked into this any further, or know anything more about it in general?

  2. #2
    Heya dELTA,

    Had the same nasty surprise myself, I'm not even a big Daemon Tools fan either (just needed it for burning a particular ISO format).

    My problem was further compounded by the fact I was tracing a rather evil protection system as well, took me a time to realise the culprit was actually Daemon Tools.

    There doesn't seem to me to be any good reason for this detection other than to stop people from delving inside the code. I have the installer still on this box, planning to investigate it at some point.

    Regards

    CrackZ.

  3. #3
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Thanks for the info CrackZ, indeed interesting to hear that it was not an "empty threat" from their side. If you'd like to share some more details about exactly how Daemon Tools interferes with the kernel mode debugging/debuggers on a machine, I'm sure there are more people here than me who would be interested to hear about it.

    If nothing else, more exactly what kind of damage/problems does it cause? Will a simple uninstall of Daemon Tools restore the situation to normal?

  4. #4
    heya,

    I remember this thread - related to the kernel debugger incompatibilities:

    http://www.woodmann.com/forum/showthread.php?t=7894&highlight=SPTD

    regards, 0xf001

  5. #5
    It's always impressive to see old time crackers that think that they can make the uncrackable protection. I'm not sure if it's the ego or simply that they are naive, the end result is the same - the protection never stays uncracked for too long. In the case of dtools, I think they are trying to avoid copy-protection ppl from spying on their tool to see how it works and then blacklist it. An honest, but futile attempt at preventing it.

    Basically, it is in line with every other piece of software that tries to block debuggers, where as even in cases where you use the debugger for non-RCE purposes, you still get annoyed by that program that's supposed to be idle but crashes your PC as soon as a debugger starts.

    This is an annoyance that you'll have to live with. You could always roll back to the 3.x version (which also use the 'incompatible' scsi pass through btw), which worked perfectly fine with every debugger out there.

  6. #6

    As Above...

    Personally, I always thought Deamon tools to be crap. Just the small footprint is the advantage.

    Alcohol is better. And there are many full versions "out there". Just my 2 cents.

    Have Phun
    Blame Microsoft, get l337 !!

  7. #7
    I've encountered a *lot* of soft that contains anti-debug. However, I always have a debugger ready (SoftICE). What to do? Hide the 'ice, and use it to kill the antidebug from whatever soft has it. No more problem

  8. #8
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Thanks a lot for the reference to that old thread 0xf001! I guess the reason I didn't remember it was because it got so massively off-topic so quick... I've updated the personal search index in my head with it now anyway.

  9. #9
    I'm using d-tools at work for some automated tasks involving ISO images. Some time ago, out of curiosity I've run ntcrash utility from sysinternals - it basically tries all system calls with some random data in order to find insecure drivers. To my surprise, I got a BSOD. After reboot, I went to event log and found that "sptd.sys" driver was responsible for it. Too bad I didn't investigate it further, just thought it's some buggy system stuff.

    Some time passed. One day I rebooted my machine after automatic windows update (or maybe it was after installing some new d-tools version, can't remember). Woops - surprise, BSOD at boot. WTF, I thought? Booted to safe mode - all works fine. After some poking and sniffing, I uninstalled d-tools, and voila - system boots without problems. Right, something was *seriously* wrong here. I uninstalled d-tools for good, but again, didn't investigate the issue further.

    Meanwhile, at my home system, I started to experience weird performance loss issues in some games. Again, after some tries and errors, I got rid of d-tools and the problems disappeared.

    Some more time passed. I've written a tool that lists all kernel system calls and modules responsible for their service. It seemed to work fine, I got a nice list from fresh windows install. Then I run it on some other machine. WTF? Some syscalls were <unknown> (dbghelp couldn't find symbols for them), located in... surprise, sptd.sys! Riiight. Let's compare list from "clean" OS and "hooked" one. Result? All registry calls were hooked.

    And finally, a few days ago I went to d-tools site. Oh, a new version!
    we updated latest DaemonTools (V4.0.3) with latest available SPTD-Driver (V1.25)!

    The new SPTD fixes several critical issues, a problem with McAfee-Virus-Scan and VistaBeta2-Problems!
    The X64-Version also fixes the latest issues between SPTD introduced by Microsoft-patch KB 914784
    Interesting... What's that hotfix?
    Microsoft Security Advisory: Update to improve kernel patch protection
    It seems like it's only for x64 systems - my home system is xp x64. Neat.
    I went to d-tools download section.
    this is the standalone-package of the SPTD-driver. To remove the SPTD-driver, simple download it and via command-console, execute it "sptdinst_x86.exe remove" and SPTD will remove itself from your windows installation. If you want to add it, execute in command console "sptdinst_x86.exe add". SPTD is also used (besides DaemonTools) in some proprietary security, antivirus and monitoring applications which are not disclosed to wide public.
    Sounds nice?
    http://www.sysinternals.com/blog/2006/02/using-rootkits-to-defeat-digital.html
    http://www.duplexsecure.com/faq/
    Q: I see that my software application is using SCSI Pass Through Direct (SPTD) layer. What is it for? Can my software application work without it?

    A: SPTD is a new method of access to storage devices that was developed by Duplex Secure Ltd.

    Basically SPTD is similar to other access layers used by other programs (eg. ASPI from Adaptec, or standard SPTI from Microsoft) who provide access to storage devices but it has a lot more features that make this interface unique.

    The key feature of SPTD is its ability to provide direct control of devices without risk of compromising it by some malicious 3rd party filter drivers or other "rootkit" applications that are common today - this is the main goal of SPTD development for organizations and applications where it currently used.
    Any more questions?
    Vulnerant omnes, ultima necat.

  10. #10
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Nice info omega_red (and everyone else too), thanks!

  11. #11
    By Alcohol sptd.sys was introduced just after version 1.9.5.3105(that is one of the reasons that version was the last for Win98).

    From www.duplexsecure.com/faq
    SPTD (similar to other access layers) is by default not removed from your system after uninstallation of software application which used SPTD, in order not to disrupt other applications that may use it! This also allows user to avoid reboots in most cases for new installations if same SPTD version is already present on his system.
    ...I really doubt,that some other applications on my machine will use this Ring0-driver.
    Sad, but now it is either to have two operating systems(one for Kernel-mode debugger and the other for Alcohol) or merely stop this SPTD-device via Device Manager,which is a bit annoying.

    So I think the question remains open -- is it somehow possible to hide SoftIce from sptd.sys and let both of these devices work together??
    If it possible, than how it would look like -- a patched sptd.sys or a plugin/utility for SoftIce that would hide him??

  12. #12
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    Hi

    Probably the first thing to try is the IceExt PROTECT option to see if it fools the sptd driver. If not, then at least you've eliminated several of the usual Sice detection methods and can dig further from there.

    If I understand correctly, sptd.sys hooks some syscalls? Just for fun it would be interesting to run KprocCheck or Raide or some other rootkit detector to see what is being hooked.

    Kayaker

  13. #13
    I cannot even install DT nor Alcohol now, SPTD just won't install on fully patched XP SP2. Which is only good. :P
    Vulnerant omnes, ultima necat.

  14. #14
    Kayaker
    IceExt is unable to hide the debugger, because SoftIce doesn't even manage to start(manually), if the active sptd.sys is present.
    If I understand correctly, sptd.sys hooks some syscalls?
    ...or maybe it uses some significant debug resources just like StarForce does??For example,SF uses INT1, INT3 and DRx for his own purposes leaving SoftIce no chance to set breakpoints...

    omega_red
    Maybe some conflict with antivirus software??

  15. #15
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    Quote Originally Posted by DillerInc
    IceExt is unable to hide the debugger, because SoftIce doesn't even manage to start(manually), if the active sptd.sys is present.
    Oh I see. Well isn't that a piss-off?

    I've been trying to think of ways to get information on how the sptd driver affects Softice and WinDbg. They *say* SPTD is not "compatible" with kernel debuggers. Again the questions are:

    1. is this just a ruse and it's doing deliberate anti-debugger tricks?
    2. is it 'deliberate' bad programming and the driver is doing things like not chaining to hooked interrupts and such, which all legitimate drivers should do?
    3. is there truly an incompatibility and sptd cannot *honestly* coexist with a kernel debugger?

    The true answer may be a combination of the above.


    I'd be interested in knowing the *order* in which driver events take place in order to figure out where sptd.sys may be acting. I don't have the driver to reverse, so please bear with me..

    Sptd.sys is loaded at boot time and from the sounds of it remains stuck like a bad leech even after the application is uninstalled.

    I read somewhere that sptd.sys can be prevented from loading by booting in safe mode and reacting to the message "Press ESC to cancel loading SPTD.sys". We also know that Softice can be prevented from loading by acting on a similar message at boot time (and not only in safe mode).

    I'd like to know if the portion of Softice which loads at boot time (Osidata.sys and Cpthook.sys) is loaded *before* sptd.sys and loads successfully. The Sice drivers DO load very early, I have a utility which displays the list of loaded drivers in the order they load (a result of querying ZwQuerySystemInformation / SystemModuleInformation), and they load number 9 and 10 out of more than 100 boot-loading drivers. Chances are that sptd.sys is loaded after Sice, but if interested, my utility is here: http://woodmann.net/forum/attachment.php?attachmentid=904&d=1077340907 (QuerySysInfo.zip)


    Let's say that part is OK. If sptd.sys is now active then it's probably pretty easy to prevent Softice from loading manually (the ntice.sys part) with any number of simple detection methods. And similarly with KWinDbg. The only recourse would be to patch sptd.sys.

    What happens if Softice is fully loaded at boot time, does sptd refuse to operate?


    The last idea I had was to see how *far* ntice.sys gets to loading manually before sptd.sys detects and interferes with that. I thought of using PoolTag for that. PoolTag is part of the DDK or Windows Resource Kit or offered at OSR, should be simple to find. It will log all "tags" used with ExAllocatePoolWithTag.

    Softice uses the tag "SIce" and this is recorded by PoolTag when you start ntice.sys manually. If used on a clean system, PoolTag will log for example, 48 non-paged Allocs with 7 Frees, for a net of 41 active memory pools tagged with the string "SIce". This simply indicates that Softice is running normally.

    I was wondering if sptd.sys was active and you tried starting Softice, PoolTag *might* show a different result that might be useful. If for example, NO Allocs were recorded then it would indicate sptd.sys doesn't even allow ntice.sys to load it's INIT section (where ExAllocatePoolWithTag is called several times). This might suggest sptd is monitoring driver loading somehow and preventing ntice from running. If however PoolTag records most of the normal Allocs by ntice.sys, then maybe it's corrupting its operation in other ways.

    Those are just examples. I'm simply trying to use PoolTag as a "probe" to figure out what's going on since we have little else to go on at this point.

    I did a bit of searching but found nothing, has no one done a detailed static reversing at least of SPTD.sys?

    Cheers,
    Kayaker

Similar Threads

  1. Getting around anti-debugger code
    By REBlog in forum Blogs Forum
    Replies: 0
    Last Post: October 19th, 2007, 20:51
  2. Different papers about SMC, polymorph code and anti trace code...
    By OHPen in forum Advanced Reversing and Programming
    Replies: 7
    Last Post: March 29th, 2007, 15:45
  3. Ring 0 -> Ring 3 : Upward calls and downward returns theoretically possible?
    By Clandestiny in forum Advanced Reversing and Programming
    Replies: 9
    Last Post: December 9th, 2004, 19:50
  4. Does asprotect have anti-tracing code???
    By padawan in forum The Newbie Forum
    Replies: 2
    Last Post: February 23rd, 2004, 16:50
  5. Replies: 10
    Last Post: May 24th, 2003, 14:12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •