i posted a question about this a few weeks ago, since then i've read LOTS of essays on manual unpacking, though i still can't seem to get my head around making softice break so i can find the oep. The file ive been trying to unpack is from h**t://www.express-soft.com/ftp/webpics.exe . i would REALLY appreciate it if someone could point out the packer of this file, and steer me in the right direction of finding the oep. cheers

(ive had this prog for a little while now and im getting real frustrated with it)

Hi fizzik,

Well, the Packer is ASProtect
To unpack i suggest to first read some other threads on this Message Board, because there are enough

Cya...

CoDe_InSiDe

Hi fizzik,
code_inside is absolutely right but i shouold give u some advices right now:
finding the oep isnt very hard task even with asprotect

The first thing u need is a tracer and if u've icedump its perfect
with the command /tracert

First of all u've to let aspr unpack the prog in memory and dump it to the hd so u've a copy of the original file
This copy wont work coz it has wrapped import table and wrong oep

Where's the oep in the original file?
In the .text section of coz
Usually its the first section of the dumped copy of the program but there r lotsa more efficient ways to identify it
So note down on a paper the addr where this section
starts and ends and so lets restart the packed program
U've to break inside it before aspr starts unpacking it and use the /tracert command giving the starting and ending address u've noted before
This way sice will trace the program and will pop every time the eip will land between the address u've given it
This will mean the before or after u'll surely get the oep

See ya
NikDH

Well, I tried your approach:no luck.
(I think you mean /tracex not /tracert though.
Maybe somebody could post a way to get Sice to break at OEP when the program starts to run?
I think the OEP is 401000, but how stop there?
Using /tracex didnt' work for me...

Hi hobo,
well i was confused u r right about /tracecx

What do u exactly get using this kinda approach ?

U say sice never pops when using /tracex ?

Be sure to have icedump loaded and test /tracex functionality

Try putting any breakpoint and when sice pops use tracex command using current eip and following instruction address
if sice pops u r sure /tracex works well

So u've to check to have set correctly the /tracex params
Try to check out the icedump manual for them

Another reason coz sice hasnt popped is coz the limit u've set doesnt identify a the .text section of the prog
and so the eip never gets between the limit set
Try with other sections till u find .text section
Think u can locate .text section quite easily analyzing the program when its unpacked in memory and is running normally
Make us know

See ya
NikDH

Hi

RCE#1 arrogant bastardo to the rescue.......

Did you try my 'aspr v commview 3.1' tutorial ? in there is my splajomatic way of getting the OEiP via the last 61,FF,E0 in aspr code before handing control to original exe ........
this is the quickest way I know

Otherwise just set a /tracex 401000 550000 for webpics and wait 45 minutes until si pops at 504CCC

USUALLY the normal start code bytes are 55,8B,EC.........

If you want me to hold yer hand just ask I can make a mini 'OEiP' tut if you still can't get it ...............an arrogant bastardo version of course

Splaj,

You are an arrogant bastard all right, but you help, me and the board in general.
I'll take that any day.

Note: Have you been in the army????

Hiya,
+Splaj, please check your pm.
regards

Hi there,
Thanks for the info. Yes, I have read your tut on comview posted recently. Nice work. But unfortunately your described way of finding the last bytes of code of the unpacking code doesn't work when I try it. (I'm on winMe, but I don't know whether that has do do with anything).
I can see what I did wrong when I tried the /tracex command in icedump. I was too impatient.:-) I only waited for a few minutes...
Okey, I'm off to try to unpack Webpics manually. I did a lot of unpacking in the past, but after being away from the cracking scene for a long time I have a lot to learn. Alexey(?) sure have developed the asprotect since the last time I unpacked it (that must have been one of the first version he put out).

regards,
hobgoblin

BTW, about being arrogant: Na, I don't think your that special.:-)
I have seen worse while surfing on the net for the past 4 years....

I remember those discussions Hobgoblin. Learned a lot about unpacking from you. In the 'good 'ol days' of dumping Aspack sections

regards,
Kayaker

hob

---------------------------------------------------------------------------------
I can see what I did wrong when I tried the /tracex command in icedump. I was too impatient.:-) I only waited for a few minutes...
---------------------------------------------------------------------------------

Alexey is putting MORE useless code to stretch the single-stepping time. Half a year ago my old notebook PII 266 used to take ~20mins against aspr. Now it's up to ~45mins :-(

Just press Ctl-D back in to SI any time to see that loop

So,

I'll make a WinME OEiP tut just for you...........it's real easy.......just maybe a prob to make the bpm/bpr etc 'stick'

.......and yes the OLD ~ 0.8 aspr was a laugh. No IAT redirection and the OEiP hard coded in the compressed exe ...... Alexey learned quickly

Spl/\j

PS i'm finished with being an Arrogant Bastardo now, that 30 day reality trial as 'unregistered' suggested was a bitch to crack. I'm sticking to fuxxing shareware only from now on

Has anyone tried CloneCD v3.110?

It redirects many functions of USER32.DLL and puts many "holes" in the IAT. Wants to bore us to death? but I think we can defeat this easily by enhancing ReVirgin/ImpREC or write plug-ins for them, coz all the redirected API calls have the same pattern:

push xxxxxxxxx
................
push YYYYYYYY <------------------somewhere in the middle of an API function
ret


I just found OEP = 401000 and managed to rebuild the IT/IAT, corrected a redirected call(call [004CC4BC] =====> call 00401584), but still got "EAccessViolation". Don't know why. Maybe it puts some data in ASprotect?

Hello Solomon !

I remember that kind of redirection. I came accross it some time ago.
I don't remeber where, but it was no ASProtect.
(great, now we don't know where ASProtect got it from )

So you can't set a breakpoint on the API, because you never get there.

Hi solomon,
its probably asprotect api
Putting code inside asprotect and reading it there its asprotect api (kill3xx docet)

The program checks 4 asprotect presence putting data inside asprotect mem space so unpacking it its hard work
To catch where the err happens just put faults on

When u find where he puts data just look inside the original file what its looking 4 and patch the unpacked one so he can get it
Its better 4 u not to patch the code that checks the asprotect api but to simulate asprotect presence allocating memory and filling the allocated zone with the approprieted data
Thats coz the program should check it many times

Usually asprotect creates kinda table filled with the address of the mem zone where asprotect api r present
If u find the where the table is u can fill it with static values
so u dont have to allocate mem but u can just put asprotect api data inside the pe if i'm right
Make me know

See ya
NikDH

hi DakienDX,

Thx for your reply. I'm sure it is a new version of ASProtect, maybe v1.3 or higher, who knows, coz Alex hides it. Yes I can't set a breakpoint at the entry point of some APIs, but we can set it at the end of the API, e.g the "RET" instruction.

YES NikDH u are right!
Tracing the unpacked exe, I saw it pushes some 00E9xxxx and attempts to copy the MainForm resource data there, where 00E9xxxx is in the addr space of the packer or in the heap. Then I got "EAccessViolation".
ASprotect evolves quickly and gets tougher.(greets Alex)