Source: https://code.google.com/p/google-security-research/issues/detail?id=525

Fuzzing packed executables found the attached crash, it might be usable as an information leak as part of another bug, so filing as a low-risk bug. If I had to guess, I would say this is the ExeCryptor unpacker.

(83c.fc0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0b61f00c ebx=00030ff4 ecx=00000000 edx=00000000 esi=0409005c edi=00000000
eip=15cc7e73 esp=0441ecf8 ebp=0441ef18 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010217
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h    ds:002b:0b650000=??

What is that code doing?

0:021> u
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h
15cc7e77 0f8596000000    jne     15cc7f13
15cc7e7d 8b540301        mov     edx,dword ptr [ebx+eax+1]
15cc7e81 8d441a05        lea     eax,[edx+ebx+5]
15cc7e85 33c9            xor     ecx,ecx
15cc7e87 3d00100000      cmp     eax,1000h
15cc7e8c 0f9cc1          setl    cl
15cc7e8f 33d2            xor     edx,edx

That edx+ebx+5 gives it away, it's searching for a jmp opcode and trying to pull out the branch target.

Why did it get lost? I'll put a breakpoint there and see where it goes wrong:

0:021> bp @eip
0:021> .restart
Breakpoint 0 hit
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7e73 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei ng nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000282
15cc7e73 803c03e9        cmp     byte ptr [ebx+eax],0E9h    ds:002b:0584f00c=00

That looks fine, eax is the start of the buffer to search, and ebx is the index to look for a jmp opcode.

0:024> t
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7e77 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000217
15cc7e77 0f8596000000    jne     15cc7f13                                [br=1]
0:024> t
eax=0584f00c ebx=00000000 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f13 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000217
15cc7f13 43              inc     ebx
0:024> t
eax=0584f00c ebx=00000001 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f14 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
15cc7f14 8d47fb          lea     eax,[edi-5]
0:024> t
eax=fffffffb ebx=00000001 ecx=0497eb4c edx=00000000 esi=05a1005c edi=00000000
eip=15cc7f17 esp=0497ebc4 ebp=0497ede4 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000203
15cc7f17 3bd8            cmp     ebx,eax


Ah, that's the bug, it's wrapping past zero and never exiting. The code is probably doing:

do {
 if (ptr[index] != JMP_OPCODE)
   index -= SIZEOF_JMP;
} while (index != 0);


That's a bug, because if index < SIZEOF_JMP, it will wrap and never exit. I would think it should decrement by 1 not sizeof(jmp) anyway, because jmps do not have to be aligned, but  I don't know anything about ExeCryptor - maybe it makes sense.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38282.zip