转关于Anti-SSDT Hook

本文探讨了SSDT Hook的检测与反检测技术,详细介绍了如何通过扫描KeServiceDescriptorTable来查找Hook痕迹,并提供了具体的代码实现。同时,文中还讨论了如何利用ntoskrnl.exe中的原始数据来对比并修复可能存在的Hook。

本文主要为学习各位大牛的技术,不敢擅称原创,见谅
SSDT HOOK最终是要修改KeServiceDescriptorTable的成员ServiceTableBase所指向内存空间的Nt××函数地址,那么我们就可以通过扫描这段内存空间就可以抓到hook的痕迹,唔,这就是我们anti-ssdt hook的基本思路,或者说scan为anti提供了可行性
最经典的,该是Greg Hoglund与James Butler合著的《Rootkits: Subverting the Windows Kernel》,唔这么好的书没人翻译太可惜了(据FC说有人翻译过,可惜我没有看到),不过也避免了恶劣翻译对经典的破坏,唉,矛于盾,就像我们的 ssdt hook与anti-ssdt hook一样
其具体步骤为(原理的演绎,不多说了,需要的看代码)获取ntoskrnl模块的内存地址范围,如果所检测的SDT中的函数地址不在这个范围,那就认为被hook了
下面相关原文:
Finding SSDT Hooks
The following DriverEntry function calls the GetListOfModules function and then walks each entry, looking for the one named ntoskrnl.exe. When it is found, a global variable containing the beginning and end addresses of that module is initialized. This information will be used to look for addresses in the SSDT that are outside of ntoskrnl.exe's range.

代码:
typedef struct _NTOSKRNL {
     DWORD Base;
     DWORD End;
} NTOSKRNL, *PNTOSKRNL;
PMODULE_LIST   g_pml;
NTOSKRNL        g_ntoskrnl;
NTSTATUS DriverEntry(IN PDRIVER_OBJECT  DriverObject,
                     IN PUNICODE_STRING RegistryPath)
{
   int count;
   g_pml = NULL;
   g_ntoskrnl.Base = 0;
   g_ntoskrnl.End  = 0;
   g_pml = GetListOfModules();
   if (!g_pml)
      return STATUS_UNSUCCESSFUL;
   for (count = 0; count < g_pml->d_Modules; count++)
   {
      // Find the entry for ntoskrnl.exe.
      if (_stricmp("ntoskrnl.exe", g_pml->a_Modules[count].a_bPath + g_pml-
>a_Modules[count].w_NameOffset) == 0)
     {
        g_ntoskrnl.Base = (DWORD)g_pml->a_Modules[count].p_Base;
        g_ntoskrnl.End  = ((DWORD)g_pml->a_Modules[count].p_Base + g_pml-
>a_Modules[count].d_Size);
     }
   }
   ExFreePool(g_pml);
   if (g_ntoskrnl.Base != 0)
      return STATUS_SUCCESS;
   else
      return STATUS_UNSUCCESSFUL;
}
The following
function will print a debug message if it finds an SSDT address out of
acceptable range:#pragma pack(1)
typedef struct ServiceDescriptorEntry {
        unsigned int *ServiceTableBase;
        unsigned int *ServiceCounterTableBase;
        unsigned int NumberOfServices;
        unsigned char *ParamTableBase;
} SDTEntry_t;
#pragma pack()
// Import KeServiceDescriptorTable from ntoskrnl.exe.
__declspec(dllimport) SDTEntry_t KeServiceDescriptorTable;
void IdentifySSDTHooks(void)
{
   int i;
   for (i = 0; i < KeServiceDescriptorTable.NumberOfServices; i++)
   {
      if ((KeServiceDescriptorTable.ServiceTableBase <
                                           g_ntoskrnl.Base) ||
        (KeServiceDescriptorTable.ServiceTableBase >
                                           g_ntoskrnl.End))
     {
        DbgPrint("System call %d is hooked at address %x!/n", i,
KeServiceDescriptorTable.ServiceTableBase);
     }
   }
}

Finding SSDT hooks is very powerful, but do not be surprised if you find a few that are not rootkits. Remember, a lot of protection software today also hooks the kernel and various APIs.
In the next section, you will learn how to detect certain inline function hooks, which are discussed in Chapter 4
Tan Chew Keong在他的’Win2K/XP SDT Restore’大作中的基本思路是不变的,但是,他的SDT是在ntoskrnl.exe的原始文件中加载的,然后使用这个SDT跟操作系统内核中正在使用的那个进行对比,这样更精确到位,而且可以对可疑的HOOK进行恢复。相关代码在网络上有提供。这种加载SDT的方法是90210在 rootkit.com中‘A more stable way to locate real KiServiceTable’提出来的。
Tan Chew Keong后来写了篇文章——《Win2K/XP SDT Restore》,基本思路仍如前篇所述,不过他的SDT在ntoskrnl.exe原始文件中加载,然用这个SDT与OS内核中那个对比,相较之更为精确,且未恢复HOOK提供了途径。
相关原文如下:

引用:
This POC code restores the values of the ServiceTable entries by writing directly to /device/physicalmemory. Hence, it works entirely in user-space and do not need to load a driver. The following steps describe how the code works.
1.Use NtOpenSection to get a handle to /device/physicalmemory with SECTION_MAP_READ | SECTION_MAP_WRITE access. If this fails, modify the DACL of /device/physicalmemory by adding SECTION_MAP_WRITE access permission to the current user. Try to open /device/physicalmemory again.
2.Load ntoskrnl.exe into memory with proper alignment and locate the address of KeServiceDescriptorTable from the export table of ntoskrnl.exe
3.Use NtMapViewOfSection to map in the physical memory page at the address of KeServiceDescriptorTable.
4.Get the address of KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable from the page.
5.Use NtMapViewOfSection to map in the physical memory page containing the running kernel's SerivceTable. This address is available at KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable.
6.Use the address of KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable to offset into the loaded ntoskrnl.exe
7.Loop through all entries in KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable, comparing the copy in the kernel memory with the copy in the loaded ntoskrnl.exe. Restore to kernel memory (i.e. into the mapped page) any discrepancies that are detected. This code works based on the fact that a complete original copy of the ServiceTable exists in ntoskrnl.exe.

具体code可在baidu到,由于思路相同,就不再赘述
如果你对这种load方法不理解的话,参看90210的“A more stable way to locate real KiServiceTable”
相关代码如下:

代码:
#include
#include
#include
#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->ImageBaseSizeOfImage;
            pService++,dwServices++)
        printf("%08X/n",*pService-poh->ImageBase+dwKernelBase);   
    printf("/n/nPossibly KiServiceLimit==%08X/n",dwServices);
    FreeLibrary(hKernel);
}

参考资料:
《ROOTKITS: SUVVERING THE WINDOWS KERNEL》
by Greg Hoglund, James Butler
《Defeating Kernel Native API Hookers by Direct KiServiceTable Restoration》
by Tan Chew Keong
《Win2K/XP SDT Restore 0.2 (Proof-Of-Concept)》
同样 byTan Chew Keong
《A more stable way to locate real KiServiceTable》
by 90210

基于实时迭代的数值鲁棒NMPC双模稳定预测模型(Matlab代码实现)内容概要:本文介绍了基于实时迭代的数值鲁棒非线性模型预测控制(NMPC)双模稳定预测模型的研究与Matlab代码实现,重点在于通过数值方法提升NMPC在动态系统中的鲁棒性与稳定性。文中结合实时迭代机制,构建了能够应对系统不确定性与外部扰动的双模预测控制框架,并利用Matlab进行仿真验证,展示了该模型在复杂非线性系统控制中的有效性与实用性。同时,文档列举了大量相关的科研方向与技术应用案例,涵盖优化调度、路径规划、电力系统管理、信号处理等多个领域,体现了该方法的广泛适用性。; 适合人群:具备一定控制理论基础和Matlab编程能力,从事自动化、电气工程、智能制造等领域研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①用于解决非线性动态系统的实时控制问题,如机器人控制、无人机路径跟踪、微电网能量管理等;②帮助科研人员复现论文算法,开展NMPC相关创新研究;③为复杂系统提供高精度、强鲁棒性的预测控制解决方案。; 阅读建议:建议读者结合提供的Matlab代码进行仿真实践,重点关注NMPC的实时迭代机制与双模稳定设计原理,并参考文档中列出的相关案例拓展应用场景,同时可借助网盘资源获取完整代码与数据支持。
UWB-IMU、UWB定位对比研究(Matlab代码实现)内容概要:本文介绍了名为《UWB-IMU、UWB定位对比研究(Matlab代码实现)》的技术文档,重点围绕超宽带(UWB)与惯性测量单元(IMU)融合定位技术展开,通过Matlab代码实现对两种定位方式的性能进行对比分析。文中详细阐述了UWB单独定位与UWB-IMU融合定位的原理、算法设计及仿真实现过程,利用多传感器数据融合策略提升定位精度与稳定性,尤其在复杂环境中减少信号遮挡和漂移误差的影响。研究内容包括系统建模、数据预处理、滤波算法(如扩展卡尔曼滤波EKF)的应用以及定位结果的可视化与误差分析。; 适合人群:具备一定信号处理、导航定位或传感器融合基础知识的研究生、科研人员及从事物联网、无人驾驶、机器人等领域的工程技术人员。; 使用场景及目标:①用于高精度室内定位系统的设计与优化,如智能仓储、无人机导航、工业巡检等;②帮助理解多源传感器融合的基本原理与实现方法,掌握UWB与IMU互补优势的技术路径;③为相关科研项目或毕业设计提供可复现的Matlab代码参考与实验验证平台。; 阅读建议:建议读者结合Matlab代码逐段理解算法实现细节,重点关注数据融合策略与滤波算法部分,同时可通过修改参数或引入实际采集数据进行扩展实验,以加深对定位系统性能影响因素的理解。
本系统基于MATLAB平台开发,适用于2014a、2019b及2024b等多个软件版本,并提供了可直接执行的示例数据集。代码采用模块化设计,关键参数均可灵活调整,程序结构逻辑分明且附有详细说明注释。主要面向计算机科学、电子信息工程、数学等相关专业的高校学生,适用于课程实验、综合作业及学位论文等教学与科研场景。 水声通信是一种借助水下声波实现信息传输的技术。近年来,多输入多输出(MIMO)结构与正交频分复用(OFDM)机制被逐步整合到水声通信体系中,显著增强了水下信息传输的容量与稳健性。MIMO配置通过多天线收发实现空间维度上的信号复用,从而提升频谱使用效率;OFDM方案则能够有效克服水下信道中的频率选择性衰减问题,保障信号在复杂传播环境中的可靠送达。 本系统以MATLAB为仿真环境,该工具在工程计算、信号分析与通信模拟等领域具备广泛的应用基础。用户可根据自身安装的MATLAB版本选择相应程序文件。随附的案例数据便于快速验证系统功能与性能表现。代码设计注重可读性与可修改性,采用参数驱动方式,重要变量均设有明确注释,便于理解与后续调整。因此,该系统特别适合高等院校相关专业学生用于课程实践、专题研究或毕业设计等学术训练环节。 借助该仿真平台,学习者可深入探究水声通信的基础理论及其关键技术,具体掌握MIMO与OFDM技术在水声环境中的协同工作机制。同时,系统具备良好的交互界面与可扩展架构,用户可在现有框架基础上进行功能拓展或算法改进,以适应更复杂的科研课题或工程应用需求。整体而言,该系统为一套功能完整、操作友好、适应面广的水声通信教学与科研辅助工具。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
数据结构部分 -- 一、栈和队列 Stack && Queue 栈 - 结构图 alt 队列 - 结构图 alt 双端队列 - 结构图 alt 二、 链表 Linked List 单链表 - 结构图 alt 单项循环链表 - 结构图 alt 双向链表 - 结构图 alt 三、 树 基础定义及相关性质内容 - 结构图 alt - 另外可以参考浙江大学数据结构课程中关于遍历方式的图,讲的十分详细 alt 使用链表实现二叉树 二叉查找树 - 非空左子树的所有键值小于根节点的键值 - 非空右子树的所有键值大于根节点的键值 - 左右子树都是二叉查找树 补充 - 完全二叉树 - 如果二叉树中除去最后一层节点为满二叉树,且最后一层的结点依次从左到右分布,则此二叉树被称为完全二叉树。 - 满二叉树 - 如果二叉树中除了叶子结点,每个结点的度都为 2,则此二叉树称为满二叉树。 代码下载地址: https://pan.quark.cn/s/b48377ea3e78 四、 堆 Heap 堆满足的条件 - 必须是完全二叉树 - 各个父节点必须大于或者小于左右节点,其中最顶层的根结点必须是最大或者最小的 实现方式及条件 - 使用数组实现二叉堆,例如下图的最大堆,在数组中使用[0,100,90,85,80,30,60,50,55]存储,注意上述第一个元素0仅仅是做占位; - 设节点位置为x,则左节点位置为2x,右节点在2x+1;已知叶子节点x,根节点为x//2; - 举例说明: - 100为根节点(位置为1),则左节点位置为2,即90,右节点位置为3,即85; - 30为子节点(位置为5),则根节点为(5//2=2),即90; 根据上述条件,我们可以绘制出堆的两种形式 - 最大堆及实现 al...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值