=========================[ Invisibility on NT boxes ]===========================
How to become unseen on Windows NT
----------------------------------
Author: Holy_Father <holy_father@phreaker.net>
Version: 1.2 english
Date: 05.08.2003
Web: http://www.hxdef.org, http://hxdef.net.ru,
http://hxdef.czweb.org, http://rootkit.host.sk
Link: http://www.rootkit.com
=====[ 1. Contents ]============================================================
1. Contents
2. Introduction
3. Files
3.1 NtQueryDirectoryFile
3.2 NtVdmControl
4. Processes
5. Registry
5.1 NtEnumerateKey
5.2 NtEnumerateValueKey
6. System services and drivers
7. Hooking and spreading
7.1 Rights
7.2 Global hook
7.3 New processes
7.4 DLL
8. Memory
9. Handle
9.1 Naming handle and getting type
10. Ports
10.1 Netstat, OpPorts on WinXP, FPort on WinXP
10.2 OpPorts on Win2k and NT4, FPort on Win2k
11. Ending
=====[ 2. Introduction ]========================================================
This document is about technics of hiding objects, files, services,
processes etc. on OS Windows NT. These methods are based on hooking Windows API
functions which are described in my document "Hooking Windows API".
Everything here was get from my own research during writing rootkit
code, so there is a chance it can be written more effectively or it can be
written much more easily. This also involve my implementation.
Hiding arbitrary object in this document mean to change some system
functions which name this object in the way they would skip its naming. In
the case this object is only return value of that function we would return
value as the object does not exist.
Basic method (excluding cases of telling different) is that we would
call original function with original arguments and then we would change its
output.
In this version of this text are described methods of hiding files,
processes, keys and values in registry, system services and drivers, allocated
memory and handles.
=====[ 3. Files ]===============================================================
There are serveral possibilities of hiding files in the way OS would
not see it. We would aim only changing API and leave out technics like those
which play on features of filesystem. It also is much easier because we dont
need to know how particular filesystem works.
=====[ 3.1 NtQueryDirectoryFile ]===============================================
Looking for a file on wNT in some directory is based on searching in
all its files and files in all its subdirectories. For file enumeration is used
function NtQueryDirectoryFile.
NTSTATUS NtQueryDirectoryFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID FileInformation,
IN ULONG FileInformationLength,
IN FILE_INFORMATION_CLASS FileInformationClass,
IN BOOLEAN ReturnSingleEntry,
IN PUNICODE_STRING FileName OPTIONAL,
IN BOOLEAN RestartScan
);
Important parameters for us are FileHandle, FileInformation
and FileInformationClass. FileHandle is a handle of directory object which
can be get from NtOpenFile. FileInformation is a pointer on allocated memory,
where this function write wanted data to. FileInformationClass determines type
of record written in FileInformation.
FileInformationClass is varied enumerative type, but we need only
four values which are used for enumerating directory content:
#define FileDirectoryInformation 1
#define FileFullDirectoryInformation 2
#define FileBothDirectoryInformation 3
#define FileNamesInformation 12
structure of recoed written in FileInformation for FileDirectoryInformation:
typedef struct _FILE_DIRECTORY_INFORMATION {
ULONG NextEntryOffset;
ULONG Unknown;
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
LARGE_INTEGER EndOfFile;
LARGE_INTEGER AllocationSize;
ULONG FileAttributes;
ULONG FileNameLength;
WCHAR FileName[1];
} FILE_DIRECTORY_INFORMATION, *PFILE_DIRECTORY_INFORMATION;
for FileFullDirectoryInformation:
typedef struct _FILE_FULL_DIRECTORY_INFORMATION {
ULONG NextEntryOffset;
ULONG Unknown;
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
LARGE_INTEGER EndOfFile;
LARGE_INTEGER AllocationSize;
ULONG FileAttributes;
ULONG FileNameLength;
ULONG EaInformationLength;
WCHAR FileName[1];
} FILE_FULL_DIRECTORY_INFORMATION, *PFILE_FULL_DIRECTORY_INFORMATION;
for FileBothDirectoryInformation:
typedef struct _FILE_BOTH_DIRECTORY_INFORMATION {
ULONG NextEntryOffset;
ULONG Unknown;
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
LARGE_INTEGER EndOfFile;
LARGE_INTEGER AllocationSize;
ULONG FileAttributes;
ULONG FileNameLength;
ULONG EaInformationLength;
UCHAR AlternateNameLength;
WCHAR AlternateName[12];
WCHAR FileName[1];
} FILE_BOTH_DIRECTORY_INFORMATION, *PFILE_BOTH_DIRECTORY_INFORMATION;
and for FileNamesInformation:
typedef struct _FILE_NAMES_INFORMATION {
ULONG NextEntryOffset;
ULONG Unknown;
ULONG FileNameLength;
WCHAR FileName[1];
} FILE_NAMES_INFORMATION, *PFILE_NAMES_INFORMATION;
This function writes a list of these structures in FileInformation.
Only three vairiables are important for us in any of these structure types.
NextEntryOffset is the length of particular list item. First item
can be found on address FileInformation + 0. So the second item is on address
FileInformation + NextEntryOffset of first one. Last item has NextEntryOffset
set on zero.
FileName is a full name of the file.
FileNameLength is a length of file name.
If we want to hide a file, we need to tell apart these four types
and for each returned record we need to compare its name with the one which
we want to hide. If we want to hide first record, we have to move following
structures by the size of the first. This will cause the first record would
be rewritten. If we want to hide another record, we can easily change the value
of NextEntryOffset of previous record. New value of NextEntryOffset would be
zero if we want to hide the last record, otherwise the value would be the sum
of NextEntryOffset of the record we want to hide and of previous record.
Then we should change the value of Unknown of previous record which is prolly
an index for next search. The value of Unknown of previous record should have
a value of Unknown of the record we want hide.
If no record which should be seen was found, we will return error
STATUS_NO_SUCH_FILE.
#define STATUS_NO_SUCH_FILE 0xC000000F
=====[ 3.2 NtVdmControl ]=======================================================
From unknown reason DOS emulation NTVDM can get a list of files also
with function NtVdmContol.
NTSTATUS NtVdmControl(
IN ULONG ControlCode,
IN PVOID ControlData
);
ControlCode specifies the subfunction which is applied on data in
ControlData buffer. If ControlCode equals to VdmDirectoryFile this function
does the same as NtQueryDirectoryFile with FileInformationClass set on
FileBothDirectoryInformation.
#define VdmDirectoryFile 6
Then ControlData is used like FileInformation. The only difference here
is that we do not know the length of this buffer. So we have to count it
manually. We have to add NextEntryOffset of all records and FileNameLength
of the last record and 0x5E as a length of the last record excluding the name
of the file. Hiding methods are the same as in NtQueryDirectoryFile then.
=====[ 4. Processes ]===========================================================
Various system info is available using NtQuerySystemInformation.
NTSTATUS NtQuerySystemInformation(
IN SYSTEM_INFORMATION_CLASS SystemInformationClass,
IN OUT PVOID SystemInformation,
IN ULONG SystemInformationLength,
OUT PULONG ReturnLength OPTIONAL
);
SystemInformationClass specifies the type of information which we want
to get, SystemInformation is a pointer to the function output buffer,
SystemInformationLength is the length of this buffer and ReturnLength is
number of written bytes.
For the enumeration of running processes we use SystemInformationClass
set on SystemProcessesAndThreadsInformation.
#define SystemInformationClass 5
Returned structure in SystemInformation buffer is:
typedef struct _SYSTEM_PROCESSES {
ULONG NextEntryDelta;
ULONG ThreadCount;
ULONG Reserved1[6];
LARGE_INTEGER CreateTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER KernelTime;
UNICODE_STRING ProcessName;
KPRIORITY BasePriority;
ULONG ProcessId;
ULONG InheritedFromProcessId;
ULONG HandleCount;
ULONG Reserved2[2];
VM_COUNTERS VmCounters;
IO_COUNTERS IoCounters; // Windows 2000 only
SYSTEM_THREADS Threads[1];
} SYSTEM_PROCESSES, *PSYSTEM_PROCESSES;
Hiding processes is similiar as in the case of hiding files.
We have to change NextEntryDelta of previous record of that we want to hide.
Usually we will not want to hide the first record here because it is Idle
process.
=====[ 5. Registry ]============================================================
Windows registry is quite big tree structure containing two important
types of records for us which we could want to hide. First type is registry
keys, second is values. Owing to registry structure hiding registry keys is
not as trivial as hiding file or process.
=====[ 5.1 NtEnumerateKey ]=====================================================
Owing to its structure we are not able to ask for a list of all keys
in the specific part of registry. We can get only information about one key
specified by its index in some part of registry. This provides NtEnumerateKey.
NTSTATUS NtEnumerateKey(
IN HANDLE KeyHandle,
IN ULONG Index,
IN KEY_INFORMATION_CLASS KeyInformationClass,
OUT PVOID KeyInformation,
IN ULONG KeyInformationLength,
OUT PULONG ResultLength
);
KeyHandle is a handle to a key in which we want to get information
about a subkey specified by Index. Type of returned information is specified
by KeyInformationClass. Data are written to KeyInformation buffer which length
is KeyInformationLength. Number of written bytes is returned in ResultLength.
The most important think we need to perceive is that if we hide a key,
indexes of all following keys woould be shifted. And because we are able to get
information about a key with higher index with asking for key with lower index
we always have to count how many records before were hidden and then return
the right one.
Let's have a look on the example. Assume we have some keys called A, B,
C, D, E and F in any part of registry. Indexing starts from zero which mean
index 4 match E key. Now if we want to hide B key and the hooked application
call NtEnumerateKey with Index 4 we should return information about F key
because there is an index shift. The problem is that we don't know that there
is a shift. And if we didn't care about shifting and return E instead of F when
asking for key with index 4 we would return nothing when asking for key with
index 1 or we would return C. Both cases are errors. This is why we have to
care about shifting.
Now if we counted the shift by recalling the function for each index
from 0 to Index we would sometimes wait for ages (on 1GHz processor it could
take up to 10 seconds with standard registry which is too much). So we have to
think out more sophisticated method.
We know that keys are (except of references) sorted alphabetically.
If we neglect references (which we don't want to hide) we can count the shift
by following method. We will sort alphabetically our list of key names which we
want to hide (RtlCompareUnicodeString can be used), then when application calls
NtEnumerateKey we will not recall it with unchanged arguments but we will find
out the name of the record specified by Index.
NTSTATUS RtlCompareUnicodeString(
IN PUNICODE_STRING String1,
IN PUNICODE_STRING String2,
IN BOOLEAN CaseInSensitive
);
String1 and String2 are strings which will be compared, CaseInSensitive
is True if we want to compare with neglecting character case.
Function result describes relation between String1 and String2:
result > 0: String1 > String2
result = 0: String1 = String2
result < 0: String1 < String2
Now we have to find a border. We will compare alphabetically the name of
the key specified by Index with the names in our list. The border would be
the last lesser name from our list. We know that the shift is at most
the number of the border in our list. But not all items from our list have to
be a valid key in the part of registry we are in. So we have to ask for all
items from our list up to border if they are in this part of the registry.
This can be done using NtOpenKey.
NTSTATUS NtOpenKey(
OUT PHANDLE KeyHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes
);
KeyHandle is a handle of superordinate key. We will use the value from
NtEnumerateKey for it. DesiredAccess are access rights. KEY_ENUMERATE_SUB_KEYS
is the right value for it. ObjectAttributes describes subkey which we want to
open (including its name).
#define KEY_ENUMERATE_SUB_KEYS 8
If the result of NtOpenKey is 0 opening was successful which mean this
key from our list exists. Opened key should be closed via NtClose.
NTSTATUS NtClose(
IN HANDLE Handle
);
For each call of NtEnumareteKey we will count the shift as a number of
keys from our list which exist in the given part of registry. Then we will add
this shift to Index argument and finally call the original NtEnumerateKey.
For getting name of the key specified by Index we will use the value
KeyBasicInformation as a KeyInformationClass.
#define KeyBasicInformation 0
NtEnumerateKey returns this structure in KeyInformation:
typedef struct _KEY_BASIC_INFORMATION {
LARGE_INTEGER LastWriteTime;
ULONG TitleIndex;
ULONG NameLength;
WCHAR Name[1];
} KEY_BASIC_INFORMATION, *PKEY_BASIC_INFORMATION;
Only thing we need here is Name and its length NameLength.
If there is no entry for shifted Index we will return error
STATUS_EA_LIST_INCONSISTENT.
#define STATUS_EA_LIST_INCONSISTENT 0x80000014
=====[ 5.2 NtEnumerateValueKey ]================================================
Registry values are not alphabetically sorted. Luckily the number
of values in one key is quite small, so we can use recall method to get
the shift. API for getting info about one value is called NtEnumerateValueKey.
NTSTATUS NtEnumerateValueKey(
IN HANDLE KeyHandle,
IN ULONG Index,
IN KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass,
OUT PVOID KeyValueInformation,
IN ULONG KeyValueInformationLength,
OUT PULONG ResultLength
);
KeyHandle is again a handle of superordinate key. Index is an index
to the list of values in given key. KeyValueInformationClass describes a type
of information which will be stored into KeyValueInformation buffer which
is long KeyValueInformationLength bytes. Number of written bytes is returned
in ResultLength.
Again we have to count the shift but according to the number of values
in one key we can recall this function for all indexes from 0 to Index.
The name of the value can be get when KeyValueInformationClass is set to
KeyValueBasicInformation.
#define KeyValueBasicInformation 0
Then we will get following structure in KeyValueInformation buffer:
typedef struct _KEY_VALUE_BASIC_INFORMATION {
ULONG TitleIndex;
ULONG Type;
ULONG NameLength;
WCHAR Name[1];
} KEY_VALUE_BASIC_INFORMATION, *PKEY_VALUE_BASIC_INFORMATION;
Again we are interested only in Name and NameLength.
If there is no entry for shifted Index we will return error
STATUS_NO_MORE_ENTRIES.
#define STATUS_NO_MORE_ENTRIES 0x8000001A
=====[ 6. System services and drivers ]=========================================
System services and drivers are enumerated by four independent API
functions. Their connections is different in each Windows version. That's why
we have to hook all four functions.
BOOL EnumServicesStatusA(
SC_HANDLE hSCManager,
DWORD dwServiceType,
DWORD dwServiceState,
LPENUM_SERVICE_STATUS lpServices,
DWORD cbBufSize,
LPDWORD pcbBytesNeeded,
LPDWORD lpServicesReturned,
LPDWORD lpResumeHandle
);
BOOL EnumServiceGroupW(
SC_HANDLE hSCManager,
DWORD dwServiceType,
DWORD dwServiceState,
LPBYTE lpServices,
DWORD cbBufSize,
LPDWORD pcbBytesNeeded,
LPDWORD lpServicesReturned,
LPDWORD lpResumeHandle,
DWORD dwUnknown
);
BOOL EnumServicesStatusExA(
SC_HANDLE hSCManager,
SC_ENUM_TYPE InfoLevel,
DWORD dwServiceType,
DWORD dwServiceState,
LPBYTE lpServices,
DWORD cbBufSize,
LPDWORD pcbBytesNeeded,
LPDWORD lpServicesReturned,
LPDWORD lpResumeHandle,
LPCTSTR pszGroupName
);
BOOL EnumServicesStatusExW(
SC_HANDLE hSCManager,
SC_ENUM_TYPE InfoLevel,
DWORD dwServiceType,
DWORD dwServiceState,
LPBYTE lpServices,
DWORD cbBufSize,
LPDWORD pcbBytesNeeded,
LPDWORD lpServicesReturned,
LPDWORD lpResumeHandle,
LPCTSTR pszGroupName
);
The most important here is lpServices which points on the buffer where
the list of services would be stored. And also lpServicesReturned pointing on
the number of records in result is important. Structure of data in the output
buffer depends on the type of function. For functions EnumServicesStatusA
and EnumServicesGroupW is returned structure
typedef struct _ENUM_SERVICE_STATUS {
LPTSTR lpServiceName;
LPTSTR lpDisplayName;
SERVICE_STATUS ServiceStatus;
} ENUM_SERVICE_STATUS, *LPENUM_SERVICE_STATUS;
typedef struct _SERVICE_STATUS {
DWORD dwServiceType;
DWORD dwCurrentState;
DWORD dwControlsAccepted;
DWORD dwWin32ExitCode;
DWORD dwServiceSpecificExitCode;
DWORD dwCheckPoint;
DWORD dwWaitHint;
} SERVICE_STATUS, *LPSERVICE_STATUS;
for EnumServicesStatusExA a EnumServicesStatusExW it it
typedef struct _ENUM_SERVICE_STATUS_PROCESS {
LPTSTR lpServiceName;
LPTSTR lpDisplayName;
SERVICE_STATUS_PROCESS ServiceStatusProcess;
} ENUM_SERVICE_STATUS_PROCESS, *LPENUM_SERVICE_STATUS_PROCESS;
typedef struct _SERVICE_STATUS_PROCESS {
DWORD dwServiceType;
DWORD dwCurrentState;
DWORD dwControlsAccepted;
DWORD dwWin32ExitCode;
DWORD dwServiceSpecificExitCode;
DWORD dwCheckPoint;
DWORD dwWaitHint;
DWORD dwProcessId;
DWORD dwServiceFlags;
} SERVICE_STATUS_PROCESS, *LPSERVICE_STATUS_PROCESS;
We are interested only in lpServiceName which is the name of system
service. Records have static size, so if we want to hide one we will move all
following records by its size. Here we have to differentiate between the size
of SERVICE_STATUS and SERVICE_STATUS_PROCESS.
=====[ 7. Hooking and spreading ]===============================================
To get the desiderative efect we have to hook all running processes
and also all processes which would be created later. New processes should be
hooked before running their first instruction of their own code otherwise
they would be able to see our hidden objects in the time before they would be
hooked.
=====[ 7.1 Rights ]=============================================================
At first it is good to know that we need at least administrators rights
to get access to all running processes. The best possibility is to run our
process as system service which run on user SYSTEM. To install the service we
also need special rights.
Also getting SeDebugPrivilege is very useful. This can be done using
API OpenProcessToken, LookupPrivilegeValue and AdjustTokenPrivileges.
BOOL OpenProcessToken(
HANDLE ProcessHandle,
DWORD DesiredAccess,
PHANDLE TokenHandle
);
BOOL LookupPrivilegeValue(
LPCTSTR lpSystemName,
LPCTSTR lpName,
PLUID lpLuid
);
BOOL AdjustTokenPrivileges(
HANDLE TokenHandle,
BOOL DisableAllPrivileges,
PTOKEN_PRIVILEGES NewState,
DWORD BufferLength,
PTOKEN_PRIVILEGES PreviousState,
PDWORD ReturnLength
);
Neglecting errors the code can look like this:
#define SE_PRIVILEGE_ENABLED 0x0002
#define TOKEN_QUERY 0x0008
#define TOKEN_ADJUST_PRIVILEGES 0x0020
HANDLE hToken;
LUID DebugNameValue;
TOKEN_PRIVILEGES Privileges;
DWORD dwRet;
OpenProcessToken(GetCurrentProcess(),
TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY,hToken);
LookupPrivilegeValue(NULL,"SeDebugPrivilege",&DebugNameValue);
Privileges.PrivilegeCount=1;
Privileges.Privileges[0].Luid=DebugNameValue;
Privileges.Privileges[0].Attributes=SE_PRIVILEGE_ENABLED;
AdjustTokenPrivileges(hToken,FALSE,&Privileges,sizeof(Privileges),
NULL,&dwRet);
CloseHandle(hToken);
=====[ 7.2 Global hook ]========================================================
Enumeration of processes is done by already metioned API function
NtQuerySystemInformation. There are few native processes in the system, so we
will use the method of rewriting first instructions of the function to hook
them. For each running process we will do the same. We will allocate a part
of memory in target process where we will write our new code for functions
we want to hook. Then we will change the first five bytes of these functions
with jmp instruction. This jump will redirect the execution to our code.
So the jmp instruction will be executed immediately when the hooked function is
called. We have to save first instructions of each function which is rewritten.
We need them to call original code of the hooked function. Saving instructions
is described in chapter 3.2.3 in the document "Hooking Windows API".
At first we have to open target process via NtOpenProcess and get
the handle. This will fail if we don't have enough rights.
NTSTATUS NtOpenProcess(
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL
);
ProcessHandle is a pointer on a handle where the result will be stored.
DesiredAccess should be set on PROCESS_ALL_ACCESS. We will set PID of target
process to UniqueProcess part of ClientId structure, UniqueThread should be 0.
Open handle can be always closed via NtClose.
#define PROCESS_ALL_ACCESS 0x001F0FFF
Now we are going to allocate the part of memory for our code. This can
be done using NtAllocateVirtualMemory.
NTSTATUS NtAllocateVirtualMemory(
IN HANDLE ProcessHandle,
IN OUT PVOID BaseAddress,
IN ULONG ZeroBits,
IN OUT PULONG AllocationSize,
IN ULONG AllocationType,
IN ULONG Protect
);
ProcessHandle is the one from NtOpenProcess. BaseAddress is a pointer
on a pointer on the beginning where we want to allocate. Here will be stored
the address of the allocated memory. Input value can be NULL. AllocationSize
is a pointer on number of bytes we want to allocate. And again it is also used
as output value for the real number of allocated bytes. It is good to set
AllocationType to MEM_TOP_DOWN in addition to MEM_COMMIT because the memory
would be allocated on the highest possible address near DLLs.
#define MEM_COMMIT 0x00001000
#define MEM_TOP_DOWN 0x00100000
Then we can write our code there using NtWriteVirtualMemory.
NTSTATUS NtWriteVirtualMemory(
IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
IN PVOID Buffer,
IN ULONG BufferLength,
OUT PULONG ReturnLength OPTIONAL
);
BaseAddress will be that address returned by NtAllocateVirtualMemory.
Buffer points on bytes we want to write, BufferLength is number of bytes we
want to write.
Now we have to hook single functions. Only library which is loaded to
all processes is ntdll.dll. So we have to check if function we want to hook is
imported to the process if it is not from ntdll.dll. But the memory where would
this function (from another DLL) be could be allocated, so rewriting bytes on
its address could easily cause error in target process. This is why we have to
check whether library (where function we want to hook is) is loaded to target
process.
We need to get PEB (Process Environment Block) of target process via
NtQueryInformationProcess.
NTSTATUS NtQueryInformationProcess(
IN HANDLE ProcessHandle,
IN PROCESSINFOCLASS ProcessInformationClass,
OUT PVOID ProcessInformation,
IN ULONG ProcessInformationLength,
OUT PULONG ReturnLength OPTIONAL
);
We will set ProcessInfromationClass to ProcessBasicInformation. Then
the PROCESS_BASIC_INFORMATION structure would be returned to ProcessInformation
buffer which size is given by ProcessInformationLength.
#define ProcessBasicInformation 0
typedef struct _PROCESS_BASIC_INFORMATION {
NTSTATUS ExitStatus;
PPEB PebBaseAddress;
KAFFINITY AffinityMask;
KPRIORITY BasePriority;
ULONG UniqueProcessId;
ULONG InheritedFromUniqueProcessId;
} PROCESS_BASIC_INFORMATION, *PPROCESS_BASIC_INFORMATION;
PebBaseAddress is what we were looking for. On PebBaseAddress+0x0C is
address PPEB_LDR_DATA. This would be get calling NtReadVirtualMemory.
NTSTATUS NtReadVirtualMemory(
IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
OUT PVOID Buffer,
IN ULONG BufferLength,
OUT PULONG ReturnLength OPTIONAL
);
Parameters are similar like in NtWriteVirtualMemory.
On PPEB_LDR_DATA+0x1C is address InInitializationOrderModuleList. It is
the list of libraries loaded to the process. We are interested only in a part
of this structure.
typedef struct _IN_INITIALIZATION_ORDER_MODULE_LIST {
PVOID Next,
PVOID Prev,
DWORD ImageBase,
DWORD ImageEntry,
DWORD ImageSize,
...
);
Next is a pointer on next record, Prev on previous, last record points
on first. ImageBase is an address of module in the memory, ImageEntry is
the EntryPoint of the module, ImageSize is its size.
For all libraries in which we want to hook we will get their ImageBase
(e.g. using GetModuleHandle or LoadLibrary). This ImageBase we will compare
with ImageBase of each entry in InInitializationOrderModuleList.
Now we are ready for hooking. Because we are hooking running processes
there is a possibility that the code we would be executed in the moment we will
be rewriting it. This can cause error, so at first we will stop all threads
in target process. The list of its threads can get via NtQuerySystemInformation
with SystemProcessesAndThreadsInformation class. Result of this function is
described in chapter 4. But we have to add the description of SYSTEM_THREADS
structure where the information about thread is.
typedef struct _SYSTEM_THREADS {
LARGE_INTEGER KernelTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER CreateTime;
ULONG WaitTime;
PVOID StartAddress;
CLIENT_ID ClientId;
KPRIORITY Priority;
KPRIORITY BasePriority;
ULONG ContextSwitchCount;
THREAD_STATE State;
KWAIT_REASON WaitReason;
} SYSTEM_THREADS, *PSYSTEM_THREADS;
For each thread we have to get its handle using NtOpenThread. We will
use ClientId for it.
NTSTATUS NtOpenThread(
OUT PHANDLE ThreadHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId
);
The handle we want will be stored to ThreadHandle. We will set
DesiredAccess to THREAD_SUSPEND_RESUME.
#define THREAD_SUSPEND_RESUME 2
ThreadHandle will be used for calling NtSuspendThread.
NTSTATUS NtSuspendThread(
IN HANDLE ThreadHandle,
OUT PULONG PreviousSuspendCount OPTIONAL
);
Suspended process is ready for rewriting. We will proceed as it is
described in chapter 3.2.2 in "Hooking Windows API". Only difference will be
in using functions for other processes.
After a hook we will revive all process threads calling NtResumeThread.
NTSTATUS NtResumeThread(
IN HANDLE ThreadHandle,
OUT PULONG PreviousSuspendCount OPTIONAL
);
=====[ 7.3 New processes ]======================================================
Infection of all running processes does not affect processes which
would be run later. We could get the process list and after a while get a new
one and compare them and then infect those processes which are in second list
but not in first. But this method is very unreliable.
Much better is to hook function which is always called when new process
starts. Because of hooking all running processes on the system we can't miss
any new with this method. We can hook NtCreateThread but it is not the easiest
way. We will hook NtResumeThread which is also called everytime after the new
process is created. It is called after NtCreateThread.
The only problem with NtResumeThread is that it is called not only when
new process starts. But we can easily get over this. NtQueryInformationThread
will give us an information about which process owns the specific thread.
The last thing we have to do is to check whether this process is already hooked
or not. This can be done by reading first byte of any function we are hooking.
NTSTATUS NtQueryInformationThread(
IN HANDLE ThreadHandle,
IN THREADINFOCLASS ThreadInformationClass,
OUT PVOID ThreadInformation,
IN ULONG ThreadInformationLength,
OUT PULONG ReturnLength OPTIONAL
);
ThreadInformationClass is information class and it should be set in our
case to ThreadBasicInformation. ThreadInformation is the buffer for result
which size is ThreadInformationLength bytes.
#define ThreadBasicInformation 0
For class ThreadBasicInformation is this structure returned:
typedef struct _THREAD_BASIC_INFORMATION {
NTSTATUS ExitStatus;
PNT_TIB TebBaseAddress;
CLIENT_ID ClientId;
KAFFINITY AffinityMask;
KPRIORITY Priority;
KPRIORITY BasePriority;
} THREAD_BASIC_INFORMATION, *PTHREAD_BASIC_INFORMATION;
In ClientId is the PID of which owns the thread.
Now we have to infect the new process. The problem is that the new
process has only ntdll.dll in its memory. All others modules are loaded
immediately after calling NtResumeThread. There are several ways how to handle
this problem. E.g. we can hook API called LdrInitializeThunk which is called
during process init.
NTSTATUS LdrInitializeThunk(
DWORD Unknown1,
DWORD Unknown2,
DWORD Unknown3
);
At first we will run original code and then we will hook all functions
we want in this new process. But it will be better to unhook LdrInitializeThunk
because it is called many times later and we don't want to rehook all functions
again. Everything here is done before execution of the first instruction of
hooked application. That's why there is no chance it would call any of hooked
functions before we hook it.
The hooking in itself is the same as when hooking running process
but here we don't care about running threads.
=====[ 7.4 DLL ]================================================================
In each process in the system is the copy of ntdll.dll. That mean we
can hook any function from this module in the process init. But how about
functions from other modules like kernel32.dll or advapi32.dll? And there are
also several processes which has only ntdll.dll. All other modules can be
loaded dynamically in the middle of the code after the process hook. That's why
we have to hook LdrLoadDll which loades new modules.
NTSTATUS LdrLoadDll(
PWSTR szcwPath,
PDWORD pdwLdrErr,
PUNICODE_STRING pUniModuleName,
PHINSTANCE pResultInstance
);
The most important for us here is pUniModuleName which is the name of
the module. pResultInstance will be filled with its address if the call is
successful.
We will call original LdrLoadDll and then hook all functions in loaded
module.
=====[ 8. Memory ]==============================================================
When we are hooking a function we modify its first bytes. Via calling
NtReadVirtualMemory anyone can detect that a function is hooked. So we have to
hook NtReadVirtualMemory to prevent detecting.
NTSTATUS NtReadVirtualMemory(
IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
OUT PVOID Buffer,
IN ULONG BufferLength,
OUT PULONG ReturnLength OPTIONAL
);
We have changed bytes on the begining of all functions we hooked and
we have also allocated memory for our new code. We should check whether caller
reads some of these bytes. If we have our bytes in the range from BaseAddress
to BaseAddress + BufferLength we have to change some bytes in Buffer.
If one ask for bytes from our allocated memory we should return empty
Buffer and an error STATUS_PARTIAL_COPY. This value says not all requested
bytes were copied to the Buffer. It is also used when asking for unallocated
memory. ReturnLength should be set to 0 in this case.
#define STATUS_PARTIAL_COPY 0x8000000D
If one ask for first bytes of hooked function we have to call original
code and than we should copy original bytes (we have saved them for original
calls) to Buffer.
Now the process is not able to detect he is hooked via reading its
memory. Also if you debug hooked process debugger will have a problem. It will
show original bytes but it will execute our code.
To make hiding perfect we can also hook NtQueryVirtualMemory. This
function is used to get information about virtual memory. We can hook it to
prevent detecting our allocated memory.
NTSTATUS NtQueryVirtualMemory(
IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
IN MEMORY_INFORMATION_CLASS MemoryInformationClass,
OUT PVOID MemoryInformation,
IN ULONG MemoryInformationLength,
OUT PULONG ReturnLength OPTIONAL
);
MemoryInformationClass specifies the class of data which are returned.
First two types are interesting for us.
#define MemoryBasicInformation 0
#define MemoryWorkingSetList 1
For class MemoryBasicInformation is returned this structure:
typedef struct _MEMORY_BASIC_INFORMATION {
PVOID BaseAddress;
PVOID AllocationBase;
ULONG AllocationProtect;
ULONG RegionSize;
ULONG State;
ULONG Protect;
ULONG Type;
} MEMORY_BASIC_INFORMATION, *PMEMORY_BASIC_INFORMATION;
Each memory section has its size RegionSize and its type Type. Free
memory has type MEM_FREE.
#define MEM_FREE 0x10000
If a section before ours has type MEM_FREE we should add the size of
ours section to its RegionSize. If the following section is also MEM_FREE we
should add following section size again that RegionSize.
If a section before ours has another type we will return MEM_FREE
for our section. Its size is counted again according to following section.
For class MemoryWorkingSetList is returned structure:
typedef struct _MEMORY_WORKING_SET_LIST {
ULONG NumberOfPages;
ULONG WorkingSetList[1];
} MEMORY_WORKING_SET_LIST, *PMEMORY_WORKING_SET_LIST;
NumberOfPages is the number of items in WorkingSetList. This number
should be decreased. We should find ours section in WorkingSetList and move
following records over ours. WorkingSetList is an array of DWORDs where higher
20 bits specifies higher 20 bits of section address and lower 12 bits specifies
flags.
=====[ 9. Handle ]==============================================================
Calling NtQuerySystemInformation with SystemHandleInformation class
gives us array of all open handles in _SYSTEM_HANDLE_INFORMATION_EX strucure.
#define SystemHandleInformation 0x10
typedef struct _SYSTEM_HANDLE_INFORMATION {
ULONG ProcessId;
UCHAR ObjectTypeNumber;
UCHAR Flags;
USHORT Handle;
PVOID Object;
ACCESS_MASK GrantedAccess;
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;
typedef struct _SYSTEM_HANDLE_INFORMATION_EX {
ULONG NumberOfHandles;
SYSTEM_HANDLE_INFORMATION Information[1];
} SYSTEM_HANDLE_INFORMATION_EX, *PSYSTEM_HANDLE_INFORMATION_EX;
ProcessId specifies the process which owns the handle. ObjectTypeNumber
is handle type. NumberOfHandles is number of records in Information array.
Hiding one item is trivial. We have to remove all following records by one
and decrease NumberOfHandles. Removing all following is needed because handles
in array are grouped by ProcessId. That mean all handles from one single
process are together. And for one process the number Handle is growing.
Now remember structure _SYSTEM_PROCESSES which is returned by this
function with SystemProcessesAndThreadsInformation class. Here we can see that
each process has an information about its number of handles in HandleCount.
If we want to be perfect we should modify HandleCount owing to how many handles
we hide when calling this function with SystemProcessesAndThreadsInformation
class. But this correction would be very time-consuming. There are many handles
opening and closing in very short time during normal system running. So it can
easily happend that number of handles is changed in between two calls of this
function and we don't need to change HandleCount.
=====[ 9.1 Naming handle and getting type ]=====================================
Handle hiding is trivial but find out which handle to hide is little
bit harder. If we have e.g. hidden process we should hide all its handles and
all handles which are connected with it. Hiding handles of this process is
again trivial. We are only comparing ProcessId of handle and PID of our process
and when they equals we hide it. But handles of other processes have to be
named before we can compare something. The number of handles in the system is
usually very big, so the best we can do is to compare handle type first before
trying to name it. Naming types will save a lot of time for handles we are not
interested in.
Naming handle and handle type can be done via calling NtQueryObject.
NTSTATUS ZwQueryObject(
IN HANDLE ObjectHandle,
IN OBJECT_INFORMATION_CLASS ObjectInformationClass,
OUT PVOID ObjectInformation,
IN ULONG ObjectInformationLength,
OUT PULONG ReturnLength OPTIONAL
);
ObjectHandle is a handle we want to get info about,
ObjectInformationClass is the type of information which will be stored into
ObjectInformation buffer which is ObjectInformationLength bytes long.
We will use class ObjectNameInformation and ObjectAllTypesInformation.
ObjectNameInfromation class will fill the buffer with OBJECT_NAME_INFORMATION
structure, ObjectAllTypesInformation class with OBJECT_ALL_TYPES_INFORMATION
structure then.
#define ObjectNameInformation 1
#define ObjectAllTypesInformation 3
typedef struct _OBJECT_NAME_INFORMATION {
UNICODE_STRING Name;
} OBJECT_NAME_INFORMATION, *POBJECT_NAME_INFORMATION;
Name determines the name of the handle.
typedef struct _OBJECT_TYPE_INFORMATION {
UNICODE_STRING Name;
ULONG ObjectCount;
ULONG HandleCount;
ULONG Reserved1[4];
ULONG PeakObjectCount;
ULONG PeakHandleCount;
ULONG Reserved2[4];
ULONG InvalidAttributes;
GENERIC_MAPPING GenericMapping;
ULONG ValidAccess;
UCHAR Unknown;
BOOLEAN MaintainHandleDatabase;
POOL_TYPE PoolType;
ULONG PagedPoolUsage;
ULONG NonPagedPoolUsage;
} OBJECT_TYPE_INFORMATION, *POBJECT_TYPE_INFORMATION;
typedef struct _OBJECT_ALL_TYPES_INFORMATION {
ULONG NumberOfTypes;
OBJECT_TYPE_INFORMATION TypeInformation;
} OBJECT_ALL_TYPES_INFORMATION, *POBJECT_ALL_TYPES_INFORMATION;
Name determines the name of type object which immediately follows
each OBJECT_TYPE_INFORMATION structure. The next OBJECT_TYPE_INFORMATION
structure follows this Name, starting on the first four-byte boundary.
ObjectTypeNumber from SYSTEM_HANDLE_INFORMATION structure is an index
to TypeInformation array.
Harder is to get the name of handle from other process. There are two
possibilities how to name it. First is to copy the handle via NtDuplicateObject
to our process and then to name it. This method will fail for some specific
types of handles. But it will fail only for few, so we can stay calm and use
this.
NtDuplicateObject(
IN HANDLE SourceProcessHandle,
IN HANDLE SourceHandle,
IN HANDLE TargetProcessHandle,
OUT PHANDLE TargetHandle OPTIONAL,
IN ACCESS_MASK DesiredAccess,
IN ULONG Attributes,
IN ULONG Options
);
SourceProcessHandle is a handle of process which owns SourceHandle
which is the handle we want to copy. TargetProcessHandle is handle of process
where to copy. This will be handle to our process in our case. TargetHandle
is the pointer on handle where to save a copy of original handle. DesiredAccess
should be set to PROCESS_QUERY_INFORMATION, Attribures and Options to 0.
Second naming method which works with any handle is to use system
driver. Source code for this is available in OpHandle project on my site.
=====[ 10. Ports ]==============================================================
The easiest way to enumarate open ports is to use functions called
AllocateAndGetTcpTableFromStack and AllocateAndGetUdpTableFromStack, and or
AllocateAndGetTcpExTableFromStack and AllocateAndGetUdpExTableFromStack from
iphlpapi.dll. The Ex functions are available since Windows XP.
typedef struct _MIB_TCPROW {
DWORD dwState;
DWORD dwLocalAddr;
DWORD dwLocalPort;
DWORD dwRemoteAddr;
DWORD dwRemotePort;
} MIB_TCPROW, *PMIB_TCPROW;
typedef struct _MIB_TCPTABLE {
DWORD dwNumEntries;
MIB_TCPROW table[ANY_SIZE];
} MIB_TCPTABLE, *PMIB_TCPTABLE;
typedef struct _MIB_UDPROW {
DWORD dwLocalAddr;
DWORD dwLocalPort;
} MIB_UDPROW, *PMIB_UDPROW;
typedef struct _MIB_UDPTABLE {
DWORD dwNumEntries;
MIB_UDPROW table[ANY_SIZE];
} MIB_UDPTABLE, *PMIB_UDPTABLE;
typedef struct _MIB_TCPROW_EX
{
DWORD dwState;
DWORD dwLocalAddr;
DWORD dwLocalPort;
DWORD dwRemoteAddr;
DWORD dwRemotePort;
DWORD dwProcessId;
} MIB_TCPROW_EX, *PMIB_TCPROW_EX;
typedef struct _MIB_TCPTABLE_EX
{
DWORD dwNumEntries;
MIB_TCPROW_EX table[ANY_SIZE];
} MIB_TCPTABLE_EX, *PMIB_TCPTABLE_EX;
typedef struct _MIB_UDPROW_EX
{
DWORD dwLocalAddr;
DWORD dwLocalPort;
DWORD dwProcessId;
} MIB_UDPROW_EX, *PMIB_UDPROW_EX;
typedef struct _MIB_UDPTABLE_EX
{
DWORD dwNumEntries;
MIB_UDPROW_EX table[ANY_SIZE];
} MIB_UDPTABLE_EX, *PMIB_UDPTABLE_EX;
DWORD WINAPI AllocateAndGetTcpTableFromStack(
OUT PMIB_TCPTABLE *pTcpTable,
IN BOOL bOrder,
IN HANDLE hAllocHeap,
IN DWORD dwAllocFlags,
IN DWORD dwProtocolVersion;
);
DWORD WINAPI AllocateAndGetUdpTableFromStack(
OUT PMIB_UDPTABLE *pUdpTable,
IN BOOL bOrder,
IN HANDLE hAllocHeap,
IN DWORD dwAllocFlags,
IN DWORD dwProtocolVersion;
);
DWORD WINAPI AllocateAndGetTcpExTableFromStack(
OUT PMIB_TCPTABLE_EX *pTcpTableEx,
IN BOOL bOrder,
IN HANDLE hAllocHeap,
IN DWORD dwAllocFlags,
IN DWORD dwProtocolVersion;
);
DWORD WINAPI AllocateAndGetUdpExTableFromStack(
OUT PMIB_UDPTABLE_EX *pUdpTableEx,
IN BOOL bOrder,
IN HANDLE hAllocHeap,
IN DWORD dwAllocFlags,
IN DWORD dwProtocolVersion;
);
There is another way to do this stuff. When program creates a socket
and starts listening it surely has an open handle for it and for open port.
We can enumerate all open handles in the system and send them special buffer
via NtDeviceIoControlFile to find out whether the handle is for open port
or not. This will also give us information about the port. Because there are
a lot of open handles we will test only handles which type is File and name
is /Device/Tcp or /Device/Udp. Open ports have only this type and name.
When we look to the code of iphlpapi.dll functions above we find out
that these functions also calls NtDeviceIoControlFile and sends special buffer
to get a list of all open ports in the system. That mean only functions we
need to hook for hiding ports is NtDeviceIoControlFile.
NTSTATUS NtDeviceIoControlFile(
IN HANDLE FileHandle
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG IoControlCode,
IN PVOID InputBuffer OPTIONAL,
IN ULONG InputBufferLength,
OUT PVOID OutputBuffer OPTIONAL,
IN ULONG OutputBufferLength
);
Interesting agruments for us now are FileHandle which specify a handle
of device to communicate with, IoStatusBlock which points to a variable that
receives the final completion status and information about the requested
operation, IoControlCode that is a number specifying type of the device,
method, file access and a function. InputBuffer contains input data that are
InputBufferLength bytes long and similarly OutputBuffer and OutputbufferLength.
=====[ 10.1 Netstat, OpPorts on WinXP, FPort on WinXP ]=========================
Getting a list of all open ports is the first way which is used by e.g.
OpPorts and FPort on Windows XP and also Netstat.
Programs calls here NtDeviceIoControlFile twice with IoControlCode
0x000120003. OutputBuffer is filled after a second call. Name of FileHandle is
here alwats /Device/Tcp. InputBuffer differs for different types of call:
1) To get an array of MIB_TCPROW InputBuffer looks as follows:
first call:
0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
second call:
0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
2) To get an array of MIB_UDPROW:
first call:
0x01 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
second call:
0x01 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
3) To get an array of MIB_TCPROW_EX:
first call:
0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
second call:
0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x02 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
4) To get an array of MIB_UDPROW_EX:
first call:
0x01 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
second call:
0x01 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x01 0x00 0x00
0x02 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
You can see the buffers are different in few bytes only. We can lucidly
recapitulate these:
Calls we are interested in have InputBuffer[1] set to 0x04 and mainly
InputBuffer[17] on 0x01. Only after these input data we get filled OutputBuffer
with desiderative tables. If we want to get info about TCP ports we set
InputBuffer[0] on 0x00, or on 0x01 for information about UDP. If we want
extended output tables (MIB_TCPROW_EX or MIB_UDPROW_EX) we use Inputbuffer[16]
in second call set to 0x02.
If we find out the call with these parameters we can change the output
buffer. To get number of rows in output buffer simply divide Information from
IoStatusBlock by size of the row. Hiding of one row is easy then. Just rewrite
it with following rows and delete last row. Don't forget to change
OutputBufferLength and IoStatusBlock.
=====[ 10.2 OpPorts on Win2k and NT4, FPort on Win2k ]==========================
We use NtDeviceIoControlFile with IoControlCode 0x00210012 to determine
if the handle of File type and name /Device/Tcp or /Device/Udp is the handle of
open port.
So at first we compare IoControlCode and then a type and the name of
the handle. If it is still interesting then we compare the length of input
buffer which should be equal to the length of struct TDI_CONNECTION_IN. This
length is 0x18. OutputBuffer is TDI_CONNECTION_OUT.
typedef struct _TDI_CONNECTION_IN
{
ULONG UserDataLength,
PVOID UserData,
ULONG OptionsLength,
PVOID Options,
ULONG RemoteAddressLength,
PVOID RemoteAddress
} TDI_CONNECTION_IN, *PTDI_CONNECTION_IN;
typedef struct _TDI_CONNECTION_OUT
{
ULONG State,
ULONG Event,
ULONG TransmittedTsdus,
ULONG ReceivedTsdus,
ULONG TransmissionErrors,
ULONG ReceiveErrors,
LARGE_INTEGER Throughput
LARGE_INTEGER Delay,
ULONG SendBufferSize,
ULONG ReceiveBufferSize,
ULONG Unreliable,
ULONG Unknown1[5],
USHORT Unknown2
} TDI_CONNECTION_OUT, *PTDI_CONNECTION_OUT;
Concrete implementation of how to determine the handle is open port
is available in source code of OpPorts on my site. We are interested in hiding
specific port now. We already compared InputBufferLength and IoControlCode.
Now we have to compare RemoteAddressLength. This is always 3 or 4 for open
port. The last we have to do is to compare ReceivedTsdus from OutputBuffer
which contains the port in network form and our list of ports we want to hide.
Differentiate between TCP and UDP is done according to the name of the handle.
By deleting OutputBuffer, changing IoStatusBlock and returning the value
of STATUS_INVALID_ADDRESS we will hide this port.
=====[ 11. Ending ]=============================================================
Concrete implementation of described techniques will be available with
the source code of Hander defender rootkit in version 1.0.0 on my site.
It is possible I will add some more information about invisibility on
Windows NT in the future. New versions of this document could also contain
improvement of described methods or new comments.
Special thanks to Ratter who give me a lot of knowhow which was
necessary to write this document and to code project Hacker defender.
Send all remarks into my mailbox or put them on the board on my site.
===================================[ End ]======================================
墨衍会员
·
AI 创作全网分发
墨衍智能分发
本文由作者通过墨衍一键同步至各平台
1分发平台
1.3k累计阅读
1.3k平均单平台
已同步平台
优快云
微信公众号
微博
知乎
掘金
百家号
博客园
抖音
小红书
你的文章也可以这样分发
墨衍会员 ¥399起/年，写一次发全网
我也要
3809
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
