Is this an example of AntiDebug using GetKeyboardState? This is some fakeav software and I've run this thru idapro and get inconclusive results - I think because edx is not set to the right value. Has anyone seen this before and can explain?


401000 mov edi, edi
401002 push ebp
401003 mov ebp, esp
401005 sub esp, 08
401008 push 00
DEBUG - 40100a USER32.dll.GetKeyboardState(0)->1 <--- changes value of edx
40100a call dword ptr dword ptr [471050]
>>>>>>>>>>>>>>>>>>>>>>>
401010 xor eax, eax
401012 jno 401042
401042 cmp ecx, edx
401044 js 40104a

40104a mov ecx, [7ffe0304]

ecx[77375e74]edx[7c90eb94]

DEBUG - 401050 NTDLL.DLL.KiFastSystemCallReturn ()
401050 call ecx
>>>>>>>>>>>>>>>>>>>>>>>
401052 mov cl, [edx] <--- ecx depends on edx

ecx[77375e00]

401054 lea edx, [esp-08]

ecx[77375e00]
401058 sub ecx, 03
ecx[77375dfd]
40105b movzx eax, cl
eax[fd]
40105e ror edx, cl
401060 call 401067


401067 mov eax, fs:[eax-a8] <-- position in _teb structure depends on initial value of edx

Yes. Show full dump of this part of the code, rather than pieces and opcodes.

Hi

I think this is an obfuscated way of getting the TEB address. If GetKeyboardState returns KiFastSystemCallRet in EDX (which it seems to from a quick "assembling" test in Olly), then the instruction

401052 mov cl, [edx]

will return the 0xC3 byte from the system call



and the rest follows:



No crystal ball is required to guess there's an [eax+30h] (PEB offset) instruction that soon follows..