Hi group,

Is it possible to hide a process in Windows NT/2000/XP from Window Task Manager invoked by ctrl-alt-del? Trick using RegisterServiceProcess seems only works for Win95/98/ME.

Posted on 2004-12-26 19:46:37 by Rulan
Try giving us a reason why you want to hide your process?
Posted on 2004-12-26 20:01:13 by f0dder
Try giving us a reason why you want to hide your process?

I'm building a file monitor for auditing files that accessed by user. I need to prevent user of knowing that they're monitored and killing the process.
Posted on 2004-12-26 20:14:01 by Rulan
If you know how to create a 2000/XP file monitor, you know how to hide the process. Solve the first problem and the other will be solved automatically :-D

Anyway, is device driver programming :o

Posted on 2004-12-27 03:34:45 by Opcode
I'm from Russia and speak English not so well. Forgive for my English. :-)

Yes, it is possible. It is necessary to make a hook for all functions like GetModuleBaseName of a toolhelp32 set. If the parameter hModule is equal GetModuleHandle(NULL) then we write to parameter lpBaseName something like svchost.exe, differently is caused original GetModuleBaseName. Making of a hooks is in detail described in the book " Programming Applications for Microsoft Windows " by J. Richter.
Posted on 2004-12-31 11:40:50 by L0nG
Would be bad and insecure to hook all the win32 APIs like that - hook the kernel.
Posted on 2004-12-31 19:40:52 by f0dder
Would be bad and insecure to hook all the win32 APIs like that - hook the kernel.

Would you please show me how to do that briefly? (hook the kernel)

I still need to hide my user-mode process, since I design to build a user mode app handled data passed from the kernel mode file monitor.

thanks in advance
Posted on 2004-12-31 20:06:59 by Rulan
I could not understand up to the end with it. The essence consists in rewriting import tables of modules which use intercepted functions. Directly in memory of course.
I can offer an example from Richter's book illustrating hooking of API-functions. It's written in C++. It's consists of simple executable module (your user-mode app, for example) and dll which contains all general code for hooking.
Posted on 2005-01-01 09:44:30 by L0nG
thanks Long, for sharing the trick. I'll take a look at it.
Posted on 2005-01-01 17:36:12 by Rulan
Process Hide v1.0

by 90210//HI-TECH

0. Abstract

"Phide" (process hide) is the engine for the low level process manipulating on kernel level, designed to be used by a userland process. It supports only nt-based systems (NT4, 2k, XP, 2k3). Process management is done through the playing with EPROCESS structures. Thread that calls engine MUST have read/write access to \Device\PhysicalMemory, otherwise engine will fail.

1. Features

The engine main features are:
- get EPROCESS offset for a given pid.
- hide the selected process by excluding its EPROCESS from the most low-level kernel process list, which starts from PsActiveProcessHead symbol.
- change selected process image name in run-time.
- patch UniqueProcess field in all ETHREADs that belong to the selected process to hide it from klister-like tools.
- process can be selected by pid or directly by its EPROCESS structure. This is useful when process is already hidden and you have to hide new thread from klister, because even one thread with a real pid of its process-creator will compromise the whole process.

Process hiding technique is the same, as in the 'fu' rootkit, but my goal was to make a small engine callable from r3. For now it's the only tool, which hides processes from klister (i have version 0.3 of this brilliant software).

Engine code doesn't rely on the hardcoded ntoskrnl offsets, that may vary from one servicepack to another. It only relays on the offsets of the needed EPROCESS and EHTREADS fields, because these structs are different in 4 types of nt-based oses.

2. Usage

ProcessHide proc dwProcess2Hide:DWORD,\

Function format is STDCALL.


Specifies the process. May be PID or pointer to EPROCESS structure. When setting dwProcess2Hide to pid, the PH_PROCESS_BY_PID flag must be set. Otherwise, set PH_PROCESS_BY_EPROCESS flag.

Specifies what engine should do with selected process and how it should interpret dwProcess2Hide parameter. dwFlags may be a combination of following flags:

dwProcess2Hide is a PID.

dwProcess2Hide points to a EPROCESS structure.

Hide specified process by excluding its EPROCESS from the EPROCESS linked list, which start from PsActiveProcessHead.

Enumerate all threads that belong to specified process, change their creator's pid to 8 (System process) and set process' image file name to 'System'. This is done to avoid detecting hidden process by klister tool.

Changes image file name of the specified process. Name is set to pNewImgName. Note that on XP and above process image name will not increase its length - if user supplied name is longer than current image name, it will be truncated.

Points to a null-terminated ANSI string that will be set as a process image filename if PH_CHANGE_IMGNAME flag is set. Ignored otherwise.

Points to DWORD that the engine sets to the found process' EPROCESS pointer. May be NULL if EPROCESS offset is not needed.

Return valules
If the engine succeeds, the return value is zero. If the engine fails for some reason, return value will be one of the following:

An exception occured somewhere in the engine while working.

Engine couldn't find process with specified PID or specified EPROCESS seems to be invalid.

Flag PH_CHANGE_IMGNAME is set but pNewImgName is NULL.

One of the VirtualAlloc engine calls has failed.

Engine couldn't find ntoskrnl imagebase. Strange.

\Device\PhysicalMemory is protected by some security program or you haven't enough privileges to open it. By default, only admins can do that.

Internal engine error: it couldn't load ntoskrnl image for further analysis. Strange.

Engine failed to find PsActiveProcessHead offset in ntoskrnl.

Engine couldn't map a region of physical memory to some userland region. Usually happens in VMWare systems.

R0 code and data pages couldn't be locked for some reason.

All GDT entries are present (bit P set). Strange.

Only NT4, 2k, XP and 2k3 server are supported.


Use PH_CHANGE_THREADS_PID very carefully. After this operation threads will "disconnect" from csrss - console output will be trashed. GUI processes may cause bsod on their ExitProcess.
Note that XP and 2k3 don't set EPROCESS SE AUDIT PROCESS CREATION INFO ImageFileName field before first thread start - they do that "a bit later", so don't expect that PH_CHANGE_IMGNAME call will succesfully change the name of the newly created process.
Posted on 2005-01-02 09:24:10 by dcskm4200
Holy_father has written two great articles on this subject...
Invisibility on NT boxes:
Hooking Windows API:
Posted on 2005-01-02 10:06:00 by dev_zero

Now ROOTKIT technology discussion is allowed in this forum?

Great news! :roll:

I didn't knew that the forum rules allowed this, because just by talking about the kernel in this forum has made general posts being deleted...
Posted on 2005-01-02 16:10:18 by Opcode
"Everyone has the right to freedom of opinion and expression;
this right includes freedom to hold opinions without interference
and to seek, receive and impart information and ideas througt
any media and regardless of frontiers."
Article 19 of "Universal Declaration of Human Rights"
Posted on 2005-01-07 06:16:46 by etn
"Everyone has the right to freedom of opinion and expression;
this right includes freedom to hold opinions without interference
and to seek, receive and impart information and ideas througt
any media and regardless of frontiers."
Article 19 of "Universal Declaration of Human Rights"

Try to post something related to virus/warez/crackz to see if the moderators will agree with you :-D
Posted on 2005-01-07 06:34:49 by Opcode
I'm going to add Article 19 to the splashscreen of my p2p :)
Posted on 2005-01-09 07:22:56 by Homer