本文共 3999 字,大约阅读时间需要 13 分钟。
在工程中看到一个魔法数, (WCHAR*)0x7FFE0030
想替换这个魔法数为其他可理解的值.
试验出一种方法, 当我们在重构和逆向时,遇到一个地址类型的魔法数, 可以采用这种方法确定魔法数的由来.
这方法有普遍性, 可以用来解决未知的地址类型魔法数.
试验环境: Vmware中的WinXpSp3.
因为是一个可以跑的开源工程, 在WinDbg中看 0x7FFE0030 是啥串?
kd> dW 0x7FFE00307ffe0030 0043 003a 005c 0057 0049 004e 0044 004f C.:.\.W.I.N.D.O.7ffe0040 0057 0053 0000 0000 0000 0000 0000 0000 W.S.............7ffe0050 0000 0000 0000 0000 0000 0000 0000 0000 ................7ffe0060 0000 0000 0000 0000 0000 0000 0000 0000 ................7ffe0070 0000 0000 0000 0000 0000 0000 0000 0000 ................7ffe0080 0000 0000 0000 0000 0000 0000 0000 0000 ................7ffe0090 0000 0000 0000 0000 0000 0000 0000 0000 ................7ffe00a0 0000 0000 0000 0000 0000 0000 0000 0000 ................那这个地址怎么来的呢 ?
是函数还是全局变量结构中的地址呢?
kd> uf 7FFE0030Flow analysis was incomplete, some code may be missingSharedUserData+0x30:7ffe0030 43 inc ebx7ffe0031 003a add byte ptr [edx],bh7ffe0033 005c0057 add byte ptr [eax+eax+57h],bl可以看出 7FFE0030 是 SharedUserData 中的一个地址, offset = 0x30
SharedUserData 看起来像一个全局变量
查看 SharedUserData 的数据
kd> dd SharedUserData7ffe0000 00017fd8 0fa00000 9327a1f0 000000037ffe0010 00000003 89068412 01ce9f1f 01ce9f1f7ffe0020 f1dcc000 ffffffbc ffffffbc 014c014c7ffe0030 003a0043 0057005c 004e0049 004f00447ffe0040 00530057 00000000 00000000 000000007ffe0050 00000000 00000000 00000000 000000007ffe0060 00000000 00000000 00000000 000000007ffe0070 00000000 00000000 00000000 00000000查找SharedUserData的数据类型定义
在WRK中搜索, 看到
#define SharedUserData ((KUSER_SHARED_DATA * const) KI_USER_SHARED_DATA)
在WinDbg中查找 KUSER_SHARED_DATA 的具体数据结构名称
kd> dt nt!*user* ntkrnlpa!_HEAP_USERDATA_HEADER ntkrnlpa!_HEAP_USERDATA_HEADER ntkrnlpa!_RTL_USER_PROCESS_PARAMETERS ntkrnlpa!_KUSER_SHARED_DATA确定 SharedUserData的定义为
ntkrnlpa!_KUSER_SHARED_DATA SharedUserData;
查看 SharedUserData 的结构值
kd> dt ntkrnlpa!_KUSER_SHARED_DATA 7ffe0000 +0x000 TickCountLow : 0x17fd8 +0x004 TickCountMultiplier : 0xfa00000 +0x008 InterruptTime : _KSYSTEM_TIME +0x014 SystemTime : _KSYSTEM_TIME +0x020 TimeZoneBias : _KSYSTEM_TIME +0x02c ImageNumberLow : 0x14c +0x02e ImageNumberHigh : 0x14c +0x030 NtSystemRoot : [260] 0x43 +0x238 MaxStackTraceDepth : 0 +0x23c CryptoExponent : 0 +0x240 TimeZoneId : 0 +0x244 Reserved2 : [8] 0 +0x264 NtProductType : 1 ( NtProductWinNt ) +0x268 ProductTypeIsValid : 0x1 '' +0x26c NtMajorVersion : 5 +0x270 NtMinorVersion : 1 +0x274 ProcessorFeatures : [64] "" +0x2b4 Reserved1 : 0x7ffeffff +0x2b8 Reserved3 : 0x80000000 +0x2bc TimeSlip : 0 +0x2c0 AlternativeArchitecture : 0 ( StandardDesign ) +0x2c8 SystemExpirationDate : _LARGE_INTEGER 0x0 +0x2d0 SuiteMask : 0x110 +0x2d4 KdDebuggerEnabled : 0x3 '' +0x2d5 NXSupportPolicy : 0x2 '' +0x2d8 ActiveConsoleId : 0 +0x2dc DismountCount : 0 +0x2e0 ComPlusPackage : 0xffffffff +0x2e4 LastSystemRITEventTickCount : 0x254cd +0x2e8 NumberOfPhysicalPages : 0x3ff7c +0x2ec SafeBootMode : 0 '' +0x2f0 TraceLogging : 0 +0x2f8 TestRetInstruction : 0xc3 +0x300 SystemCall : 0x7c92e4f0 +0x304 SystemCallReturn : 0x7c92e4f4 +0x308 SystemCallPad : [3] 0 +0x320 TickCount : _KSYSTEM_TIME +0x320 TickCountQuad : 0 +0x330 Cookie : 0x5b973f62找出 0x7FFE0030 的出处
0x7FFE0030 = SharedUserData结构地址(7ffe0000) + 0x30,
结合WinDbg 列出的 SharedUserData结构值, 可以看到 (7ffe0000) + 0x30 为 SharedUserData.NtSystemRoot
是一个260个wchar_t的宽字符串缓冲区
kd> dt ntkrnlpa!_KUSER_SHARED_DATA 7ffe0000 +0x000 TickCountLow : 0x17fd8 ... +0x030 NtSystemRoot : [260] 0x43
缓冲区size的确定
+0x030 NtSystemRoot : [260] 0x43 +0x238 MaxStackTraceDepth : 0
kd> dt ntkrnlpa!_KUSER_SHARED_DATA 7ffe0000 +0x000 TickCountLow : 0x17fd8 ... +0x030 NtSystemRoot : [260] 0x43
现在找到 0x7FFE0030的出处了.
转载地址:https://lostspeed.blog.csdn.net/article/details/10197349 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!