Detecting loops in code
Sometimes when we look at a stack trace and disassembled code we see that a crash couldn’t have happened if the code path was linear. In such cases we need to see if there is any loop that changes some variables. This is greatly simplified if we have source code but in cases where we don’t have access to source code it is still possible to detect loops. We just need to find a direct (JMP) or conditional jump instruction (Jxxx, for example, JE) after the crash point branching to the beginning of the loop before the crash point as shown in the following pseudo code:
set the pointer value
…
label:
…
>>> crash when dereferencing the pointer
…
change the pointer value
…
jmp label
Let’s look at one example I found very interesting because it also shows __thiscall calling convention for C++ code generated by Visual С++ compiler. Before we look at the dump I quickly remind you about how C++ non-static class methods are called. Let’s first look at non-virtual method call.
class A
{
public:
int foo() { return i; }
virtual int bar() { return i; }
private:
int i;
};
Internally class members are accessed via implicit this pointer (passed via ECX):
int A::foo() { return this->i; }
Suppose we have an object instance of class A and we call its foo method:
A obj;
obj.foo();
The compiler has to generate code which calls foo function and the code inside the function has to know which object it is associated with. So internally the compiler passes implicit parameter - a pointer to that object. In pseudo code:
int foo_impl(A *this)
{
return this->i;
}
A obj;
foo_impl(&obj);
In x86 assembly language it should be similar to this code:
lea ecx, obj
call foo_impl
If you have obj declared as a local variable:
lea ecx, [ebp-N]
call foo_impl
If you have a pointer to an obj then the compiler usually generates mov instruction instead of lea instruction:
A *pobj;
pobj->foo();
mov ecx, [ebp-N]
call foo_impl
If you have other function parameters they are pushed on the stack from right to left. This is __thiscall calling convention. For virtual function call we have an indirect call through virtual function table. The pointer to it is the first object layout member and in the latter case where the pointer to obj is declared as the local variable we have the following x86 code:
A *pobj;
pobj->bar();
mov ecx, [ebp-N]
mov eax, [ecx]
call [eax]
Now let’s look at the crash point and stack trace:
0:021> r
eax=020864ee ebx=00000000 ecx=0000005c edx=7518005c esi=020864dc edi=00000000
eip=67dc5dda esp=075de820 ebp=075dea78 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
component!CDirectory::GetDirectory+0×8a:
67dc5dda 8b03 mov eax,dword ptr [ebx] ds:0023:00000000=????????
0:021> k
ChildEBP RetAddr
075dea78 004074f0 component!CDirectory::GetDirectory+0x8a
075deaac 0040e4fc component!CDirectory::FindFirstFileW+0xd0
075dffb8 77e64829 component!MonitorThread+0x13
075dffec 00000000 kernel32!BaseThreadStart+0x34
If we look at GetDirectory code we would see:
0:021> .asm no_code_bytes
Assembly options: no_code_bytes
0:021> uf component!CDirectory::GetDirectory
component!CDirectory::GetDirectory:
67dc5d50 push ebp
67dc5d51 mov ebp,esp
67dc5d53 push 0FFFFFFFFh
67dc5d55 push offset component!CreateErrorInfo+0x553 (67ded93b)
67dc5d5a mov eax,dword ptr fs:[00000000h]
67dc5d60 push eax
67dc5d61 mov dword ptr fs:[0],esp
67dc5d68 sub esp,240h
67dc5d6e mov eax,dword ptr [component!__security_cookie (67e0113c)]
67dc5d73 mov dword ptr [ebp-10h],eax
67dc5d76 mov eax,dword ptr [ebp+8]
67dc5d79 test eax,eax
67dc5d7b push ebx
67dc5d7c mov ebx,ecx
67dc5d7e mov dword ptr [ebp-238h],ebx
67dc5d84 je component!CDirectory::GetDirectory+0×2a1 (67dc5ff1)
component!CDirectory::GetDirectory+0x3a:
67dc5d8a cmp word ptr [eax],0
67dc5d8e je component!CDirectory::GetDirectory+0x2a1 (67dc5ff1)
component!CDirectory::GetDirectory+0x44:
67dc5d94 push esi
67dc5d95 push eax
67dc5d96 call dword ptr [component!_imp__wcsdup (67df050c)]
67dc5d9c add esp,4
67dc5d9f mov dword ptr [ebp-244h],eax
67dc5da5 mov dword ptr [ebp-240h],eax
67dc5dab push 5Ch
67dc5dad lea ecx,[ebp-244h]
67dc5db3 mov dword ptr [ebp-4],0
67dc5dba call component!CStrToken::Next (67dc4f80)
67dc5dbf mov esi,eax
67dc5dc1 test esi,esi
67dc5dc3 je component!CDirectory::GetDirectory+0x28c (67dc5fdc)
component!CDirectory::GetDirectory+0x79:
67dc5dc9 push edi
67dc5dca lea ebx,[ebx]
component!CDirectory::GetDirectory+0x80:
67dc5dd0 cmp word ptr [esi],0
67dc5dd4 je component!CDirectory::GetDirectory+0x28b (67dc5fdb)
component!CDirectory::GetDirectory+0x8a:
>>> 67dc5dda mov eax,dword ptr [ebx]
67dc5ddc mov ecx,ebx
…
If we trace EBX backwards (red) we would see that it comes from ECX (blue) so ECX could be considered as an implicit this pointer according to __thiscall calling convention. Therefore it looks like the caller passed NULL this pointer via ECX.
Let’s look at the caller. To see the code we can either disassemble FindFirstFileW or disassemble backwards at the GetDirectory return address. I’ll do the latter:
0:021> k
ChildEBP RetAddr
075dea78 004074f0 component!CDirectory::GetDirectory+0×8a
075deaac 0040e4fc component!CDirectory::FindFirstFileW+0xd0
075dffb8 77e64829 component!MonitorThread+0×13
075dffec 00000000 kernel32!BaseThreadStart+0×34
0:021> ub 004074f0
component!CDirectory::FindFirstFileW+0xbe:
004074de pop ebp
004074df clc
004074e0 mov ecx,dword ptr [esi+8E4h]
004074e6 mov eax,dword ptr [ecx]
004074e8 push 0
004074ea push 0
004074ec push edx
004074ed call dword ptr [eax+10h]
We see that ECX is our this pointer. However the virtual table pointer is taken from the memory it references:
004074e6 mov eax,dword ptr [ecx]
…
…
004074ed call dword ptr [eax+10h]
Were ECX a NULL we would have had our crash at this point. However we have our crash in the called function. So it couldn’t be NULL. There is a contradiction here. The only plausible explanation is that in GetDirectory function there is a loop that changes EBX (shown in red in GetDirectory function code above). If we have a second look at the code we would see that EBX is saved in [ebp-238h] local variable before it is used:
0:021> uf component!CDirectory::GetDirectory
component!CDirectory::GetDirectory:
67dc5d50 push ebp
67dc5d51 mov ebp,esp
67dc5d53 push 0FFFFFFFFh
67dc5d55 push offset component!CreateErrorInfo+0x553 (67ded93b)
67dc5d5a mov eax,dword ptr fs:[00000000h]
67dc5d60 push eax
67dc5d61 mov dword ptr fs:[0],esp
67dc5d68 sub esp,240h
67dc5d6e mov eax,dword ptr [component!__security_cookie (67e0113c)]
67dc5d73 mov dword ptr [ebp-10h],eax
67dc5d76 mov eax,dword ptr [ebp+8]
67dc5d79 test eax,eax
67dc5d7b push ebx
67dc5d7c mov ebx,ecx
67dc5d7e mov dword ptr [ebp-238h],ebx
67dc5d84 je component!CDirectory::GetDirectory+0×2a1 (67dc5ff1)
component!CDirectory::GetDirectory+0x3a:
67dc5d8a cmp word ptr [eax],0
67dc5d8e je component!CDirectory::GetDirectory+0x2a1 (67dc5ff1)
component!CDirectory::GetDirectory+0x44:
67dc5d94 push esi
67dc5d95 push eax
67dc5d96 call dword ptr [component!_imp__wcsdup (67df050c)]
67dc5d9c add esp,4
67dc5d9f mov dword ptr [ebp-244h],eax
67dc5da5 mov dword ptr [ebp-240h],eax
67dc5dab push 5Ch
67dc5dad lea ecx,[ebp-244h]
67dc5db3 mov dword ptr [ebp-4],0
67dc5dba call component!CStrToken::Next (67dc4f80)
67dc5dbf mov esi,eax
67dc5dc1 test esi,esi
67dc5dc3 je component!CDirectory::GetDirectory+0x28c (67dc5fdc)
component!CDirectory::GetDirectory+0x79:
67dc5dc9 push edi
67dc5dca lea ebx,[ebx]
component!CDirectory::GetDirectory+0x80:
67dc5dd0 cmp word ptr [esi],0
67dc5dd4 je component!CDirectory::GetDirectory+0x28b (67dc5fdb)
component!CDirectory::GetDirectory+0x8a:
>>> 67dc5dda mov eax,dword ptr [ebx]
67dc5ddc mov ecx,ebx
…
If we look further past the crash point we would see that [ebp-238h] value is changed and then used again to change EBX:
component!CDirectory::GetDirectory+0x80:
67dc5dd0 cmp word ptr [esi],0
67dc5dd4 je component!CDirectory::GetDirectory+0×28b (67dc5fdb)
component!CDirectory::GetDirectory+0x8a:
>>> 67dc5dda mov eax,dword ptr [ebx]
67dc5ddc mov ecx,ebx
…
…
…
component!CDirectory::GetDirectory+0×11e:
67dc5e6e mov eax,dword ptr [ebp-23Ch]
67dc5e74 mov ecx,dword ptr [eax]
67dc5e76 mov dword ptr [ebp-238h],ecx
67dc5e7c jmp component!CDirectory::GetDirectory+0×20e (67dc5f5e)
…
…
…
component!CDirectory::GetDirectory+0×23e:
67dc5f8e cmp esi,edi
67dc5f90 mov ebx,dword ptr [ebp-238h]
67dc5f96 jne component!CDirectory::GetDirectory+0×80 (67dc5dd0)
We see that after changing EBX the code jumps to 67dc5dd0 address and this address is just before our crash point. It looks like a loop. Therefore there is no contradiction. ECX as this pointer was passed as non-NULL and valid pointer. Before the loop started its value was passed to EBX. In the loop body EBX was changed and after some loop iterations the new value became NULL. It could be the case that there were no checks for NULL pointers in the loop code.
- Dmitry Vostokov @ DumpAnalysis.org -