Log in

View Full Version : Praise for r!sc's Asprotect Deprotector v0.6 (rAD)


Kayaker
December 12th, 2000, 02:00
Hi All,

Just wanted to mention an experience I had with rAD so r!sc could get a little feedback

I was checking out a nice little Tool of our Trade brought to my attention by Hz (thanks man) called D-Peeper, which is a Delphi application peeper to help you debug applications written with Delphi or CBuilder.
http://batry.hypermart.net/D_Peeper.htm

Turns out it uses the EXACT same protection as EIAnyCalc, which I had been griping about in an earlier Antidebugging thread on this board. It's also listed as a PE Windows GUI type file by FileInfo (most other file identifiers don't even recognize any compiler used), same FilemonClass/RegmonClass monitor protection, CRC check, Asprotect version unknown.

I was able to make a manual dump with full resources and partial Import Table, but most of the IAT is still missing. I'd like to ask SV or Spath for some pointers on how you dumped AnyCalc if you have a moment sometime. As I said, the unpacking routine for D-Peeper operates the same way. Getting to the REAL OEP still eludes me, though I can get a seemingly workable dump at a few locations. I just don't want to waste time trying to rebuild the IAT if I don't have a good dump. Thanks for any input.

On to rAD. This worked quite well with both programs, which must use Asprotect v1.1 since rAD only works with this version. rAD must completely strip all the Asprotect protections from the program - as well as being unpacked, the GetClassNameA monitor protections and CRC check was also gone.

Interestingly, one other protection common to both programs (and again must be part of Asprotect), is a check of an encrypted entry in HKCR/CLSID which contains the install date info. The only problem with this is that the unpacked program no longer reads this Registry value and the install date check part of the program now fails. This isn't really a problem as it can be easily patched, but it shows that part of what Asprotect does is still integrated into the programs basic code, i.e the program NEEDS a value retrieved by the Asprotect code it seems.

Tsehp, I was wondering if the universal anti-asprotect program you're working on takes this little oddity into account? This would be part of the Limited Trial option settings in AsProtect, but I assume there must be a similar mechanism at work for the Registration Key option as well. Just thought I'd bring this up as well.

Regards,

Kayaker

SV
December 12th, 2000, 03:59
Hi Kayaker

I have downloaded your target and have a look inside
EOP is 86DB4 and i have used my tools to rebuild it.
I have an unpacked one. It works but i have not used it
in deep
I send you my exe.

SV

risc
December 12th, 2000, 10:07
heh, praise me :-) /me loves it ..

r.e. This isn't really a problem as it can be easily patched, but it shows that part of what Asprotect does is still integrated into the programs basic code, i.e the program NEEDS a value retrieved by the Asprotect code it seems.

uhm, im sure one of the asprotect api's was to get trial days left, and i hooked it so it returns a 'good' value .. (it did for aspack.exe .. never found anything else that used it) (see whatever section rad adds to files that used asprotect api, and data_dump.txt / dw 1F45h ; new_hook / trial days, and days left)

i cant give any advice as ive drank way too much beer since i coded rad & last debugged asprotect.

uhm, cheerio

Kayaker
December 12th, 2000, 18:20
Heh heh, seems the more I learn about AsProtect the less I understand

Thanks for the tool SV. The RVA's pointed out by it will give me some addresses to watch while AsProtect is doing its "thing".

Kayaker

tsehp
December 13th, 2000, 02:41
Quote:
Kayaker (12-11-2000 15:00):
Interestingly, one other protection common to both programs (and again must be part of Asprotect), is a check of an encrypted entry in HKCR/CLSID which contains the install date info. The only problem with this is that the unpacked program no longer reads this Registry value and the install date check part of the program now fails. This isn't really a problem as it can be easily patched, but it shows that part of what Asprotect does is still integrated into the programs basic code, i.e the program NEEDS a value retrieved by the Asprotect code it seems.

Tsehp, I was wondering if the universal anti-asprotect program you're working on takes this little oddity into account? This would be part of the Limited Trial option settings in AsProtect, but I assume there must be a similar mechanism at work for the Registration Key option as well. Just thought I'd bring this up as well.

Regards,

Kayaker


Hi kayaker,
The tool I'm working on is intended only to fix *damaged* iat's.
They can be encrypted, redirected, or valid, they are fixed in 98% in asprotect's all versions and will be pretty soon for every program.

The feature you're talking about is not os dependent, it's some data provided by asprotect and can be randomly put in target's data structures or resource or anything you can imagine, so my app cannot
fix globally this for all asprotect apps, otherwise I'm forced to put some heuristic searching skills to make an attempt.
Anyway, you can describe this mechanism precisely, who knows maybe I could do something ?

If you're interested to test my beta version, email me, I'll send it to you, but actually the most interesting tracer module is not included while it's still at dev stage.

regards,

tsehp