Detecting SoftICE ?

View: New views
3 Messages — Rating Filter:   Alert me  

Detecting SoftICE ?

by Bruce Klein :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Hello all,
 
I am writing a Win32 DLL and am currently trying to detect if SoftICE is present.
 
I am trying the "classic" detection methods and for my version of SoftICE (4.3.2) under Windows XP, so far no method has succeeded at detecting it.
 
The methods I am trying are well described in Viega & Messier's "Secure Programming Cookbook" and all over the net.  One is the "Meltice" technique that looks for a virtual device named "\.\\NTICE"; the other uses the "Boundschecker" method that uses int 3, with "BCHK"
in a register.
 
I am having no luck with either method. Perhaps because the methods are obsolete with the current version of SoftICE. Perhaps because I'm doing something stupid.
 
Given the above, I have two questions I'm hoping someone can answer:
    - Does anyone know a method to detect today's SoftICE?
    - Do the other methods even work (and for what versions)?
 
I'd be happy to post the small source or answer any further questions.
 
Thanks in advance.

Re: Detecting SoftICE ?

by Thierry Haven :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Bruce,

you may have a look at crackz's pages for usual tricks concerning Sice detection (http://www.woodmann.com/crackz/Tutorials/Protect.htm#detectsoftice)

However, please have a look at the following routines:

First, we can use int 68h to check the "magic" value 0x0F386 (= debugger present). Then, we may also check the interrupt descriptor table and see if there is a handler installed for INT 68h.

__inline bool IsSICELoaded() {
        _asm {
                mov ah, 0x43
                int 0x68
                cmp ax, 0x0F386 // Will be set by all system debuggers.
                jz out_

                xor ax, ax // check the IDT
                mov es, ax
                mov bx, word ptr es:[0x68*4]
                mov es, word ptr es:[0x68*4+2]
                mov eax, 0x0F43FC80
                cmp eax, dword ptr es:[ebx]
                jnz out_
                jmp normal_
        normal_:
                xor eax, eax
                leave
                ret
        out_:
                mov eax, 0x1
                leave
                ret
        }
        return false;
}

If a debugger is not present AX will be 4300h.

Then, as you said, the CreateFile function may be used to check if the Sice device driver is loaded... It should be working with the latest versions anyway...

/*
        Function: IsSoftIceNTLoaded
        Description: Like the previous one but for use under Win NT only
        Returns: true if SoftIce is loaded
*/

__inline BOOL IsSoftIceNTLoaded() {
        HANDLE hFile=CreateFile( "\\\\.\\NTICE",
                                GENERIC_READ | GENERIC_WRITE,
                                FILE_SHARE_READ | FILE_SHARE_WRITE,
                                NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

        if(hFile!=INVALID_HANDLE_VALUE) { CloseHandle(hFile); return true; }
                return false;
        }


Or maybe the dedicated function "IsDebuggerPresent" will detect it (I haven't tested it with Sice yet)
http://msdn.microsoft.com/library/en-us/debug/base/isdebuggerpresent.asp

BOOL IsDebuggerPresent(void);


But, if your Sice is patched, it may already include protections against those "anti-debugging" features. In this case, you should use your own imagination to detect it :)


--
_______________________________________
Thierry Haven - Xmco Partners
Consultant Sécurité / Test d'intrusion

web  : http://www.xmcopartners.com 


Bruce Klein wrote:

>
> Hello all,
>  
> I am writing a Win32 DLL and am currently trying to detect if SoftICE is present.
>  
> I am trying the "classic" detection methods and for my version of SoftICE (4.3.2) under Windows XP, so far no method has succeeded at detecting it.
>  
> The methods I am trying are well described in Viega & Messier's "Secure Programming Cookbook" and all over the net.  One is the "Meltice" technique that looks for a virtual device named "\.\\NTICE"; the other uses the "Boundschecker" method that uses int 3, with "BCHK"
> in a register.
>  
> I am having no luck with either method. Perhaps because the methods are obsolete with the current version of SoftICE. Perhaps because I'm doing something stupid.
>  
> Given the above, I have two questions I'm hoping someone can answer:
>     - Does anyone know a method to detect today's SoftICE?
>     - Do the other methods even work (and for what versions)?
>  
> I'd be happy to post the small source or answer any further questions.
>  
> Thanks in advance.
>


Re: Detecting SoftICE ?

by Turd :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The ASM code above will certainly work but many crackers have patched SoftIce & other disassemblers to "disappear" if another process calls this interrupt. Check out this link:

http://www.reteam.org/papers/e55.pdf

The "creativity" thing is the best approach. You should also throw a few "fakes" and make 'em think you're a dumb developer. When I'm checking for a process, I enumerate running processes and examine their associated exe's. This isn't a fast operation but if you do it once at the beginning of the program (and make it look innocent with some fake string data), you can quickly check for a number of signatures later. Feed them a fake keygen routine, then fail much later in the program due to licensing issues. I usually set up a random time to trigger an event on an API timer that checks for "licensing issues". I duplicate this routine in several places so a cracker won't have just one patch point to look for. I also make sure each routine has a different code signature so they can't just do a simple pattern search. It's not that they can't figure this out; it's just that you can waste a lot of their time and make it not worth cracking.

I also keep important data encrypted in memory until I actually need it. I put it in classes that automatically encrypt with a random key so that a cracker will have to develop a different hack for each copy of my software.

A final word about detecting SoftICE: play the cracker's game. Go on the offensive. Patch SoftICE so it won't debug your code. Disassemble SoftICE and find out how it does its thing.
LightInTheBox - Buy quality products at wholesale price