according the several online tutorials the most working method for OEP discovery of 1.x ASProtected app is :

shift + f9 upto the time when the app starts
next time restart the app in olly and shift+f9 1 time less than the previous time
them BREAK ON ACCESS on code section
and shift+f9 once again should break right on the OEP ( if stolen codes then it will be taken care onwards )

but i have a weird prob here, before the last shift+f9 i break on here

00E24A19 3100 XOR DWORD PTR DS:[EAX],EAX
00E24A1B EB 01 JMP SHORT 00E24A1E
00E24A1D 68 648F0500 PUSH 58F64
00E24A22 0000 ADD BYTE PTR DS:[EAX],AL
00E24A24 00EB ADD BL,CH
00E24A26 02E8 ADD CH,AL
00E24A28 0158 A1 ADD DWORD PTR DS:[EAX-5F],EBX
00E24A2B 3C 65 CMP AL,65

............
............

now if i shift+f8 , then i break in NTDLL

7C90EAF0 8B1C24 MOV EBX,DWORD PTR SS:[ESP]
7C90EAF3 51 PUSH ECX
7C90EAF4 53 PUSH EBX
7C90EAF5 E8 C78C0200 CALL ntdll.7C9377C1
7C90EAFA 0AC0 OR AL,AL
7C90EAFC 74 0C JE SHORT ntdll.7C90EB0A
7C90EAFE 5B POP EBX ; 0012FC54
7C90EAFF 59 POP ECX ; 0012FC54
7C90EB00 6A 00 PUSH 0
7C90EB02 51 PUSH ECX
7C90EB03 E8 11EBFFFF CALL ntdll.ZwContinue
7C90EB08 EB 0B JMP SHORT ntdll.7C90EB15
7C90EB0A 5B POP EBX ; 0012FC54
7C90EB0B 59 POP ECX ; 0012FC54
7C90EB0C 6A 00 PUSH 0
7C90EB0E 51 PUSH ECX
7C90EB0F 53 PUSH EBX

and on the CALL ntdll.ZwContinue the program shows a messagebox and on clicking ok the program exits. i surely know that this is not the last SHIFT+F9, it's exactly the previous one b4 the last.

the weird thing is while the msgbox is shown , i cant break in the program with f12 , olly just cant break

now, could anyone help me with how i can break in and unpack the program

PEiD shows : ASProtect 1.23 RC4 - 1.3.08.24

thank u

** i'm going thru a couple of richardo's tutorials, but as i dont really speak the language and using a 3rd party translator , may b i'm missing many things, so if anyone would like to suggest anything , everyone is welcome

thank u

This is just a wild stab in the dark, but perhaps the ASProtect crew have gotten wise to this method and put in a countermeasure.
Look for any calls to GetTickCount, QueryPerformanceCounter, GetSystemTime or GetLocalTime after your penultimate break. It's possible that ASProtect is keeping track of the elapsed time between these last two exceptions (which you've spent applying a memory breakpoint).

Alternatively, it may be detecting the access breakpoint itself. Maybe you could try making the code section a guard-page by means of an inline patched call to VirtualProtect (I never found a way of doing this through Olly's Memory Map screen). Or even setting the page's access to 'No Access'. Then OllyDbg will break at the OEP with an access violation.
Failing that, if you have a little time to waste, you could try a run trace (into) with an EIP boundary condition.

Let us know how you get on.
Admiral

when u are at last exception, in olly open she chain window and make a bp on the first address present(ralative to prg code, no address of api) e click on shift+f9, u will be at bp and there step until u are at the .code section of progie

admiral, thanks for the reply , but could u please explain ur method to try a little more elaborately ....

the version i'm trying to unpack is ASProtect 1.23 RC4 - 1.3.08.24 , i think ASProtect was with it's trivial features only back then ...

thanks again for ur reply and suggestion and please keep it coming

punluck, thanks for the reply , i tried ur method but same thing again ... it breaks on the SEH bp , then i continue with F8 , i face this code section again ....

7C90EAF0 8B1C24 MOV EBX,DWORD PTR SS:[ESP]
7C90EAF3 51 PUSH ECX
7C90EAF4 53 PUSH EBX
7C90EAF5 E8 C78C0200 CALL ntdll.7C9377C1
7C90EAFA 0AC0 OR AL,AL
7C90EAFC 74 0C JE SHORT ntdll.7C90EB0A
7C90EAFE 5B POP EBX ; 0012FC54
7C90EAFF 59 POP ECX ; 0012FC54
7C90EB00 6A 00 PUSH 0
7C90EB02 51 PUSH ECX
7C90EB03 E8 11EBFFFF CALL ntdll.ZwContinue
7C90EB08 EB 0B JMP SHORT ntdll.7C90EB15
7C90EB0A 5B POP EBX ; 0012FC54
7C90EB0B 59 POP ECX ; 0012FC54
7C90EB0C 6A 00 PUSH 0
7C90EB0E 51 PUSH ECX
7C90EB0F 53 PUSH EBX

and on CALL ntdll.ZwContinue , the message box is shown and on clicking okay , the app terminates ...

ok it's normal, beacause i forgot to tell u this: in seh chain step till zwContinue, there set a memory bp on section where is the seh chain and click f9. At bp step all the code till the last call before the ret, on this call step into, and step into in all the call till u will find the oep :P

PS: however the oep maybe inglobe, i hope who it isn's your case

In more detail:

When you break on the second-to-last exception to set your access-breakpoint, also set execute-breakpoints on any API function that can return elapsed time. Likely candidates are GetTickCount, QueryPerformanceCounter, GetSystemTime and GetLocalTime . If you do break on any of these before you get your messagebox, check to see what ASProtect is doing with the return value. If it grabs a static or global variable, subtracts it from the returned EAX, compares the result and 'JGE's somewhere (presumably the messagebox & PostQuitMessage routine), you'll probably want to NOP out that conditional jump. Of course, your target may be a little less direct than this, but if it looks like it's calculating the elasped time since a previous event and acting on that, you may want to ensure you don't get caught out by such a cheap trick.

If you think ASProtect is detecting the memory-access breakpoint, you could try another method for causing an exception at the OEP:
Instead of setting a memory-access breakpoint, try setting the entire code page to 'No Access' so that when execution gets passed to the OEP, an access violation occurs, which you can catch in OllyDbg. Of course, this relies on the unpacked code being in a different memory page from ASProtect's code.
Similarly, you get the same effect using a guard-page. If ASProtect sets the code page's access back to RWE before passing control to the target, then the above method will fail. Instead, you could try (again on the penultimate break) noting down your EIP and ESP, then 'New Origin Here' in some cave somewhere and patching in your own call to VirtualProtect to set the page's access to (PAGE_EXECUTE_READWRITE | PAGE_GUARD), say. This way, Olly will break with a guard-page violation when ASProtect tries to execute anything within the guarded memory section.

Again, this isn't foolproof. If ASProtect calls VirtualProtect (or VirtualProtectEx) before its CALL to OEP, then your hard work may be for nothing. If you suspect this is the case, you could try catching any such calls to VirtualProtect and forcing a premature return (after setting EAX = 1) to prevent the access-change from going through.

If ASProtect detects all breakpoints, then you'll either have to find out where it's doing so, or devise a method to get to your OEP without using any.
You may want to try to start a run-trace after 'Set Condition' with 'EIP is in range <whatever range your OEP will lie in>'. Be prepared to go to the cinema or something while the trace executes (if ASProtect does a lot of work in this time) as it can take a while.
This method isn't breakpoint free though (tracing uses BP on 'next command'), but it does keep the breakpoints very localised. If none of this works, you could try setting OllyDbg's 'Use hardware breakpoints' in the 'Trace' section so that no 0xCCs will appear where ASprotect doesn't expect them.

If you still have no luck, you could always look furthar afield for a different approach: Get a decent API spying utility (I recommend NuMega SmartCheck if you can afford it) and let it do its thing. Preferably restrict its logging so it starts near the end of ASProtect's code and finishes close to the unpacked target's first call to DefWndProc (for example). This way you will have less deadwood to dig through. I know this is a bit of a tall order, so don't worry if you can't find a way to limit your logging time.
Once you have an ordered list of all the APIs the program called, it's only a matter of looking for the sequence of calls that are characteristic of a Win32 exe starting up (GetModuleHandleA, GetCommandLineA, GetVersion, GetStartupInfoA etc.), and find what looks to be the last few API calls ASProtect makes before calling the OEP (something atypical of early initialisation code, perhaps CreateThreadA or something). If you can isolate any such call, and are able to break on it, it's unlikely that ASProtect will be able to do anything about any breakpoints you set then (including the memory-access breakpoint you're currently using).
It may even be worth a trial-and-error approach of the same technique - setting breakpoints all but at random on API functions you suspect will get a call before EIP hits the OEP. There's a significant chance that in doing so, you can get yourself past some of the antidebug tricks.

Bear in mind that you may need to do any or all (or none) of these in order to find your OEP, but let us know how you get on.

Regards
Admiral

Well, I also have a problem with this version of ASProtect.

First of all sorry, if I had to start a new thread...

My guess was to unpack a german /english file manager.

It would be easier to help me, if I could post name of it, but I don't like to be banned.
(No, not the two best known file manager...)

1. Got protection by PEid
2. Read some good tuts by LaBBa, R@dier, MaDMan_H3rCuL3s etc.
3. Started unpacking with OllyDbg and ImpRec

This ist the last Shift-F9 before prog starts:

http://www.gwebspace.de/magicbyte/pic1.jpg

Now set a breakpoint on memory access in code section and started tracing.
Got into EP with 38 stolen bytes above:

http://www.gwebspace.de/magicbyte/pic2.jpg

Inserted stolen bytes extracted from Run Trace of Olly:

http://www.gwebspace.de/magicbyte/pic3.jpg

Now dumped prog with Olly and fired up ImpRec...
ImpRec found IAT and got imports...
Trace level 1 found most of invalid imports.
Trace plugin ASProtect 1.23 RC4 found rest except one only.
Trace plugin ASProtect 2 found last one.

So I fixed dump and tried out unpacked program.
Dump starts, shows a little start screen and then exit...

Started dump in Olly to see why this happens.
Inside prog ist a large loop with lots of calls of getmessage and translatemessage.
At this calls sometimes, but not always, i. e. 3rd and 15th etc. an exception
to pass over with Shift-F9 appears and the prog exits.

Seems to be happen while some parameters for this calls are wrong.
Don't know why, don't know how to get the right values to put on stack...

Any hints, ideas and suggestions how to get the program running are appreciated!

Regards,
magic

Tried out last version (4.12) of file manager...

Just found in internet an older version (3.85) protected with ASProtect v1.23 RC1.
Started unpacking as described before and no problems at all...

Help still appreciated.

Regards,
magic

magic. Clearly something is missing from your dump that is preventing it from running correctly. This may be because you have made a mistake or it could be due to an antidump trick.

What exactly are the exceptions raised in the message loop (I'm guessing access violation)? Do these same exceptions occur in the protected version of the app when it gets to the same point?
In this situation, I'd be tempted to find out exactly where your dump starts to perform differently from the ASProtected version:

Go through the OEP finding process again in the ASProtected exe, but before the stolen code starts to execute, binary copy-paste it in before the OEP as in your screenshot, and set a new origin (EIP := OEP - length of stolen code) to run from your newly pasted code. Now hit F9 and see if the target runs. This will determine if the problem is being caused by the pasting process (maybe ASProtect injected a CRC check at the OEP or something).
If it does run correctly, then unstealing the code is fair game. Otherwise, set a memory access breakpoint on it to find out where it's being detected (if anywhere).

Supposing the stolen code is not the cause of the problem, you may want to try a run-trace comparison:
Fire up your dumped exe in OllyDbg and let it run until your exception occurs. Take a note of the address at which it happens, restart and place a breakpoint at this address. Let it run to the breakpoint, then hit F8. If your exception gets thrown then you can be sure that this instruction is causing the problem first time 'round. If not you'll have to find another benchmark point to use (use your imagination).
So once you know where the exception occurs, you can get to work in producing a useful trace. Let Olly perform a run trace right the way from your EP to this instruction. Save the trace to a log file.
Now try and get an equivalent run trace from the protected exe: Trace from when it reaches the OEP up to where the exception occurs (or would occur in the dump). Of course, save this one too.

If your trace logs are reasonably short, you can compare them by observation (I tend to maximise two instances of Notepad and make heavy use of alt-tab and the PgDown key). If they're huge, you may want to run a text-compare on the two files.

Once you know where your dump starts behaving strangely, you'll have a much better idea how to get to fixing it.

Good luck
Admiral

@Admiral

Thanx a lot for your reply...

I will try out those things you offered to me.

The reason maybe located in a main difference between this two versions.
v3.85 is a standalone EXE file, while v4.12 has a lot of additional DLL's.
And they all are packed or protected with ASPack and ASProtect...

Perhaps those DLL's will not work together with an unpacked and dumped file.

Regards,
magic

@Admiral


Yes indeed it's access violation!


Stolen code is working properly, so I have next to spend a lot of time to make a run trace comparison...

Regards,
magic

Well run-trace is compared...

But no obvious differences in code or content of registers.
Program crashes in some passes of a 200 lines loop at DispatchMessageA.

Jump over will make program continue...
Think it's not rational to pass the whole loop by hand, because of several of hundreds of passes.
So I cannot say, if program runs, when I jump over all crashing calls.

What the hell is going on there?
Is it an unknown Antidump-Trick by ASProtect, or a special gimmick by this filemanager?

Seems like i have to give up at the moment, because I have no idea how to go on...

No one else then Admiral could give me a help?

Regards,
magic

Doh, already giving up? Maybe you should sell your computer and do something else
I've never had a look at asprotect yet, but there are generic approaches to your problem (of course!):

Usually, when I happen to run into such a thing, I try to find out more details. Try to find out when and where *EXACTLY* it crashes. It crashes with access violation, which probably means that it is trying to access something that isn't there (anymore!). I guess you will have to take the hard way, that means finding out when exactly it crashes and then check why. For example: It is calling some code in asprotect, which isn't there anymore.
Or it is accessing some buffer created by asprotect, which will result in the same crash. The baseline is this: Don't just sit there and do nothing, investigate
Small example (totally made up, just to clarify):


If ECX points to somewhere where currently no memory is allocated, this will cause an access violation. In such a case write down the value of ECX, and start over. Check if the crash occurs in the same place again(and in the same round of the loop!). If it does, very good. If it does not: Doh!
In addition, check under which circumstances the crashing code is executed. The program could send itself check messages which crash the program if asprotect is no longer existing - there are many possibilities. I am too lazy to write down all my ideas about this, please investigate first and report back your findings

If ECX (or whatever is the reason for the crash) has the same value again, fire up the protected exe and have a look what's going on there. Have a look at the memory at the location ECX points to. I suppose it will point to either asprotect code or DLL code. In the latter case, I'd suspect that protected DLLs do not work with a dumped main executable, and you will have to dump all the DLLs as well.

As you said the comparison between protected and dumped exe shows no difference - This can mean that some subroutines have been moved from the program into the asprotect layer. Hence when they are called from the dumped program, they are just not there -> BANG.

And yes, it might be a bad idea to bypass the whole message processing loop Although I have to complain that you were to lazy to even try it In general, you should experiment much more. Up to now it looks to me as if you are thinking "will this help me? Hmm, don't think so. Let's cry for help" instead of playing around with what you already got. This is one of the things I always wonder about: Why are so many people so short-sighted. Be creative! With a decent backup, nothing severe can happen, so why do you just sit there? One of my slogans for this is: You can't tell if you haven't tried.

And for now it's been enough yadda-yadda in one post, it's your turn


BTW, is that file manager cool? (Except for the protection). If yes, please drop me a PM with the name I'm still searching for a decent file manager utility because none of the ones I tested yet really satisfies me

Well I'm not lazy but rational...
If I find the reason for the first crash, I will pass the whole loop by hand.

Read my post again and you will see, that I wrote "give up for the moment".
In some way I'm in that situation, that I see lots of trees, but not the whole wood.

Making a pause and collecting mind can be very helpful sometimes...
I tried out all the things, that you and Admiral had post, for several days without having success.
So I admit to be a little bit frustrated.

In fact of trying out to unpack some other programs protected with v1.23 RC4
in the meanwhile and getting still the same errors, I should start once more straight from the beginning.
Seems like I make a basic mistake...

That means I will protect our beloved notepad with ASProtect v1.23 RC4 and try to find out what happens.
But I'm still looking for a link to get v1.23 RC4, because I don't have this version.

Name of program dropped by PM...

Regards,
magic

In my experience, an access violation that causes a dump to fail generally falls into one of two categories:

Either the program is accessing a clearly invalid pointer (be it null, -1, 0x3C or whatever), in which case you may be experiencing stack or heap corruption. Inspect your trace and find out where this pointer was last set (prior to its use). You may have to do a bit of cat-and-mouse, but eventually the trail will lead back to where the problem value is loaded from.

The other possibility is when the pointer causing the access violation looks fairly convincing (i.e. it would seem at a glance to be in the process's address space, say 0x4xxxxxxx or 0x7xxxxxxx etc.), but on further inspection turns out to be nonexistent (or inaccessible) memory. If this is the case, find out exactly where your invalid pointer is pointing, and try to think what it is aiming for. If you can find your way to the (exact) same spot in the packed executable (which isn't always too easy if it's in a lower tier of the message loop, as seems to be the case) then check out what the address of this same (and now valid) pointer is. Compare and contrast.
If it's pointing into the space that has been allocated to the packer (which obviously doesn't exist in the unpacked binary) then you've isolated your problem. You may be able to patch this problem away if it only occurs once or twice. Otherwise you're going to need to find out which chunk of the unpacker's memory you to need to retain (and possibly get your dump to VirtualAlloc in by means of an inline patch at the beginning of your dump, if it's outside of the module's address space).

I would suggest as a first step (to get you into the right ballpark) debuggering up your packed exe, letting it do its thing and breaking at the OEP as usual. If the process is dumpable at this point, then the unpacker code will be dispensable. I doubt this is the case (because your dumps don't seem to work), so now's the time to set a memory access breakpoint over all the memory pages you believe are not needed by the unpacked program.
Hitting F9 will show you which parts of the unpacker's memory are still needed (pay particular attention to the unpacker's .data section).
If you don't get any breaks, then your access violation problem will need a bit more thought.

Until then, let us know where your invalid pointer is going, and where you think it should be going.

Regards
Admiral

Well, here is an interim report of what's going on (or not)

As I already announced, I played a little bit with a demo version of ASprotect 1.23 RC4 build 08.07
This version is recognized by Peid as 1.23 RC4 1.3.08.24, therefore exactly as my target.

All programs which I protected with that, could be unpacked without problems.
So I tried out i. e. protected notepad.exe to unpack with stripper.
Unpacked version by stripper crashed with the usual read error...

So I compared unpacked version by stripper, with manual unpacked program.
The result of comparison was one wrong Import in Import Table of stripper.

That makes me believe, that an incorrect Import let's my program crash!
This are the restored Imports by ImpRec ASProtect plugin:

002161D4 ? 0000 00ED1CC0 GetCurrentProcessID
0021625C ? 0000 00ED1CD8 GetCommandLineA
002162D8 ? 0000 00ED1C8C GetVersion
00216338 ? 0000 00ED1CB8 GetCurrentProcess
0021634C ? 0000 00ED1C64 GetModuleHandleA
00216394 ? 0000 00ED17A4 GetProcAdress

GetVersion and GetCommandlineA are straight at the beginning of program and should be OK.
So one or more of the other Imports should be wrong or in wrong sequence...

In the past I unpacked once a ASProtect 1.2 [New strain] program.
Here following Imports were reconstructed:

0015C26C BFF76DAC 0000 KERNEL32.dll GetProcAddress
0015C270 BFF7771A 0000 KERNEL32.dll GetModuleHandleA
0015C284 BFF8C5AC 0000 KERNEL32.dll GetCommandLineA
0015C318 BFF7771A 0000 KERNEL32.dll GetModuleHandleA
0015C3D0 BFF92E29 0000 KERNEL32.dll LockResource
0015C41C BFF7BB26 0000 KERNEL32.DLL GetUserDefaultLCID
0015C448 BFF76DAC 0000 KERNEL32.dll GetProcAddress
0015C454 BFF7771A 0000 KERNEL32.dll GetModuleHandleA
0015C488 BFF92DFC 0000 KERNEL32.dll GetVersion
0015C48C BFF9622C 0000 KERNEL32.dll GetCurrentProcess
0015C498 BFF92E24 0000 KERNEL32.dll FreeResource

11 Imports and not 6...
That seems not to be a great help for my problem.

Somebody has a hint, which of the four Imports
(GetCurrentProcessID, GetCurrentProcess, GetModuleHandleA, GetProcAdress)
could be wrong or which sequence could be correct?

I think anybody should know, which Imports are rebuilded by ASProtect 1.23 RC4 1.3.08.24,
because Alexey seems to take always the same Imports in one version.

Regards,
magic