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
