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