ntqueryObject通过WOW64返回了错误的不足所需尺寸，为什么？

Question

我正在使用NT本机API / zwqueryObject（） 来自用户模式（我知道一般的风险，我过去曾在我的专业中为Windows编写了内核模式驱动程序容量）。

通常，当一个人使用典型的“查询信息”功能（其中少数）时，协议首先要用太小的缓冲区询问，无法用 status_info_info_length_mismatch 检索所需的大小，然后分配一个缓冲区再次提出尺寸和查询 - 这次使用缓冲区和先前返回的尺寸。

为了在系统上获取对象类型的列表（我的构建中的67），我正在做：

ULONG Size = 0;
NTSTATUS Status = NtQueryObject(NULL, ObjectTypesInformation, &Size, sizeof(Size), &Size);

在 size 中，我获得了8280（WOW64）和8968（x64）。然后，我继续将缓冲区分配给 calloc（）并再次查询：

ULONG Size2 = 0;
BYTE* Buf = (BYTE*)::calloc(1, Size);
Status = NtQueryObject(NULL, ObjectTypesInformation, Buf, Size, &Size2);

nb： ObjectTypesInformation 为3。 >，但是Nebbett（作为 QuadicalTypesInformation ）和其他人描述了它。由于我不是在查询特定对象的特征，而是在询问对象类型的系统范围列表，因此我将 null 用于对象句柄。

奇怪的是，在WOW64上，即32位，从第二个查询返回后的 size2 中的值为16个字节（= 8296），比先前返回的所需尺寸大。

就一致而言，我期望这种事情最多8个字节，实际上8280和8296都处于16个字节对齐边界，而是在8个字节上。

当然，我可以在返回的所需大小的顶部添加一些松弛空间（例如 align_up 到下一个32个字节对​​齐边界），但老实说，这似乎是非常不规则的。我宁愿理解发生了什么，而不是实施打破的解决方法，因为我错过了重要的事情。

代码的实际问题是，在释放 buf 时，它告诉我某处有一个损坏的堆。这表明 ntqueryObject（）确实是在提供缓冲区之外的这些额外的16个字节 之外。

问题：任何想法为什么这样做？

与NT本地API一样，信息来源很少。完全相同的代码的X64版本返回所需字节的确切数字。所以我在这里认为WOW64是问题所在。有些粗略地看着 wow64.dll iDA并未透露任何对将结果转换为32 bit的问题的直接点。

PS：Windows 10（10.0.19043，ntdll.dll“ Timestamp” 77755782）

pps：this May 是相关的： https://wj32.org/wp/wp/2012/11/11/11/11/11/11/330/obquerytypeinpeinpeinpeinfo-and-ntqueryobject -buffer-overrun-in-in-windows-8/（存档）通过检查 object> object> object> object_type_information :: typename.length + sizeof（wchar）== object_type_information :: typename.maximumlength 在所有返回的项目中，情况就是如此。

Answer 1

objecttypesinformation 公共的唯一部分是 winternl.h 在Windows SDK中定义的第一个字段：

typedef struct __PUBLIC_OBJECT_TYPE_INFORMATION {
    UNICODE_STRING TypeName;
    ULONG Reserved [22];    // reserved for internal use
} PUBLIC_OBJECT_TYPE_INFORMATION, *PPUBLIC_OBJECT_TYPE_INFORMATION;

对于x86，这是96个字节，对于x64，这是104个字节（假设您启用了正确的包装模式）。区别是 unicode_string 中的指针，它改变了x64中的对齐方式。

任何其他内存空间都应与 typename 缓冲区有关。

unicode_string 帐户为8280和8296之间差的8个字节。该函数使用 sizeof（ulong_ptr）用于对齐返回字符串和额外的WCHAR，因此可以轻松地轻松剩下的8个字节。

AFAIK：公众使用 ntqueryObject 应该仅限于内核模式使用，这当然意味着它始终与OS本机位匹配（X86代码在X64 Native OS中不能作为内核运行），因此，这可能只是通过WOW64 THUNK使用NT功能的怪癖。

Answer 2

好吧，我想我在WindBG的帮助下弄清楚了这个问题，并彻底看 wow64.dll 使用IDA。

NB： WOW64.dll 我的构建号码相同，但仅在数据上略有不同（校验和安全目录条目，版本资源的零件）。该代码是相同的，可以预期，给定。

有一个称为 whntqueryObject_specialquerycase （根据PDB）的内部功能，该功能涵盖 Object> Objecttypesinformation class Queries。

对于上述 wow64.dll ，我使用了WindBG中的感兴趣点，从32位程序中调用 ntqueryObject（null，ObjectTypesinformation，...）（该程序>不过，本身是无关紧要的）：

0:000> .load wow64exts
0:000> bp wow64!whNtQueryObject_SpecialQueryCase+B0E0
0:000> bp wow64!whNtQueryObject_SpecialQueryCase+B14E
0:000> bp wow64!whNtQueryObject_SpecialQueryCase+B1A7
0:000> bp wow64!whNtQueryObject_SpecialQueryCase+B24A
0:000> bp wow64!whNtQueryObject_SpecialQueryCase+B252

上述兴趣点的说明：

• +b0e0：基于32位
• +b14e的经过的长度： ntqueryObject（ntqueryObject（）
• +b1a7， 基于64位查询所需的计算长度：用于复制64至32位缓冲区内容的循环主体，成功 ntqueryObject（） call
• + b24a：通过从基本缓冲区中减去电流（最后 + 1）条目来计算书面长度地址
• +B252：返回（64位）所需的长度为32位至32位

该函数的逻辑，以 Just ObjectTypesInformation 大致如下：

通用步骤：常见步骤

1. 采用 ObjectInformationLength （32位查询！）参数并进行大小调整以适合64位信息，以
2. 使所检索的大小将大小对齐到下一个16个字节边界，
3. 如有必要，请从某些 peb :: ProcessHeap 并存储在TLS插槽3中；否则，将其用作刮擦空间
4. 调用 ntqueryObject（）将缓冲区和长度从上一步传递

到 ntqueryObject（）是第1步，而不是步骤1的一个步骤。一个与16个字节边界对齐。似乎有一些划痕空间的标题，所以也许这就是16个字节对齐的来源？

情况1：缓冲区大小太小（这里：4），只需查询所需的长度，

在这种情况下，上尺寸的长度等于4，它太小，因此 ntqueryObject（）返回 status_info_length_mismant_mismatch < /代码>。所需的尺寸报告为8968。

1. 尺寸从64位所需的长度降至32位，最终16个字节太短
2. 从 ntqueryObject（）返回状态（）和down - 所需长度表格上一个步骤

案例2：缓冲区大小据称（！）足够

1. 复制 object_types_information :: numberOftypes 从查询缓冲区到32位到32位
2. 到第一个条目（ object> object_type_information ）源（64位）和目标（32位）缓冲区，8和4字节分别
3. 对每个条目分别对齐至 object_types_information :: numberoftypes ：
   • 复制 unicode_string ::长度和 unicode_string :: maximum -length

   • memcpy（） unicode_string :: length 从源到目标 unicode_string :: buffer （目标条目）
   • 添加终止零（ WCHAR ）经过Memcpy'D String
   • 将单个成员从键入从64到32位结构
   • 通过对齐 unicode_string :: maximut -lengtth 计算下一个条目的指针最高为8个字节边界（即 ulong_ptr 在其他答案中提到的对齐） + sizeof） （object_type_information64）（已经对8个字节对齐！）
     • 下一个目标条目（32位）获得4个字节对准
4. 通过从缓冲区的基础地址中减去我们为“下一个”条目（即超过最后一个）的值来减去我们到达的值（即一个超过最后一个），以在所需的末端计算（32位）进行4个字节对齐。通过WOW64程序（32位）传递给 ntqueryObject（）
   • 在我的调试场景中，这些是： 0x008ce050-0x008cbfe8 = 0x00002068 （= 8296），比我们在情况1（8280）中告诉我们被告知的缓冲长度大16个字节！

最后一步至关重要的问题

在仅查询和实际填充缓冲区之间有所不同。我描述的是情况2中的该循环中没有进一步的界限检查。

这意味着它将仅覆盖经过的缓冲区并返回比缓冲区长度更大的书面长度。

可能的解决方案和解决方法

在睡觉后，我必须以数学方式接近此操作，这显然是为了填补从情况1返回的所需长度，以避免缓冲区超支。最简单的方法是使用我的 up_size_from_32bit（）从下面的示例中使用，并在返回的必需大小上使用它。这样，您可以在查询32位的同时分配足够的64位缓冲区。在复制循环期间，这绝对不应超越。

但是，我想 wow64.dll 中的修复程序更多地参与其中。在将界限添加到循环中可以帮助避免超支，这意味着呼叫者必须对所需的两次进行查询，因为它第一次围绕它是对我们的。

这意味着仅查询的情况（1）必须在查询所需长度64位的内部缓冲区后必须分配该内部缓冲区，然后将其填充，然后将条目（就像复制循环一样），然后跳过最后一个条目以计算计算所需的长度与之后的相同。

示例程序通过 wow64.dll

为x64构建的“静态”计算，只是 wow64.dll 就是！

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <cstdio>

typedef struct
{
    ULONG JustPretending[24];
} OBJECT_TYPE_INFORMATION32;

typedef struct
{
    ULONG JustPretending[26];
} OBJECT_TYPE_INFORMATION64;

constexpr ULONG size_delta_3264 = sizeof(OBJECT_TYPE_INFORMATION64) - sizeof(OBJECT_TYPE_INFORMATION32);

constexpr ULONG down_size_to_32bit(ULONG len)
{
    return len - size_delta_3264 * ((len - 4) / sizeof(OBJECT_TYPE_INFORMATION64));
}

constexpr ULONG up_size_from_32bit(ULONG len)
{
    return len + size_delta_3264 * ((len - 4) / sizeof(OBJECT_TYPE_INFORMATION32));
}

// Trying to mimic the wdm.h macro
constexpr size_t align_up_by(size_t address, size_t alignment)
{
    return (address + (alignment - 1)) & ~(alignment - 1);
}

constexpr auto u32 = 8280UL;
constexpr auto u64 = 8968UL;
constexpr auto from_64 = down_size_to_32bit(u64);
constexpr auto from_32 = up_size_from_32bit(u32);
constexpr auto from_32_16_byte_aligned = (ULONG)align_up_by(from_32, 16);

int wmain()
{
    wprintf(L"32 to 64 bit: %u -> %u -(16-byte-align)-> %u\n", u32, from_32, from_32_16_byte_aligned);
    wprintf(L"64 to 32 bit: %u -> %u\n", u64, from_64);
    return 0;
}

static_assert(sizeof(OBJECT_TYPE_INFORMATION32) == 96, "Size for 64 bit struct does not match.");
static_assert(sizeof(OBJECT_TYPE_INFORMATION64) == 104, "Size for 64 bit struct does not match.");
static_assert(u32 == from_64, "Must match (from 64 to 32 bit)");
static_assert(u64 == from_32, "Must match (from 32 to 64 bit)");
static_assert(from_32_16_byte_aligned % 16 == 0, "16 byte alignment failed");
static_assert(from_32_16_byte_aligned > from_32, "We're aligning up");

但是，这并不模仿在情况2中发生的计算。