ACProtector
 

Is there a way to unpack this? (e.g. a generic unpacker?)
How difficult is it?
What about programs like ProcDump, can they dump this?

ACProtect
 

Of course it is and was done, several times - manually.

About difficulty - it's medium hard. In theory very similar to AsProtect.

About dumping - you can dump it by yourself but then you need to rebuild import table (manually) and jumps to perplex.

Good luck,
dyn!o

Hi,
a newbie question, is there any good tut around for doing such a thing manually? I digged somewhere but with no luck.

TIA

waste of time
 

unpacking is a bit of a pointless exercise, all the apps I've seen protected with it are function limited and you are not going to enable them (well I don't know of anyone that has succeeded) you might just as well stick with EVACleaner. If you are set on unpacking, lownoise released a plugin (search the forum) for ollydb may be of help.

If there function limited they most likely use encrypted sections, in which case your right theres nothing you can do about that without a real key on hand. Only app I use thats ACProtect is UltraFXP, and DiGERATi did a very good job on the loader with it functions great.

The anti-debug trick of ACProtect is INT3/INT1 etc., easy to bypass.

The Import-Table-Destroy scheme of ACProtect is just like TELock, so we can recover IT/IAT without ReVirgin/ImpREC.

The stolen bytes of ACProtect needs patience to recover.

As MrAnonymous said, code-snippet-encryption needs a real key to decrypt and there may be too many snippets encrypted. crazy.

the stolen bytes for acprotect perior to 1.20 is easy to find, trace after int3, when you stop at the code section look in the trace for ebp==esp, you will find the stolen and the address of your oep shown in trace as eax value.but 1.20 and up is different.

The strange think is that this protector seemed to not obtain attention..no one of the tools around support unacprotecting..or am I wrong?

I think this is due to few programs protected with it.