hello,

I spend two nights on Aston v1.8 and i know i can't be far from the goal (unpack it). The program can be found quite easily i think, just look for Aston and go to their official web site

First there's 3 exe protected with last asprotect version, to begin i unpacked Thwizard.exe and A-master.exe, but still have the same problem on them (crash at 40103F)

Take Thwizard.exe for example, here's what i did :
- double dip : i skipped first dip and keep second dip coz we need the value in a redirect call later
- dump at 4133FF which seems to be oep, but that's last asprotect version so we must add : 55,8B,EC,83,C4,F4,B8,1C,33,41,00
And now the oep is 4133F4 (- 400000)
- okay then i rebuild iat with no problem as it's not my first asprotect target, except we must be carefull here :
000222F4 user32.dll 0093 DialogBoxParamA

Now i thought all would be fully rebuild, but i traced and saw unpacked Thwizard.exe fucked at 40D3CB when it calls DialogBoxParamA...
I first thought this api wasn't DialogBoxParamA as it crashed and try to replace it with asprotect original code to have a better view, and same problem again, so i guess it's not the api...

Could you guys have a look ? thanks for you help again (and btw if i forgot to explain something just tell me, i'll correct that)

hi there,

i just downloaded the app and have some fast questions. i discovered 3. dips.

1. dip: 401014
simple return

2. dip: 41071c

41071d mov ebp,esp
41071f mov eax,[0041d4a0]
410724 mov edx,[ebp+08]
410727 mov [eax],edx // stores 6E3861 at 4212CC
410729 pop ebp
41072a ret 0004

3. dip: 4107b8

4107b8 push ebp
4107b9 mov ebp,esp
4107bb mov eax,[ebp+08]
4107be mov [0041d1cc],eax // stores 410730 at 41d1cc
4107c3 pop ebp
4107c4 ret 0004
4107c7 nop
4107c8 call [0041d1cc] // <- here it will be called
4107ce ret

here my question: u sure skipped the second dip, but why? this looks like a redirection, too. am i wrong?

oh..yes..oeip is 4133ff for me, too will have soe deeper look into it soon.

Hi,

First thanks fo your try on it
And...no i don't think it's a dip problem, and i even try without skipping it to be sure

If you have a few times (it must take one minute...) to dump and rebuild it, we could see if you have the same problem

I still have an error calling 40103F and i know it happens when calling DialogBoxParamA but i guess there's a long piece of code between these two address so i can't find the precise location that call 40103F

Hmm... No probs here...

Do I have to do anything special to trigger that error?

Did you perchance use that a there rv-helper... ??

If not... Need more info...

/Manko

I used ImpRec to rebuild the iat, in cutting thunks and so on, but i've just tried with revirgin and it works at least for Thwizard.exe and Aston.exe, because the third exe (A-master.exe) always keep saying :
Instruction at address "0x00000000" use memory address "0x00000000" ....

It's a bit strange because there's the same aspr version on all 3 files and only this one give me this error, but i keep looking for the problem atm



mm no i'm used to do a maximum manually, i prefer to learn a maximum of things hehe

Anyways i'll reply again when i'll have had a deeper look at third exe...
Thanks Manko to try it too

regards

Ahh! oki.

I used rv first try, maybe why it worked. Haven't tried a-master...
Will maybe look into it later.

btw, if you zero out the iat-area before it's mangled/created you get a fresh nice iat with rv. ...and probably imprec too?

/Manko

Damn, my two working files work on my win 2k sp3 and win 98 but i gave them to a friend to test and it seems that it won't work on other's windows version, and it seems i get this problem with all last aspr version protected stuff

Manko check your pm please

regards

Can't help you with Win"X"-compability... Have only W2k...

I solved A-Master last night, though.

It was interesting...

1.
It uses the same aspr-check I've posted about twice already, although this time it's not deced/inced but each byte is xored with it's rellative possition. And it never crashes inside it, since a SEH(?) has been initialized before it, wich continues the execution causing some variable to not be set and lets it crash later, diverting attention from it.

2.
When I get a fault in an unpacked asprd app I tend to consult dr.dawson... In this case the fault was on adress 00000000 so I looked at the returnadress instead and found an adress where getprocaddress is called and a jmp eax is made. Naturally this doesn't work unpacked. The asprd version gets an internal aspr-adress and puts it in eax. This address leads to a routine that puts the number of remaining trial-days in eax.

Go Patch!

/Manko

thanks to Manko it finally works...

I knew that it was a fault on adress 00000000 but i couldn't find the return address, now it's done thanks to drwatson

call getprocaddress
call eax <- eax = an aspr address, the call return our days left

That's why it crashed, it patched it with a double inc eax so that instead of 0 it returns 2 (always 2 days left...)

That's not all, after there was a bad value somewhere in eax that made a jump active, but if we jump the prog exits, so i patched it into two nop and it works fine

There's still one problem : i think all my unpacked aspr (last version only) run only on my win 2k sp3 and win 98 because i gave it to some friends of mine to test, and i don't have another windows version to have a look at the problem

Hope Manko and someone else could resolve this
thanks Manko again

regards

Hi backeyes,

Well done on the job against aspr... anyway, here is a tip on how to find all these crash error.. debug it with Olly Debugger and set debugging exception to catch all Exception... then you will be able to find where call eax is generated, as well as aspr trick of checking loader present or not...

If you had posted your problem that it crashes at 0000000 then i think solution would have been provided much faster instead of saying generally that your dump crashes... anyway it is always good to work out things on your own ....

Cheers,
crUsAdEr

ok i'll try to see with ollydbg too

thanks for this other tip

My favorite technique is to "Faults ON" in SoftICE and then you can walk the stack.

Just do a "dd esp" and you will see what is on the stack. Take values that look like addresses, and unassemble them. This can help lead back to the problem area. Walking the stack is one of the most powerful techniques you can develop - of course it doesn't work at all with JMP's. Grr. However, on a fault, SI will tell you the last two addresses that were executed.

-nt20