Page 1 of 4 1234 LastLast
Results 1 to 15 of 64

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

Hybrid View

  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
    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??

  8. #8
    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

  9. #9
    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.

  10. #10
    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??

  11. #11
    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

  12. #12
    Quote Originally Posted by Kayaker
    I did a bit of searching but found nothing, has no one done a detailed static reversing at least of SPTD.sys?
    This was my first thought, just open it in IDA and take a look.

    I haven't the file either, so I can't make any statements regarding it, but static analysis is sometimes still the best way to understand hostile code.

  13. #13
    Quote Originally Posted by LLXX
    I haven't the file either, so I can't make any statements regarding it
    I attached the latest version of sptd.sys -- 1.25.0.0
    I'm not very familiar with the kernel-mode stuff,so I can't get the point of all these ntoskrnl functions...but IDA shows some interesting strings like:

    Code:
    .data:00078808  00000053 C Debug TEST trigger in DPC: overflow by %I64d ms!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n
    Attached Files Attached Files

  14. #14
    Quote Originally Posted by DillerInc
    I attached the latest version of sptd.sys -- 1.25.0.0
    I'm not very familiar with the kernel-mode stuff,so I can't get the point of all these ntoskrnl functions...but IDA shows some interesting strings like:

    Code:
    .data:00078808  00000053 C Debug TEST trigger in DPC: overflow by %I64d ms!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n
    It also looks like it's been encrypted/packed... I'm not familiar with NT kernel architecture either, so that's all I can see...

  15. #15
    Quote Originally Posted by DillerInc
    omega_red
    Maybe some conflict with antivirus software??
    No, it's a clean xp 32-bit.
    I've had this problem with my 64-bit system at home, but that was related to some 64-bit specifix hotfix affecting Windows kernel protection (at least that's what I found with google - KB914784). However, I've found no online sources mentioning that it's an issue on 32-bit xp too, and this specific KB is not installed on 32bit system. Interestingly, I have the same DT version (4.03) working on other 32-bit machine with xp, fully patched too..

    As for hooked syscalls, the list is as follows:
    0029: NtCreateKey
    0047: NtEnumerateKey
    0049: NtEnumerateValueKey
    0077: NtOpenKey
    00a0: NtQueryKey
    00b1: NtQueryValueKey
    00f7: NtSetValueKey
    Vulnerant omnes, ultima necat.

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
  •