|
|
|---|---|
|
|
你这个样本是有点特殊： API调用总是在这个vCall上；通常不应该“固定”在某个vCall上。 我在“一个反调试有特色的CrackMe”里提到看过的两个VMP3的样本v301和v309，外壳部分(vmp1)都各有11个vCall，按入口地址依次标记为vCall1~vCallB。 从壳的入口到第一个vGetHash(v301是一个GetHash函数)之间，所有vCall的记录都为12次，但不是总在同一个vCall上： v301样本 1) vCall6 kernel32.LocalAlloc ; size 0xA4; for anti data! 2) vCallA kernel32.GetCurrentProcess 3) vCall5 kernel32.IsDebuggerPresent 4) vCallB kernel32.CheckRemoteDebuggerPresent 5) vCall2 ntdll.ZwQueryInformationProcess ; ProcessDebugPort 6) vCall8 kernel32.GetCurrentThread 7) vCallB ntdll.ZwSetInformationThread 8) vCall4 ntdll.ZwQuerySystemInformation ; SystemDebuggerInfo 9) vCall5 ntdll.ZwQuerySystemInformation ; SystemModuleInfo, get buffer size 10) vCall8 kernel32.LocalAlloc ; alloc buf 11) vCall4 ntdll.ZwQuerySystemInformation ; SystemModuleInfo, query 12) vCall2 kernel32.LocalFree ; free buf v309样本 1) vCall1 kernel32.LocalAlloc ; size 0xA4; for anti data! 2) vCall3 kernel32.GetCurrentProcess 3) vCall4 kernel32.IsDebuggerPresent 4) vCall7 kernel32.CheckRemoteDebuggerPresent 5) vCall4 ntdll.ZwQueryInformationProcess ; ProcessDebugPort 6) vCall4 kernel32.GetCurrentThread 7) vCall7 ntdll.ZwSetInformationThread 8) vCall8 ntdll.ZwQuerySystemInformation ; SystemDebuggerInfo 9) vCall7 ntdll.ZwQuerySystemInformation ; SystemModuleInfo, get buffer size 10) vCall1 kernel32.LocalAlloc ; alloc buf 11) vCall6 ntdll.ZwQuerySystemInformation ; SystemModuleInfo, query 12) vCallA kernel32.LocalFree ; free buf 这两个样本在vmp0段解密后，它的vCall都各多达110个！即壳代码部分VM的handler数要远远少于用户代码保护部分VM的handler。 我对VMP3研究得还不多，也许您可以把样本放上来大家看看。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
感谢mist |
|
|
新版本3.2改进了反调试
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
