Log in

View Full Version : Safecast is driving me crazy Help needed


eclipse2k2
January 27th, 2004, 11:00
I'm still blocked on Debugger detection under win2k. I've tryed using Iceext and still sucks. I found a detection routine that checks all first byte of kernel apis to detect breakpoints.
Please help needed.

lenwuk
January 27th, 2004, 11:24
Quote:
[Originally Posted by eclipse2k2]I'm still blocked on Debugger detection under win2k. I've tryed using Iceext and still sucks. I found a detection routine that checks all first byte of kernel apis to detect breakpoints.
Please help needed.


You don't say what debugger you're using, but with Softice you can set a memory-location execution breakpoint which doesn't modify the code.
e.g "bpm GetWindowItemTextA x"

eclipse2k2
January 27th, 2004, 11:33
Sorry, I'm using Softice, but even without any breakpoint and having IceExt activated Sice is still detected. I have no more ideas to bypass the checks.
Any help is apreciated.

Thank you in advance

Mr. Blue
January 27th, 2004, 12:35
I never dealt with Safecast, but I have certain experience with Safedisc. Soon after the application starts it calls into one of several Safedisc dlls. Then there is a massive antidebug routine called which tries to detect a debugger using various antidebug tricks. As far as I remember the first trick it uses is IsDebuggerPresent, then it continues with more advanced tricks. This is one way to detect
where the antidebug starts. Put a breakpoint on IsDebuggerPresent, on its return zero EAX and trace back to the caller. Then trace until the next RET, you'll end up in the big antidebug routine. Now I found something interesting - this routine was controlled by a WORD pushed as an argument on the stack. The WORD seem to act like a bitmask which the big anti debug routine uses to determine
which anti debugger checks to execute. I found out that zeroing the WORD being pushed at the routine entry point lets you safely pass the checks. Of course this is just me

I hope this helps.

eclipse2k2
January 27th, 2004, 13:47
I tryed seting a bpm on isdebuggerpresent and it breaks, Then I'm able to detect a battery of sice checks that I bypass, but the code, enters in an ofuscated zone that I cant continue tracing and finally the program exit without any error message.

I'm working on a flexlm licence for a famous 3D program (it's latest version) cause I can't deploy to various PCs If the program is regged with the keygen so the best solution is to generate a flexlm license, but I'm not able even to load the program with softice loaded so imagine how fustrated am i...

Thanks for your fast replys and support.

doug
January 27th, 2004, 14:32
Quote:

Sorry, I'm using Softice, but even without any breakpoint and having IceExt activated Sice is still detected. I have no more ideas to bypass the checks.


what else have you tried besides installing iceext?

-----
Read the threads on hiding softice on this board & the ones on safedisc.. If you want to bypass the checks manually each time:

This also applies to the most recent safedisc version:

bpm ExitProcess X;
dd esp

tell us the little hex value sitting there (hint: starts with F).

Then search where this value comes from. (push xxxxxxxx/Jmp ExitProcess)
Then find the beginning of that procedure. (lets call this proc "SilentExit"

And bpm on SilentExit too, everytime it breaks, check esp to see where the check originated from.

iirc, there were 3 of those checks, executed several times each.. on startup.

evlncrn8
January 27th, 2004, 17:49
try iceext, you might also have to modify your ntice.sys, basically safecast uses the exact same code for anti debug as safedisc.. same company and essentially the same product (just cut down a little)

Pyrae
January 27th, 2004, 23:50
I remember lots of driver-based timing traps, which used the exported kernel symbol KeTickCount. Those are probably the culprits, if your app doesn't start up after debugging some SafeCast code...



regards,
Pyrae

evlncrn8
January 28th, 2004, 00:32
int 1 -> int 3 distance check
meltice
ntquerysysteminformation (0bh)
drx checks
checking of kernel32/user32 exports 1st byte = 0cch (int 3) = bad boy
isdebuggerpresent (useless if using ntice)

thats more or less what you're up against, oh and anti bpm, same as safedisc like i said

eclipse2k2
January 28th, 2004, 09:03
Thank you for your help, I've been able to run the program so the fun is just about to start but I think now it will be easier.
Long time out of the scene without working on hard protections, hopely there are people with great level ready to help others. Many thanks to everybody.
ecl

dELTA
January 28th, 2004, 14:31
In what way is "ntquerysysteminformation" used for anti-debug purposes?

Kayaker
January 28th, 2004, 16:40
That would give the ImageName of all .sys files running, ntice, siwvid, iceext...

ZwQuerySystemInformation (or NtQuerySystemInformation) gives you a raft of information depending on the SystemInformationClass you set in the call, there are 53 different classes, defined in ntifs.h. Most handy are probably SystemProcessesAndThreadsInformation (class 5) and SystemModuleInformation (class 11) (which is the one which returns ntice.sys etc.) Both of these are used by the PSAPI functions to get process and device driver info about the system.

Programatically you have to handle the returned info from these 2 classes slightly differently, it's necessary to determine the exact size of the buffer required before you can successfully retrieve it all. Unless the protection decides to take a "guess" on the size of the buffer needed the scenario is probably like this - In the case of SystemModuleInformation, there would likely be 2 calls to NtQuerySystemInformation, the first one is set with a '0' return buffer size and will fault (STATUS_INFO_LENGTH_MISMATCH) but give you the required size, then there will be a dynamic memory buffer created of that size, then a repeat call to NtQuerySystemInformation which will successfully retrieve an array of SYSTEM_MODULE_INFORMATION structures for each module in the system. While most of the modules returned are .sys drivers, they also include ntoskrnl.exe, hal.dll and ntdll.dll.


Code:

; SystemModuleInformation - Information Class 11
SYSTEM_MODULE_INFORMATION STRUC ; sizeof = 120h
Reserved DWORD 2 dup(?) ; 00h
Base DWORD ? ; 08h
_Size DWORD ? ; 0Ch
Flags DWORD ? ; 10h
Index WORD ? ; 14h
Unknown WORD ? ; 16h
LoadCount WORD ? ; 18h
ModuleNameOffset WORD ? ; 1Ch
ImageName BYTE 256 dup(?) ; 20h
SYSTEM_MODULE_INFORMATION ENDS


Oh, and there's a SystemKernelDebuggerInformation class too, but it doesn't work for Softice

Code:

; SystemKernelDebuggerInformation - Information Class 35
SYSTEM_KERNEL_DEBUGGER_INFORMATION STRUC
DebuggerEnabled BYTE ? ; BOOLEAN
DebuggerNotPresent BYTE ? ; BOOLEAN
SYSTEM_KERNEL_DEBUGGER_INFORMATION ENDS


TMI?
Kayaker

JMI
January 28th, 2004, 16:50
Well, he did ask, didn't he?? And now he has been told. Ahmen.
Damn Kayaker, that's good stuff. Guess I need to spend more time in my windows NT/2000 Native API Reference.

Regards,

dELTA
January 28th, 2004, 17:04
You can always trust good old Kayaker for nice answers on the low-level stuff, thanks as always.

Kythen
January 29th, 2004, 01:16
Just another little note... I don't remember offhand, but I think it might use NtQueryProcessInformation as well to look for a debugger. It definitely uses TIB and PEB checks though. Look for references to fs:[18h] to find those.

JMI
January 29th, 2004, 03:33
And if you don't know what the heck a TIB or PIB is, check this thread:

http://www.woodmann.com/forum/showthread.php?t=5420

Regards,