前言
当你接触了一款叫做“变速齿轮”的软件，你可以玩上一整个星期。因为它实在是太酷炫了，无论网页（Flash、HTML5）、还是小软件，又或者是单机游戏，他总能给你惊喜，唯独网游不能！那么我们今天就来探究一下变速原理，并且我们试试看，能不能写出一个更牛逼的变速软件。
我们本章节内容大致如下图：
变速原理探究变速齿轮(GearNT 0.46) 原理
我们拿个经典的变速软件开刀，这就是“变速齿轮”了，感觉变速的始祖就是他了。记得之前读过一篇文章，关于兄弟变速的，内容大致是说兄弟变速的创造历史，作者也是个很早很牛逼的程序辕。他写的变速器是受到了“变速齿轮”的启发，并且用了多个方面重新实现了一款变速软件，可以通过内核实现变速。所以，为了起到同样的这种启发作用，我们就拿“变速齿轮”这款软件做为学习的样本吧。
首先打开一个32位的记事本，作者的系统是 Win7x64 的，但是一代经典还是年事已高，只支持32位软件，所以吧用个32位的记事本研究下咯。然后在“变速齿轮”里对记事本调一下速度，随便调，我就不截图了。使用软件PCHunter，扫描记事本中的应用层钩子，我们可以看到如下图：
看到他被挂钩了8个API相关个 inline hook，其中两个API钩子能够实现“继承”，简单的说就是打开一个登录器使用了“变速齿轮”加速，然后登录器打开游戏时，游戏也会被加速。然后剩下的6个API都是关键，分别是
GetTickCount
QueryPerformanceCounter
GetMessageTime
SetTimer
timeGetTime
timeSetEvent游戏常用的一般都是高精度计时，比如 Timer 啊什么的并不常用于游戏，因为精度一般。接下来就让我们深入了解“高精度计时API”
高精度计时API
GetTickCount
GetTickCount64
QueryPerformanceCounter
timeGetTime顾名思义，就是精度很高，时间不会产生偏差，我们可以写个例子代码（使用 MinGW 编译）如下
代码由for(;;){}来产生无限循环，Sleep(1000)来产生1秒的延迟。然后分别由3个高精度计时API来计算时间差，并吧计算结果显示出来。由图上可以看出，QueryPerformanceCounter和timeGetTime的计算精度还是可以的，GetTickCount的精度略差。我们暂且不管精度怎么样，接来下操起家伙（IDA）就是干。
逆向与深入计时APIQueryPerformanceCounter 原理详解
我们就先对QueryPerformanceCounter进行逆向吧，毕竟所有高精度计时API中，精度最最高的就是他。研究他比较有“说服力”（假的，纯粹是因为很想知道这个API的工作原理以及为毛精度如此高。我们先试用 OllyICE 跟一下发现QueryPerformanceCounter的原型是ntdll.RtlQueryPerformanceCounter，我们就使用IDA对ntdll进行逆向。
由于算法还是比较复杂的，而且运算比较多，用的汇编指令不是特别常见，所以我们还是直接F5吧
我们得到他的返回值的算法应该就是这样
(LARGE_INTEGER)((MEMORY[0x7FFE03B8] + __rdtsc()) >> (MEMORY[0x7FFE02ED] >> 2))大致原理就是(*a+rdtsc)>>(*b>>2)，a、b是两个内存指针，我们尝试下
使用CE，打开程序的7FFE03B8地址，可以看到这个数字是在跳动（变化）的，我们要改的话不怎么好改，再打开7FFE02ED地址，可以看到一个固定的值不会变化。那我们尝试改一下这个地址里的值，然后发现改不了。然后又试了下写进程序里用WriteProcessMemory修改也改不动，再尝试使用VirtualProtectEx修改内存属性PAGE_EXECUTE_READWRITE，完了改写数值能成功，但是会导致GetTickCount和timeGetTime计时异常。哎呀，难道说…… 这个地址，有蹊跷！
深入 0x7FFE0000 SharedUserData
我们百度0x7FFE0000这个地址，得到了一个叫做 SharedUserData 的东东，是个内核的映射，Ring3下是只读的，所以如上，我们并改不了他的数据（确切的说改了，数据就不会同步，会导致大量的API无法工作）。
这个结构在应用层和内核的地址如下表
| 内核起始地址 | 内核结束地址 | 用户起始地址 | 用户结束地址 |
32 系统 | 0xFFDF0000 | 0xFFDF0FFF | 0x7FFE0000 | 0x7FFE0FFF |
64 系统 | 0xFFFFF780 00000000 | 0xFFFFF780 00000FFF | 0x7FFE0000 | 0x7FFE0FFF |
然后我们使用 LiveKD / WinDbg 对 KUSER_SHARED_DATA 的结构进行列出，在我的电脑（Win7x64 7601）上，他的结构如下
WDFLDR!KUSER_SHARED_DATA
+0x000 TickCountLowDeprecated : Uint4B
+0x004 TickCountMultiplier : Uint4B
+0x008 InterruptTime : _KSYSTEM_TIME
+0x014 SystemTime : _KSYSTEM_TIME
+0x020 TimeZoneBias : _KSYSTEM_TIME
+0x02c ImageNumberLow : Uint2B
+0x02e ImageNumberHigh : Uint2B
+0x030 NtSystemRoot : [260] Wchar
+0x238 MaxStackTraceDepth : Uint4B
+0x23c CryptoExponent : Uint4B
+0x240 TimeZoneId : Uint4B
+0x244 LargePageMinimum : Uint4B
+0x248 AitSamplingValue : Uint4B
+0x24c AppCompatFlag : Uint4B
+0x250 RNGSeedVersion : Uint8B
+0x258 GlobalValidationRunlevel : Uint4B
+0x25c TimeZoneBiasStamp : Int4B
+0x260 Reserved2 : Uint4B
+0x264 NtProductType : _NT_PRODUCT_TYPE
+0x268 ProductTypeIsValid : UChar
+0x269 Reserved0 : [1] UChar
+0x26a NativeProcessorArchitecture : Uint2B
+0x26c NtMajorVersion : Uint4B
+0x270 NtMinorVersion : Uint4B
+0x274 ProcessorFeatures : [64] UChar
+0x2b4 Reserved1 : Uint4B
+0x2b8 Reserved3 : Uint4B
+0x2bc TimeSlip : Uint4B
+0x2c0 AlternativeArchitecture : _ALTERNATIVE_ARCHITECTURE_TYPE
+0x2c4 AltArchitecturePad : [1] Uint4B
+0x2c8 SystemExpirationDate : _LARGE_INTEGER
+0x2d0 SuiteMask : Uint4B
+0x2d4 KdDebuggerEnabled : UChar
+0x2d5 MitigationPolicies : UChar
+0x2d5 NXSupportPolicy : Pos 0, 2 Bits
+0x2d5 SEHValidationPolicy : Pos 2, 2 Bits
+0x2d5 CurDirDevicesSkippedForDlls : Pos 4, 2 Bits
+0x2d5 Reserved : Pos 6, 2 Bits
+0x2d6 Reserved6 : [2] UChar
+0x2d8 ActiveConsoleId : Uint4B
+0x2dc DismountCount : Uint4B
+0x2e0 ComPlusPackage : Uint4B
+0x2e4 LastSystemRITEventTickCount : Uint4B
+0x2e8 NumberOfPhysicalPages : Uint4B
+0x2ec SafeBootMode : UChar
+0x2ed Reserved12 : [3] UChar
+0x2f0 SharedDataFlags : Uint4B
+0x2f0 DbgErrorPortPresent : Pos 0, 1 Bit
+0x2f0 DbgElevationEnabled : Pos 1, 1 Bit
+0x2f0 DbgVirtEnabled : Pos 2, 1 Bit
+0x2f0 DbgInstallerDetectEnabled : Pos 3, 1 Bit
+0x2f0 DbgLkgEnabled : Pos 4, 1 Bit
+0x2f0 DbgDynProcessorEnabled : Pos 5, 1 Bit
+0x2f0 DbgConsoleBrokerEnabled : Pos 6, 1 Bit
+0x2f0 DbgSecureBootEnabled : Pos 7, 1 Bit
+0x2f0 SpareBits : Pos 8, 24 Bits
+0x2f4 DataFlagsPad : [1] Uint4B
+0x2f8 TestRetInstruction : Uint8B
+0x300 QpcFrequency : Int8B
+0x308 SystemCallPad : [3] Uint8B
+0x320 TickCount : _KSYSTEM_TIME
+0x320 TickCountQuad : Uint8B
+0x320 ReservedTickCountOverlay : [3] Uint4B
+0x32c TickCountPad : [1] Uint4B
+0x330 Cookie : Uint4B
+0x334 CookiePad : [1] Uint4B
+0x338 ConsoleSessionForegroundProcessId : Int8B
+0x340 TimeUpdateSequence : Uint8B
+0x348 BaselineSystemTimeQpc : Uint8B
+0x350 BaselineInterruptTimeQpc : Uint8B
+0x358 QpcSystemTimeIncrement : Uint8B
+0x360 QpcInterruptTimeIncrement : Uint8B
+0x368 QpcSystemTimeIncrement32 : Uint4B
+0x36c QpcInterruptTimeIncrement32 : Uint4B
+0x370 QpcSystemTimeIncrementShift : UChar
+0x371 QpcInterruptTimeIncrementShift : UChar
+0x372 Reserved8 : [14] UChar
+0x380 UserModeGlobalLogger : [16] Uint2B
+0x3a0 ImageFileExecutionOptions : Uint4B
+0x3a4 LangGenerationCount : Uint4B
+0x3a8 Reserved4 : Uint8B
+0x3b0 InterruptTimeBias : Uint8B
+0x3b8 TscQpcBias : Uint8B
+0x3c0 ActiveProcessorCount : Uint4B
+0x3c4 ActiveGroupCount : UChar
+0x3c5 Reserved9 : UChar
+0x3c6 TscQpcData : Uint2B
+0x3c6 TscQpcEnabled : UChar
+0x3c7 TscQpcShift : UChar
+0x3c8 TimeZoneBiasEffectiveStart : _LARGE_INTEGER
+0x3d0 TimeZoneBiasEffectiveEnd : _LARGE_INTEGER
+0x3d8 XState : _XSTATE_CONFIGURATION然后顺个便，把其他几个API也给逆了，对照上表，我们得到详细的注解。
QueryPerformanceCounter
(LARGE_INTEGER)((MEMORY[0x7FFE03B8] + __rdtsc()) >> (MEMORY[0x7FFE02ED] >> 2));
+0x3b8 TscQpcBias : Uint8B
+0x2ed Reserved12 : [3] UChar
GetTickCount
MEMORY[0x7FFE0004] * (MEMORY[0x7FFE0324] << 8)
+ (MEMORY[0x7FFE0320] * (unsigned __int64)MEMORY[0x7FFE0004] >> 24)
+0x004 TickCountMultiplier : Uint4B
+0x320 TickCount : _KSYSTEM_TIME
GetTickCount64
(MEMORY[0x7FFE0324] * (unsigned __int64)MEMORY[0x7FFE0004] << 8)
+ (MEMORY[0x7FFE0320] * (unsigned __int64)MEMORY[0x7FFE0004] >> 24)
timeGetTime@0x41B00000
dword_41B28FE0 + (unsigned __int64)((MEMORY[0x7FFE0008] - qword_41B28FD8) / 10000)
+0x008 InterruptTime : _KSYSTEM_TIME这边还有个 _KSYSTEM_TIME 结构，这个结构是3个DWORD32。
ntdll!_KSYSTEM_TIME
+0x000 LowPart : Uint4B
+0x004 High1Time : Int4B
+0x008 High2Time : Int4B有了他，我们能够事倍功半，呸！事半功倍。接下来我们就要进内核玩Ring0了，想想就有些小激动。
深入与验证使用CE、MinGW（G++）验证
我们先来用 MinGW 写一个小程序，程序原理如下图
程序根据这个原理，来推出新值下的时间，和老的时间比值。这个值也就是之后能否实现加速的关键，如果无法反推出这个值，那么就无法实现加速。我们开始写代码吧
程序完美运行！鼓掌，那我们就确定了这个值，能被用于加速，里面的数学原理我也不懂，但从结果表明，应该和4（1<<2）的倍数有关。得到了这个值，我们接下来就用CE的内核模式，来修改内核数据。第一步先开启CE的内核设置，按照我下图这么设置
然后打开 System 进程，找到地址0xFFFFF780000002ED（作者电脑是64位，32位请用0xFFDF02ED），尝试着 Ring0 改写（给作者 666）。我们先运行时钟小程序，然后把上面计算出来的二倍速数值填写进去。观察变化
可以看出，修改后了，成功加速了QueryPerformanceCounter，同时又不影响其他的计时API，那我们就验证完毕，接下来就是写自己的内核变速器了
变速器的实现（Win7x64 内核变速）
由于64位系统需要签名，作者又是穷diao，那没法自己写驱动了（其实以前写都是用kmdkit来写的，汇编写64位驱动没底气），那就直接考虑用WinRing0或者WinIo64来实现。 首先作者考虑的是WinRing0，因为有签名嘛，所以首选他，结果用的时候发现没有物理内存读写接口，然后就想着怎么开启，重新编译了一番，发现众多的坑。等到我把所有的DLL条件编译去除，然后重新编译后，用上发现，并不能用。一开始以为内核是有物理内存读写的，只是应用层的dll给去除了。
从上面这幅图上完全看不出有问题是吧，感觉这个内核功能齐全，但是看下面这个，哎！
强烈的怀疑作者是不是弄了两份驱动，一份是收费PRO版本，支持物理内存读写，一份是免费版本，给大家拿来玩的。与其这样要装庞大的WDK重新编译驱动，不如直接用WinIo64这么想。那我们下面就用VB+WinIo64展开。
首先是为了能够运行没有签名的WinIo64.sys，我们不得不把系统的测试模式开出来，那下面一个命令搞定
bcdedit /set testsigning on
然后我们就编写代码，使用VB写简单又好用，代码如下图，很少的代码。
运行下，我们试试效果，咩哈哈哈！
使用PCHunter检测，不产生任何的Ring3/Ring0钩子，堪称完美，还不赶紧试试
