Hacking Asprotect 1.31

[britedream]

Svensk post a target protected with the new 1.31, the name is dvdIdlepro Version 5.0.1.6 this is the Version as of today.I am not going to unpack it this time, for change, I will hack it. To avoid crc checks I will use the idea brought up by a gentleman called Saccopharynx,Thanks Saccopharynx, but similarity ends here, I will use a different approach.

I coded dll to do all the patches needed as follow:

1- check the first byte of code section for change as signal .

2- go and get the imagebase that be used in the pc from 45c64b for this target.

3- hold asprotect till my dll finishes its calculations of addresses needed to be patched.
4- patch , and let asprotect go on,wait for it to decrypt the location where I will
redirect the address to my name as registered.(this step is cosmetic).


send me pm if you need detail.
your version should be 5.0.1.6

unpack the files and replace yours.

this will probably only work on winxp because it crashes when it tries to access a static system dll address (possibly kernel32) pointer which doesn't jive with win2k. anyway, it doesn't work on win2k.

on a positive note, this app keeps intact its native iat. so it is easy to rebuild. when i first ran it i thought it was too fast for the new protection. now i know why cuz he didn't use the aspr import handler which adds way too much extra time if you ask me. good for the author and his customers.

[britedream]

bollygud, thanks for the feed back, I have no idea about w2k, but for the xp please make sure that you use version 5.0.1.6, and don't change target folder name, so keep it as:
XX:\program files\dvdidle pro\......

[britedream]

if it didn't work while you installed 5.0.1.6 on xp, please tell me what the error MSG.

[britedream]

the version has changed to 5.0.2.6, two versions changed in one day, they must be reading this forum. our patch will not work on the new version.

it is no longer protected with new asprotect 1.31, it went back to the old one

just so you know, i was using 5.0.1.6. but here's a little crash report:

Access violation when executing [77E7D961]

stack:
0012FF74 00476FE1 RETURN to 00476FE1 from 77E7D961
0012FF78 00476FC8 ASCII "DvdIdlePro"
0012FF7C 0090D818
0012FF80 7FFD7BF8
0012FF84 0045C013 RETURN to 0045C013 from 0045C014
0012FF88 0012FF9C
0012FF8C 00400000 00400000

00476FD7 PUSH 00476FC8 ; ASCII "DvdIdlePro"
00476FDC CALL 77E7D961 ; offending caller
00476FE1 MOV ESI,EAX
00476FE3 PUSH 1
00476FE5 PUSH EAX
00476FE6 CALL 77E7B332
00476FEB CALL EAX
00476FED POPAD
00476FEE PUSH DWORD PTR SS:[EBP+9D5]
00476FF4 PUSH 0045C03F
00476FF9 RETN

00476FC8 44 76 64 49 64 6C 65 50 72 6F 00 00 00 00 60 68 DvdIdlePro....`h
00476FD8 C8 6F 47 00 E8 80 69 A0 77 8B F0 6A 01 50 E8 47 萶G.鑰i爓嬸j
P鐶
00476FE8 43 A0 77 FF D0 61 FF B5 D5 09 00 00 68 3F C0 45 C爓衋嫡...h?繣
00476FF8 00 C3 00 00 00 00 00 00 62 72 69 74 65 64 72 65 .?.....britedre
00477008 61 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 am..............

the way to fix this would be to call a pointer address to whatever api you're trying to use, instead of a direct call. this would fix the issue i'm sure. and, yes, this is still on my win2k system

if they went back to the older aspr, that's a good thing for them and their customers. i don't like the way the new aspr runs (which is too slow). programmers who use these protections should always opt for speed cuz even when they use these 'advanced' options it doesn't make it unbreakable for those of us who know the ways around this stuff. if they opt for a slower more heavily protected app you should expect complaints from your customers about sluggish performance. just my 2 cents.