Quote:
|
Originally Posted by Frequency
I wont get into too much detail, but seems this is way to inline patch it 
sorta like how we go after aspr's api's (the inline patch vulnerability), we do the same here it seems. I thought i had i down yesterday, app started to run, and then "file corruption". All i did was a simple nop somewhere outside main startup routine, to see if this would work. |
Yeah, you are right
"the inline patch vulnerability" is there...
For example, code of one execryptor-api:
Code:
.004771B4: 56 push esi
.004771B5: 51 push ecx
.004771B6: 89C6 mov esi,eax
.004771B8: 89D1 mov ecx,edx
.004771BA: 83E904 sub ecx,004 ;"�?quot;
.004771BD: FC cld
.004771BE: AC lodsb
.004771BF: D0E8 shr al,1
.004771C1: 80F874 cmp al,074 ;"t"
.004771C4: 750E jne .0004771D4 -----�?(1)
.004771C6: 8B06 mov eax,[esi]
.004771C8: 0FC8 bswap eax
.004771CA: 01C8 add eax,ecx
.004771CC: 8906 mov [esi],eax
.004771CE: 83C604 add esi,004 ;"�?quot;
.004771D1: 83E904 sub ecx,004 ;"�?quot;
.004771D4: 49 dec ecx
.004771D5: 7FE7 jg .0004771BE -----�?(2)
.004771D7: 59 pop ecx
.004771D8: 5E pop esi
.004771D9: C3 retn
From this code we can jump to convenient =) place (many ZEROS, NOPS, ect) or to not using code... but there is some feature
Execryptor will make unpacking code part gradually and call this api after unpacking everyone from of parts.
Therefore in code which we will add (and will do jump to it), we should check "is unpacked our part of code (which we want to patch) or not?" =)
For this purpose i will tell one hint:
.004771B6: 89C6 mov esi,eax
.004771B8: 89D1 mov ecx,edx
EAX - address of start of unpacked code
EDX - size of unpacked code
But sometimes there is CRC-Check too... solve this promlem and enjoy