Hi,

I seem to be getting a lot of ASPR'd programs lately. Most of these are update versions on a regular basis (new version per week is not uncommon it seems). Unpacking these programs is not a problem, but it is getting a little boring and tedious now. Therefore, I want to write a program to help automate the task.

For testing, I use dvd2one and dvd95copy as they are fairly recent programs. I want the software to unpack both of these automatically without having to use ring0 - going to try and do it purely in user mode. Once (if) done, I will gradually expand the program to handle the other apps.

Now, the program at the moment can find the OEP of both programs noted above within a few seconds. It can also find the stolen bytes from dvd2one, fix the header, rebuild the import table, and, create a working exe file within the minute. However, it falls over on dvd95copy, as it can't find the stolen bytes. I know why this is (they are overwritten with garbage by aspr), but not sure how to get around to pausing the program before the bytes are trashed. If I use softice, I can pause the program and find the stolen bytes, but is it possible from a standard user program ?

At the moment, the program just runs the aspr'd program in debug mode, and relies on debugger event messages to see what it should do next. It's worked quite well upto now (must say however, that the SEH's in aspr's unpacking code made it a LOT easier - Thanks Alex! :-)

Is there a way to tell where in memory you need to stop ? If so, you should be able to do something about it...hm.

One "trick" I used in my debug brute forcer was to throw a deliberate int3 in there somewhere -

perhaps you could pause the program at a known point - where you know the stolen bytes should be decrypted by now, then search for the apsr signature, and throw a deliberate INT3 in there, and have your debugger watch for it. When it gets hit, grab the stolen bytes.

Just a thought.

YOu'd think Alexy would have tried using IsDebuggerPresent huh? (Even tho it's easy to "patch". I can't, for example, get Tamosoft's Commview to run under a debugger. DOn't know yet if it's asprotect or commview that's exiting in those conditions. Also never could get Armadillo to run in debugger either (even tho I used DEBUG_ONLY_THIS_PROCESS).

Also, if you are using Windows XP you can now do a couple of new debugger trix. You can for example, force another process to throw an int3 immediately (there's a call called DebugBreakProcess)

ALso, squidge, if you could PM me and help me with OllyDbg - just one small question - when I pass the exception handler to the program, I usually land in kernel exception handler, I then press ALT+f9 to get back to user code. Is this correct - and will I actually land in the SEH code - because seems most of the time I land at the next bad instruction (xor [eax], eax) right after doing this. (Unless that's just how it is)

-nt20

hi squidge,

I hope it will be PRIVATE only tool
coz alexey improve his assproduct without pay us
plz, don't make same mistakes, don't publish your new, I hope amazing tool

@sp8: Well, since most people here know how to unpack ASProtect manually (and there's certainly enough information for anyone else to learn how to), and each program seems to have yet another version of ASProtect which causes existing versions of unpackers to fail, I don't really see the point is publishing another unpacker. All it seems to bring is people asking why it will not unpack prog X.

Therefore, my prog will indeed be a personal use only program. It'll be "tuned" to my set of apps and hopefully work for a while with minimal tinkering, as Alexey won't be able to get his hands on it to find out how it works

@nikolatesla20: int 3 seems like a good idea - I forgot about that. Aspr does dynamically allocate the memory, but since I can tell where it calls the routines, I can easily find these memory addresses and throw some INT 3 instructions in them. For now, I'll see if a simple offset patch works.

Hi squidge,

How about using Hardware breakpoint on stack ? just like the way Olly does it ... should work...

The problem with unpacking aspr is that you will still have to fix all the small aspr loader check etc which makes it annoying... i would say a generic approach would be gl0bal's path of making generic patcher... inline patching aspr is not that hard actually, in fact quite easy reverse engineering task due to bugs in aspack ...

I assume you mean placing a "on access" hardware breakpoint at the position in the stack where aspack would access via a push ebp or similar ?

Not played with hardware breakpoints before so I'll have to find some documentation for it - is there any example code anywhere? My breakpoints normally consist of nothing more than placing int 3 into the code.

hi squidge,

try bpm pack at y0da site... pretty simple to use Drx i think...

hxxp://y0da.cjb.net/ <-- remember change http

h**t://win32asmboard.cjb.net

Here you have a good program for removing Asprotect
h**p://www.is.svitonline.com/syd/

best regards,
.:hack3r2k:.

Yah... syd...

But noone learns by dl.ing an automatic unpacker...

And besides... Has he even finished the new version to cope with the erased stolen bytes? Like in DVD95Copy?

(I guess if he has, I'll get shit for asking... But I'm too lazy to check it out for myself... or, maybe... nah... later!)

/Manko

crUsAdEr / S3ri@l CoDe9x: I've downloaded the c source of hardware BP from Y0da's site and will be playing with it today. Doesn't seem as difficult as I first thought.

hack3r2k: AsprStripperXP is a good program, but it can't unprotect many programs - which includes the one I'm trying to get my own unprotector to unprotect (dvd95copy). It doesn't come with source either, making it difficult to support new versions of asprotect.

Manko: Not finished new version yet - I guess it will not be long however now I got source for setting hardware bp's

Thought maybe some might find this useful to play around with , as I'm currently doing.

Some template debugger code, it allows you to load both Aspr and Armadillo programs into it. It patches IsDebuggerPresent in the program's memory as well, which allows Arma to run

It then passed the exceptions back to the programs to let them handle what they need to handle, but you still get the first chance.

Seems the solution maybe for them is to check the firstchance code of the exception? perhaps....then they could know they are being debugged? Maybe I shouldn't give that away



-nt20

Ya, super easy to inline patch

Just debug and count exceptions, at last exception, patch the code you want. Done. 27 exceptions in latest aspro.

Is this too much info for Alexy?


BY THE WAY, the code I posted above only works with Armadillo on WinXP. On Win2K, it gets the child process sent to it for some stupid reason, and causes it to fail. WOrks 100% on XP tho. On WIn2K you have to patch IsDebuggerPresent the other way, without using INT3's. (create suspended, Set infinite loop at oep, let the process run, patch api, then suspend, fix oep, release. - now you can debugactiveprocess)



-nt20

oi! thats how my proggy works! (and how I unpack them with Ollydbg). also means I can set breakpoints without fear of them getting cleared

Niko ... u r talking about a "loader" aren't you ??? Or are you planning to "inline" the whole debugger code into aspr ?

Yeah, it's basically a loader.

-nt20

Aw, c'mon guys, don't say you haven't still disassembled and re-created your own "peidy.com loader.exe". Every ASsPR cracker MUST disassemble it...

As Eric S. Raymond states in his How To Become a Hacker essay, "Nobody should ever have to solve a problem twice."

-- FoxThree

You may have a point...I don't get it yet tho - (cause I don't know what the peidy loader thingy is yet)

However, there is a complete lack of tutorials on the web that cover anything to do with creating your own loaders or unpackers. I have not found one tutorial on how to write an unpacker, and I think someone needs to do so - if not a full unpacker, at least the basic skeleton of how to get started (Even though I am sure there are several ways to do it).

Perhaps I have just not looked in the right areas yet.

Besides, sometimes the best way to learn is to just experiment

So what have you been up to lately foxthree?

-nt20

Tesla:

Glad to see that you're doing some good work. The loader thingy I'm referring to was the one that some chinese hacker released which found the OEP of ASsPR in a few seconds... by the stack balancing method as Crusader writes in the previous posts. You must get the binary and disassemble it. I did it and managed to learn a lot about the working of ASsPR and generic ways of defeating it. Hell, if I'm not swamped with "real-world" work, I could write a tutorial... but ...

If you want, I could send you my commented IDA listing of the loader...

BTW, have you seen +Splaj offlate?

Greetz to Kayaker, Crusader and ofcourse, the *evil* EVAL

-- FoxThree

FoxThree !

Why are you so shure that loader.exe uses stack balance
described by Crusader. Have you tried to load new Aspred programs with no

popad
jmp eax

and have you seen the result. The last dip is actually fake OEP, but he can't interpret as well, but also can't find real stolen OEP. And it can be due to two reasons

1) He doesn't use stack balance
2) Or new Aspr have some stack fillings before he goes on usual stack managing. For i.e the same method with stack balancing will not work in identical way with new and old Aspr. Crusader said that one have to pass pushad. But that is not the way with oldy proggies

And can that be then generic way to find OEP ? For particular version yes, but in general ?

Soldat

Just for your info: my current aspr unpacker finds OEP by counting the number of access violation exceptions, then restarting the program, and before the last exception, it places breakpoint in the 401000 section of memory and prog breaks on the OEP.

Kinda more difficult to find the stolen bytes on the latest version of aspr however. On this version it does use stack balancing.

Hey fox3, long time no see ...

LOL... me kinda busy but keep comeng to read the forum, kinda nostalgic...

Anyway, i think Kanxue Studio (loader.exe) used VirtualProtect(Ex) which is what squidge should use i think, that way you wont have to re-run the target program...

Also, squidge... placing breakpoint on 401014 (bpm x)... that will ensure all codes are decrypted by then... you can also bpx and numerous Registry API that aspr uses...

Tesla : unpackers source code are there on tools sites... you can find many written by r!sc, Deamon which are pretty nice... there are too way, the proper way is reverse the loader of aspr and emulate it to fully decrypt the proggy, the lame way that i do is let proggy run and wait for the right moment to dump it... loader are basically process patcher, source code are also available, the best i found are R!sc's RPP and another one by thewd... you cna just grab them from protools... take a look on r!sc aspr1.1 unpacker ...

Soldat : yeah, old aspr you dont trace pass pushad but the method is similiar... you cant expect a ready to use anytime solution but this way of finding OEP is pretty generic for any protector/packer...

Is your unpacker helping tool or is press and don't think. And do you manage dips automaticaly (bad for me) or leave user to manage them by himself (better), and your unpacker just give him the info about them with option which one to bypass, thouhgt it would demand once more pass, or maybe not with some tricks.

And I don't know if I've understood as well about finding stolen bytes. Have you solved that or not yet.


And if you manage dips, if you don't want to stay the secret because one guy PM me about that. Just to compare idea.

Soldat

Yea I realized that and wanted to ask for that. But wasn't sure if is that with all proggies so. With some I tried was and gave to me several ideas about dips finding.
Can you explane whay is that ret executed. Is that some basic check
for alignment....

Soldat

Squidge:

your idea for finding oep is the same way I was thinking of doing it - count exceptions and right before last exception set bpm in low memory area. Won't find stolen bytes of course but works sort of like a ring3 tracer in a way.

Crusader: I do remember browsing thru the source code of an aspack unpacker, in which they ripped the decryptor code out and used it. (Stood out in my mind because they ripped the hex code itself and just patched it in as an array, instead of actual asm instructions) However, browsing thru source code and a tutorial are not the same thing There were internal data structures used in the aspack unpacker, which I do not know how they came about on. It would have been nice to see how they arrived at what they did. FOr now, I was personally planning on using the lame way to do my own little unpackers at first - force the program to do the work for me. Obviously asprstripper author has some time on his hands....

Time to exeriment with those hardware breakpoints. Easy enough. Just a question - I've looked at some docs and I'm not sure - when a hardware breakpoint comes thru (a bpm X) what is the exception code? EXCEPTION_BREAKPOINT ? Or something else. 'Cause you may have to keep a list of the breakpoints you set and check it when the exception comes in if it's EXCEPTION_BREAKPOINT, just in case the program itself happens to do its own exceptions (so you can return exceptions that aren't yours)

Speaking of Splaj+ , I'm sure this would all be hooey to him, probably consider it a waste of time.


-nt20

Squidge:

I got a similar result by counting exceptions and then evily patching int3's into the entire first half of the program. (like 00401000 to 0040a000). THen I just report any bad int3's - which will be the oep pretty much. Tried it on a couple of progs and it works.

Now if there was a more reliable way to trace down stolen bytes..


I tried VirtualProtectEx with GUARD_PAGE but I could't get virtualprotect to work, it kept just failing.


PM me to clue me on how to set the breakpoint in the 00401000 area like you are doing.


-nt20

You may find this interesting to try.

It works on all the programs I tried that are asprotected.

It's an OEP finder and dump holder - finds the program oep and stops there while you dump it.

Since the orginal program was compiled using standard linker setups, mostly the code comes before any data sections. Hence I can just take BaseOfData - BaseOfCode and plop int3's into the entire code section so it will break no matter what when it hits oep. THen I restore it and let you dump. That's the basic concept.


-nt20

VirtualProtectEx (processid, 0x401000, 4096, PAGE_EXECUTE_READWRITE | PAGE_GUARD, &oldprot);

Seems to work pretty well for me. Gives a 0x80000001 debug exception code back (STATUS_GUARD_PAGE_VIOLATION) with the exception address being the address that the prog attempted to execute (ie, OEP, etc

are we giving too much away here?

let me know, maybe some posts should be deleted...


I still cant get virtualprotect to work - my code was very similar to yours (only difference was size argument). returns failure. Oh well int3 works too....

-nt20

Might be giving a little too much away, but hey, how much can the code of protectors change now? We all know that Alexey is as idle as any coder, and wants to change his protection code as little as possible

True, we may be doing some of the work for him, but I think most of the posts here are valid for many packers, not just aspr, and no doub't would generate a good ground knowledge for any newbie that can code.

As for your error, are you sure you are passing the correct flags to OpenProcess? If so, what is the result from GetLastError after the VirtualProtectEx ?

At first I wasnt using OpenProcess. Then I tried it with it and it still didn't work. This is on Win2K. Haven't tested it on WinXP yet.


My OpenProcess call was:



I also thought of another idea: you could just virtualprotect it to PAGE_NO_ACCESS and then catch that exception.

I'm trying to think of a good way to catch which instruction led to the access of where the oep is. For example, the usual instruction is a JMP from asprotect. Is there some way to track this JMP - I thought even maybe about doing simple Trap flag tracing after the 27th exception. Could be by that late such a trace wouldn't be killed by aspro.


-nt20

Seems dvd95copy's download is broken right now

anyone want to send it to me?

untouched of course. I can do the work.

nikolatesla20@yahoo

append .com

-nt20

Nikola ... most stuff here are known for sometimes already... a search in the board will prolly yield the results you need ... like fox3 said, get kanxue studio and u r done... u should really study aspr.dll before attempting an unpacker

cheers,
/me is gone

Hiyas,

There's some wild ideas being kicked around here. One of the more technical packer discussions I've seen, actually dealing with programming. DEBUG_EVENT as a control proc, the coding possibilities are interesting.. But Patching INT3's over the ENTIRE code section to force catching the interrupt?? Lol, I don't think this is generally an accepted coding practice!! But, after all, this *is* RE Devilishly effective though.

Private unpackers are a good thing. Maybe the biweekly variations of Aspr are a better protection than all its dipsy doodling double dips combined.

It's good to see some old 'faces' around, it's terrible isn't it when RL interferes with RE?

Cheers,
Kayaker

Are you sure that OldProtection is being allocated somewhere first? I'll assume it is, so try changing that PDWORD to a DWORD and putting &OldPRotection in your VirtualProtectEx.

Kayaker

Yes, patching int3's is a wild idea, but hey, I like to think outside the box. It works very effectively, and isn't killed by SEH code.

You think that is on the edge, what about my blatant patching of system calls with WriteProcessMemory() ? Walking all over the system on that one. In Win2K and XP it's safe tho, because of the copy-on-write protection Don't you love new technology?

Also, I recently added more code to my "GenericDebug" to allow it to patch GetSystemTime() to defeat the random rebase aspr uses for the OEP jump code. That's right, no more searching for signature bytes. Just run my program once, write down the "OEP". Then before you allow it to continue, run superBPM (for NT ) and but a bpm X on OEP. Get out of my program and let the protected program run normal. BPM will show you LastBranchFromIP. This is where the jump code is. Now you can look around for stolen bytes or whatnot. If they are being overwritten, set a new bpm X in that area now. It will be in the same spot always now since GetSystemTime is patched Now you can get stolen bytes.

As an exercise, I plan on attempting to write a device driver that grabs the MSR registers for me on my int3 exception catch, so I can get that LastBranchFromIP ( or more probably LastExceptionFromIP) for you in my program. DOn't know if it will work yet - I know I can get the MSR's, but I don't know if the values will be right or not.

Just as a side note, superBPM allows hardware breakpoints to work as well from my debugger, not just SI

Yes, I have no life, and yes, I am obsessed. It's in my nature, it's why I usually beat every video game.

-nt20

OK I cheated a little on the ring0 stuff. I wrote a device driver - but only to give you one more piece of info.

Here's what the new stuff does.

Patches GetSystemTime so *spr doesn't rebase anymore.
plops int3's as discussed earlier in thread.
hooks int 3 with a kernel mode driver.
uses int3 hook to capture MSR LastExceptionFromIP. This gives you the EIP at the instruction before *spr hits the OEP. That's right, no more signature bytes required, and no superBPM required. You can go to the address in SI and see if you have stolen bytes or not. (If you have a version that overwrites the stolen bytes, you'll still need superBPM to but a bpm before they get overwritten. You will be okay as long as you load with this tool, it keeps *spr from rebasing, so bpm's will work fine).

Yep, I think it's pretty useful now.

Just as a side note, I hate service api's. Grr.

THIS IS ONLY FOR WIN2K / XP !!!!!!!

Tack on a disassembler and I could show the memory area right away, and then also allow you to set BPM, it would be very very handy. SuperBPM simply hooks ZwContinue, and that's pretty much it - could be replicated into the int3 hook eventually to all work together...


-nt20

Nice one nikolatesla20 !

Your source code will be very usefull for a lot of different packers/protectors I'm sure.

Attached is a disassembler for you to put into the code as and when you have the time. It's the same one as used in Ollydbg and RTA.

actually this one is wroted by olleh, the author of ollydbg so its a nature it will be used in olly :P
as for the rta tool, well since the disasm code is under the gpl so it ccan be used freely =)

yes, I know it's written by Olly, that why I said it's the same engine as used in Ollydbg, and the left the copyright and GPL in the zip file. Just downloaded and posted here for more convenience.