export table | Life In Hex

VMProtect and dbghelp.dll bug in export processing

If your Olly is crashing when loading executable protected by VMProtect, you most likely have outdated dbghelp.dll somewhere on your path. Grab the latest version from Microsoft and put it in the Olly folder.

Well, that might be enough to work around the issue that I had - but I still wanted to know what's causing the crash.

Cause of the problem

If you try to debug Olly with another Olly, you'll see the Access Violation happening somewhere in dbghelp.dll:

Log data, item 0
 Address=6D529B91
 Message=Access violation when reading [C4983C3E]

Log data, item 0

Address=6D529B91

Message=Access violation when reading [C4983C3E]

6D529B8E   8B55 F4          MOV EDX,DWORD PTR SS:[EBP-C]
6D529B91   66:833C42 00     CMP WORD PTR DS:[EDX+EAX*2],0
6D529B96   75 07            JNZ SHORT DBGHELP.6D529B9F

6D529B8E 8B55 F4 MOV EDX,DWORD PTR SS:[EBP-C]

6D529B91 66:833C42 00 CMP WORD PTR DS:[EDX+EAX*2],0

6D529B96 75 07 JNZ SHORT DBGHELP.6D529B9F

Check register values in Olly:

EAX 00000000   <----------------
ECX 00000001
EDX C4983C3E   <----------------
EBX 0458A390
ESP 0018A450
EBP 0018AC94
ESI 045EE7E8
EDI 045EF738
EIP 6D529B91 DBGHELP.6D529B91

EAX 00000000 <----------------

ECX 00000001

EDX C4983C3E <----------------

EBX 0458A390

ESP 0018A450

EBP 0018AC94

ESI 045EE7E8

EDI 045EF738

EIP 6D529B91 DBGHELP.6D529B91

For some reason, value in EDX is garbage and therefore access violation happens.

Call stack doesn't tell us much:

Call stack of main thread
Procedure / arguments                 Called from              Name from PDB
DBGHELP.6D52997D                      DBGHELP.6D52ACFD         LoadExportSymbols(struct _MODULE_ENTRY *, struct _IMGHLP_DEBUG_DATA *)
DBGHELP.6D52A755                      DBGHELP.6D52B035         load(char *, DWORD)
DBGHELP.6D52ADB8                      DBGHELP.6D5264B2         InternalLoadModule(char *, char *FullPath, char *Str1, unsigned __int64, unsigned __int32, void *, struct _DBGHELP_MODLOAD_DATA *, unsigned __int32)
DBGHELP.SymLoadModuleEx               DBGHELP.6D526502              
DBGHELP.SymLoadModule64               DBGHELP.6D526522            
DBGHELP.SymLoadModule                 OLLYDBG.00491502

Call stack of main thread

Procedure / arguments Called from Name from PDB

DBGHELP.6D52997D DBGHELP.6D52ACFD LoadExportSymbols(struct _MODULE_ENTRY *, struct _IMGHLP_DEBUG_DATA *)

DBGHELP.6D52A755 DBGHELP.6D52B035 load(char *, DWORD)

DBGHELP.6D52ADB8 DBGHELP.6D5264B2 InternalLoadModule(char *, char *FullPath, char *Str1, unsigned __int64, unsigned __int32, void *, struct _DBGHELP_MODLOAD_DATA *, unsigned __int32)

DBGHELP.SymLoadModuleEx DBGHELP.6D526502

DBGHELP.SymLoadModule64 DBGHELP.6D526522

DBGHELP.SymLoadModule OLLYDBG.00491502

And same piece of code in IDA doesn't help much either:

.text:6D529B8E loop_check_something:                   ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+225j
.text:6D529B8E                 mov     edx, [ebp+ptrAllocatedMemory]
.text:6D529B91                 cmp     word ptr [edx+eax*2], 0 ; <----------------
.text:6D529B96                 jnz     short loc_6D529B9F
.text:6D529B98                 add     [ebp+var_10], 10h
.text:6D529B9C                 inc     [ebp+arg_4]
.text:6D529B9F
.text:6D529B9F loc_6D529B9F:                           ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+219j
.text:6D529B9F                 inc     eax
.text:6D529BA0                 cmp     eax, ecx
.text:6D529BA2                 jb      short loop_check_something

.text:6D529B8E loop_check_something: ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+225j

.text:6D529B8E mov edx, [ebp+ptrAllocatedMemory]

.text:6D529B91 cmp word ptr [edx+eax*2], 0 ; <----------------

.text:6D529B96 jnz short loc_6D529B9F

.text:6D529B98 add [ebp+var_10], 10h

.text:6D529B9C inc [ebp+arg_4]

.text:6D529B9F

.text:6D529B9F loc_6D529B9F: ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+219j

.text:6D529B9F inc eax

.text:6D529BA0 cmp eax, ecx

.text:6D529BA2 jb short loop_check_something

So, it's debugging time! Set breakpoint to start of LoadExportSymbols, then set hardware breakpoint on write to address [ebp+ptrAllocatedMemory].

First hit is initialization of variable with 0:

.text:6D529986                 xor     ecx, ecx
.text:6D529988                 test    byte ptr dword_6D57F438+1, 4
.text:6D52998F                 mov     [ebp+ptrAllocatedMemory], ecx

.text:6D529986 xor ecx, ecx

.text:6D529988 test byte ptr dword_6D57F438+1, 4

.text:6D52998F mov [ebp+ptrAllocatedMemory], ecx

Second hit stores the address of allocated memory:

.text:6D529AA7                 call    _pMemAlloc@4    ; pMemAlloc(x)
.text:6D529AAC                 xor     ecx, ecx
.text:6D529AAE                 cmp     eax, ecx
.text:6D529AB0                 mov     [ebp+ptrAllocatedMemory], eax
.text:6D529AB3                 jz      loc_6D529D56

.text:6D529AA7 call _pMemAlloc@4 ; pMemAlloc(x)

.text:6D529AAC xor ecx, ecx

.text:6D529AAE cmp eax, ecx

.text:6D529AB0 mov [ebp+ptrAllocatedMemory], eax

.text:6D529AB3 jz loc_6D529D56

And third time is a charm:

.text:6D529AF5                 lea     edx, [ebp+exportFunctionName] ; 0018A45C
.text:6D529AFB                 sub     edx, eax        ; EDX = FBAD009A
.text:6D529AFD
.text:6D529AFD loop_strcpy_overflows:                  ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+188j
.text:6D529AFD                 mov     cl, [eax]
.text:6D529AFF                 mov     [edx+eax], cl   ; <----------------
.text:6D529B02                 inc     eax
.text:6D529B03                 test    cl, cl
.text:6D529B05                 jnz     short loop_strcpy_overflows

.text:6D529AF5 lea edx, [ebp+exportFunctionName] ; 0018A45C

.text:6D529AFB sub edx, eax ; EDX = FBAD009A

.text:6D529AFD

.text:6D529AFD loop_strcpy_overflows: ; CODE XREF: LoadExportSymbols(_MODULE_ENTRY *,_IMGHLP_DEBUG_DATA *)+188j

.text:6D529AFD mov cl, [eax]

.text:6D529AFF mov [edx+eax], cl ; <----------------

.text:6D529B02 inc eax

.text:6D529B03 test cl, cl

.text:6D529B05 jnz short loop_strcpy_overflows

Good folks at Microsoft have left us with a nice buffer overflow. exportFunctionName is defined as byte array of size 2048 bytes. Any exported function name longer than that will cause stack overflow and (possibly) subsequent crash.

010Editor with PETemplate confirms that the export name is indeed very long (3100 chars):

From what I can tell, it's a similar (but not the same) bug to what was described by j00ru at http://j00ru.vexillium.org/?p=405 (see "PE Image Fuzzing (environment + process)")

Stay safe!

P.S Here's an example file, if you want to test your Olly: https://forum.tuts4you.com/topic/38963-vmprotect-professional-v-309-custom-protection/
P.P.S. CFF Explorer, HIEW and IDA do not show us any exports in this example file - but that's a matter of another story..