Log in

View Full Version : Another newbie's struggle against ASProtect...


triz-
May 31st, 2002, 05:26
First off, I just want to say that without Fravia's site and this messageboard, I'd still be wandering around muttering "Why does the disassembler crash!?!" and giggling to myself. You guys are a tremendous source of information and without the site, I wouldn't know half of what I do

That said, I throw myself before the mercy of the court seeking some pointers for ASProtect. I've been tinkering with it on and off for a little while now, and I think I've gotten the hang of getting to OEP and dumping (one step at a time ).

My setup: Win 98 SE, SoftIce 4.00

Target: h**p://www.sapphiregames.com/15pack/15pack.zip (500k)

Downloaded, unzipped, installed and checked with PEId..."Asprotect." Drat, my arch-nemesis once again.

Loaded Icedump and Iceload, and ran. Broke on INVALID's, traced a few steps and ran a /tracex 400000 470000 (half lazy and half ignorant as to when to set a breakpoint without ASPR clearing it - I'm trying ). Broke on the usual 4010xx RET - F10, traced again. Here's where it gets interesting (to me, anyways)

PUSH EBP
MOV EBP, ESP
MOV EAX, [ESP+0C]
MOV [004XXXXX], EAX
POP EBP
RET

Tracex breaks on this chunk of code 3 times I believe (I typed this from memory, and my short-term memory is a bit hazy sometimes, so bear with me if I goofed up a register in there somewhere). I believe the [004XXXXX] address changes each time, although I'm not positive. After tracing out of the third and /tracexing again, it travels on to 4457A8 which appears to be OEP.

/option p i0
/dump 400000 457A8 c:\dump.exe

Allrighty, close SoftICE and load Revirgin. Pick 15pack.exe from the menu, "Table corrupt, enter OEP blah blah" Enter 004457A8 for OEP and click Fetch IAT.

"Nothing found." Ummm...
I don't recall why, but I entered 401000 eventually, and got RVA of 4912C and Length of 5D0. IAT Resolver -> Resolve again....hm, there it is??

Here's where I falter. For example:

19 00049178 00C11270 0000 ?????? ??????

???? doesn't sound too useful . Close 15Pack, bpx GetVersion, run again. When SI pops, D C11270 to find a lot of ???'s. F5 - oh, there's something there now. U C11270 to get

PUSH 00
CALL Kernel32!GetModuleHandleA
PUSH DWORD PTR [00C16CF0]
POP EAX
RET

D C16CF0...lots of 000's. F5 again - now there's something there. "81B7A260" (this address seems to change everytime I run it). D 81B7A260 - "C:\Program Files\15-Pack 1.28\15pack.exe" Why thank you kind program, if you hadn't told me where the EXE was I might have lost it

Something else that seems...different (wrong? ) In Revirgin, using 00401000 as OEP, there's a number of KERNEL32 functions, followed by 3 USER32, 3 ADVAPI32, some OLEAUT32 functions, 4 more KERNEL32's, some other assorted functions, then even more KERNEL32s...I was under the impression they were generally in one group together?

I realize ASProtect has been discussed quite frequently in the past (I've read some of it over and over again trying to find something I might have missed), but it was starting to drive me a bit crazy, so I decided to take a new small target, do what I can, document my steps and present it here hoping to maybe learn something else from the masters
Another thing:

15PACK.EXE 252,416 bytes
15DUMP.EXE 284,587 bytes
15DUMP2.EXE 252,928 bytes (I forget why I made 2 dumps This one looks to close to be a good dump - if anyone gets a good dump of this, could you tell me how big your dumped EXE is?)

StARaY
May 31st, 2002, 05:59
hi,triz-
your oep:4457a8 is right
i have dumped it by lordpe and fixed it by imprec1.42

and it can run
but the file was still unregister

my file size is 593520byte

Lbolt99
May 31st, 2002, 08:02
Quote:
Originally posted by triz-
Downloaded, unzipped, installed and checked with PEId..."Asprotect." Drat, my arch-nemesis once again.

PUSH EBP
MOV EBP, ESP
MOV EAX, [ESP+0C]
MOV [004XXXXX], EAX
POP EBP
RET

ASPR's been beaten to death here, literally and figuratively, there's really nothing new going on with it for awhile.. but since you are making an effort, will point u in the right direction

Looks like it's doing those pre-dips into the code before the OEP is actually reached; look for +Splaj's posts on this, very well done. It sets variables which are later accessed by the program itself


Tracex breaks on this chunk of code 3 times I believe (I typed this from memory, and my short-term memory is a bit hazy sometimes, so bear with me if I goofed up a register in there somewhere). I believe the [004XXXXX] address changes each time, although I'm not positive. After tracing out of the third and /tracexing again, it travels on to 4457A8 which appears to be OEP.


It dips 3 times then, before OEP


"Nothing found." Ummm...
I don't recall why, but I entered 401000 eventually, and got RVA of 4912C and Length of 5D0. IAT Resolver -> Resolve again....hm, there it is??


RV works sometimes to get the IAT RVA but if it doesn't get it the first time, the quickest I've been able to is by Kayacker's method involving stopping the ASPR wrapper process right before it decrypts the IAT, search for his posts on this. It works every time and is the only way I've figured out to get it if RV doesn't work


Here's where I falter. For example:

19 00049178 00C11270 0000 ?????? ??????

???? doesn't sound too useful . Close 15Pack, bpx GetVersion, run again. When SI pops, D C11270 to find a lot of ???'s. F5 - oh, there's something there now. U C11270 to get

PUSH 00
CALL Kernel32!GetModuleHandleA
PUSH DWORD PTR [00C16CF0]
POP EAX
RET


It's the new way that ASPR obscures the emulated imports; see +splaj's post on "asprotect 1.4"


Something else that seems...different (wrong? ) In Revirgin, using 00401000 as OEP, there's a number of KERNEL32 functions, followed by 3 USER32, 3 ADVAPI32, some OLEAUT32 functions, 4 more KERNEL32's, some other assorted functions, then even more KERNEL32s...I was under the impression they were generally in one group together?


Seen it before, it's normal, just watch out for the GetDialogBoxParamA problem (search thru Aspr postings for more info. It'll be a strange kernel function right smack-dab in the middle of a bunch of user calls, usually, but I've only seen that trick in one ASPR'd program I've done out of 15 or so

I realize ASProtect has been discussed quite frequently in the past (I've read some of it over and over again trying to find something I might have missed), but it was starting to drive me a bit crazy, so I decided to take a new small target, do what I can, document my steps and present it here hoping to maybe learn something else from the masters
Another thing:


if anyone gets a good dump of this, could you tell me how big your dumped EXE is?)
Will look tomorrow, looks like some fairly decent games mind-puzzle etc on that site.. crack all 11 of 'em
[/B]


Risotto
May 31st, 2002, 22:55
Hola!

To use /tracex while unpacking AsProtected prog is no good nowadays. As you may have seen AsProtect tries to cheat you:

PUSH EBP
MOV EBP, ESP
MOV EAX, [ESP+0C]
MOV [004XXXXX], EAX
POP EBP
RET

Yep, this is it. Not to get to such a trap try to use other ways to find OEiP. One of the usable methods is to put a break point at GetModuleHandleA if(*(esp+4)==0) so the result will be passed to the main code. While Sice breaking, check esp and is there is something interesting for us, press F12 and several lines upper you'll see the very OEiP. In some realizations of AsProtect this approach can var, just try to look around.

To be cont...

Lbolt99
June 1st, 2002, 08:56
Quote:
Originally posted by Risotto
Hola!

To use /tracex while unpacking AsProtected prog is no good nowadays. As you may have seen AsProtect tries to cheat you:



Actually I've found /tracex to be INVALUABLE as far as finding the pre-oep dips that Asprotect does before the OEP is reached.

If it was Alexy's intent to screw with people using /tracex, by using the dips, he failed miserably: quite the contracy, it's what's allowed me to find EVERY pre-oep dip in all ASprotected targets I've looked at.

Just set thru the dip code, until it RETs back into the ASPR code, and /tracex again.. the oep code is usually pretty recognizable if you're experienced enuf

Risotto
June 1st, 2002, 22:19
Quote:
Originally posted by Lbolt99


If it was Alexy's intent to screw with people using /tracex, by using the dips, he failed miserably: quite the contracy, it's what's allowed me to find EVERY pre-oep dip in all ASprotected targets I've looked at.


G'day!

BTW, Alex likes reading such stuff and i do believe he'll take some measures. But in any way, you are absofuckinglutely right: one can /tracex till the very OEiP.

Best regards to Alexy! Когда будет новый AsProtect, Алексей?

Agur, R!50770.

triz-
June 5th, 2002, 02:40
Blargh. After screwing around with 15-Pack for a couple days off and on with no success (page faults aplenty ), I decided to follow an old tutorial of Splaj's to the letter as best I could. After a few minutes of searching (thank God for Google), I managed to find an old copy of Commview 3.1 and set upon it. Found OEP, dumped, rebuilt IAT, inserted into end of dumped.exe, changed entrypoint/IAT pointer, and ran.


"...has encountered an invalid page fault..."

I am totally stumped. The process in the tut works for Splaj but crashes every time I try it. Does ASProtect have something against Win 98 SE?

I have another question that comes from searching for "ASProtect page fault" (Yes, I actually searched before posting this ):

I noticed that Commview 3.1 has one break during a /tracex before the OEP (the usual 401014 RET junk), but 15-pack has several between that and the OEP. I was under the impression that these dips were only used by ASProtect and that when the EXE is dumped, these can be forgotten. From reading another post, I got the idea that this isn't true. With newer version of ASProtect, do you have to reinsert these chunks of code from the dips into the dumped EXE somewhere near the beginning, or can they actually be discarded?

I'm off to bang my head against the wall for a while now, so don't call the cops about that knocking sound....

Lbolt99
June 5th, 2002, 03:02
Quote:
Originally posted by triz-
Blargh. After screwing around with 15-Pack for a couple days off and on with no success (page faults aplenty ), I decided to follow an old tutorial of Splaj's to the letter as best I could. After a few minutes of searching (thank God for Google), I managed to find an old copy of Commview 3.1 and set upon it. Found OEP, dumped, rebuilt IAT, inserted into end of dumped.exe, changed entrypoint/IAT pointer, and ran.


Funny, I was just looking at 15 pack today, got sidetracked though. Will finish up hopefully tomorrow. Sounds like you might have put in the "actual" OEP instead of the RVA. A common mistake and I've done it before, if you accidently put in something like 4AEBB3 instead of just AEBB3 (the RVA) it's a sure page fault. So that's the first thing I would check.

BTW what you are dumping with? Try LordPE, when you're at the OEP, change the memory to an EB FE, so the instruction jumps to itself, locking the process, go to Lordpe, select 15 pack and Dump Full. LordPE will automatically realign the sections. LordPE is the easiest to use as far as dumping in general.


I noticed that Commview 3.1 has one break during a /tracex before the OEP (the usual 401014 RET junk), but 15-pack has several between that and the OEP. I was under the impression that these dips were only used by ASProtect and that when the EXE is dumped, these can be forgotten. From reading another post, I got the idea that this isn't true. With newer version of ASProtect, do you have to reinsert these chunks of code from the dips into the dumped EXE somewhere near the beginning, or can they actually be discarded?


The 401014 ret can be ignored, but all other dips have to be dealt with on a case by case basis. Here are some examples:

a) program initalization (chamemeon clock)

b) simple RET back to program code

c) set variables and RET

d) code decryption

e) other junk like HD hashes not frequently encountered

15 pack has 3 of the type c dips. write down the values in EAX that it writes into RAM. You'll see when to use them later on when running the program (indirect calls I think) It'll generally page fault but just restart and debug to where the fault happens and you'll see an access to the mem location that the dip wrote to, patch accordingly

FWIW I'm working on a compilation tutorial that will cover all aspects of the various recent versions of aspr as far as dumping, iat rebuild, dips, indir calls, etc. It'll be a good comprehensive reference, everything all in one place which will be good because alot of the good aspr messages are aging on here

foxthree
June 5th, 2002, 14:46
People:

Yet another "2 min cooking guide to ASPR".

Latest ASPR targets OEiP Sig: 61, FF, E0 (POPAD/JMP EAX)

If Win98SE:

1. Run Process
2. Use OEPFinder Hybrid build to locate the OEiP Sig Bytes
3. Use ICELoad to load the process. Set BPMB X on 61 (POPAD) instr.
4. F5
5. SoftICE breaks. F8. You're at JMP EAX. Look at EAX == OEiP
6. bc *
7. /dump <IMAG BASE> <IMG SIZE> <FILE>

Now the best tool to build IAT? RV ? ImpRec? RV Plugin ? ImpRec Plugin? lol

If it is "traditional ASPR" [i mean not a special buld ], my best bet would be ImpRec Plugin (ofcourse 1.42+)

IAT Rebuilding:

1. Locate Process in ImpRec
2. Enter OEiP/Get Imports
3. Show Invalid, Choose Level -1 (Disassembler) Whoa! 90% of IT is rebuilt
4. Show Invalid, Choose ASPR Plugin 1.2xx
5. "Congratulations. Will it works" he eh
6. Fix Dump. lol

ASPR is gone

BTW, I'm yet to notice any target that effectively utilizes the pre-dips. I mean, even if you bypass the pre-dips and dump at OEiP it shouldn't matter 99.9% of cases.

And btw, look out for the indirect calls

Signed,
-- FoxThree

Pssst... triz- did you try caspr on this target ...

+SplAj
June 5th, 2002, 22:17
Triz-

I wanted to send you some infos but u have no e-mail available

FYA

ASPR made the following calls and stored them :-

[C16CE0] == GetVersion
[C16CE4] == GetCurrentProcess
[C16CE8] == GetCurrentProcessId
[C16CF0] == GetCommandLineA

You can understand that for trick API calls ???

Next the IAT :-
Line 67 C11280 is LockResource and
Line 95 C11290 is FreeResource

Your OEiP is correct. Always dump with LordPE (forget Icedump)

Patch in FF FF FF FF at offset 0x46AD4 and any size grid is available

If you need more help e-mail me cos Kayaker is putting his steel toe cap boots on and ready to kick some butts .....and i'm gone

Spl/\j

Kayaker
June 6th, 2002, 06:57
Quote:
Originally posted by +SplAj


If you need more help e-mail me cos Kayaker is putting his steel toe cap boots on and ready to kick some butts .....and i'm gone

Spl/\j



Are you kidding? I don't even pay attention to these anymore. There's enough steel toed boots poised elsewhere, lol. Knock yourselves out

K.

Lbolt99
July 2nd, 2002, 21:00
Thanks for the tip but I'm having no luck getting it to start up after the 15 day trial Looked @ it with DeDe but can't make heads or tails of any of the form procedures with pertinance to any kind of comparison the program would be doing to "decide" whether or not to start up in trial or reg mode..

Unfortunately I'm finding removing asprotect to be the easy part of these cracks If someone could point me into the right direction on this one, I'd really appreciate it. It uses the Aspr internal reg method using a keyfile.. So I think the "decision" whether to run reg or trial is made in the ASprotect code if I'm right.. but I'm not sure what approach to use in this instance.


Quote:
Originally posted by +SplAj


Patch in FF FF FF FF at offset 0x46AD4 and any size grid is available


Lbolt99
July 11th, 2002, 20:17
I figured it out.. I was dumping several of them AFTER expiration!! I installed 15 pack on another PC, dumped during eval period, it's working fine now.. got to remember to dump before expiration. My mind is cloudy right now, trying to focus on too many cracking projects at once..

I'm going to take a look at dumped expired vs dumped trial period and see if I can figure out what the discrepancy is.. recall it uses the aspr internal reg key scheme..