Log in

View Full Version : dump problem


salsa
October 30th, 2002, 00:41
dump problem on Win98

It is the latest aspr antidump trick, I think. -tracex [sect.1] [sect.2] does not work because sice stops at almost every line in between the section boundaries. I search for 61, FF, E0 and sice returns an address then I set BPR [address] [address]+1 R IF (EIP==[address]) and F5. Prog starts with or without SuperBPM.

Tried aspr loader, it gave me an OEP, I dumped and fixed. Everything seemed OK ( A VB prog, so no problem auto tracing and all MSVBVM60.dll imports are there). However, this time at entry point ThunRTMain calls an address from where it jumps to a pointer and then the prog silently terminates thru ExitProcess as I traced with sice. So, this is clearly a special OEiP for the dumped version of the prog. Only solution I got so far is to have it inline patched by a ready made tool. However, this is not actually what I want.

Question: how to safely arrive at POPAD before starting the prog? -tracex and BPR at the signature bytes used to work in the past, but not this time.

Thanks.

JMI
October 30th, 2002, 02:04
salsa:

Have you read +Spl/\j's "aspr 'randomizer II' f*xed" thread? You probably have a version of aspr that uses "GetSystemTime" to "rebase" the OEP EACH TIME the program is restarted. Therefore, if you "find the OEP with 61 ff e0, BPR [address] [address]+1 R IF (EIP==[address]) and F5" and then RESTART the program, OEP will now be at a DIFFERENT ADDRESS. If you dump from the addres of OEP from the previous start, it will NOT be correct for a second landing at that address or on following starts, except by chance.

Food for thought.

Regards.

username
October 30th, 2002, 20:22
Quote:
Originally posted by salsa
It is the latest aspr antidump trick, I think. -tracex [sect.1] [sect.2] does not work because sice stops at almost every line in between the section boundaries.
How about changing the tracer code to peek at the would be pop up address and continue tracing if it's some specific instruction like 'ret' (or whatever aspr uses)?

SpeKKeL
October 30th, 2002, 22:25
And what about giving eax (after getsystemtime) all the time

the same value (like 000000) ????????

Your oep will then be always the same...........................

Sstttt, (don't tell anybody)

SpeKK.

salsa
October 30th, 2002, 22:53
Thank you all !

GOT IT.

Phew... What a daemon...

Solomon
October 31st, 2002, 02:51
There may be no POPAD any more in new ASPR.
Check this target "Absolute Time Corrector".

ASPR has moved the first few instructions of original program to its own address space.

nikolatesla20
October 31st, 2002, 05:30
Since this is VB, it is VERY simple to find OEP.

For NORMAL packed VB apps:
Simply dump the RUNNING program, and then mod the sections so WinDasm will open it. There will be a string reference to "VB5!". The OEP is right at this string reference. VB pushes this string and then calls ThunRTMain, and then it's running.


For "Advanced **Protect" apps:
If you know the address of "VB5!" string you could just put a BPM R on it and this may land you on the PUSH "VB5!" right at the OEP of a VB program, even if ASP* recreated it in its own space. You'll need the code anyway right?


-nt20