Simple Hooking of Functions not Exported by Ntoskrnl.exe

本文介绍了一种通过映射ntdll.dll到进程空间的方法来获取未导出的内核函数地址的技术。这种方法避免了硬编码位置的问题,并确保了在不同Windows版本间的一致性。
 As many of you will know, hooking functions not exported by ntoskrnl.exe is a real pain, as you need to hard code their position in KeServiceDescriptorTable, and this will change between windows releases.

Hardcoding the positions seems a poor solution, since it means after a new service pack, the rootkit may no longer work and become discovered.

As I have found the code on this site extremely helpful, I think it is only fair that I return the favour ;-)

I have implemented the method described in previous posts, whereby I have mapped a view of ntdll.dll into the process space of whoever loads the driver initially, and then retrieve the required function positions directly from the dll.

This was relatively simple to do, and only requires knowledge of the pe file format, and a few undocumented apis.

Using the function pasted below, when hooking you simply do as follows:


RtlInitUnicodeString(&dllName, L"//Device//HarddiskVolume1//Windows//System32//ntdll.dll");
functionAddress = GetDllFunctionAddress(functionName, &dllName);
position = *((WORD*)(functionAddress+1));
    
g_OriginalZwCreateProcessEx = (ZWCREATEPROCESSEX)(KeServiceDescriptorTable.ServiceTableBase[position]);


and here's the function GetDllFunctionAddress:


DWORD GetDllFunctionAddress(char* lpFunctionName, PUNICODE_STRING pDllName)
{
    HANDLE hThread, hSection, hFile, hMod;
    SECTION_IMAGE_INFORMATION sii;
    IMAGE_DOS_HEADER* dosheader;
    IMAGE_OPTIONAL_HEADER* opthdr;
    IMAGE_EXPORT_DIRECTORY* pExportTable;
    DWORD* arrayOfFunctionAddresses;
    DWORD* arrayOfFunctionNames;
    WORD* arrayOfFunctionOrdinals;
    DWORD functionOrdinal;
    DWORD Base, x, functionAddress;
    char* functionName;
    STRING ntFunctionName, ntFunctionNameSearch;
    PVOID BaseAddress = NULL;
    SIZE_T size=0;

    OBJECT_ATTRIBUTES oa = {sizeof oa, 0, pDllName, OBJ_CASE_INSENSITIVE};

    IO_STATUS_BLOCK iosb;

    //_asm int 3;
    ZwOpenFile(&hFile, FILE_EXECUTE | SYNCHRONIZE, &oa, &iosb, FILE_SHARE_READ, FILE_SYNCHRONOUS_IO_NONALERT);

    oa.ObjectName = 0;

    ZwCreateSection(&hSection, SECTION_ALL_ACCESS, &oa, 0,PAGE_EXECUTE, SEC_IMAGE, hFile);
    
    ZwMapViewOfSection(hSection, NtCurrentProcess(), &BaseAddress, 0, 1000, 0, &size, (SECTION_INHERIT)1, MEM_TOP_DOWN, PAGE_READWRITE);
    
    ZwClose(hFile);
    
    hMod = BaseAddress;
    
    dosheader = (IMAGE_DOS_HEADER *)hMod;
    
    opthdr =(IMAGE_OPTIONAL_HEADER *) ((BYTE*)hMod+dosheader->e_lfanew+24);

    pExportTable =(IMAGE_EXPORT_DIRECTORY*)((BYTE*) hMod + opthdr->DataDirectory[ IMAGE_DIRECTORY_ENTRY_EXPORT]. VirtualAddress);

    // now we can get the exported functions, but note we convert from RVA to address
    arrayOfFunctionAddresses = (DWORD*)( (BYTE*)hMod + pExportTable->AddressOfFunctions);

    arrayOfFunctionNames = (DWORD*)( (BYTE*)hMod + pExportTable->AddressOfNames);

    arrayOfFunctionOrdinals = (WORD*)( (BYTE*)hMod + pExportTable->AddressOfNameOrdinals);

    Base = pExportTable->Base;

    RtlInitString(&ntFunctionNameSearch, lpFunctionName);

    for(x = 0; x < pExportTable->NumberOfFunctions; x++)
    {
        functionName = (char*)( (BYTE*)hMod + arrayOfFunctionNames[x]);

        RtlInitString(&ntFunctionName, functionName);

        functionOrdinal = arrayOfFunctionOrdinals[x] + Base - 1; // always need to add base, -1 as array counts from 0
        // this is the funny bit.  you would expect the function pointer to simply be arrayOfFunctionAddresses[x]...
        // oh no... thats too simple.  it is actually arrayOfFunctionAddresses[functionOrdinal]!!
        functionAddress = (DWORD)( (BYTE*)hMod + arrayOfFunctionAddresses[functionOrdinal]);
        if (RtlCompareString(&ntFunctionName, &ntFunctionNameSearch, TRUE) == 0)
        {
            ZwClose(hSection);
            return functionAddress;
        }
    }

    ZwClose(hSection);
    return 0;
}
源码链接: https://pan.quark.cn/s/dbe32f6bace6 在本指南中,我们将详细解析如何在银河麒麟v10操作系统平台上完成MySQL 5.7的安装过程。银河麒麟v10作为一个基于Linux内核的国产操作系统,特别适用于arm架构的aarch64计算平台。鉴于我们讨论的是免编译的安装方法,这意味着我们将借助预先编译好的二进制软件包来简化操作步骤,而非采用从源代码开始的编译方式。 ### 一、前期准备 1. **系统更新**: 在部署任何新软件之前,务必确保操作系统处于最新状态,此举旨在规避潜在的兼容性挑战和已知的安全隐患。 ``` sudo apt-get update sudo apt-get upgrade ``` 2. **依赖安装**: MySQL 5.7版本在运行时可能需要特定的库文件支持,比如libaio和jemalloc。在银河麒麟v10环境中,可以通过以下指令来安装这些必需的依赖项: ``` sudo apt-get install libaio1 libaio-dev jemalloc-dev ``` ### 二、获取MySQL 5.7二进制文件 由于银河麒麟v10运行在arm架构之上,因此需要寻找适配aarch64架构的MySQL 5.7二进制文件。这些文件可从MySQL的官方发布渠道或授权的第三方镜像站点获取。务必确认下载的文件名与压缩包内的内容一致。例如,文件名应为`mysql-5.7.37-linux-glibc2.17-arm64.tar.gz`。 ### 三、部署MySQL 5.7 1. **文件解压缩**: 将下载的MySQL压缩文件解压至一个指定目录,例如 `/usr/local/`。 ``` tar...
下载代码方式:https://pan.quark.cn/s/a4b39357ea24 Node.js 是一种开放源代码且能够在多种操作系统上运行的 JavaScript 执行环境,它使得开发人员能够在服务器端执行 JavaScript 代码。Node.js 采用了 V8 引擎,该引擎是由 Google 为 Chrome 浏览器开发的一个高性能的 JavaScript 解释器。Node.js 的 16.x 版本在其发展历程中占据着重要位置,其中包含了众多新功能以及性能上的改进。标题 "Nodejs16-x64 windows安装包" 指向的是专为 Windows 操作系统设计的 64 位版本的 Node.js 16 安装程序。在 Windows 平台上安装 Node.js 的 64 位版本对于处理大量数据或运行需要高性能的应用程序来说尤为关键,因为 64 位系统能够更有效地利用硬件资源。描述 "Nodejs-16 x64位windows 安装包" 明确了该安装程序是为 Windows 用户准备的,特别是对于那些需要运行 64 位应用程序的用户。x64 表明该版本兼容 64 位架构,意味着它能够充分利用 64 位计算机的内存和处理能力。标签 "Node Nodejs nodejs16" 提供了关于此安装包的核心信息,表明它与 Node.js 相关,并且具体指的是 v16 版本。这些标签有助于进行搜索和分类,从而方便用户找到他们所需要的特定版本。压缩包文件 "node-v16.18.0-x64.msi" 代表实际的安装文件,其中 "v16.18.0" 指示了 Node.js 的具体版本号,"x64" 再次强调了其适用于 64 位系统,而 ".msi" 后缀表明这是一...
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值