TitanHide

[mr.exodia]

Released V0007:
- fixed a BSOD
- plugins for x64_dbg (use the command 'TitanHide')

Latest release can always be downloaded from:
https://bitbucket.org/mrexodia/titanhide/downloads

Greetings,

Mr. eXoDia

[ahmadmansoor]

Hi
very Good and very fast ,,,I still make the test on v006 Lol
anyway.

For (TitanHideTest)
I make very tiny change ,because let this prog go in sycal make my eyes flash .

Test: <<<<<<<<
char title[256]="";
sprintf(title, "pid: %d", (int)GetCurrentProcessId());
SetConsoleTitleA(title);
while(1)
{
printf("ProcessDebugFlags: %d\n", CheckProcessDebugFlags());
printf("ProcessDebugPort: %d\n", CheckProcessDebugPort());
printf("ProcessDebugObjectHandle: %d\n", CheckProcessDebugObjectHandle());
printf("NtQueryObject: %d\n", CheckObjectList());
printf("CheckSystemDebugger: %d\n", CheckSystemDebugger());
printf("CheckNtClose: %d\n", CheckNtClose());
//printf("ThreadHideFromDebugger: %d\n", HideFromDebugger());
puts("");
//Sleep(1000);
system("Pause"); <<<<<<
printf("\n"); <<<<<<
goto Test; <<<<<<

By the way I have checked "CheckProcessDebugFlags "

and find something go wrrong in ur x64_dbg (x32)
-CheckProcessDebugFlags come when the debugger try to handle exception which is a trap could be the coder have use it to check if u debug his software or not Like this example :Author: Dejan Lukan with my little tiny changes

Test:
BOOL bExceptionHit = FALSE;
__try {
_asm
{
pushfd
or dword ptr [esp], 0x100
popfd
// Set the Trap Flag
// Load value into EFLAGS register
nop
}
}
__except(EXCEPTION_EXECUTE_HANDLER) {
bExceptionHit = TRUE;

// An exception has been raised ¨C
// there is no debugger.
}

if (bExceptionHit == FALSE)
printf("A debugger is present.n");
else
printf("There is no debugger present.n");

/* wait */
getchar();
system("Pause");
goto Test;

return 0;

anyway in olly u can Ignore this exception and make the software handle this exception ,but it ur Deubger x64_dbg (x32) ,I think ur deubgger not see this exception at all and not mention it at command bar and pass it so the the
CheckProcessDebugFlags =1 in ur Deubgger .
Lol alot of lab lab ,sorry for bother u .

anyway my Advice is to not ram this (CheckProcessDebugFlags) in Kernel mode ,let keep it in user mode by the debugger it self ,that my opinion .

Thanks again for ur Good work .

[ahmadmansoor]

My friend and about kernel32!CloseHandle it is the same for CheckProcessDebugFlags by Keeping it in User Mode insted of Kernel mode
because some times we need to check this API for other prog so it is not good to make it in Kernel mode ( I think )

http://www.symantec.com/connect/articles/windows-anti-debug-reference
(5) kernel32!CloseHandle and NtClose

APIs making user of the ZwClose syscall (such as CloseHandle, indirectly) can be used to detect a debugger. When a process is debugged, calling ZwClose with an invalid handle will generate a STATUS_INVALID_HANDLE (0xC0000008) exception.

As with all anti-debugs that rely on information made directly available from the kernel (therefore involving a syscall), the only proper way to bypass the "CloseHandle" anti-debug is to either modify the syscall data from ring3, before it is called, or set up a kernel hook.

This anti-debug, though extremely powerful, does not seem to be widely used by malicious programs.

example

__try {
CloseHandle((HANDLE)0x1953);
} __except(1) {
return TRUE;
}

return FALSE;

[mr.exodia]

@ahmadmansoor: How would you fool NtQueryInformationProcess without being in kernel mode? I tried NtSetInformationProcess with the DebugFlag, but I don't think it worked very well...

Notice that not every process is hidden, just the PID you specify.

I agree with you on NtClose though, it could affect performance very badly, if it is done incorrectly. But because it is now an SSDT hook (and later I will also use direct pointers to the original API) it is just a call & check if the current PID is hidden (simple lookup), which doesn't slow down the program.

About the trap flag: I will check this, I think I forward all the non-debugger exceptions to the program (by calling ContinueDebugEvent with the DBG_CONTINUE flag), but I didn't check this for all exceptions yet (GUARD_PAGE for example is now automatically forwarded to the application when it is no memory breakpoint).

Do you have an example for NtClose on x64? I tried many things, but it doesn't seem to work as an anti-debug trick.

Greetings,

Mr. eXoDia

[mr.exodia]

Hi,

I tested this trap flag example, the exception gets reported as first chance (this is supposed to happen for all exceptions) and when you run again, the debugger is NOT detected, which means the exception was forwarded to the application.

The closehandle trick indeed detects x32_dbg... but that's because it forwards the exception to the program (as it's supposed to), but you could write a simple plugin that skips all STATUS_INVALID_HANDLE exceptions (by calling TitanEngine's SetNextContinueStatus function).

What kind of idea(s) do you have for 'keeping things in usermode'? I looked a little around, but it's not possible without hooking in usermode, something I want to avoid.

Greetings

[ahmadmansoor]

hi
this is a Quick solution .
http://fy.chalmers.se/~appro/LD_*-gallery/WINLOGOUT.c

Pls read this too:
http://forum.sysinternals.com/howto-...opic18892.html

So we need to work Get this
ZwDuplicateObject,ZwQueryInformationProcess,ZwQuerySystemInformation
quotation:
An unusual aspect of calling NtQuerySystemInformation with SystemHandleInformation is that if you supply a buffer which is too small, it returns STATUS_INFO_LENGTH_MISMATCH (0xc0000004) instead of giving you the correct buffer size in ReturnLength. This means you will have to guess the buffer size. A common technique is to call NtQuerySystemInformation in a loop until it succeeds with STATUS_SUCCESS (0), reallocating and doubling the buffer size each time it fails with STATUS_INFO_LENGTH_MISMATCH.

/* Dump processes and find this session's CSRSS.EXE */
Let get PID of CSRSS.EXE
then retrieve of ZwQuerySystemInformation and go in a Loop to get compare with STATUS_INFO_LENGTH_MISMATCH ,untill it is not equel
quotation:
After you have the list of handles, you will probably want to get the types and names of the handles. There is no way to do this without duplicating the handle into your own process, so we can do that using DuplicateHandle (NOTE: in the source code I use NtDuplicateObject, but it's the same idea)

after we get a valid not equel STATUS_INFO_LENGTH_MISMATCH
then we go throu this handle table and check OpenProcess if it is not Null
then Close this Handle I think .
By the way mr.exodia I think u don't have to give this care about CloseHandle
because a very rare Protector use this technical .
so it is not a big deal at all ,This is my Opinion .

[mr.exodia]

Hm,

So I would have to enum all handles in order to check if the used handle is valid? Maybe it's easier to remove the exception that is added to the chain after a process to hide and an exception is found.

Maybe it's possible to use NtDuplicateHandle to check if the handle is valid??

I will check all this.

Greetings

[mcp]

@mr.exodia
You might want to look at the implementation of NtClose in ntoskrnl.exe. AFAIR, NtClose raises an exception by means of a user mode call back through ntdll (KiRaiseUserExceptionDispatcher). If you need help with that, just ping me and I'll jump in if you like

@Ahmadmansoor
Not sure if the code you suggested makes sense for the NtClose anti debugging trick since that technique works by closing an invalid handle, so there is no point in enumerating all system handles, no?

Btw, I do agree that NtClose is not really critical, since any decent debugger should allow you to simply swallow the exception and continue execution. As a consequence, the debuggee won't even notice that NtClose raised an exception.
However, VMProtect uses it, so one could argue that this "trick" is somewhat common.

[mr.exodia]

@mcp: yea, my previous implementation was to hook this callback function (returning directlt when the exception came from ntclose), but it doesnt seem like a clean way.

Jump in if you want I can give yoy write accws to the repo if yoy want

Greetings

[mcp]

After quickly looking at ntsokrnl.exe in IDA it seems that the function that raises the exception in user mode is indeed KeRaiseUserException (which in turn redirects control flow via the trap frame to its user mode equivalent: KiRaiseUserExceptionDispatcher in ntdll, which in turn will simply call the RaiseException user mode API IIRC).

So the control flow actually works like this:
When NtClose is invoked it will actually let ObpCloseHandle do all the dirty work. This function does some checks on the handle, and the current process state and then attempts to close the given handle.
This function will then invoke KeRaiseUserException if the given handle is invalid, was passed in from user mode (and is not a process/thread handle), and the debug port in PEPROCESS of the current process is set. So by setting this flag to NULL, you should be able to silence the exception in user mode.
However, I'm not sure what other side effects this might have! Does the debugger continue to work afterwards? That would require some testing I guess ;-)

[mr.exodia]

@mcp:

Today I tested setting the DebugPort to 0 in the PEPROCESS structure, it works fine like this:

ULONG pid=(ULONG)PsGetCurrentProcessId();
    NTSTATUS ret;
    if(HiderIsHidden(pid, HideNtClose))
    {
        Log("[TITANHIDE] NtClose by %d\n", pid);
        PVOID OldDebugPort=SetDebugPort(PsGetCurrentProcess(), 0);
        ret=NtClose(Handle);
        SetDebugPort(PsGetCurrentProcess(), OldDebugPort);
    }
    else
        ret=NtClose(Handle);

There is however a problem, which is that the EPROCESS structure according to http://www.nirsoft.net/kernel_struct/vista/EPROCESS.html doesn't seem to work on windows XP (it's a vista structure definition). I think I need to install every OS to check the structure definitions using WinDbg...

And about:

Btw, I do agree that NtClose is not really critical, since any decent debugger should allow you to simply swallow the exception and continue execution. As a consequence, the debuggee won't even notice that NtClose raised an exception.

I don't agree at all, a decent debugger passes all unhandled exceptions back to the original program. It would be easy to detect if a debugger doesn't pass the 0xC0000008 exception, by simply throwing it yourself. It would require hooking NtClose in usermode for this trick to work and hooking in usermode is something I want to avoid.

Greetings

[Insid3Code]

There is however a problem, which is that the EPROCESS structure according to http://www.nirsoft.net/kernel_struct/vista/EPROCESS.html doesn't seem to work on windows XP (it's a vista structure definition). I think I need to install every OS to check the structure definitions using WinDbg...

Windows XP SP3 X86
0x0BC DebugPort
Windows 7 SP1 X86
0x0EC DebugPort
Windows 7 SP1 X64
0x1F0 DebugPort

[mr.exodia]

@Insid3Code: Thanks! I will add these to the function...

Greetings

[mr.exodia]

Also found these:
Vista x86: 0xD4
Vista x64: 0x150
xp x86: 0xBC
xp x64: 0x148

[mcp]

Well, you can of course throw the exception yourself to test if this exception is always swallowed. However, I don't know any malware/packer that does this, so right now one could argue that hooking NtClose is more of a "comfort feature" than a requirement for an anti-anti-debugging plugin/driver. Issue is that the offset is very much kernel dependent, and therefore dealing with NtClose is quite brittle.
Anyways, glad, the DebugPort patching works ;-)