![]() |
|
|
|
#1
|
||||
|
||||
|
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.
__________________
AKA Solomon/blowfish. |
|
#2
|
|||
|
|||
|
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.
|
|
#3
|
||||
|
||||
|
The strange think is that this protector seemed to not obtain attention..no one of the tools around support unacprotecting..or am I wrong?
__________________
Ŝħůb-Ňìĝùŕřaŧħ ₪) There are only 10 types of people in the world: Those who understand binary, and those who don't http://www.accessroot.com |
|
#4
|
|||
|
|||
|
I think this is due to few programs protected with it.
|
![]() |
|
|