#1
|
|||
|
|||
PowerStrip PE???
Dose anyone know what pe powerstrip 3.45 Build 410 is?????
|
#2
|
|||
|
|||
Ehh, what pe? ...
It's protected with recent version of asprotect... /Manko |
#3
|
|||
|
|||
ok i use procdump on all asprotect settings and it crashes in windows xp pro
PROCDUMP.EXE - Application Error ----------------------------------------------------------------------------------- The instruction at "0x00405c94" referenced memory at "0x00fa0000". The memory could not be "read".\r\n \r\n Click on OK to terminate the program\r\n Click on CANCEL to debug the program ----------------------------------------------------------------------------------- | OK| | Cancel | ----------------------------------------------------------------------------------- any help on this |
#4
|
|||
|
|||
better yet how do i get a program to not detect a dumper like softice or win32intro
|
#5
|
|||
|
|||
You need to read a lot and search a lot on various forums...
You need to read up on: generic unpacking asprotect unpacking hiding softice (detect softice) (patch softice) (iceext) Anyway to dump a protected executable it is necessare to pause the execution of that program first, or it can detect you or have addresses set to contain values that is illegal on start... Anyway, you have to find OEP (The address the original proggy starts with...) Hmm... Either you know too little for me to start helping you or I have missunderstood... Can you tell me again point for point, what you need help with? I'm guessing you need to do a lot of reading first though. btw, LordPE is a good dumper too. /Manko |
#6
|
|||
|
|||
Quote:
|
#7
|
|||
|
|||
Hi Zeurx !
you should be able to unpack it with the following info. oep=54F8BA stolen byets=55 8B EC 81 EC 0C 00 00 00 IatRVA=16712c size~800 after unpacking nop two calls: starting at 51FA68 and starting at 51DDDD Last edited by britedream; 08-24-2003 at 05:37. |
#8
|
|||
|
|||
stolen bytes...
I follow the aspr 1.23 tutorial that has been posted line for line, and I am able to unpack the program (can't remember what it was, but it doesn't matter)... I'm interested in knowing what steps are necessary to find the missing bytes. I don't seem to have any problems finding the point right after all of the "00" bytes (where the missing bytes should be) but I have no idea where to get the missing bytes from.. the tutorial is very vague and basically just says 'it works for this program' which really isn't a good method for attacking the packer on a regular basis. If anyone has a simple system for getting the actual bytes that need to be pasted, please drop me a PM on EFnet or just reply on the forums... thanks.
|
#9
|
|||
|
|||
Hi!
U should mention this to LaBBa, and he will maybe update tut... Hope someone will share tricks with you... else, they can be found on Woodman.cjb.net, I think. (LaBBa is there too.) /Manko |
#10
|
|||
|
|||
I tried woodman, but I think that url goes up and down throughout the day. It would still be nice to just have a simple 10 steps type of tut that gives me the missing bytes so I can drop them at the OEP and fix everything up. I have no problem finding where the bytes are to be pasted, but I can tell that aspr handles different languages in different ways. Some of the steps in Labba's tut can't be duplicated if you were attacking say VC or VB. I think with time more tutorials will show up and explain the variations. There doesn't seem to be a very clear cut approach to every single target. It depends on what options were used when the packer was applied and what language the target was written in (at least that is my perception).
If you are the same manko that writes aspr debugger, I've tried your tool a few times (and admittedly it confuses the hell out of me since it tells me the stolen bytes are at some very high memory range that makes no sense to me... I should probably see if there is documentation or something as I get lost very fast when using it =) Thanks for the reply nonetheless. |
#11
|
|||
|
|||
To T0xic !
I apologize for not responding sooner, I didn't see yr pm till today. for Labba tut I don't follow it in unpacking so I will not be able to help on Qs regarding that, but for my remarks you referred to, clarification as follow: 1-after setting the breakpoint as I mentioned, u will land in the program code, whether you see addresses in the stack window or not depends on aspr., if u see two addresses double click on the second one, if u see only one do the same ,if u see none, then u are in the right place all the zeroes above where u are, are for the stolen bytes. 2- from the above u will have a- the right place to dump. b- # of stolen bytes c- oep position d- if eax or ebx has a valid address in program's code range then your stolen bytes almost alwayes have:mov eax, [value in eax or ebx] ,as last instruction. 3- in my remarks I mentioned the place where stolen bytes should be placed,not the place where to find them, for that do the folowing : instead of pressing shift+f9 as noted in my remarks, press ctrl+f11 , you will be in the same place as above and you will see also in trace window mov ecx=[# bytes to be erased], restart, set condition to be ecx=# of bytes u saw, trace from where u traced before, it will stop just before erasing stolen bytes, go up to the jump above , will take you to the place where u should be looking for them. Last edited by britedream; 08-25-2003 at 06:46. |
#12
|
|||
|
|||
Quote:
I am. Yep. Aspr-code is always in some high memory area... The reason it's called "stolen bytes" is cause he ripp them and execute them in his own memory space before he jump to proggies memory-space... The problem now is that stolen bytes are not in plain view, like before... There are some obfuscated code embedding it and sometimes it's atleast partly mutated, meaning he does what it should with other instructions... If you study the normal start of an app from the same language... And take the time to trace through the whole block (starting from where my asprdbgr reports it...) a number of times, you will start to see what's what... Also, with newest aspr he often emulate part of code he didn't rip and dive into code at places that are not near OEP. Often inside the first call... or even deeper... I have honestly done too few of these to have had time to figure out some smart method to arrive nearer to the stolen bytes... except traceing... (dont wanna bpm on stack as that is so easy to break... he has before...) Can I buy moore time please?? There's no documentation for AsprDbgr yet and that might not happen very soon, though it WOULD be good... It is assumed that one already knows a great deal about aspr for it to be of any use... If I had time I WOULD like to make some document that explains everything, but... I don't have much time... Hmm... /Manko Last edited by Manko; 08-25-2003 at 05:38. |
#13
|
|||
|
|||
Quote:
Thanks again britedream, -t0x |
#14
|
|||
|
|||
Quote:
I may not know everything there is to know about ASPR but I can tell you that I have an open mind, and that's really what counts. I'm sure some day I will understand your program =) Thanks for your time manko. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
PowerStrip 3.0 - Hardly Packed | loman | General Discussion | 0 | 07-24-2002 03:26 |