[原创]对一个变速器原理的分析-逆向工程-看雪安全社区

# 背景

原本是朋友在调试一个看起来比较新的变速器驱动，整体来说支持两种变速模式，一种是进程级，这种用了HOOK，中规中矩的实现，原理网上都有。另一种是”系统级内核全局变速“，这个模式初步看了下有些特殊，已知的关键点没被修改，也没hook。比较好奇是怎么实现的，花了几天时间分析，也有一些有意思的地方，发个文章记录一下。

## 一，KeQueryPerformanceCounter
写了个简单的驱动，直接调用KeQueryPerformanceCounter会被加速，那么从这里入手应当没问题。  
KeQueryPerformanceCounter网上其他相关文章或多或少都有涉及，只写一下关键调用路径：

```
KeQueryPerformanceCounter
    HalpPerformanceCounter + 0x70;
        HalpHvCounterQueryCounter
            HalpHvTimerApi
            HvlGetReferenceTimeUsingTscPage
```
&nbsp;  
核心逻辑在最后一层的HvlGetReferenceTimeUsingTscPage中，主要是读__rdtsc()然后做一些运算：
&nbsp;
```
__int64 __fastcall HvlGetReferenceTimeUsingTscPage(int a1, __int64 a2)
{
        v2 = __rdtsc();
        LODWORD(a2) = HIDWORD(v2);
        v2 = (unsigned int)v2;
        a2 = (unsigned int)a2;
        a2 = *((_QWORD *)HvlpReferenceTscPage + 2)
           + (((v2 | (a2 << 32)) * (unsigned __int128)*((unsigned __int64 *)HvlpReferenceTscPage + 1)) >> 64);
        v5 = a2;
        a1 = *(_DWORD *)HvlpReferenceTscPage;
        if ( *(_DWORD *)HvlpReferenceTscPage == v3 )
        return v5;
}
```
&nbsp;  
没开嵌套虚拟化，所以rdtsc肯定没被动手脚，调用链里涉及到的相关函数指针及代码确实都没修改。为了缩小范围及进一步排除，跳过前面几层，直接调用HvlGetReferenceTimeUsingTscPage，甚至把代码抠出来直接执行也是被加速，那么猫腻一定在这段代码里面，对其逻辑做一些分析简化：
&nbsp;

```
struct HvRTP
{
    uint32_t unk1;
    uint32_t unk2;
    uint64_t factor;
    uint64_t unk3;
    //........
};

//上面IDA伪代码中的HvlpReferenceTscPage大致就是上面这么一个结构体指针, 核心逻辑简化后等价于：

__int64 __fastcall HvlGetReferenceTimeUsingTscPage()
{
        count = HvlpReferenceTscPage->unk3 + (__rdtsc() * HvlpReferenceTscPage->factor) >> 64;
        return count;
}
```
&nbsp;  
unk3固定是0，那就等价于：```count = (__rdtsc() * HvlpReferenceTscPage->factor) >> 64;```
排除hook以及rdtsc，剩下唯一的可能就是改变了factor（HvlpReferenceTscPage + 8）。

&nbsp;  
多次观察验证：
* 在不启动变速功能时，factor值一直不变，当开启加速后，factor会被修改，如果停止变速，factor值就会被还原；
* factor变化规律与加速倍率直接相关，如果调1.2倍，样本驱动就会把factor改为近似于原值*1.2，变速软件本身限制最高倍率1.5，但手动eq将factor改为原值的10倍后，系统整体就会表现出10倍速效果。
&nbsp;

看起来很简单，但实际上分析才刚刚开始。

## 二，蓝屏
当朋友按照这个结论去测试时，发现HvlpReferenceTscPage+8根本就没法改，可以读，但只要写入就会发生WHEA_UNCORRECTABLE_ERROR（0x124）蓝屏，我最初一直认为是写内存方式不对，但是朋友最后发现了一些规律：
 * 几乎所有写入方式，比如常用的mdl/MmGetPhyAddr+map，或者关WP位，包括windbg的eq无一例外全部都会导致0x124蓝屏；
 * !pte检查map后的页属性没问题；
 * 变速样本始终可以稳定运行，而且只要通过变速样本开启一次加速，即使停止加速后，随便怎么写都不会触发蓝屏。
 * 蓝屏只在HyperV环境出现

&nbsp;  
当我也切换为HyperV，果然出现0x124蓝屏:

```
8: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffbf81`3a347918 fffff807`276f7adb     nt!KeBugCheckEx
01 ffffbf81`3a347920 fffff807`24db1740     nt!HalBugCheckSystem+0xeb
02 ffffbf81`3a347960 fffff807`27826c93     PSHED!PshedBugCheckSystem+0x10
03 ffffbf81`3a347990 fffff807`276f9411     nt!WheaReportHwError+0x393
04 ffffbf81`3a347a60 fffff807`276f9858     nt!HalpMcaReportError+0xb1
05 ffffbf81`3a347bc0 fffff807`276f96f0     nt!HalpMceHandlerCore+0x134
06 ffffbf81`3a347c20 fffff807`276f9922     nt!HalpMceHandler+0xe0
07 ffffbf81`3a347c60 fffff807`276f8bd6     nt!HalpMceHandlerWithRendezvous+0x62
08 ffffbf81`3a347c90 fffff807`276fb4fb     nt!HalpHandleMachineCheck+0x62
09 ffffbf81`3a347cc0 fffff807`27756e39     nt!HalHandleMcheck+0x3b
0a ffffbf81`3a347cf0 fffff807`276281be     nt!KiHandleMcheck+0x9
0b ffffbf81`3a347d20 fffff807`27627de8     nt!KxMcheckAbort+0x7e
0c ffffbf81`3a347e60 fffff807`430a72eb     nt!KiMcheckAbort+0x2a8
```
从蓝屏栈可以看到是写内存时发生MCE异常，VBS没开而且也不像是VBS的表现，应当是hypervisor发现某些异常后，主动向虚拟机内注入的MCE，触发原因可能是EPT物理页属性只读。  
&nbsp;
理论上有一种简单的解决办法：不要直接改HvlpReferenceTscPage+8，而是自己分配一块内存，然后把指针替换到HvlpReferenceTscPage。但样本驱动不是这么干的，应当有它的原因，比如PG或者为了隐蔽？具体什么原因不重要，最关键同时也最让我好奇的是，如果真的是因为EPT页只读触发的蓝屏，那样本驱动是怎么让页变成可写的？

&nbsp;  
正面硬刚VMP是下策，所以首先尝试的思路是对常用内存相关函数下断点，没看出变速驱动有什么特殊操作，就是普普通通的IoAllocateMDL + Map，传的参数与自己的测试代码也是一模一样。  那么这个驱动在写内存前，必然还有其他操作在配合。此时要么直面VMP，要么调试HyperV，没找到能用的VMP插件，调HyperV现实一点。

## 三， Hyper-V

首先验证猜测，确认是不是因为EPT不可写而注入的MCE：

0. 这里本该有图，不过写这个贴子的时候，距离分析已经有一段时间了，懒得再重新搭建调试环境，所以写一下关键思路和过程
1. 通过搜索0x4402/0x6400定位HyperV的vcpu_run_loop()及vmexit_dispatch() 
4. 梳理vmexit_dispatch()内针对每种exit_reason的处理函数（重点是EPT退出）
5. 在ept_vio_exit_handler内合适位置下条件断点，条件设置为vmread(0x2400h)=GPA(HvlpReferenceTscPage)
6. guest内尝试写入HvlpReferenceTscPage+8；
7. 断点会命中，根据vmread(0x6400)的信息或者手动转换也能发现对应页面只有读权限，再往后执行就会给子机注入MCE异常；
8. 重启子机，继续下第3步的断点
9. 加载变速驱动开启变速功能，断点不会命中也不会蓝屏，但对应内存已改写；随便在vcpu_run路径上下个断点，当vcpu退出命中断点，根据EPTP推一遍，会发现对应页已经是可读写；

可以证实MCE蓝屏确实是因为物理页不可写导致，接下来的关键问题是要分析变速驱动是如何让GPA从只读变成可读写的。  
&nbsp;  
理论上在没有通过EFI等方式Patch hvix64.exe的情况下，要从Guest内实现改变EPTP内的GPA属性就三种方式：
* 第一种是通过vmfunc(0,)切换EPTP, 这种一般不会产生vmexit，windows内部也确实会用到，但通过断点验证可以确定当时没执行过，或者变速驱动自己调用了vmfunc(0,)，通过指令搜索方式也基本上可以排除掉，VMP后vmfunc这类指令还是以原来的形式存在，在对应代码段里并不能搜索到这条指令；
* 第二种是变速驱动在guest里做了什么操作，促使hypervisor修改了对应的页面属性。这类方式首先想到的是HyperV是不是有什么VMCall，但是在VMCall的exit_handler下断点并没有什么线索；
* 第三种是bug，可能性太小。。。。

验证完自己能想到的两种方式但没有线索后，只能回到标准思路：
* 先定位HyperVisor修改页面属性的代码，然后设置条件断点判断是不是在修改HvlpReferenceTscPage所对应的GPA页属性，如果断点触发，结合host/guest当时的栈去分析。

这个思路肯定行得通，但是仔细想一下，vmfunc(0)这种唯一无VMExit的方式可以排除，那么即使想不到它具体用的什么方式，也可以确定过程中一定会产生vmexit。  
&nbsp;  
所以最终我用了一个偷懒的思路，统计未开启和开启加速时的vmexit事件，对比分析差异:
* 在vcpu_run_loop()函数内，vmread(0x4402)读取到exit_reason之后的位置下断点自动trace虚拟机的vmexit信息(主要记录reason和guest_rip)；
* 对比变速前后的vmexit统计信息，如果发现某些vmexit仅在变速驱动开启加速的过程中才出现，那么这些vmexit事件就很可能是突破口；

反复跑几遍，最后发现的规律是：  
* 变速驱动在开启变速，改写HvlpReferenceTscPage+8之前，一定有几次rd/wrmsr，而这些msr在正常运行过中系统从不访问，并且通过vmexit时的guest_rip可以确认这些rd/wrmsr都是由变速驱动直接执行。

接下来就是具体分析这些rd/wrmsr，直接在guest_rip或者在HyperV这边的rd/wrmsr_exit_handler处下断点，再观察rd/wrmsr执行前/后VCPU ecx,edx,eax的值，就可以知道读写了哪些寄存器，以及读写的具体数据。

## 四， MSR 0x40000021

在HyperV的wrmsr_exit_handler处下断点，多次观察后首先发现这样一个规律：
1. 开机后第一次开启加速时，变速驱动会读取MSR 0x40000021， 此时读取到的值为0xC001
2. 变速驱动对这个MSR 写入0xC000（仅在第一次开启加速时才会写入）
3. 后续开启加速，每次都会读但不会再写入（每次读取到的值也都是上一步中写入的0xC000）；
&nbsp;

如果只是读MSR倒也没什么，但写MSR比较可疑。搜一下MSR 0x40000021，找到这样两个相对比较有用的文档：

1. <mark class="encrypted">b4aK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9k6h3q4J5L8W2)9J5k6h3#2A6j5%4u0G2M7$3!0X3N6q4)9J5k6h3y4G2L8g2)9J5c8X3g2F1i4K6u0V1N6i4y4Q4x3V1k6$3K9i4u0@1N6h3q4D9K9i4A6S2N6r3W2G2L8W2)9J5c8X3S2&6M7r3g2J5i4K6u0V1N6W2)9J5k6r3!0F1i4K6u0V1N6$3W2F1k6r3!0%4M7#2)9J5c8Y4c8D9k6Y4y4Q4x3V1k6@1K9h3#2W2M7Y4y4Q4c8e0y4Q4z5o6m8Q4z5o6t1`.</mark>  
2. <mark class="encrypted">a67K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2I4k6h3#2#2i4K6u0W2L8%4u0Y4i4K6u0r3k6r3!0U0M7#2)9J5c8X3#2S2M7%4c8W2M7W2)9J5c8Y4y4&6M7%4c8W2L8g2)9J5c8X3V1K6z5o6k6Q4x3V1k6Z5P5i4m8W2M7Y4k6Q4x3X3g2Z5N6r3#2D9</mark>

综合这些文档，可以知道以下关键信息：  
1. 0x40000021是HyperV自己定义的MSR，相当于一个接口，用于GuestOS与HyperV协商初始化Reference TSC page；
2. Reference TSC page是为了给GuestOS提供一个访问时不会产生vmexit的时间戳计数器；
3. MSR对应的读写数据格式为：bit 0表示是否启用Reference TSC page，bit 12-63表示GPA PageNumber，其他都是保留位；
4. 默认情况下Reference TSC page功能是禁用状态，值为0，开机启动过程中由GuestOS主动写入这个MSR才能启用；

结合这些信息和上面所说的变速驱动读写0x40000021的规律，可以进一步明确其每一步的含义：  
1. 第一次读取rdmsr(0x40000021)返回的是0xC001：
    * 解析0xC001：  
        * bit 0为1，那就说明此时GuestOS与HyperV已经协商并初始化Reference TSC page
        * 对应GPA PageNumber为0xC，对应GPA为0xC*0x1000=0xC000
2. 变速驱动对这个MSR写入0xC000：
    * 0xC000就是0xC001清掉bit 0，其他位保持原样；bit 0表示是否启用，那么变速驱动这一步就是通过这个MSR接口，通知HyperV禁用掉Referenct TSC page；

此外还有一个最最关键的信息：
* 上面提到“0xC001对应的GPA=0xC*0x1000=0xC000”，这个0xC000其实就是HvlpReferenceTscPage的GPA，并且也正是发生EPT写入异常最终导致MCE蓝屏的GPA

结合推测，变速驱动禁用reference tsc page的目的，很有可能是禁用后HyperV就会在EPT中将对应Page的从只读变为读写。
&nbsp;
调整测试代码，在修改内存前也加上这个操作，终于可以顺利写入HvlpReferenceTscPage；同时也在HyperV这边进行验证：  
* 在wrmsr_exit_handler_0x40000021处下断点，断点触发时，确认0xC这个页面在EPT中属性为只读，随后step out，让HyperV处理完这次wrmsr，当再次中断到Windbg时，0xC页面就变为了可读写。此时尚未执行VMResume，虚拟机又是单核，VCPU退出后下一次VMResume前等同于是停转状态，这期间GuestOS不可能再有任何操作，也不可能再有其他vmexit，因此可以断定GPA从只读变为可写，100%是由wrmsr(0x40000021,0xc000)触发。  
## 五，系统假死
解决这个页面写入问题之后，再次遇到新的问题：
* 如果将factor改为原来的10倍，虚拟机会假死，而通过变速样本驱动进行10倍加速后系统依旧正常运行

原因是GuestOS内确实变速了，但Hypervisor这边没变，而GuestOS是将时钟设备配置为OneShot模式，在这种模式下，写到时钟设备的“到期时间”是一个绝对时间，这个绝对到期时间的计算方法是：HalpHvCounterQueryCounter() + ClockInterval，这里的HalpHvCounterQueryCounter其实等同于调用KeQueryPerfCounter()，所获取到的Counter值是10倍加速后的结果，而时钟设备是由Hypervisor模拟，Hypervisor这边的时间是以正常速度流逝，所以最终时钟到期时间会越来越晚，对于GuestOS来说就是时钟中断被大幅延迟，最终DPC/线程调度全部跟着延迟，分时系统遇到这种情况必然假死。  
&nbsp;

这个结论的分析和验证过程如下：
1. Hook SwapContext：发现调用次数相比正常时少了很多，线程切换调度肯定出了问题，看看DPC是否有问题
2. 创建一个DPC Timer：实际执行时机相比预期时间被延迟而不是被加速，DPC Timer也有问题，那么继续看时钟中断是否有问题
3. Hook HalpTimerClockInterrupt/KeClockInterruptNotify/KeUpdateRuntime：调用次数明显少于正常情况，再往下就是Hypervisor了，但不一定是Hypervisor导致，有可能是GuestOS配置的时钟周期有问题
4. 结合IDA/Windbg，顺着时钟中断一路分析，发现在需要配置时钟中断到期时间时，最终都会经过以下路径：  
    * HalpTimerClockArm->HalpSetTimer->HalpClockTimer+0x80()->HalpHvTimerArm()
5. 在HalpHvTimerArm中，就会执行上面说的HalpHvCounterQueryCounter() + ClockInterval计算绝对到期时间，并配置到时钟设备，问题是这个时间是被加速后的
6. 尝试Hook HalpHvTimerArm，将其从HalpHvCounterQueryCounter()获取到的值，重新还原回加速前的正常值，再写到时钟设备，假死问题消失

HOOK HalpClockTimer+0x80指向的HalpHvTimerArm确实也是一种解决办法，但样本驱动用了另一种方案：通过两个MSR接口，额外启动另一个时钟设备，并配置为period模式，周期为1ms。怎么发现的这两个MSR，绕了一圈最后还是通过VMEXIT统计对比发现的差异，变速样本驱动在写了0x40000021之后，会继续写0x400000B2/B3这两个MSR，只是VM运行过程中vmexit本身就比较频繁，这两个WRMSR退出事件和0x40000021中间还有一大堆其他vmexit，导致最初没注意到。

## 六，MSR 0x400000B2/B3

这两个MSR也是HyperV自己定义的，在前面的文档中一样有描述。主要用途其实跟LAPIC Timer差不多：
* 0x400000B2 用于配置时钟模式，类似于LAPIC的LVTT(0x320)
    * 关键bit：
        * bit 0： Enable；是否启用；
        * bit 1： Period；是否为周期性时钟；
        * bit 3： AutoEnable；写入B3时是否自动启用Timer；
        * bit 4:11： Vector；时钟到期时，向GuestOS注入的中断Vector；
        * bit 12： DirectMode；如果为1, 时钟到期后通过标准的APIC向Guest注入中断通知子机，如果为0，则通过HyperV的SynIC注入中断通知子机；
* 0x400000B3 用于配置时钟周期/到期事件，类似于LAPIC的TMICT(0x380)

变速驱动主要是执行```wrmsr(0x400000B2,0x1D1A);wrmsr(0x400000B3,0x2710)```，其中0x1D1A表示周期性模式+自动启用+Vector D1+DirectMode，Vector D1对应Windows的HalpTimerClockInterrupt，0x2710=1ms。这样的话即使Win自己配置到时钟设备的绝对时间是加速后的，但是变速驱动额外启动了1ms周期性时钟用于给OS维持稳定的心跳，最终就不会卡死。
&nbsp;
至此就知道关键流程：  
1. 对40000021 的bit 0清零，即禁用TSCRefPage，从而使HyperV将对应GPA从只读变为读写属性；
2. 通过400000B2/B3提前配置好时钟，避免变速后系统假死；
3. 改写factor实现变速；

按照这个逻辑，就可以复刻变速驱动的“全局系统级变速”模式。

## 七，其他

1. 有心人可能会对0x40000021这个接口感兴趣，简单看了下应当不太好利用，因为当写入值bit 0为0时，wrmsr_handler_0x40000021其实并不是加上”W“权限，而是直接”恢复”原来的页映射。在HyperV里叫Overlay Page，简单理解就是贴一张新的A4纸到原来的纸上，如果要禁用，那就把贴上去的A4纸撕下来，将原来的A4纸原样“显示”出来，纸上的内容还是原来的样子。另外，虽然看起来可以通过0x40000021将任一Page贴到另一个Page之上，但是新Page权限以及Page中数据是由Hypervisor强制填充，即使自己先写好也会被清零。当然我没有深究，如果感兴趣的可以自己再调一下看看。
&nbsp;

2. 最后看一下(__rdtsc() * HvlpReferenceTscPage->factor) >> 64这个运算的意义及变速原理，Windows对factor的计算逻辑是：
    ```
    unsigned __int64 unk(__int64 a1, unsigned __int64 a2, unsigned __int64 a3, __int64 *a4)
    {
      __int64 v7; // rdi
      __int64 v8; // rcx
      __int64 v9; // r9
      __int64 v10; // rdx
      __int64 v11; // rbx

v7 = 64i64;
      do
      {
        v8 = 2 * a2;
        v9 = (2 * a1) | (a2 >> 63);
        v10 = a1 >> 63;
        a1 = v9 - a3;
        v11 = 2 * a2;
        if ( (v10 | (unsigned __int64)v9) < a3 )
        a1 = v9;
        a2 = v11 | 1;
        if ( (v10 | (unsigned __int64)v9) < a3 )
        a2 = v8;
        --v7;
    }
    while ( v7 );
    if ( a4 )
        *a4 = a1;
    return a2;
    }
    ```
    传的参数是： ```unk(10000000i64, 0i64, 3.19xxxx, 0i64); ```

其中10000000是代码逻辑中写死的QPC频率；3.19xxxx是tsc频率；

这几行代码里面混着大数乘除法+定点浮点数，看着可能有点迷糊，但其实等价于：
    * factor = 2^64 * qpc_freq / tsc_freq

我的机器tsc频率是3.2GHZ，按公式计算得到0xcccccccccccccc，有点怪，看到一串0xcc多少有点怀疑是不是哪搞错了，其次这个值与Win算出来的确实有点差异。  
    &nbsp;
    实际上是正确的，运算结果只是恰好等于0xcccccccccccccc而已，然后Win并不会通过CPUID/MSR去获取CPU的标称tsc频率，而是在启动时候用一个很短的时间去动态测算CPU的真实tsc频率，算出来的频率会是3.19xxxxxxxxGHZ，而不是标称3.2G，那么最终多少会有点误差。
    &nbsp;
    这个运算的目的则是在CPU的tsc频率与Win的QPC频率之间算一个系数，用于频率转换，因为QPC在新一点的机器上一般都是建立在TSC基础之上(CPU要支持iTSC)，在支持iTSC的情况下，QPC频率是代码写死的固定10MHZ，TSC频率却取决于CPU，tsc频率肯定不会等于10Mhz，那么必然要在中间做一层转换。至于为什么还要乘以2^64，因为如果不这么干，那就不可避免要涉及到浮点数运算有性能代价，不想用浮点数，又想保留小数点确保精度，最终就引入了定点数。VMX的tsc scaling也一样，只不过用的是2^48，微软直接用了2^64。
    &nbsp;
    按照2^64 * qpc_freq / tsc_freq计算出factor之后，就可以通过逆运算 ```__rdtsc()*factor>>64``` 得到以10MHZ为基准的QPC计数值。将Factor调大，自然也就可以实现倍速，本质上跟以前的修改kuser_data差不多，都是干扰参与计算的数据，最终改变计算结果，只是修改的位置不同；
    &nbsp;
    3. 以上MSR仅在虚拟机模式才有，但变速驱动在物理机上用的也是类似的方式，只是改了KeQueryPerfCounter所使用的另一个page中的factor，与虚拟机场景有一些差异，但基本也是一样的rdtsc*factor>>64运算逻辑，而且更简单，因为看了下我的物理机上本身时钟模式就是Period，实测物理机上似乎也并不会出现假死问题；
    &nbsp;
    4. 至于检测，本地检测最简单的方式就是按照公式结合tsc频率，计算出原始值然后对比，但要注意的是Windows是动态计算出的tsc频率，理论上原始factor值本身就有一定误差，所以如果仅仅只进行极低倍率的变速，有可能会误判;
    &nbsp;
    5. 如果直接用IDA F5去看HyperV的vcpu_run_loop函数，在某些版本的HyperV上可能看不到正确逻辑，因为紧跟VMResume和VMLanuch的一条跳转指令对IDA F5有一定干扰；
    &nbsp;
    6. vcpu_run_loop与vmexit_dispatch：
    &nbsp;
     搜索0x4402常量定位vcpu循环线程：
     ![](upload/attach/202310/978739_9N3795TAUEF9SGC.webp)
     vmeixt_dispatch内针对各种vmexit的处理，根据switch_case定位各种exit的处理函数：
     ![](upload/attach/202310/978739_2G32G37EVZ9YCTC.webp)

登录后可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2023-10-5 12:43 被lidowx编辑，原因：加两个图

#调试逆向 #系统底层 #其他内容

最新回复 (28) 1 2 ▶
sunsjw 雪币： 10331 活跃值： (7234) 能力值： ( LV4，RANK：50 ) 在线值：发帖 49 回帖 1329 粉丝 20 关注私信	sunsjw 1 2 楼好文章 2023-10-5 08:57 0
值得怀疑雪币： 1605 活跃值： (9489) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 395 粉丝 1 关注私信	值得怀疑 3 楼来点图就好了 2023-10-5 11:50 0
lidowx 雪币： 1704 活跃值： (573) 能力值： ( LV4，RANK：50 ) 在线值：发帖 2 回帖 10 粉丝 25 关注私信	lidowx 1 4 楼值得怀疑来点图就好了调试时候环境临时搭的，写的时候懒得再搭一遍。另外关键过程思路以及相关函数名/变量名都在。 2023-10-5 12:03 0
秋狝雪币： 10161 活跃值： (34236) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 1571 粉丝 39 关注私信	秋狝 5 楼感谢分享 2023-10-5 20:07 1
R0g 雪币： 2220 活跃值： (7875) 能力值： ( LV7，RANK：100 ) 在线值：发帖 4 回帖 153 粉丝 194 关注私信	R0g 2 6 楼太厉害了，能分析出来一定得非常熟悉Hyper-V吧 2023-10-6 02:09 0
mb_xknjnwpm 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 1 关注私信	mb_xknjnwpm 7 楼这个应该只支持19041以上 2023-10-6 17:27 0
lidowx 雪币： 1704 活跃值： (573) 能力值： ( LV4，RANK：50 ) 在线值：发帖 2 回帖 10 粉丝 25 关注私信	lidowx 1 8 楼 mb_xknjnwpm 这个应该只支持19041以上具体没测。不过它利用的这几个机制，2012年的时候就有相关微软文档。理论上从2012年到现在的OS应当都支持，当然也不排除不同OS上需要做不同微调。 2023-10-6 19:04 0
pysafe 雪币： 1296 活跃值： (6230) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 120 粉丝 13 关注私信	pysafe 9 楼牛逼 2023-10-7 11:23 0
tmflxw 雪币： 3466 活跃值： (6072) 能力值： ( LV2，RANK：10 ) 在线值：发帖 20 回帖 123 粉丝 22 关注私信	tmflxw 10 楼太牛逼了 2023-10-7 12:11 0
CanineTooth 雪币： 2353 活跃值： (4928) 能力值： ( LV4，RANK：40 ) 在线值：发帖 3 回帖 13 粉丝 79 关注私信	CanineTooth 11 楼很强 2023-10-7 12:25 0
Roger 雪币： 4869 活跃值： (4606) 能力值： ( LV8，RANK：147 ) 在线值：发帖 6 回帖 132 粉丝 138 关注私信	Roger 1 12 楼 mark 2023-10-9 22:05 0
青眼白龙雪币： 7433 活跃值： (8334) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 152 粉丝 1 关注私信	青眼白龙 13 楼漂亮，感谢分享 2023-10-10 00:42 0
洪七公. 雪币： 2139 活跃值： (2005) 能力值： ( LV5，RANK：70 ) 在线值：发帖 15 回帖 124 粉丝 2 关注私信	洪七公. 14 楼感谢分享 2023-10-10 18:03 1
shinratensei 雪币： 1719 活跃值： (215957) 能力值： ( LV4，RANK：40 ) 在线值：发帖 1 回帖 141 粉丝 18 关注私信	shinratensei 1 15 楼 tql 2023-10-17 09:51 0
ArmVMP 雪币： 3349 活跃值： (3384) 能力值： ( LV7，RANK：111 ) 在线值：发帖 3 回帖 45 粉丝 16 关注私信	ArmVMP 16 楼相比移动端windows端技术真的是卧虎藏龙, 作者用高屋建瓴形容不为过吧 2023-10-17 10:16 0
青丝梦雪币： 1502 活跃值： (4945) 能力值： ( LV5，RANK：60 ) 在线值：发帖 9 回帖 171 粉丝 26 关注私信	青丝梦 1 17 楼想问一下产品名称是什么。可以告知么 2023-10-18 18:52 0
saloyun 雪币： 2240 活跃值： (5403) 能力值： ( LV2，RANK：10 ) 在线值：发帖 8 回帖 273 粉丝 4 关注私信	saloyun 18 楼变速器这么都这么牛了么。。。 2023-10-19 20:27 0
王cb 雪币： 7732 活跃值： (9174) 能力值： ( LV13，RANK：680 ) 在线值：发帖 44 回帖 154 粉丝 190 关注私信	王cb 14 19 楼 2023-10-20 12:35 0
coneco 雪币： 5151 活跃值： (4978) 能力值： ( LV10，RANK：171 ) 在线值：发帖 10 回帖 141 粉丝 88 关注私信	coneco 3 20 楼感谢分享，学习了，mark。 2023-10-20 12:58 0
Archar 雪币： 84 活跃值： (3364) 能力值： ( LV2，RANK：10 ) 在线值：发帖 7 回帖 71 粉丝 3 关注私信	Archar 21 楼优秀，感谢分享！ 2023-10-20 16:04 0
hambaga 雪币： 187 活跃值： (3976) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 94 粉丝 61 关注私信	hambaga 22 楼 vmware pro 15 + win10 19045 写入成功，写入后马上读取可以读到新的值，但是马上就被还原了，windbg下内存写入断点没有断下，所以应该是hypervisor把它还原了 2023-10-29 19:52 0
hambaga 雪币： 187 活跃值： (3976) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 94 粉丝 61 关注私信	hambaga 23 楼 hambaga vmware pro 15 + win10 19045 写入成功，写入后马上读取可以读到新的值，但是马上就被还原了，windbg下内存写入断点没有断下，所以应该是hypervisor把它还原了也有可能是写不进去，但是r0以为写进去了，有tlb所以读到了修改后的值 2023-10-29 21:54 0
hambaga 雪币： 187 活跃值： (3976) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 94 粉丝 61 关注私信	hambaga 24 楼请问不调试虚拟机的情况下怎么跟踪vmp驱动调用write msr呢 2023-10-29 22:21 0
轻装前行雪币： 815 活跃值： (3432) 能力值： ( LV2，RANK：10 ) 在线值：发帖 14 回帖 119 粉丝 0 关注私信	轻装前行 25 楼不明觉厉 2023-11-2 21:15 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复