how unpack this -> EXECryptor
 

how unpack this -> EXECryptor ? Any examples?

Never come across it before, have you tried a generic unpacker?

this thing messes up for me as well i think u need to program an application a certain way to allow it.

Execryptor doesn't look very easy. i'm working on WikMail, but the important parts are all crypted. and the most sad about it: there's no real OEP. all is handled by execryptor code while the target runs. so there must be a way do decrypt this shit and then save it, no other possibility

most important parts on execryptor are crypted.. it decrypts those parts when neccesary and needs to use it.. so you most decrypt each crypted part by dumping from memory when program needs those parts it will decrypt them without any condition..you set your breakpoint where you want to break and decrypt then dump that part from memory ..it could take long time consuming work or maybe there's a better way to decrypt all stuff in one step..not sure ...but once you got the good you want to crack .... take those RVA/Bytes and make a patch like DZA does and you could easily patch most targets with it.... that could be best solution since there's many encryption involved on this... that's the only reason why it could be hard in some ways....but not unbeatable :)

i was checking the company that bought VBOX ?? Aladdin?? it has last section called as .protector ... i think both use similar encryption method with many and most interested parts encrypted

To Crk:

Hello man,
So,how to patch the execryptor,would you like give us a tut? Maybe that will be more clearly. I'm interested in it.

Regards
nimda2k3

maybe im talking out of my ass here but...
 

>most important parts on execryptor are crypted.. it decrypts those parts
>when neccesary and needs to use it.. so you most decrypt each crypted
>part by dumping from memory

Seems to me the same kind of schema as used by ms to protect the components of os activation.
What i did was to analyze how exactly the info for each encrypted part is stored and how it is decrypted by protector.

Then write your own program to find all those parts in the .exe, decrypt them the same way, save back to .exe.
I think much less work than messing around with ollydbg bpx'ing around and dumping memory 10000 times:P

sorry... guys... but...
I think you are all wrong.

IF they do not lie at strongbit.com, there is no "decryption" at all.

code is morphed one time, then the garbage runs - and it does NOT decrypts anything, but just does the same (among some side effects) that the original code did.

so I am afraid that you can unpack it - but you will only increase the size, you won't make it any more readable. so that - unless you have a lookup table along with some quite complicated maths - you must trace/analyse/patch the garbage; disassembling it just makes no real sense.

Dear etienne,
Sorry but I can't understand what you said about morphing.
What's it?
Can you explain this trick?

Best Regards,
Android.

I think he tried to say that all instructions are converted to their equivalents, e.g. xor eax,eax == mov eax,0. Good example of polymorphism/metamorphism are different viruses

Android:
check the offsite...
http://strongbit.com/execryptor_details.asp

"EXECryptor 2.0 uses conceptually new approach to protect software applications. The essential of the protection technology is a brand new concept of the code transformation calling "Code Morphing". The code block to protect is disassembling and becomes a subject to a nondeterminate transformations which destroys the visible logical code structure. It is important to note that after the code transformation it remains executable and working as it is suppose to but it size will increase by a couple of dozens times, thus it becomes a really paintfull to analyze transformed code."

yes i agree. i looked into this protection for a few hours yesterday.
it bla..bla..bla.... 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.

If you use olly you can find script here that will help you find OEP..
ExeCryptor v1.5x - find target's OEP (by loveboom)

http://ollyscript.apsvans.com/ its not for last version which is 2.0 but i think it will help you if you check it :)



but here is solution anyway.. :

if you know REAL OEP just dump from there set it with a PEeditor ... fix IAT ...same process for all packers/protectors, when you reach real OEP exe/.dll will be fully decrypted for most cases ..


bye NeO

Yeah, you are right ;) "the inline patch vulnerability" is there...
For example, code of one execryptor-api:

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 ;)

this not true for execryptor. you dont reach a OEP. you exe is descrambled bits at a time. i know OEP, and dumped their, execcryptor is still present, so obviously was to early, i only get so far before it locks up olly. any pointers. also.. IAT.... this one seems like a tough one. but not impossible.