A more stable way to locate real KiServiceTable

SSDT获取原始服务地址的方法与原理(灯灯灯灯,我肥来了..) 好吧,我胡汉三肥来了..(确实肥了- -),几个月没发什么文章.其实.我也只是一个新丁~欢迎大家交流,高手勿喷,谢谢合作^_^     对于SSDT,不知道的同学请自己百度,判断出SSDT被HOOK之后,如何恢复成原始服务地址?主要方法有两个,简单来说,一个Ring0,一个Ring3的方法(可能分类不够准确),我今天除了介绍方法之外,主要还是讲讲里面的原理吧,原理神马的才是最吸引人的对吧. 阅读详情
Tan Chew Keong in his Win2K/XP SDT Restore 0.1 uses a simple way to find changed SDT entries - he just compares SDT from memory with SDT from ntoskrnl.exe file, assuming that KeServiceDescriptorTable.Base is not changed. If it is, Tan's code that locates KiServiceTable on disk will fail when KeServiceDescriptorTable.Base points somewhere outside the ntoskrnl.
  I've found a way how to locate original KiServiceTable in the ntoskrnl file even if KeServiceDescriptorTable.Base has been changed. Method works both in the user mode and in the kmode.
  This may be useful to bypass SDT-patching hooks, and not only to restore old SDT. For example, KAV uses SDT relocation ;)
  KeServiceDescriptorTable is initialized by KiInitSystem():
   KeServiceDescriptorTable[0].Base = &KiServiceTable[0];
   KeServiceDescriptorTable[0].Count = NULL;
   KeServiceDescriptorTable[0].Limit = KiServiceLimit;
   KeServiceDescriptorTable[0].Number = &KiArgumentTable[0];
   for (Index = 1; Index < NUMBER_SERVICE_TABLES; Index += 1) {
   KeServiceDescriptorTable[Index].Limit = 0;
   }
  Thus, we can find KiServiceTable by examining all xrefs to KeServiceDescriptorTable in the kernel. We will search for
  C7 05 ..8 bytes.. mov ds:_KeServiceDescriptorTable.Base, offset _KiServiceTable
  from which we will get _KiServiceTable rva.
  It's easy to find KeServiceDescriptorTable xrefs by scanning the code, but this is dangerous and time-consuming. It's better to use ntoskrnl's relocation information - it is always present in all nt systems.
  This "mov [mem32], imm32" instruction will have 2 relocs pointing in it, and the second is the one we're searching for. So, the usermode code will do these steps:
  1. Load ntosknrl as a dll.
  2. Locate KeServiceDescriptorTable - it is exported.
  3. Enumerate all relocations to find xrefs to the KeServiceDescriptorTable.
  4. Check these opcodes to be a "mov [mem32],imm32".
  5. Get KiServiceTable - it's offset is +6 from the opcode beginning.
  The example code dumps KiServiceTable data from file and does no comparings with the existing sdt.
  So, it's a must to a SDT-patching rootkit to hook file system and show "patched" version of ntoskrnl to all readers. And of course, services hooks code must reside in the ntoskrnl region and have no codepaths outside it. Otherwise it may be tracked in seconds.
  #include <windows.h>
  #include <winnt.h>
  #include <stdio.h>
  #define RVATOVA(base,offset) ((PVOID)((DWORD)(base)+(DWORD)(offset)))
  #define ibaseDD *(PDWORD)&ibase
  #define STATUS_INFO_LENGTH_MISMATCH ((NTSTATUS)0xC0000004L)
  #define NT_SUCCESS(Status) ((NTSTATUS)(Status) >= 0)
  typedef struct {
   WORD offset:12;
   WORD type:4;
  } IMAGE_FIXUP_ENTRY, *PIMAGE_FIXUP_ENTRY;
  typedef LONG NTSTATUS;
  #ifdef __cplusplus
  extern "C" {
  #endif
  NTSTATUS
  WINAPI
  NtQuerySystemInformation(
   DWORD SystemInformationClass,
   PVOID SystemInformation,
   ULONG SystemInformationLength,
   PULONG ReturnLength
   );
  #ifdef __cplusplus
  }
  #endif
  typedef struct _SYSTEM_MODULE_INFORMATION {//Information Class 11
   ULONG Reserved[2];
   PVOID Base;
   ULONG Size;
   ULONG Flags;
   USHORT Index;
   USHORT Unknown;
   USHORT LoadCount;
   USHORT ModuleNameOffset;
   CHAR ImageName[256];
  }SYSTEM_MODULE_INFORMATION,*PSYSTEM_MODULE_INFORMATION;
  typedef struct {
   DWORD dwNumberOfModules;
   SYSTEM_MODULE_INFORMATION smi;
  } MODULES, *PMODULES;
  #define SystemModuleInformation 11
  DWORD GetHeaders(PCHAR ibase,
   PIMAGE_FILE_HEADER *pfh,
   PIMAGE_OPTIONAL_HEADER *poh,
   PIMAGE_SECTION_HEADER *psh)
  {
   PIMAGE_DOS_HEADER mzhead=(PIMAGE_DOS_HEADER)ibase;
  
   if ((mzhead->e_magic!=IMAGE_DOS_SIGNATURE) ||
   (ibaseDD[mzhead->e_lfanew]!=IMAGE_NT_SIGNATURE))
   return FALSE;
  
   *pfh=(PIMAGE_FILE_HEADER)&ibase[mzhead->e_lfanew];
   if (((PIMAGE_NT_HEADERS)*pfh)->Signature!=IMAGE_NT_SIGNATURE)
   return FALSE;
   *pfh=(PIMAGE_FILE_HEADER)((PBYTE)*pfh+sizeof(IMAGE_NT_SIGNATURE));
  
   *poh=(PIMAGE_OPTIONAL_HEADER)((PBYTE)*pfh+sizeof(IMAGE_FILE_HEADER));
   if ((*poh)->Magic!=IMAGE_NT_OPTIONAL_HDR32_MAGIC)
   return FALSE;
  
   *psh=(PIMAGE_SECTION_HEADER)((PBYTE)*poh+sizeof(IMAGE_OPTIONAL_HEADER));
   return TRUE;
  }
  DWORD FindKiServiceTable(HMODULE hModule,DWORD dwKSDT)
  {
   PIMAGE_FILE_HEADER pfh;
   PIMAGE_OPTIONAL_HEADER poh;
   PIMAGE_SECTION_HEADER psh;
   PIMAGE_BASE_RELOCATION pbr;
   PIMAGE_FIXUP_ENTRY pfe;
  
   DWORD dwFixups=0,i,dwPointerRva,dwPointsToRva,dwKiServiceTable;
   BOOL bFirstChunk;
   GetHeaders((PBYTE)hModule,&pfh,&poh,&psh);
   // loop thru relocs to speed up the search
   if ((poh->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress) &&
   (!((pfh->Characteristics)&IMAGE_FILE_RELOCS_STRIPPED))) {
  
   pbr=(PIMAGE_BASE_RELOCATION)RVATOVA(poh->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress,hModule);
   bFirstChunk=TRUE;
   // 1st IMAGE_BASE_RELOCATION.VirtualAddress of ntoskrnl is 0
   while (bFirstChunk || pbr->VirtualAddress) {
   bFirstChunk=FALSE;
   pfe=(PIMAGE_FIXUP_ENTRY)((DWORD)pbr+sizeof(IMAGE_BASE_RELOCATION));
   for (i=0;i<(pbr->SizeOfBlock-sizeof(IMAGE_BASE_RELOCATION))>>1;i++,pfe++) {
   if (pfe->type==IMAGE_REL_BASED_HIGHLOW) {
   dwFixups++;
   dwPointerRva=pbr->VirtualAddress+pfe->offset;
   // DONT_RESOLVE_DLL_REFERENCES flag means relocs aren't fixed
   dwPointsToRva=*(PDWORD)((DWORD)hModule+dwPointerRva)-(DWORD)poh->ImageBase;
   // does this reloc point to KeServiceDescriptorTable.Base?
   if (dwPointsToRva==dwKSDT) {
   // check for mov [mem32],imm32. we are trying to find
   // "mov ds:_KeServiceDescriptorTable.Base, offset _KiServiceTable"
   // from the KiInitSystem.
   if (*(PWORD)((DWORD)hModule+dwPointerRva-2)==0x05c7) {
   // should check for a reloc presence on KiServiceTable here
   // but forget it
   dwKiServiceTable=*(PDWORD)((DWORD)hModule+dwPointerRva+4)-poh->ImageBase;
   return dwKiServiceTable;
   }
   }
  
   } else
   if (pfe->type!=IMAGE_REL_BASED_ABSOLUTE)
   // should never get here
   printf("/trelo type %d found at .%X/n",pfe->type,pbr->VirtualAddress+pfe->offset);
   }
   *(PDWORD)&pbr+=pbr->SizeOfBlock;
   }
   }
  
   if (!dwFixups)
   // should never happen - nt, 2k, xp kernels have relocation data
   printf("No fixups!/n");
   return 0;
  }
  void main(int argc,char *argv[])
  {
   HMODULE hKernel;
   DWORD dwKSDT; // rva of KeServiceDescriptorTable
   DWORD dwKiServiceTable; // rva of KiServiceTable
   PMODULES pModules=(PMODULES)&pModules;
   DWORD dwNeededSize,rc;
   DWORD dwKernelBase,dwServices=0;
   PCHAR pKernelName;
   PDWORD pService;
   PIMAGE_FILE_HEADER pfh;
   PIMAGE_OPTIONAL_HEADER poh;
   PIMAGE_SECTION_HEADER psh;
  
   // get system modules - ntoskrnl is always first there
   rc=NtQuerySystemInformation(SystemModuleInformation,pModules,4,&dwNeededSize);
   if (rc==STATUS_INFO_LENGTH_MISMATCH) {
   pModules=GlobalAlloc(GPTR,dwNeededSize);
   rc=NtQuerySystemInformation(SystemModuleInformation,pModules,dwNeededSize,NULL);
   } else {
  strange:
   printf("strange NtQuerySystemInformation()!/n");
   return;
   }
   if (!NT_SUCCESS(rc)) goto strange;
  
   // imagebase
   dwKernelBase=(DWORD)pModules->smi.Base;
   // filename - it may be renamed in the boot.ini
   pKernelName=pModules->smi.ModuleNameOffset+pModules->smi.ImageName;
  
   // map ntoskrnl - hopefully it has relocs
   hKernel=LoadLibraryEx(pKernelName,0,DONT_RESOLVE_DLL_REFERENCES);
   if (!hKernel) {
   printf("Failed to load! LastError=%i/n",GetLastError());
   return;
   }
   GlobalFree(pModules);
   // our own export walker is useless here - we have GetProcAddress :)
   if (!(dwKSDT=(DWORD)GetProcAddress(hKernel,"KeServiceDescriptorTable"))) {
   printf("Can't find KeServiceDescriptorTable/n");
   return;
   }
   // get KeServiceDescriptorTable rva
   dwKSDT-=(DWORD)hKernel;
   // find KiServiceTable
   if (!(dwKiServiceTable=FindKiServiceTable(hKernel,dwKSDT))) {
   printf("Can't find KiServiceTable.../n");
   return;
   }
   printf("&KiServiceTable==%08X/n/nDumping 'old' ServiceTable:/n/n",
   dwKiServiceTable+dwKernelBase);
  
   // let's dump KiServiceTable contents
  
   // MAY FAIL!!!
   // should get right ServiceLimit here, but this is trivial in the kernel mode
   GetHeaders((PBYTE)hKernel,&pfh,&poh,&psh);
  
   for (pService=(PDWORD)((DWORD)hKernel+dwKiServiceTable);
   *pService-poh->ImageBase<poh->SizeOfImage;
   pService++,dwServices++)
   printf("%08X/n",*pService-poh->ImageBase+dwKernelBase);
   printf("/n/nPossibly KiServiceLimit==%08X/n",dwServices);
   FreeLibrary(hKernel);
  } 
国央企创新负责人如何通过平台提升技术需求挖掘与资源配置的精准性?.docx 国央企创新负责人如何通过平台提升技术需求挖掘与资源配置的精准性? 立即下载

相关推荐

两路半桥LLC谐振变换器软开关Simulink仿真(模拟谐振参数不同、分裂电容)

内容概要:本文介绍了“两路半桥LLC谐振变换器软开关Simulink仿真”资源包,重点在于基于Simulink平台对两路半桥LLC谐振变换器进行高精度建模与动态仿真,特别考虑了谐振参数不一致及分裂电容等非理想工况对系统性能的影响。该仿真模型不仅涵盖了主电路拓扑、软开关实现机制与谐振网络设计,还深入分析了不同参数配置下系统的启动特性、稳态效率、动态响应及软开关条件的满足情况。通过参数扫描与对比仿真,帮助用户掌握LLC变换器的关键设计要素与优化方法,具备较强的工程指导价值和科研教学意义。; 适合人群:电力电子、电气工程及其自动化等相关专业的高校师生,以及从事高频开关电源、新能源变换器、车载充电机等领域的研发工程师和技术人员。; 使用场景及目标:① 掌握两路并联半桥LLC谐振变换器的建模与仿真方法;② 理解软开关技术在提升变换器效率与降低EMI方面的关键作用;③ 分析谐振参数偏差与分裂电容结构对系统均流特性、增益曲线及软开关范围的影响;④ 支持科研项目中的拓扑验证、控制策略开发与故障工况分析; 阅读建议:建议结合Simulink仿真模型与配套说明文档进行学习,重点关注谐振腔参数设置、驱动时序设计及软开关波形观测;可通过调整谐振电感、电容值或引入参数失配,观察系统行为变化,深入理解LLC变换器的稳定边界与优化设计原则。

找KiServiceTable

为什么80%的码农都做不了架构师?>>> ...

weixin_33739541的博客 240

双向全桥CLLC谐振变换器仿真模型(Simulink仿真实现)

内容概要:本文系统介绍了双向全桥CLLC谐振变换器的Simulink仿真模型,重点阐述了变频控制、闭环仿真及其与多种电力电子拓扑(如维也纳整流器、DAB变换器、图腾柱PFC等)的联合仿真设计。资源包涵盖2.5kW双向全桥LLC、V2G电动汽车充放电系统、三相PFC、多相交错LLC等多种变换器的仿真案例,并深入展示了三电平VIENNA整流器在双闭环PI控制与SVPWM调制策略下,结合上下电容电压差值补偿实现中点电位平衡的先进控制方法。通过仿真验证,该策略不仅有效维持了800V直流母线电压的稳定,还在动态工况下显著提升了电容电压的均衡度,同时保持了较低的输入电流THD,充分体现了SVPWM与中点平衡控制协同优化的技术优势。; 适合人群:具备电力电子与自动控制理论基础,从事新能源发电、电动汽车、工业电源、微电网等领域的研究生、工程师及科研人员。; 使用场景及目标:① 学习并构建高频谐振变换器(如LLC、CLLC)的Simulink仿真模型,掌握其变频与混合控制策略;② 深入理解并应用中点电位平衡、双闭环PI控制、SVPWM调制等核心技术于VIENNA等三电平变换器中;③ 复现高水平期刊论文中的控制算法,服务于科研项目申报、学术论文撰写或工程产品开发。; 阅读建议:该资源为综合性仿真资料库,建议使用者结合自身研究方向(如电动汽车充电、新能源并网)选择对应案例进行精学,重点关注控制策略的设计逻辑、仿真参数的整定方法以及SVPWM与中点平衡的协同机制,并充分利用附带的计算书和参考文献深化理解,以实现从仿真模型到实际工程应用的顺利转化。

java 钩子 64位 操作系统_恢复在WIN64上的SSDT钩子

要恢复SSDT,首先要获得SSDT各个函数的原始地址,而SSDT各个函数的原始地址,自然是存储在内核文件里的。于是,有了以下思路:1.获得内核里KiServiceTable的地址(变量名称:KiServiceTable)2.获得内核文件在内核里的加载地址(变量名称:NtosBase)3.获得内核文件在PE32+结构体里的映像基址(变量名称:NtosImageBase)4.在自身进程里加载内核文件并...

weixin_42365898的博客 343

全桥LLC谐振(变频+移相混合控制)变换器闭环仿真模型(Simulink仿真实现)

全桥LLC谐振(变频+移相混合控制)变换器闭环仿真模型(Simulink仿真实现)

PCIe学习笔记(一)-------1.3 PCIe数据包(TLP,DLLP,PLP)

1,PCIe的层次结构 PICe设备在硬件电路上可以分为三个层次结构:事务层(Transaction Layer)、数据链路层(Data Link Layer)、物理层(Physical)。每一个层次又可以分为两个部分,分别为处理发送和处理接收的部分。 也可以分为四个层次,将事务层以上的层次称为软件层(Software Layer)。 2,PCIe数据包 前面已经说过PCIe之间是以数据包的形式来传输数据的,协议共定义了3类数据包。与处理层相关的是处理层数据包(TLP),与数据链路层相关的是数据

llxxyy507的博客 2万+

windows内核——基石

用户内存空间和内核内存空间之间的gap是为了避免不经意的越界而导致安全问题系统启动期间,会对所有的处理器进行初始化操作大部分初始化操作我们都不必了解,因为你了不了解都不影响你的逆向,毕竟你又不是开发操作系统的但是艺多不压身,多知道点东西总没有坏处处理器控制区PCR processor control region是一个结构体,每一个处理器都有一个对应的PCR结构体实例,它存储了CPU的重要信息在x86中,它包含了IDT的基地址和当前的IRQL(interrupt request level——中断请求等级

ma_de_hao_mei_le的博客 1204

核磁分析必备,ACD/Labs软件使用全解析

核磁共振(NMR)是化学分析中的重要工具,而ACD/Labs提供了一套强大的软件解决方案。从实验设计到数据解读,ACD/Labs 的 NMR 预测可以显著加快您的工作流程。使用 ACD/NMR 预测可以:根据化学结构预测 1H、13C、15N、19F 和 31P 核的全套 1D 和 2D NMR 光谱;在几秒钟内计算化学位移和耦合常数;利用内部数据训练算法,提高新化学空间的准确性。

a13981820402的博客 5637

SSDT hook技术中KeServiceDescriptorTable 结构及获取

KeServiceDescriptorTable 结构  KeServiceDescriptorTable:是由内核(Ntoskrnl.exe)导出的一个表,这个表是访问SSDT的关键,具体结构是    typedef struct ServiceDescriptorTable {    PVOID ServiceTableBase;    PVOID ServiceCounterTabl

namelcx的专栏 2302

双RTX 3090实战:如何用vLLM低成本部署Qwen2.5-14B大模型(附避坑清单)

本文详细介绍了如何利用双RTX 3090显卡低成本部署Qwen2.5-14B大模型的完整指南,包括硬件选型、环境配置、vLLM优化及生产环境调优。重点解析了BF16混合精度在显存占用与推理质量上的平衡策略,并提供了实用的避坑清单和性能调优技巧,帮助开发者高效实现大模型部署。

pz890123456的博客 702

OTA(Over-The-Air)升级

OTA(Over-the-Air)是一种通过无线方式进行数据传输和更新的技术,通常用于电子设备(如智能手机、汽车、物联网设备等)的软件、固件或配置更新。OTA可以在设备与服务器之间进行远程传输,用户无需将设备接入电脑或进行有线操作。通过OTA,用户只需要通过Wi-Fi或移动网络连接,便能自动接收并安装最新的更新,而无需手动干预。OTA的优点是便捷和高效,能够确保设备随时保持最新状态,同时减少用户的操作负担。:如智能家居设备、路由器、汽车等硬件设备的固件更新。:确保设备上的应用保持最新版本。

weixin_50127894的博客 5071

Windows 内核驱动:A more stable way to locate real KiServiceTable

By: 90210 Tan Chew Keong in his Win2K/XP SDT Restore 0.1 uses a simple way to find changed SDT entries - he just compares SDT from memory with SDT from ntoskrnl.exe file, assuming that KeServiceDesc

IamRainLiang的专栏 1196

rv1126 SDK编译【2020-0912版本SDK包】

rv1126 sdk 编译

学习记录 1万+

Windows2000 内核级进程隐藏、侦测技术

摘要    信息对抗是目前计算机发展的一个重要的方向,为了更好的防御,必须去深入的了解敌人进攻的招式。信息对抗促使信息技术飞速的发展。下面我选取了信息对抗技术的中一个很小一角关于windows内核级病毒隐藏技术和反病毒侦测技术作为议题详细讨论。 关键字:内核,拦截,活动进程链表,系统服务派遣表,线程调度链Abstract        Nowadays, informati

天蓝的专栏 1776

【CAD二次开发】炸开所有的嵌套块

代码】【CAD二次开发】炸开所有的嵌套块。

1515

基于学术研究于NASA官网GPM卫星数据下载详细教程

基于学术研究于NASA官网GPM卫星数据下载详细教程

珞瑜的博客 8657

通过Hook SSDT (System Service Dispath Table) 隐藏进程

1.原理介绍:        Windows操作系统是一种分层的架构体系。应用层的程序是通过API来访问操作系统。而API又是通过ntdll里面的核心API来进行系统服务的查询。核心API通过对int 2e的切换,从用户模式转换到内核模式。2Eh中断的功能是通过NTOSKRNL.EXE的一个函数KiSystemService()来实现的。在你使用了一个系统调用时,必须首先装载要调用的函数索引号到

rosykee的专栏 929

32、运算放大器的工作原理与应用

本文详细介绍了运算放大器的工作原理与多种应用场景,涵盖开环与闭环放大器的基本概念、理想运算放大器的特性及其‘黄金规则’。文章深入解析了反相放大器、同相放大器、单位增益跟随器与反相器的配置和增益计算,并探讨了电压比较器及窗口比较器的工作机制。同时提供了运算放大器在实际应用中的选型流程、使用注意事项以及常见故障排查方法,帮助读者全面掌握运算放大器的设计与应用要点。

u5v6w7的博客 164

分析360安全卫士HOOK

分析了一下360安全卫士的HOOK(一)  分析了一下360的HOOK,通过直接hook KiFastCallEntry实现对所有系统调用的过滤。  我分析的版本如下:  HookPort.sys版本: 1, 0, 0, 1005  HookPort.sys的TimeStamp: 4A8D4AB8  简单说明:360把所有被hook的系统服务的过滤函数放在了一个表里,索引即对应的系统服务

多媒体编程、网络编程、系统编程、网络安全编程、驱动编程 2184

STM32F407中文手册

STM32f407中文手册 本参考手册面向应用开发人员,提供有关使用 STM32F405xx/07xx、STM32F415xx/17xx、 STM32F42xxx 和 STM32F43xxx 微控制器存储器与外设的完整信息。STM32F405xx/07xx、STM32F415xx/17xx、STM32F42xxx 和 STM32F43xxx 构成一个微 控制器系列,各产品具有不同的存储器大小、封装和外设。有关订购信息以及器件的机械与电气特性,请参见数据手册。有关 ARM Cortex™-M4F 内核的信息,请参见《Cortex™-M4F 技术参考手册》。

Outlook Express 6 (OE6) for Win7/Win8/Win10

英文版 Outlook Express6.0, 兼容Win7/Win10/WinXP,解压就可用。

-------- Rootkit 核心技术——利用 nt!_MDL 突破 KiServiceTable 的只读访问限制 Part II --------...

——————————————————————————————————————————————————————————————————————————————————————————— 本篇开始进入正题,因为涉及 MDL,所以相关的背景知识是必须的: nt!_MDL 代表一个“内存描述符链表”结构,它描述着用户或内核模式虚拟内存(亦即缓冲区),其对应的那些物理页被锁定住, 无法换出。 ...

weixin_30651273的博客 220

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

恢复在WIN64上的SSDT钩子

原始位置链接:http://www.weixianmanbu.com/article/57.html  在上一篇文章里我描述了如何在Win64系统上实现SSDTHOOK,有SSDTHOOK,自然也有UNHOOKSSDT的方法,现在我就来讲一下如何实现UNHOOKSSDT。 要恢复SSDT,首先要获得SSDT各个函数的原始地址,而SSDT各个函数的原始地址,自然是存储在内核文件里的。于是,有

qq_36453052的博客 1924

NTscan扫描工具

ntscan是一个扫描器,可以扫描没有密码和弱密码的共享,先到配置文件中填写猜测的用户名和密码,扫描过程中右侧出现的是扫描日志。

Rootkit 核心技术——利用 nt!_MDL(内存描述符链表)突破 SSDT(系统服务描述符表)的只读访问限制 Part I...

———————————————————————————————————————————————————————— 在 rootkit 与恶意软件开发中有一项基本需求,那就是 hook Windows 内核的系统服务描述符表(下称 SSDT),把该表中的 特定系统服务函数替换成我们自己实现的恶意例程;当然,为了确保系统能够正常运作,我们需要事先用一个函数指针保存原始 的系统服务,并且在我们恶意...

weixin_30346033的博客 285

获取SSDT,SSSDT原始函数地址

SSDT 当前函数地址 = KiSeviceTable + *(KiServiceTalbe + index * 4); TableRVA = KiSeviceTable - 内核真实加载地址 ; ImageBase = 0x140000000;(理想加载地址) ImageKiSeviceTable = ImageBase + TableRVA; LoadDLLBase = LoadLi

zhuhuibeishadiao 4886
上一篇: hotpatch的参考文档和一些加载驱动或者xx的方法
下一篇: 几种建立http-tunnel的方法
iiprogram
博客等级 码龄25年 1068粉丝 1515原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值