Exetools - TitanHide

Page 1 of 2

Show 40 post(s) from this thread on one page

Exetools (https://forum.exetools.com/index.php)

- Community Tools (https://forum.exetools.com/forumdisplay.php?f=47)

- - TitanHide (https://forum.exetools.com/showthread.php?t=15569)

mr.exodia

01-26-2014 22:59

TitanHide

1 Attachment(s)

Code:

Overview:



TitanHide is a driver intended to hide debuggers from certain processes.

The driver hooks various Nt* kernel functions (using inline hooks at the

moment) and modifies the return values of the original functions.

To hide a process, you must pass a simple structure with a ProcessID and

the hiding option(s) to enable to the driver. The internal API is

designed to add hooks with little effort, which means adding features

is really easy.



Features:



- ProcessDebugFlags (NtQueryInformationProcess)

- ProcessDebugPort (NtQueryInformationProcess)

- ProcessDebugObjectHandle (NtQueryInformationProcess)

- DebugObject (NtQueryObject)

- SystemKernelDebuggerInformation (NtQuerySystemInformation)

- NtClose (STATUS_INVALID_HANDLE exception)

- ThreadHideFromDebugger (NtSetInformationThread)



Test environments:



- Windows 7 x64 (SP1)

- Windows XP x86 (SP3)

- Windows XP x64 (SP1)



Installation:



1) Copy TitanHide.sys to %systemroot%\system32\drivers

2) Start 'loader.exe' (available on the download page)

3) Delete the old service (when present)

4) Install a new service

5) Start driver

6) Use 'TitanHideGUI.exe' to set hide options



NOTE: When on x64, you have to disable PatchGuard and driver signature

      enforcement yourself. Google is your friend :)

Repository:
https://bitbucket.org/mrexodia/titanhide/

Downloads:
https://bitbucket.org/mrexodia/titanhide/downloads

Feel free to report bugs and/or request features.

Greetings,

Mr. eXoDia

ahmadmansoor

01-27-2014 05:04

u r very fast man ......:eek:
I begin feel as the clock has stop here :D .
today I have install win 7.0 x64 on vmw.
Thanks for ur great work

mr.exodia

01-28-2014 00:17

Quote:

Originally Posted by ahmadmansoor (Post 89630)

u r very fast man ......:eek:
I begin feel as the clock has stop here :D .
today I have install win 7.0 x64 on vmw.
Thanks for ur great work

Hehe, you can join in if you like :)

Attached V0002, fixed some bugs with UNICODE_STRING (pointed out by deepzero)

cxj98

01-28-2014 12:48

how can i get your latest build x64dbg with compiled exe?

mr.exodia

01-28-2014 15:05

Quote:

Originally Posted by cxj98 (Post 89640)

how can i get your latest build x64dbg with compiled exe?

Hi, it would be better to ask this in the 'x64_dbg' topic :) But I will upload a dev build (it's not stable though..)

Sigma is currently unavailable, so the dump window works, but still needs some improvements.

Greetings

ferrit.rce

01-29-2014 02:27

Cool :) How works it together with patchguard? SSDT hooking is being wathed there...

mr.exodia

01-29-2014 02:28

Hi,

It doesn't work with patchguard :) and no ssdt hooking aswell :D

Greetings

ferrit.rce

01-29-2014 02:59

I thought you've found the holy grail and it works :) That was the reason why I've designed out the driver based protection from OllyExt. BTW I've made big steps to make my plugin multi-debugger capable. If you make a plugin framework for your debugger then I could make an X64DbgExt ;)

mr.exodia

01-29-2014 03:05

Quote:

Originally Posted by ferrit.rce (Post 89652)

I figured out how to do SSDT hooking (still with PatchGuard & Driver signing disabled), but it is very unstable, because the addresses are relative. It requires a memory page withing 128MB range of ntoskrnl. This is sometimes possible, but not always unfortunately.

The debugger has a plugin framework, but I don't know if it is good enough to support your needs, could you maybe PM me what kind of stuff you need? I will work on that.

Greetings

mr.exodia

01-31-2014 04:07

Hi everyone,

V0003 is out.

Changelog:
- SSDT hooks instead of inline hooks
- fixed the bug reported by Insid3Code
- many small fixes

Greetings,

Mr. eXoDia

mr.exodia

01-31-2014 05:41

A new hotfix V0004:

- support for different kernel names
- added log file (always in C:\TitanHide.log)

When you find a bug, please include the log file + crash dumps...

Greetings,

Mr. eXoDia

mcp	01-31-2014 05:46

1 Attachment(s)

Had a quick look at the source code. You have a potential infinite loop in this code in hider.cpp

Code:

//simple locking library

static bool locked=false;



static void lock()

{

    while(locked);

    locked=true;

}

if locked is true upon entry, then this is an infinite loop because locked is not declared volatile. An optimizing compiler will thus only fetch memory once, but not repeatedly in the loop.
The disassembly confirms this (see screenshot).

mr.exodia

01-31-2014 05:53

Quote:

Originally Posted by mcp (Post 89675)

Had a quick look at the source code. You have a potential infinite loop in this code in hider.cpp

Code:

//simple locking library

static bool locked=false;



static void lock()

{

    while(locked);

    locked=true;

}

Yes, you're right :) Will be fixed in the next release.

mr.exodia

02-03-2014 05:05

Released a fixed binary (V0005), thanks to mcp!

mr.exodia

02-04-2014 03:22

Released V0006

Fixed the UNICODE_STRING issue (reported by Insid3Code, thanks!)

Tested on Win7x64 and WinXPx86 (SP3), no freezes, no BSOD (before I indeed got a BSOD on the WinXP machine)

Greetings,

Mr. eXoDia

mr.exodia

02-05-2014 06:11

1 Attachment(s)

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

02-05-2014 08:24

1 Attachment(s)

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 :eek: .

Quote:

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

Quote:

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

02-05-2014 10:27

kernel32!CloseHandle

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 )

Quote:

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

Quote:

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

return FALSE;

mr.exodia

02-05-2014 18:42

@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

02-06-2014 02:42

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

02-06-2014 04:38

1 Attachment(s)

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 :rolleyes: .
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

02-06-2014 05:39

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	02-06-2014 06:20

@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

02-06-2014 06:34

@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	02-06-2014 07:22

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

02-08-2014 20:59

@mcp:

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

Code:

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:

Quote:

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

02-08-2014 21:48

Quote:

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

mr.exodia

02-08-2014 22:08

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

Greetings

mr.exodia

02-08-2014 23:49

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

mcp	02-09-2014 01:36

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 ;-)

besoeso

02-09-2014 04:03

@Insid3Code

do you know codes for DeviceIoControl funtion???

mr.exodia

02-09-2014 04:11

Quote:

Originally Posted by besoeso (Post 89862)

@Insid3Code

do you know codes for DeviceIoControl funtion???

For TitanHide there are no such codes, you should take a look at TitanHideGUI: https://bitbucket.org/mrexodia/titanhide/src/d3168decc80020c36f6402cebf4a18bcbe34869a/TitanHideGUI/main.cpp?at=master

Greetings

mr.exodia

02-09-2014 04:15

Changelog V0008l:
- re-added NtClose, not working on Windows Server 2012, Windows 8 and Windows 8.1

Greetings,

Mr. eXoDia

Insid3Code

02-09-2014 23:08

Quote:

Originally Posted by besoeso (Post 89862)

@Insid3Code

do you know codes for DeviceIoControl funtion???

You mean IoControlCode passed as parameter or (GetLastError code) formatted messages to display ?

@Mr. eXoDia
another hardcoded offset:
Windows 8 SP0 X86
0x154 DebugPort
Windows 8 SP0 X64
0x2F8 DebugPort
Windows 8 SP1 X64
0x410 DebugPort

mr.exodia

02-09-2014 23:32

@Insid3Code: Thanks a lot!

V0009 released:
- changed logging behavior
- added offsets for windows 8 and server 2012 (2012 not tested)

Greetings,

Mr. eXoDia

mcp	02-10-2014 07:13

@mr.exodia
If you want a more robust implementation, I would recommend that you let your driver determine the OS specific offset by itself, i.e. let it disassemble the kernel function PsGetProcessDebugPort. You could do that like this:
a) determine function boundaries, i.e. disassemble all instructions from start of the function until ret.
b) go backwards starting at ret until you find the first instruction that writes to eax/rax. The immediate in the source operand expression should be the offset you're looking for.

mr.exodia

02-15-2014 18:31

V0010 Released:
- dynamic retrieval of DebugPortOffset (thanks to mcp!)
- added some alternative code for NtClose (thanks to ahmadmansoor!)
- also updated the TitanHide plugin for x64_dbg

Greetings,

Mr. eXoDia

mr.exodia

03-16-2014 21:34

1 Attachment(s)

TitanHide plugins:
- OllyDbg v1.10
- OllyDbg v2.01
- TitanEngine (x86 + x64)
- x64_dbg (x32 + x64)

Attached a full archive, latest versions can be downloaded from https://bitbucket.org/mrexodia/titanhide/downloads

Plugins features will not be extended, but I will fix any bugs you find.

Greetings,

Mr. eXoDia

mr.exodia

02-02-2015 04:55

V0012 Released:
- fixed weird BSOD with NtQueryInformationProcess
- better installation guide
- various code fixes

Source:
https://bitbucket.org/mrexodia/titanhide

Download:
https://bitbucket.org/mrexodia/titanhide/downloads

Greetings,

Mr. eXoDia

mr.exodia

02-02-2015 04:55

All times are GMT +8. The time now is 00:28.

Page 1 of 2

Show 40 post(s) from this thread on one page