Hi all

i've been struggling with this asprotected piece of crap for some days but by now i'm stuck absolutely.

it can be downloaded from here:
http://www.wizetech.com/download/amcpro.zip
(ver : 2.00h )

- i found the oep : 15cba8
- fixed the import table (by the help of revirgin/win98): attached
(iat: 1651b8 len:818)
- fixed the pe header

when i run the dump it crashs : access violation at 102256

i examined the code
(registers' values are the same)

the prog wanders to a memory location that exists only in the original version

thereafter it moves/decrypts/unpacks lots of data to 13dxxxx

i think it's an asprotect trick
but i'm yet too few to solve this problem

i hope anyone could help me


byez

Hi

I deleted your attached IAT file. We can't have copy 'n paste crack attachments that give it away here, and it doesn't really help anyway.

The first question you need to answer is what is in the memory address the code wanders off to, a variable, an address, or more code? Whichever it is, the tricks to handling the Asp redirections have been discussed before, a little reading and understanding will go a long way.

Try doing some reading of past Asp threads and rethink the problem with them in mind. Spend more time in the code and you just might be able to figure it out on your own.

I'm not suggesting you can't get help here, just encouraging you to do a bit more work and come back with more detail. One more app specific answer doesn't add much to what's already here to learn from.

Regards,
Kayaker

hi

first of all thanx for your advices
i'll follow them

but i think my problem havent been discussed yet
(i'd collected all the info about asprotect that i could,
i'd also read the asprotect stuffs in this forum before i wrote here)

hitherto i haven't read about a thing like this - its not an api redirection, the problem emerges after the original program starts

i wrote because i run out of ideas....
but i have to keep on tryin' - you are right

thx and byez

Well, I didn't mean specifically an API redirection. From what you said the code in your unpacked file goes to a high mem address which is no longer there. What I was trying to get at, and what was unclear from your first post is what's at that address in the original version? You said thereafter it moves/decrypts/unpacks lots of data to 13dxxxx, but I wasn't clear how that's directly tied to the high mem jump. Does this all occur during the high mem code or do you jump back to program code first? This could be important because maybe a variable is being checked and the decryption code could be avoided.

What is the decrypted code doing? Can you make any sense of what is being handled in it? Does it access the registry? Check a keyfile?

If what's at the high mem address is just a variable (may have been placed there during unpacking and is the return result from an API call which is used later let's say), then you may be able to duplicate the value in a spare section of your dumped file or replace it with a RET.

If it's an address that points to unpacked code, then you may be able to duplicate the address or emulate the missing code. If it points to high mem code, then keep tracing.

If it's a short code section which seems to jump to kernel code then this is an API redirection that maybe your IAT resolving didn't pick up, or you have one of them wrong.

It could be caused by one of the 'Double dips', in which case there are special ways to handle that during dumping, and better people to explain it than me.

The point was I didn't feel you gave enough explanation as to what the problem was without someone having to crack the program themselves, then tell you how to fix it, *if* they could duplicate it. Some kind soul might do this, might not. Or you might have to wait a long time for no answer. But with a bit more detail someone might be able to help just from your description. Try to analyze exactly what's going on and you may pick up clues on how to fix it.

Kayaker

Mem7

There is nothing new here (except the 'rebased] aspr code to get to OEiP)

You need to examine your rebuilt.exe at offset 0x161000 length 1k...if there is anything otherthan zeros you got caught by a DD
and InitializeCriticalSection already flagged.

My dumped exe runs fine.

Spl/\j

thanx SplAj

ok, i'll do so...
(but it seems i still need to study the forum...)

byez

hi

finally... it runs

im so happy - - -

yesterday i fixed it. i just had to dig in the prior posts and now
i know wtf is DD - thanx to +SplAj for the hint

but one thing is not clear yet

i found 3 dips before oep:
- 401014 - not really interesting
- 55C3F4 - yeah its a "big" dip
- 4FB6A4 - sets some variables

so i skipped (just NOPed the CALL itself) the second one and dumped at oep,
fixed it and "who knows maybe it runs" and run!!!

but i hadn't called the skipped dip yet. thereafter i made the call and the jump to oep - but it still runs... - dunno why (the posts i read said that the dip have to be called before oep to make the target run - in this case it seems to be unnecessary)

one more question : are there any methods to find pre-dips outside /tracex?

peace&love (dont be a hippie

byez

ps. sorry 4 poor english