Log in

View Full Version : Sice detection/Unpacking

naides
October 30th, 2003, 21:15
I am trying to understand and manually unpack ceratain app.
Before sending me to search the board, please read:

The application's executables are encrypted and packed to a certain extent. I explain, if I dissasemble them with IDA or Windasm, I can still see most of the resources, dialogs, which do exist inside the app, but no import or export functions and the code looks like garbage.

I have scanned the .exe with all the file analyzers I have been able to find and, while they report the file is packed, do not find typical signatures of commercial packers, so I may assume it was crypted/packed by the coders. I have nil expirience with packed programs (so far I never needed one) so I cannot recognize code patterns.

The big problem with trying to manually unpack is debugger detection.
The program quits silently when Sice is active, or is loaded to Olly, or pretty much all the debuggers I have tried.
I systematically tried all of the Sice hiding tools that one time or another have been mentioned here, including the Sice 4.27 patch that Nikola posted, and have come out empty handed.


I eventually moved the application to a Win98 machine and used FrogIce to catch at least some of the Sice detection tricks. FrogsIce reports:

Code 07
=======

Method of detection of the WinICE handler in the int68h (V86)

mov ah,43h
int 68h
cmp ax,0F386h
jz SoftICE_Detected


My question to a good soul in here is, how can I use this information to bypass the Sice detection?

I have traced with Sice from the entry point, and the code is a mess: Self generating, obfuscated with a bunch of jmps and conditional jmps into the middle an instruction bytes, which changes the meaning of the dissassembled code on the flight, etc, so I stand little chance of finding in the dead listing some int 68 call or a pettern of bytes consistent with the code snippet above.

a BPint 68h does not work in Sice.

The solution may be obvious to someone by I don't get it.

Thanks
Manko
October 31st, 2003, 00:58
Hi!

You tried iceext? (I haven't but they say it is good...)

/Manko
naides
October 31st, 2003, 14:20
Quote:
[Originally Posted by Manko]Hi!

You tried iceext? (I haven't but they say it is good...)

/Manko


I tried Iceext. It hides Sice as long as I do not break inside the program.
As soon as I break and try to trace, it "realizes" Sice is up it goes towards "quit" procedure.

Sounds familiar to anyone?
evaluator
October 31st, 2003, 16:03
well, your solution can be: unhide protector for us.
naides
November 1st, 2003, 20:32
Quote:
[Originally Posted by evaluator]well, your solution can be: unhide protector for us.

By looking at the files it wrote on the disk, it looks like C-dilla.
What has me out of a fighting chance is my inability to use a debugger, or even when the debugger is hidden, tracing.
What I want to do is defeat this sucker, because it Fucked up my system. I been trying to restore my Double boot all day long!!!!.

This thing wrote to my partition/boot record and messed up every thing, and I, trying to fixing it, fucked up what good things were left.
SO IT IS PERSONAL

I don't care about the software that much. Only get those suckers exposed!!!
nikolatesla20
November 1st, 2003, 23:12
There are only a few more checks a process can really do to detect a user mode debugger -


The one to look for that might be being used against Olly is NtQueryProcessInformation(), when you pass in a 7, I think, it's PROCESS_DEBUG_INFO..which will return the process debug port. This value will be nonzero if the process is being debugged. So check into that function. I don't have the details since it's been so long since I've played with that..

Also, some programs check for a parent process that is running them. Check for functions which list processes. NtQueryInformationProcess() for example. (Or the toolhelp functions Process32Next, etc). Other programs will check for Olly's window.

SoftICE can still be detected via int3 on UnhandledExceptionFilter even with my patches I don't think I patched that since it leaves trace messages everywhere...

If the protector uses a system driver, it can look at the debug registers and check if they are set a certain way, this detects SoftICE as well then. ALso you HAVE to patch INT1 in the IDT table by resetting its Privilege level back to normal (SoftICE sets the level for itself).

You can find info on how to both of the above items by searching the board. I'd tell you here but it's seriously been too long for me - I've been working on compilers and virtual machines lately...

-nt20
evaluator
November 2nd, 2003, 03:40
hey, you are about MM program!?
(i just say about it in offtop)
Kayaker
November 2nd, 2003, 04:04
Hiya,

You're right nikola that one can check the parent process to see if it's a debugger running you. One way is to check the InheritedFromUniqueProcessId field of the PROCESS_BASIC_INFORMATION structure.

I've got an unfinished project where, if I detect Olly or other Win32 debugger, I create a remote thread in the debugger with PsCreateSystemThread, then use a shared Kernel/User Named Event (using IoCreateNotificationEvent) to signal the thread from usermode (after cleaning up and closing my own driver) to terminate Olly (the remote kill thread is waiting indefinitely on a KeWaitForSingleObject).

I was going to publish this in a "stupid driver tricks" post at some point, but I don't mind discussing anti-cwacker tricks, so here's a few snippets (without what should rightfully be a full explanation), just for fun ;-)

Code:


;========DebuggerCheck=================

DebuggerCheck proc



lea edi, pEventObject_ATTRIBUTES

lea esi, pCLIENT_ID



; initialize OBJECT_ATTRIBUTES and CLIENT_ID structures

assume editr OBJECT_ATTRIBUTES

mov [edi].dwLength, sizeof OBJECT_ATTRIBUTES

mov [edi].RootDirectory, 0

mov [edi].ObjectName, 0 ; can set to object name if 

; ClientID.UniqueProcess not used

mov [edi].Attributes, 0

mov [edi].SecurityDescriptor, 0 

mov [edi].SecurityQualityOfService, 0 



assume esitr CLIENT_ID

invoke PsGetCurrentProcessId  ; This is OUR PID

mov [esi].UniqueProcess, eax

mov [esi].UniqueThread, 0





invoke ZwOpenProcess, offset hProcess,\      ; OUT PHANDLE phProcess

PROCESS_ALL_ACCESS,\     ; IN ACCESS_MASK AccessMask

edi,\                    ; IN pEventObject_ATTRIBUTES ObjectAttributes 

esi                      ; IN PCLIENT_ID pClientId



invoke ZwQueryInformationProcess, hProcess,\

ProcessBasicInformation,\    ; ntddk.inc ; enum _PROCESSINFOCLASS

offset pPROCESS_BASIC_INFORMATION,\

SIZEOF pPROCESS_BASIC_INFORMATION,\

offset ReturnLength



;=======================================

; CHECK 1

;--------------------------------------------------



mov eax, pPROCESS_BASIC_INFORMATION.PebBaseAddress

bt dword ptr [eax], 16

 ; Bit Test to see if BeingDebugged flag is at byte 002 of PEB

jc @F

jmp nodebugger     

@@:



;=========================================

; CHECK 2

;-----------------------------------------------------



mov eax, pPROCESS_BASIC_INFORMATION.InheritedFromUniqueProcessId

; If being debugged, this will be the Debugger PID,

; if not, this will be a non-valid system PID

; (unless this is a child process)

; the trick now is how best to confirm this

; (ZwQueryInformationProcess or ZwOpenProcess

; could be used..)



; left as an exercise ;-)



; If PID confirmed as belonging to debugger:



mov [esi].UniqueProcess, eax

 ; redefine CLIENT_ID to that of the debugger PID



invoke ZwOpenProcess, offset hDebuggerProcess,\

PROCESS_ALL_ACCESS,\

edi,\

esi



;--------------------------------------	

; Now that we have the handle to the Process (in this case the Debugger)

; create a remote kill thread in the (suspended) target

; with PsCreateSystemThread.

; This thread will be signalled with an Event once we return

; to Usermode and clean up and unload our driver.

;--------------------------------------------------------



nodebugger:



assume esi:nothing

assume edi:nothing



mov eax, STATUS_SUCCESS



ret

DebuggerCheck	endp

;================End DebuggerCheck==================



In User mode you can also use RtlQueryProcessDebugInformation with the PDI_MODULES flag to some advantage to get at the very least the ImageName of a process (via the DEBUG_MODULE_INFORMATION aka SYSTEM_MODULE_INFORMATION structure) to confirm the presence of known debuggers.

'nuff for now.

Kayaker
Zwyzum
November 2nd, 2003, 08:37
Hi.

<commercial>

I usually avoid dealing with anti debugging tricks as I am not interested in countermeasures. I'm presenting a different solution in the thread I started a couple of days ago.

</commercial>

Bye
Zwyzum
naides
November 2nd, 2003, 09:17
Quote:
[Originally Posted by evaluator]hey, you are about MM program!?
(i just say about it in offtop)


I f I understand you correctly, MM is not the program I am trying to break.
I think it is against THE RULES to mention my target here, but if you are interested, I can PM you a link.
Notice that I am not asking any one to take a look or crack it for me. . .

Nikola, Kayaker, evaluator and Zwyzum, thank you for your answers, you ceratainly give me quite a bit of leads to explore.

I will post it if I find any thing interesting.
JMI
November 2nd, 2003, 13:22
naides:

It's not against the rules to "identify" your target. It's against the rules to post target specific code "after" identifying, or which "identifies," the target.

The general point of the rule is to attempt to prevent the posting of target specific code which would permit others to take that code and make a specific target work without its protection system, whatever that may be. It is such posts that tend to draw accusations of permitting the posting of "cwacked" software or "cwacks" and lead to complaints to our host seeking to have the Board taken off the host.

In your case, posting a piece of code which seems to detect a debugger, would not seem to provide anyone else a method of simply plugging in your code and getting a working verson of the software. Identifying the target for others to look at still would not provide a working program. Even identifying "how" the software detected the debugger would not, itself, give that solution. One would still have to use the debugger themselves to work through whatever is protecting the code.

This is intended to be generic, rather than specific. Hope it makes it somewhat more clear.

Regards.
evaluator
November 2nd, 2003, 14:54
I did some tests.
Seems it detects debuger(ntice) by driver name, but not CreateFileA.
(maybe CreateFileW or NtCreateFile?)
tommorow will look closer..

On my Xp I had renamed 4 drivers names, so it not detects.
evaluator
November 2nd, 2003, 16:47
nop, i found only \\.\Ntice detection via CreateFileA, not other..

MM means Macr0Media, then it's products are DW, FW, FH, AW..
currently I'm on FW.
SiNTAX
November 3rd, 2003, 09:10
Quote:
[Originally Posted by nikolatesla20]There are only a few more checks a process can really do to detect a user mode debugger -

The one to look for that might be being used against Olly is NtQueryProcessInformation(), when you pass in a 7, I think, it's PROCESS_DEBUG_INFO..which will return the process debug port. This value will be nonzero if the process is being debugged. So check into that function. I don't have the details since it's been so long since I've played with that..
...
-nt20


SD uses secdrv.sys to pass the clock back to the main exe.. so you have to fix that check too. Don't know about safecast, but I heard it's pretty much the same as the SD targets. (NOTE: you only need to fix this one if you want to use Olly as this has no effect on NTICE)
doug
November 4th, 2003, 00:20
Quote:
[Originally Posted by naides]By looking at the files it wrote on the disk, it looks like C-dilla.
What has me out of a fighting chance is my inability to use a debugger, or even when the debugger is hidden, tracing.
What I want to do is defeat this sucker, because it Fucked up my system. I been trying to restore my Double boot all day long!!!!.

This thing wrote to my partition/boot record and messed up every thing, and I, trying to fixing it, fucked up what good things were left.
SO IT IS PERSONAL

I don't care about the software that much. Only get those suckers exposed!!!


c:\C-Dilla + writting to boot record? that sounds very much like safecast (or safedisc hd). And I think their main license checking exe file is protected by safedisc. Check your temp dir.. clean it up, then launch the program, check what's unpacked in there.