Team Project: PHP Processor v1.2???

1. You will find out in the mean time ... but i think the tutorials should have already mentioned... no anti-dumping though...

2. Stolen bytes make it harder to obtain a good dump, OEP but in this case there is no stolen byte so you dont have to worry about it YET.

Your OEP is correct ... good job... counting number of exception is ok to find OEP but not generic, since each version of aspr has different number of exceptions... but we will work on other methods afterwards ...

If you read the many aspr tutorials, they will explain what those exceptions do, why your memory breakpoint wont work ...

Well, I do believe 599600 is not < 500000 so of course your tracer failed ... i do not use Olly so i cant tell u how it works.. sorry abt that... i dont like tracers anyway cos they are slow...

keep working

crusader, sorry, I made a mistake about the tracing stop condition ... the one I used is EIP < 900000 (I corrected the previous post). And although the OEP is indeed < 900000 tracing NEVER stops and just goes on forever!!! As I said, I repeated this step numerous times and then puzzled I just gave up defeated. But I'd like to understand why this is happening.

The tuts I read talk about anti-softice tricks ... they don't mention any other trick to address other tools (ida, w32dasm, ollydbg, procdump, etc.) or any generic (anti-debugger, anti-disassembler) tricks. Could you say something on this? I imagine that different versions may also implement different countermeasures.

As for the exception counting method, it is true that there may be a different number of exceptions generated by different versions BUT can't I just count the number of exceptions for the specific target and stop just one before and then trace to find the OEP????

And no, the tuts I read say nothing as to why exceptions are generated. Is it to verify if the application is being debugged (exceptions in a debugged application are sent to the debugger ... so if an app generates one exception but does not "receive" it it's a sign that the app is being debugged)???? Or is it an API calling technique (exceptions are generated with an index and this is used by the exception handling routine to invoke a given API with the parameters that have been pushed on the stack)????

As for memory breakpoints, well, they do work (haven't tried HW breakpoints)!!
When I was battling with this tracing stop condition not working, arrived at the 19th exception I tried placing a memory breakpoint on the instruction following the OEP to stop ollydbg if the trace stop condition would not work and that breakpoint did stop ollydbg's tracing!! This is one of the tests I made to verify that tracing stop conditions where failing. Could it be that from the 19th exception on asprotect does not check or remove breakpoints anymore (this is done acting on the debug registers, right?).


padawan

PS: around what asprotect version where stolen bytes introduced???

Hi Padawan,

Okie i installed Olly... at the last exception, i set trace condition by Ctrl T with EIP within range 40100 to 600000 then press Ctrl F11, boom olly breaks at OEP so i am not sure what you did wrong, maybe different OS... i am on win 2k3 server...

What exactly is the problem? the tracer never stop and PHPProc runs normally or Olly throw up an exception?

Okie, looks like you need to find more tutorial ... which tuts r u reading now? Labba one? Ricardo one or which one? there are lots of aspr tuts out there and it is important to read more, each explain thigns slightly differently...

You are right about the exception couting method ... in fact you dont need to count, just keep pressiing Shift F9 until the app runs, then u look at Olly screen and see the address of the last exception, then when you re run simply stop at that same address and start tracing ... then again this kind of trick is not educational simply because you dont learn anything about unpacking...

About seh, I am sure there tutorials out there mentioning it and how it clear debug register to prevent hardware breakpoints... that is exactly why aspr throw up so many exceptions .. to prevent cracker from placing hardward breakpoints...

Regarding exception generated by program, yes the OS will call the debugger to handle exception first, then the debugger has the option to handle this exception or not, if not then the exception is passed onto the handler within the program itself... when you press Shift F9 in Olly, you are saying that Olly do NOT handle exception caused by Aspr, let Aspr handle itself... hope this is clear

Yep sorry abt memory and hardware breakpoint confusion.. i didnt try olly before and the way Olly name it is slightly different...

Hello crusader,

yes, I'm reading tutorials from LaBBa, MrGandalf and Ricardo.
Tracing works fine now for me too. I had the option to trace over system DLLs selected and I was always starting tracing from inside ntdll.dll. Unfortunately OllyDbg seems to have a bug because in this situation somehow any pause condition (such as EIP<900000) is somehow ignored and tracing goes on forever (even after getting out of the ntdll.dll).

About the exceptions, from what you say it seems that they are generated just to remove HW breakpoints (no debugger detection e no API calling thru them) ... I expect memory breakpoints (int 3) to work though. Can you confirm???

The tuts I've read however said nothing about why exceptions are generated .... only on how they can be exploited to identify the OEP. I'll need to find one that describes how HW breakpoints can be removed by generation of an exception.

crusader, could you please answer the following question:

1) around what asprotect version where stolen bytes introduced???
2) the tuts I read talk about anti-softice tricks ... they don't mention any other trick that addresses other tools (ida, w32dasm, ollydbg, procdump, etc.) or any generic (anti-debugger, anti-disassembler) tricks. Could you say something on this?

I suppose I should now dump the application when at the OEP. But maybe I should look for other ways to find the OEP. Let me know. In the meantime I'll read other tuts.


padawan

Stolen bytes were introduced abt 1.5 years ago... no official version because Aspr version are never known, its website is stuck with 1.20 i think... some softwares uses stolen bytes, some dont depending on aspr setting... i fail to appreciate why this is so relevant ?

int3 on Aspr will work but be careful because Aspr has self-crc check which will throw up an error and exit if it detects int3 breakpoints.

TO be honest, anti-unpacking tricks are numerous in aspr, from anti manual tracing to obfuscation... again i dont think it is relevant until you encounter difficulty... it is too general to just talk about everything now... just go on with what u have n you will learn slowly... try not to suffocate in too much new information

Now you can move on to fixing IAT and achieving a 'fair' dump or you can try downloading other aspr protected programs and work on OEP... find one with stolen bytes and you will see how it make finding OEP hard

crusader, nothing is really necessary, I was only asking to better appreciate the protection.

I want to complete this manual unpacking and then I will try to repeat the process on other targets (possibly with stolen bytes).

BTW I must remember to look into nanomites.

Anyhow, I will let the app run until on the OEP, I will dump the application with OllyDump, and since there are no stolen bytes I will fix the EP to point to the OEP.

I will get back when I'm done.


padawan

lol padawan, yeah curiousity is good... but rather than asking, slowly you can discover yourself.. it feels better that way ... u dont want to be asking all the time do you ? Soon u will be out there helping others in turn...