SSDT Table Explanation

SSDT (System service Dispatch table) Systems Services Dispatch table

SSPT (System service Parameter table) systems Services parameter table

#pragma Pack (1) Structure of the//SSDT table

typedef struct Servicedescriptorentry {
unsigned int *servicetablebase;
unsigned int *servicecountertablebase; Used only in checked build
unsigned int Numberofservices;
unsigned char *paramtablebase;
} servicedescriptortableentry_t, *pservicedescriptortableentry_t;

#pragma pack ()

Function Call Procedure Analysis:

(1) The user calls Kenel32.dll in the Readfile,kenel32.dll is the wrapper function, Kenel32.dll will use these wrapper function to complete the validity of the parameter check, convert everything to Unicode, and then lock NTDLL.dll ntreadfile function.

(2) NTDLL.dll is a wrapper function in the service, when the ntreadfile is called, these service wrapper functions feed the required Servcie ID into the EAX register, the pointer to the parameter stack frame into the edx register, and then issue an int 2e interrupt. This command switches the processor to kernel mode. The handler for INT 2e is created by the Windows NT Executive (estimated kernel), which copies the parameters from the user-mode stack to the kernel-mode stack. The base address of the stack frame is the value of the edx register. And this interrupt program is called KiSystemService ()

(3) then into the kernel state, NTOSKRNL.exe begins to work, it is the final call of the system service, and its system service user interface is provided in the form of a wrapper function (wrapper functions). These functions are in a DLL called NTDLL.DLL. Ntosknl. EXE is initialized first, during initialization, a function table, SSDT, is created for the different services provided by NTOSKRNL, and each item in the table specifies the address of the function required by the service ID, each of which is in the kernel. Similarly, SSPT is also starting to create.

The illustrations are as follows:

The following is a structure of two tables:

SSDT Hook Explanation: SSDT hooks are implemented by modifying the function address of the SSDT table, the following is a macro of three related operations, directly using

Take the position of the function in SSDT, the following is a fixed calculation method
#define Systemservice (_function) keservicedescriptortable.servicetablebase[* (Pulong) ((Puchar) _function+1)]

Take the index of the function, fixed mode
#define SYSCALL_INDEX (_function) * (Pulong) ((Puchar) _function+1)

Modify the address of a function
#define Hook_syscall (_function, _hook, _orig) _orig = (PVOID) interlockedexchange ((Plong) &m_mapped[syscall_index ( _function)], (LONG) _hook)

The other operation is the driver write, the principle is to modify the SSDT table, with its own function to replace the original function for process protection or other purposes

Reference: "Undocumented Windows NT", "Hacker Defense magazine 2010.9", Hacker Defense Drive Tutorial.

If you want to know more about it, look at the above things, basic can be found on the Internet

SSDT Table Explanation