Anyone look Advanced Find & Replace 1.4.0 at http://www.vknoware.com/
look like a new version of asprotect (at least an unknow version to ASPR)
So i use revirgin and got some interesting result, some funtion like GetVersion, GetCurrentThreadID are completely emulate by ASPR so there in no way to trace back (only SEN) other funtions like GetModuleHandleA (RVA 98330) use some type of brach so if you trace it with eax=0 you never found the correct api entry. Finally after all import table rebuild i found that some procedure are redirect (static procedures inside .exe not imported APIs) and some string point to ASPR code, so if you remove ASPR you got tons of crash.
I finally manage to crack it , usign some loader coz i cant remove the damm ASPR.
BTW if a delphi proggy.
Any idea ???

R

Don't worry I'll soon take care of this, I'm still on the revirgin's tracer development but this new version of asprotect is planified.
while I finish this, maybe +splaj will find a temp solution, we'll see.
If you really can't remove asprotect, you can also make temp solution and use r!sc's process patcher, this method is fast and impossible
for the protector to block, but you don't have the revirginized program.

later,

+Tsehp

Having spent a lot of time on asprotect, recently you appear to be most of the way through the process.

Asprotect changes quite a bit every few weeks,.

The GetVersion and friends are fun tp play with, it's just enough to irritate you if you forget to not the values down the 1st time you run it.

I was annoyed to discover the redirected calls, initially, but they can be coped with, they as not as nasty as they first appear.

It sounds like you where almost there, have another try, then look at the newst elcomsoft product, if you really want to see asprotect in it's full glory

Regards,
Kilby...

i was able of revirgin the proggy and found GetVersion & co APIs, the problem was with the delphi code, some code are called using redirections, buts the pointer to this redirections are store in the static data declaration , not in the import part.

R

i was able of revirgin the proggy and found GetVersion & co APIs, the problem was with the delphi code, some code are called using redirections, buts the pointer to this redirections are store in the static data declaration , not in the import part.

R

psst Rainor_ 3 things :-

wot did you do with the call at 0x4942AC that puts 58C81501 in location 0x495F8C ? (was 94424900)
before going to the OEiP at 494564 ? , also the RET at 401014 - pfff Alexey come on

Did you re-locate/emulate those 2 calls at 115C904 & 115C90C :-

Push EBP
MOV EBP,ESP
Pop EBP ......


Did you emulate the mov eax, 816CC38C & C0005A04 & FFF40AA5 in the last 3 calls 115C8FC, 115C8C4 and 115C8F4 repectively somewhere else ?

game on }>

SplAj

hmm i miss something, here is what i do
i found OEP using DEDE, icedump to break in the original OEP usign /tracex OEP after that, dump the target realign all sections, use revirgin to get correct import & paste it in a new section, of course i update all PE header info (OEP & import table) after all the proggy crash so i found in no time the
call [0x495F8C] , fire Softice trace this call.
The question, there is some info/essay about how emulate ASPR APIs call, or how avoid
or get the static modify data???? do i had to trace all ASPR stuf???????

R

Hi again

mmmm I've been thinking, maybe we need a quick 'dll' builder module in RV that would take the place of these 'redirected->code' in the API jmp table now. RV struggles to create a 'valid' IT from missing info and the alternative of putting in dummy API then changing the code of these dummy API calls in the JMP table to JMP to your new poking routine .......is a big PITA.

Better to have a dll that you can make RV link to and make these stupid code emulation in your customised dll.

Just a thought. I've only had one cuppa coffee so far.......

ahh thats better, 2 more coffees while debugging and MUCH better brain power now


Look at this stupid code I found to get the missing API's :-

0187:0115C868 6A00 PUSH 00
0187:0115C86A E8DD7BFFFF CALL KERNEL32!GetModuleHandleA
0187:0115C86F A3D4351601 MOV[011635D4],EAX
0187:0115C874 E8EB7BFFFF CALL KERNEL32!GetVersion
0187:0115C879 A3D8351601 MOV 011635D8],EAX
0187:0115C87E 68E4351601 PUSH 011635E4
0187:0115C883 E8E47BFFFF CALL KERNEL32!GetVersionExA
0187:0115C888 E88F7BFFFF CALL KERNEL32!GetCurrentProcess
0187:0115C88D A3DC351601 MOV [011635DC],EAX
0187:0115C892 E88D7BFFFF CALL KERNEL32!GetCurrentProcessId
0187:0115C897 A3E0351601 MOV [011635E0],EAX
0187:0115C89C E8737BFFFF CALL KERNEL32!GetCommandLineA
0187:0115C8A1 A378361601 MOV [01163678],EAX
0187:0115C8A6 C3 RET
0187:0115C8A7 90 NOP

Thats a BIG clue from Alexey, thanks mate

Now you can fill in 3 more of the 7 missing API's directly with Revirgin at RVA :-

GetCurrentProcessA
GetCurrentProcessId
GetCommandLineA

mixed for your pleasure

25 000981E0 0115C8FC 0000
97 00098318 0115C8C4 0000
111 00098350 0115C8F4 0000

...and the duplicate calls of the above. Getting closer ?

Ok, I'm feeling dejected nobody else is playing the 'game'......... where
are you guys ?

I will not post more ramblings here but the full monty is attached for your pleasure :-

ASdisprotect v. SplAj

Game Over Alexey .....}>
'patch+play'
+SplAj

I looked at this target, and it was "easy" after working on PDF program from elmcosoft.com...I noticed you seemed to do a little work with the RET 0004 trick...This bugger had me crashing for a while too, till i finally found it =) I just placed a RET 0004 where JMP [PTR HERE] was, both instances and had no probs...If i recall, one of them was at 406DD4. The himem relocation trick kinda gives itself away since aspr jumps back to the programs mem (400000==>4D0000) to make the alteration...I found it by enabling /tracex min. to max., and will do so in future...It could be trickier if he found another way (not using writeprocmem of course) to alter stuff...

madmax!

Splaj, I'm willing to play the game

Advanced PDF wasn't too bad, though the user32 one caught me out for a while, it was so simple to fix I needed help (thanks SV).

Though it was interesting to note that the registration window was the only part of th app to use that call, so I wonder if asprotect took particular care of it ?

I have noticed in one newer app that there is a redirected internal call in the form of
call [xxxxxxxx]

The call is internal to the app.

I needed more coffee to figure out what I wanted to do about it.

The IT mangling also appears to have changed in this app, no longer the stretches of zero bytes, I have seen in other asprotected apps.

Note: I recoment Percol Rocket Fuel as the coffee for aspr work.

Kilby...

madmax
_____________________________________________
I just placed a RET 0004 where JMP [PTR HERE]
_____________________________________________

Yes, you are completely right. In the cold lite of day and after sending my findings to Tsehp for RV development and having thought it out now I realise it is a simple RET 004 that will suffice in offsets 406CE4 and 406DD4 :-) BUT late last night after a few hours in the codewoods with several whiskeys+ice (or was it several hours in the codewoods and a few whiskeys+ice ?) I thought my first solution was the dogs bollocks....but it did not impress the wife, she went to bed without me :-(

hehehe

Kilby, I also found it strange how it disregards all calls to load/lockresource except for the reg box in PDF program...Must be unimportant APIs, but thats an assumption by alexey i guess...
I just finished yet another of the products from elcomsoft.com, the Advanced office 2000 pro...It
was an easy rebuild for the IAT with imprec...But fixing those redirected calls was not as easy as in AFR, which had only 2....It involved manually inserting the "virgin" section into the dump...Then, as a last bonus there is a little "check" from the author, PUSH FF / PUSH 04 / CALL GetProcAddress...This will obviously return 0 unless API is hooked...This could be cracked by rerouting API like splaj mentioned, but the return value from ASPR hooked API is never used! so easy crack =) take a look!

madmax