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