Windows kernel analysis index directory: https://www. cnblogs.com/onetrainee/p/11675224.html
System service table descriptor in Windows system call
in front , We will solve the system service table. However, we have a question, where is the system service table stored?
The answer is: the system service table is stored in the system service descriptor table. (It is also called SSDT Service Descriptor Table)
1. Use the PELord function from View the SSDT export function in the ntoskrnl.exe file
As shown in the figure, you can see the KeServiceDescriptorTable export function.
Through this function, you can find the location of the SSDT table.
2. View SSDT table in memory through Windbg
Using Windbg, you can use kd> dd nt!KeServiceDescriptorTable command to view SSDT table.
But this instruction has shortcomings. You can see that the second table is 0, which means that if we use the public export function of KeServiceDescriptorTable, we cannot see the table structure of win32k.sys
kd> dd nt! KeServiceDescriptorTable
83f759c0 83e89d9c 00000000 00000191 83e8a3e4
83f759d0 00000000 00000000 00000000 00000000
83f759e0 83ee86af 00000000 0327aa43 000000bb
83f759f0 00000011 00000100 5385d2ba d717548f
< p> In order to solve the above problem, we can only use another instruction, which corresponds to an undocumented exported function.
is as follows, you can see the second line, win32k.sys system service table is already visible.
kd> dd KeServiceDescriptorTableShadow
83f75a00 83e89d9c 00000000 00000191 83e8a3e4
83f75a10 83b66000 00000000 00000339 83b6702c
83f75a20 00000000 00000000 83f75a24 00000340
83f75a30 00000340 855e8440 00000007 00000000
< /p>
Three, verify the real kernel implementation part of ReadMemory
In this article, “The three-ring part of the API in Windows system calls (rewrite the ReadProcessMemory function based on analysis) ) “It was mentioned in the “Quick call” directly to abandon the R3 encapsulated API, which gives eax a function number. Now let’s analyze it in action.
mov eax, 0x115
mov edx, 0X7FFE0300
is as follows, the data structure of the system descriptor, in order Respectively
, respectively, are ServiceTable 83e89d9c,Count 00000000,ServiceLimit 00000191,ServiceTable 83e8a3e4
Use Windbg to view the function address of its 115h serial number 115h*4 + 83e89d9c (ServiceTable)
Get the function address as 8406c82c
kd> dd 115h*4 + 83e89d9c
83e8a1f0 8406c82c 840feb46 83fb488c 83fb6128
> u 8406c82c
nt NtReadVirtualMemory:!
8406c82c 6a18 push 18h
8406c82e 68282ae683 push offset nt !? :: FNODOBFM :: `string ‘+ 0x3ea8 (83e62a28)
8406c838 648b3d24010000 mov edi, dword ptr fs:! [124h]
8406c83f 8a873a010000 mov al, byte ptr [edi + 13Ah]
8406c845 8845e4 mov byte ptr [ebp – 1Ch], al
8406c848 8b7514 mov esi, dword ptr [ebp + 14h]
8406c84b 84c0 test al, al
After that, we see the nt!NtReadVirtualMemoryNumber of function parameters
kd> db 83e8a3e4 + 115
83e8a4f9 14 08 04 04 14 04 10 08-0c 04 14 18 08 08 08 0c
83e8a509 0c 08 10 14 08 08 0c 08-0c 0c 04 08 08 08 08 08 83e8a519 08 0c 0c 24 00 08 08 08-0c 04 08 10 08
Four. Add system service functions by modifying the SSDT table
The three-ring part of the API in our Windows system call (rewritten based on analysis ReadProcessMemory function) calls function 115h.
Now, we put the function address at function 191 (previously, there were 191 functions, occupying 0-190 bits).
Modification ideas:
1) Put the nt!NtReadVirtualMemory function address 8406c82c at No. 191 (83e89d9 + 191h*4)
< p> kd> ed 83e89d9 + 191h*4 8406c82c
2) Increase the maximum number of service tables. (Because when we analyzed its disassembly code in the previous section, we found that it will judge the maximum number)
kd> ed 83f75a00+8 192
< p> 3) Modify the number of corresponding parameter No. 191 in the parameter number table. (We have checked it before it is 14, in bytes)
kd> eb 83e8a3e4+191 14
4) After that, we run the following code. The only difference between it and the “three-ring part of the API in Windows system calls (rewrite the ReadProcessMemory function based on analysis)” is called 192, and the final effect is exactly the same.
1 #include "pch.h"
2 #include
3 #include
4 #include
5 void ReadMemory(HANDLE hProcess, PVOID pAddr, PVOID pBuffer, DWORD dwSize, DWORD *dwSizeRet)
6 {
7
8 _asm
9 {
10 lea eax, [ebp + 0x14]
11 push eax
12 push[ebp + 0x14]
13 push[ebp + 0x10]
14 push[ebp + 0xc]
15 push[ebp + 8]
16 sub esp, 4
17 mov eax, 0x192 // Note: The modification is here
18 mov edx, 0X7FFE0300 //sysenter cannot be called directly, I call it indirectly
19 CALL DWORD PTR[EDX]
20 add esp, 24
21
22 }
23 }
24 int main()
25 {
26 HANDLE hProcess = 0;
27 int t = 123;
28 DWORD pBuffer;
29 //hProcess = OpenProcess(PROCESS_ALL_ACCESS, 0,a);
30 ReadMemory((HANDLE)-1, (PVOID)&t, &pBuffer, sizeof(int), 0);
31 printf("%X ", pBuffer);
32 ReadProcessMemory((HANDLE)-1, &t , &pBuffer, sizeof(int), 0);
33 printf("%X ", pBuffer);
34
35 getchar();
36 return 0;
37 }
mov eax, 0x115
mov edx, 0X7FFE0300
1 #include "pch.h"
2 #include
3 #include
4 #include
5 void ReadMemory(HANDLE hProcess, PVOID pAddr, PVOID pBuffer, DWORD dwSize, DWORD *dwSizeRet)
6 {
7
8 _asm
9 {
10 lea eax, [ebp + 0x14]
11 push eax
12 push[ebp + 0x14]
13 push[ebp + 0x10]
14 push[ebp + 0xc]
15 push[ebp + 8]
16 sub esp, 4
17 mov eax, 0x192 // Note: The modification is here
18 mov edx, 0X7FFE0300 //sysenter cannot be called directly, I call it indirectly
19 CALL DWORD PTR[EDX]
20 add esp, 24
21
22 }
23 }
24 int main()
25 {
26 HANDLE hProcess = 0;
27 int t = 123;
28 DWORD pBuffer;
29 //hProcess = OpenProcess(PROCESS_ALL_ACCESS, 0,a);
30 ReadMemory((HANDLE)-1, (PVOID)&t, &pBuffer, sizeof(int), 0);
31 printf("%X ", pBuffer);
32 ReadProcessMemory((HANDLE)-1, &t , &pBuffer, sizeof(int), 0);
33 printf("%X ", pBuffer);
34
35 getchar();
36 return 0;
37 }