Page 4 of 5 FirstFirst 12345 LastLast
Results 46 to 60 of 64

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

  1. #46
    And for those whose searching skills may not be up to par:

    The in-circuit emulator (ICE) remains the most powerful debugging tool available. Nothing else approaches an ICEís wide range of troubleshooting resources; no other tool so completely addresses problems stemming from hardware/software interaction. The emulatorís birth was almost coincident with the start of the microprocessor age, since micros live deeply buried in applications that simply donít resemble computers.

    http://www.embedded.com/1999/9910/9910sr.htm

    Regards,
    JMI

  2. #47
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    talking of hardice "au contraire" softice yep may be something like american arium products were used to debug them

    hi kayaker,

    though a lot of things you posted doesnt register in my mind yet

    i grasp that the sptd.sys patches sice's entrypoint and prohibits
    it from loading and thats the most probable cause of sice being not able to load

    well so i have a question i assume you might have tested this with windbg kernel debugger too with two machine setup

    in the target the only requirement is to add the /debug switch to boot .ini
    for activating the kerneldebugger

    so i think (there cannot be a generic driver or whatever that could be patched in its entry point (yeah i may be wrong may be some kd.sys exist and may be its being loaded if there is a /debug switch i dont know it just occured to me that a legacy old win2k cd with no service packs loaded into a vm and not updated but just install this app that uses this sptd.sys might not anticipate changes that would be there in the latest versions of kd
    or does it check if the debug switch exist and prevent from loading itself so that the child usermode programs dont work probably its later maybe )

    so why does this sptd.sys hate kd too (does it hate kd ?)
    yeah it might be checking some apis like isKDebuggerEnabled()
    but that could be handled i suppose if you really break while this sptd.sys is
    doing its stuff

    you can break into a kd while only one process is active that is the system process i believe and when the minimalist of minimal drivers has loaded

    any explanation in this regard would be enlightning


    and thanks for writing such excellent articles in a four part series its
    absolutely fantastic reading articles of this calibre motivates one to
    really dig deep deeper and deepest

    regards
    Last edited by blabberer; October 18th, 2006 at 13:49.

  3. #48
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    I *KNEW* you'd be the one asking about WinDbg blabberer, I just knew it!

    Yep that was a good guess, if you boot with the /DEBUG switch, SPTD never loads at all and you can use Softice or WinDbg to your hearts content. In fact this a great way to set up a dual-boot option to allow you to use one or the other (SPTD or debugger). Kinda surprised they might not have mentioned this option to users who DO want to use a kernel debugger for valid reasons other than reversing SPTD or its apps

    So yeah, SPTD probably checks the exported variables KdDebuggerNotPresent or KdDebuggerEnabled early during its initialization, but this is most likely hidden within the Virtual Machine code it uses.

    Far be it from me to suggest a way to circumvent this , but what IF..

    ..you create a boot loading driver which loads just *before* SPTD and disables the KdDebuggerEnabled flag. You might be able to do this by modifying the ServiceGroupOrder as we discussed earlier.
    ..you "later" reenable the KdDebuggerEnabled flag so things operate correctly.
    .. if "later" (post boot) is too "late", maybe create a second driver but which loads immediately *after* SPTD and reenables the flag. Boot loading then continues normally.

    This isn't to say there might not be other checks for /DEBUG, but if it's a simple test of that flag during SPTD initialization this idea should effectively "blind" it.

    K.

  4. #49
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    I *KNEW* you'd be the one asking about WinDbg blabberer, I just knew it!


    premonitions,some kind of esp (not the damn register in x86 cpus) or telepathy what makes you know it


    anyway thanks for confirming my dumb guess
    so if it didnt load sptd then the child dont work so windbg works and
    i am happy (i was looking at the site there is a sptdinst avialble for download) is it enough to download only that if i want to play with sptd ? or should i get that whole bunch of thingies including the toolbars and stuff that it asks)
    any way it looks like its a slim package no gigabytes of bloat to downlaod
    so possibly i may give it a spin if only to see and understand )

    ok so if it commits suicide since it cant assasinate (damn suicide bomber)
    how about getting it to a lab and injecting it with truth serums like
    trying to load it after you start with (load image whatever )(just like your sysdasm loads) and have some breakpoints ready in kd in system code
    and simply bruting (no brain just brawn)through the code step by step (yep if it is a vm it might be tough but ) and having damn breaks all over it has to end up in system some where (once it spits one little secret password forensics can take over the rest of the jigsaw)

    with kd on
    and doing a bm nt!A* bm nt!B* bm nt!C* bm nt!D* .....,bm nt!Z*
    bm hal!A* to bm hal!Z*

    and have a logopen so that you could simply g g g and if it crashed
    you could simply look at the log and stop one stepabove

    yeah it sounds simple i guess the authours of this thing would have
    sure thought about this if they wrote such master pieces damning
    every piece of debugger and would have put in place some kind of
    checks to prevent this

    but like the sages of the yore used to say if it runs it cant hide
    it can hide from someone for somedays but it cant hide from everyone
    everyday

    yep its time to get the four-f's kit and masm32 dusted out

  5. #50
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    premonitions,some kind of esp (not the damn register in x86 cpus) or telepathy what makes you know it
    Noooo.., [ESP+00h] had nothing to do with it. It has more to do with your apparent mastery of the usage and syntax of all the cryptic WinDbg commands (I've seen the output you've sent me). This "tool wizardry" is only rivaled by that you show with Olly

    is it enough to download only that if i want to play with sptd?
    The driver install is enough for analysis purposes. The rest is no big deal, the usermode toolbar ad-thingy is a secondary optional install which you can completely disable from the registry Autorun.

    how about getting it to a lab..
    Yup

    Regards

  6. #51
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    hi kayaker,

    i was reviewing this thread from start

    i see you mentioning an indirect call that calls Driverentry()

    this call called only by which class of drivers only those that are started via SERVICE_DEMAND_START ?

    does it apply to your bootbus extender and boot phase drivers too

    anyway it looks like boot phase drivers arent being called via this call
    and also the loadasimage or linkasdll sysdasm.sys or neither four-fs



    here is the output of windbg
    Code:
    kd> .reboot
    Shutdown occurred...unloading all symbol tables.
    Waiting to reconnect...
    Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
    Kernel Debugger connection established.
    Symbol search path is: srv*c:\debugsymbols*http://msdl.microsoft.com/download/symbols
    Executable search path is: 
    Windows 2000 Kernel Version 2195 UP Free x86 compatible
    Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e1b8
    System Uptime: not available
    Break instruction exception - code 80000003 (first chance)
    nt!DbgBreakPoint: <--- break by /break switch in boot.ini
    
    8045647c cc              int     3
    kd> bl 
     0 d 8045647c     0001 (0001) nt!DbgBreakPoint
    
    kd> bp nt!NtLoadDriver
    kd> bp 8049a037 ".printf \"%y\\n\", poi(eax+2c);g"
    kd> bl
     0 d 8045647c     0001 (0001) nt!DbgBreakPoint
     1 e 8052dc72     0001 (0001) nt!NtLoadDriver
     2 e 8049a037     0001 (0001) nt!IopLoadDriver+0x66f ".printf \"%y\n\", poi(eax+2c);g"
    
    kd> g
    *** ERROR: Module load completed but symbols could not be loaded for vpc-8042.sys
    vpc_8042+0xd1f2 (feaca1f2)
    kbdclass!DriverEntry (f96abe64)
    mouclass!DriverEntry (f96bb4e4)
    serial!DriverEntry (f945a380)
    serenum!DriverEntry (f987ab00)
    fdc!DriverEntry (f96d4f30)
    parport!DriverEntry (f96e04a2)
    gameenum!DriverEntry (f9881ba0)
    ctlsb16!DriverEntry (feaaff00)
    cdrom!DriverEntry (f96fdbc0)
    *** ERROR: Module load completed but symbols could not be loaded for vpc-s3.sys
    vpc_s3+0x73ca (fea4a3ca)
    dc21x4!DriverEntry (f947ece0)
    audstub!DriverEntry (f9a3f500)
    rasl2tp!DriverEntry (f948b780)
    ndistapi!DriverEntry (f9891762)
    ndiswan!DriverEntry (fea3fae0)
    raspptp!DriverEntry (f949a920)
    ptilink!DriverEntry (f97282e0)
    raspti!DriverEntry (f973b240)
    parallel!DriverEntry (f94a2bbe)
    swenum!DriverEntry (f9a426c0)
    update!DriverEntry (fea2a660)
    flpydisk!DriverEntry (f9753b80)
    Breakpoint 1 hit
    nt!NtLoadDriver:
    8052dc72 55              push    ebp
    kd> g
    NDProxy!DriverEntry (f94d8720)
    Breakpoint 1 hit
    nt!NtLoadDriver:
    8052dc72 55              push    ebp
    kd> g
    Sfloppy!DriverEntry (f98bdc80)
    Fips device driver loaded successfully
    Fips driver locked into memory
    Fips driver unlocked from memory
    giveio: Entering DriverEntry <--- four-fs datetime dbgprint
    giveio: Leaving DriverEntry
    
    Breakpoint 1 hit
    nt!NtLoadDriver:
    8052dc72 55              push    ebp
    kd> g
    *** ERROR: Module load completed but symbols could not be loaded for SysDasm_LinkAsDLL.sys
    SysDasm_LinkAsDLL+0x940 (f9af3940)
    Invalid Address <--- i passed kdasm da 701000 :)
    Invalid Address
    Invalid Address

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

    Cool results. Undoubtedly the different driver types and load methods use different code from the standard SERVICE_DEMAND_START startup. My assumption was that C:\NTLDR handled much of the early boot loading. Within NTLDR is the embedded file osloader.exe, within that you can see string references to bits of driver loading info, including the ScsiPort* imports that SPTD.sys and its associated driver SPTD***.sys use. Someone over at RET did some NTLDR reversing of interest:
    http://www.reteam.org/board/index.php?showtopic=351

    I took a look at the boot sequence as recorded by Boot Log XP (Greatis). It shows the 'Boot Bus Extender' drivers such as sptd and cpthook, also 'PnP Filter' drivers such as agp440 or 'Base' drivers such as KSecDD, all loading as the first group. I presume these are all loaded by the NTLDR process.

    Next it shows the drivers which are loaded at boot as the second group, by the SYSTEM process, such as i8402prt, kbdclass, mouclass, etc.

    What's interesting is that if you output the results to a text file it indicates that the first group of drivers (loaded via NTLDR) are loaded under the ProcessId = -1. The second group of drivers are loaded by the SYSTEM process, with a ProcessId = 4 (as normal).

    I was just thinking in terms of WinDbg whether you can use this ProcessId value, or some other way, to make WinDbg *stop* execution on boot loading while the NTLDR (osloader.exe) or SYSTEM process is executing. If your intent is to break while SPTD is loading you need *some* way to get WinDbg to stop OS loading at a very early stage. Not sure how you could do this but it would be interesting to be able to step through OS loading from the very start.

    Kayaker

  8. #53
    The earliest possible breakpoint that can be set with WinDbg is if you use the /BREAK switch (along with the ususal stuff) in boot.ini. This causes the kernel to break at HAL initialisation. I don't think you can break earlier with WinDbg as the target machine hasn't initialised enough for the debugger to be usable. The only way to break before this would be to use a hardware solution.

    According to Windows Internals, boot drivers are loaded by NTLDR, but their DriverEntrys are not called until much later, just before the system-start service drivers are started. I have used WinDbg to step through the driver loading code on XP when I was playing about with some rootkits. I can't remember exactly what happened as it was maybe 6 months or more ago. However, the signature for the code that calls DriverEntry from IopLoadDriver is '57 ff 57 2c 3b c3' on all XP versions I've looked at:

    Code:
    push edi
    call [edi + 2c]
    cmp eax, ebx

  9. #54
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    yes auturky /break switch is the most earliest break thats possible in normal way of things but reversers dont work normally if you screw up on /break
    stepping inside while cli sti disable interrupts are effective and it is highly possible its a royal pain in the uhmmm to step through many of the codes
    as many of them call irets and stuff that

    (its completely spaghetti code if you ask a c application programmer interspersed with gotos (unconditional jumps to hell ) yeah goto is of tremendous use when you are coding pretty lowlevel )

    effectively cant be single stepped
    (single stepping on irets mostly causes stack to filled with gibberish and the return pointing to iret again and again till possibly stack overflows )
    i think stack gets filled with cs,eip,and possibly efl and the retn address which points to itself


    you end up with HAL_INITIALISATION FAILED bugcheck (bugcheckcode ox5c)

    after that comes commandline switch -d which breaks on symbol loading of the first kernel module usually ntoskrnl.exe the next is hal.dll and the then starts bootvid.dll and other blah blah drivers
    and then comes -b commandline switch which breaks after kernel is initialised

    and btw are you sure IopLoadDriver is called ?? probably may be called with disabled interrupts because after success of HAL_INITIALISATION
    you can see HalExecutiveInitialize calling RestoreInterrupts()

    anyway ill check if it is being called i highly doubt windbg will break while it is in HalExecutiveInit stage

  10. #55
    You're right, IopLoadDriver isn't called during HAL initialisation, or anything like that. I've just used it to break on driver loading. However, I can't remember if the code I mentioned above was called by the kernel when it calls the DriverEntrys of drivers loaded (but not initialized) by the NTLDR. I know it's called by IopInitializeSystemDrivers. I've got Daemon Tools on the machine I normally debug, so I can check in about 5 hours time when I get back from work. Maybe MiBuildImportsForBootDrivers is worth a look, or MiReloadBootLoadedDrivers (called from MiInitMachineDependent) and IopInitializeBootDrivers (called from IoInitSystem). Not much/any documentation on any of these.

    Also, I've never tried stepping through the HAL, just used it as a useful stopping point to set further breakpoints. From what you've said, I don't think I'll ever try it either.
    Last edited by autarky; October 23rd, 2006 at 07:18.

  11. #56
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    hi kayaker ,

    thanks for the information i was looking around for information on the

    f8 debugging mode (advanced options in boot menu)to see if it in any way helps in breaking pretty early

    though i couldnt land any pertinent information on how to break

    i found some sites which do have a lot of information of the process itself
    if these guys do know all these then there should be some ways not everyone runs with hardware ices so some software debugging methods should exist ill post back if i find anything more

    in the meanwhile

    this link is what i am referring

    http://onyx.yonsei.ac.kr/courses/management/down/Chap4-StartupandShutdownbootprocess.ppt

    just explore the root it looks like its holding a goldmine of information

  12. #57
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    reviewing the ppt again today with little help of kd
    all the percentages it speaks of is after the splash screen is shown
    and not before the splash screen is hsown

    i was jumping to conclusions thinking that the ppt is talking about the
    progress bar in txt mode

    well all that the ppt says could be confirmed with kd

    anyway here is some edited paste on driver entries from kd after all it is debuggable may be one needs some patience to get the vm or whatever obfuscation straightened out and thats what is needed to find out if it is a true incompatibility or intentional antidebug

    Code:
    kd> g
    nt!RawInitialize (8056308e)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    *** ERROR: Module load completed but symbols could not be loaded for sptd.sys
    sptd+******* (********)
    Error code: (NTSTATUS) 0xc000009a - Insufficient system resources exist to complete the API.
    ACPI!DriverEntry (febdc14b)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    pci!DriverEntry (f940bca8)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    isapnp!DriverEntry (f9419b62)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    intelide!DriverEntry (f99002c0)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    MountMgr!DriverEntry (f968e100)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    ftdisk!DriverEntry (febb42f8)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    Diskperf!DriverEntry (f99033a0)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    dmload!DriverEntry (f99044fa)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    dmio!DriverEntry (feb7b816)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    PartMgr!DriverEntry (f98161a0)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    atapi!DriverEntry (feb75bfa)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    disk!DriverEntry (f9695b40)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    Fastfat!DriverEntry (feb5e8e6)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    KSecDD!Sel <PERF> (KSecDD+0x1031e) (feb3e31e)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    NDIS!DriverEntry (feb2ab7e)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    Mup!DriverEntry (feaf3de4)
    Error code: (NTSTATUS) 0 - STATUS_WAIT_0
    have phun

  13. #58
    for sure its intentional... they want to stop people from recreating their product (and/or the protection people from finding methods to blacklist their code easily... and seeing as its pretty much blacklisted by most prots (you need to use 3rd party tools to 'hide' alcohol or daemon) already, its kinda futile)..

  14. #59
    I spent all week down the pub, and have only got round to going through the driver loading now. So, a quick overview for the interested:

    Boot drivers are loaded by NTLDR somewhere low down in physical memory. Once paging and protected mode is turned on (I'm not sure which order this happens in, but Windows Internals will say), these boot drivers (including ntoskrnl) will all be in the low area of kernel memory, typically 0x800XXXXX. This is done to avoid a circular dependency whereby ntoskrnl would have to use a file system driver to load itself - directly talking to the hardware being left to the HAL and NTLDR.

    However, these drivers cannot be run by NTLDR, as the NT subsystem isn't up and running yet. So, once execution is handed over to ntoskrnl, all boot drivers are relocated and initialised during Phase1Initialisation. The IO manager initialises itself, and in so doing calls MiReloadBootLoadedDrivers which copies all the boot drivers up to the other end of kernel memory where drivers typically live (0xFXXXXXXX). Having done this, the drivers' are all initialised by calling IopInitializeBootDrivers, which in turn calls IopInitializeBuiltinDriver, which calls the DriverEntry directly for each driver. The code signature on XP SP2, single processor is FF 53 2C 8B F0 (I haven't checked any others):

    Code:
    call [ebx + 2c]
    mov esi, eax
    Not that you need to find and BP that code - a one shot on MiReloadBootLoadedDrivers, then a BP on the call in that function to LdrRelocateImage will suffice. This will be called for every boot driver to do the relocation table fixups. Recognising sptd is not difficult, so just hit 'g' until it's its turn - I just dereferenced what was on the top of the stack each time a BP was hit. And, seeing as the new base address is on the top of the stack, we can just use that to put a BP on the EP, and then hit 'g'.

    I may have a look later today to see where the code that's returning that error is. 'tc' might do the trick. I'm not very experienced with WinDbg.
    Last edited by autarky; October 29th, 2006 at 12:35.

  15. #60
    This isn't directly related to the above post. Anyway, the code is encrypted, and the VM is used to decrypt the encrypted code section and original DriverEntry. It may well do other stuff as well, I haven't stepped all the way through it as I haven't the patience. It does use the debug registers for stuff. I don't know what is returning the 'insufficient resources' error, but it's not one of the usual suspects (such as ExAllocatePoolWithTag). Underneath, it's a plain old driver written in C.

    It's possible to dump the image, though it will be missing the INIT section. It can be dumped - livekd works (try .writemem), and I've been working on something to dump kernel modules from user mode. There is section based obfuscation (due to the slightly different way kernel modules are loaded), so the dumped file needs some reconstruction. I should have a decent reconstruction this evening, minus original DriverEntry. The section based obfuscation is worth paying attention to if you're interested - I haven't seen it before.

    It doesn't look rootkit-esque at the moment, I'll be able to get a better idea later. To be honest, I was and still am more interested in the armour. KM armour isn't that well explored (at least not publicly) under NT to my knowledge. You can do some pretty cool stuff.

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
  •