Some words from r!sc
--------------------------------------------------------------------------------
I had the same problem with 'ImageEye v5.1'
The OEP is hardcodet and decryptet, here the tip,
r!sc me gave:
hehe, looks like he is using asprotects mighty morphing stub decryptor (and
encryptor)
simple decryptor..
004514A0 loc_4514A0: ; CODE XREF: .aspack:004514DCj
004514A0 mov edx, 0E120074Fh
004514A5 xor esi, 27924507h
004514AB dec byte ptr [ebp-4F0C28Fh] ; do the actual 'decryption'
004514B1 mov edx, 0EB8B32D1h
004514B6 sub esi, 2146BC41h
004514BC inc ebx
004514BD mov esi, 0C34E0847h
004514C2 mov si, cx
004514C5 xor dh, 13h
004514C8 sub ebp, 1
004514CE mov si, bx
004514D1 mov edi, ebx
004514D3 movsx ecx, di
004514D6 cmp edi, 0FCF03D3Ah
004514DC jnz loc_4514A0 ; loop until finished 'decrypting' stub
so, the simple decryption is dec byte ptr .. the rest, apart from 'sub ebp,
1 / inc ebx / mov edi, ebx / cmp edi, 0FCF03D3Ah / jnz loc_4514A0' is junk code..
the exit point ..
0137:004513B5 6800000000 PUSH 00000000
0137:004513BA C3 RET
the exit point again
0137:004513B5 6889DA4200 PUSH 0042DA89
0137:004513BA C3 RET
so, 0042DA89 is the original entrypoint .. sub imagebase = 0002da89 .. = search
for 89 da 02 00 ..
oi, but its decrypted @ runtime! lets encrypt the data we have .. inc byte ptr
will encrypt it..
so 89 da 02 00 -> 8a db 03 01 ! ..
search for that, u find @ offset .aspack + 7dh (somewhere around file offset
21a7dh)
say i insert patch code in the pe header, offset 300h .. would load into va
400300h .. edit entrypoint (.aspack +7dh) -> 01 04 01 01 .. decrypts to 00 03
00 00 which is dd 00000300h + imagebase = 00400300h :d
any questions?
btw, heres the push 00000000, ret, encrypted ;) .. 69 01 01 01 01 C4 .. :/
Hope this helps