Exetools

Exetools (https://forum.exetools.com/index.php)
-   General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)
-   -   Team Project: PHP Processor v1.2??? (https://forum.exetools.com/showthread.php?t=3475)

padawan 02-21-2004 03:57

Team Project: PHP Processor v1.2???
 
Hello,

I'd like to propose a team project that hopefully will take to writing a tutorial. The target I've been taking a look at is PHP Processor v1.2 (hxxp://www.gridinsoft.com/downloads/phppro12.zip).
It's an asprotected target. I have unpacked it using the latest version of stripper. It would be nice if we could work on it from unpacking to cracking it so to write a complete tutorial.
I believe the application also uses the asprotect APIs, since once unpacked it behaves as if trial period has expired.

Having found no way around the "expire" status I was thinking of making a loader. One that deletes the trial period registry entry, patches the target to hide the starting nag screen, programmatically clicks the "continue" button on the nag, and deletes all signs of the application being unregistered (10 files project limit).

I'd love to be able to work with someone more expert and I'd like to see if someone is able to identify a better solution. Is anyone willing to work on it with me?


padawan

[Edit by JMI: this doesn't belong in the "Software Releasing Forum" until you are actually "releasing" software.]

padawan 02-21-2004 05:53

Sorry JMI, I didn't notice I placed the post in the Software Releases forum ... I thought I posted in the Crack Tutorials forum for I wanted the people posting there to join. I must be more tired than I thought. Sorry again.

padawan

JMI 02-21-2004 06:43

No big deal. There isn't a "Mini-Projects Forum" like at Woodmann's to put it in anyway.

Regards,

crusader 02-21-2004 12:54

well it wont be much of a project if u use stripper to unpack for u... if u want to do things manually i would join in n help out...

padawan 02-21-2004 18:30

crusader, I have done for what I know. Not knowing how to unpack it manually I used an unpacker.

But as you can see from my initial post, I'd like to write a tutorial that goes from unpacking the target to cracking/keygenning it and I'm more then willing to contribute for what I can or to follow when I can be of no help.

The application can be downloaded here hxxp://www.gridinsoft.com/downloads/phppro12.zip (1.37MB).

Now, PEiD identifies the target as protected by ASProtect 1.2 / 1.2c. Where do I start from wanting to unpack the application manually?

padawan

crusader 02-21-2004 19:34

erm ok, i am not sure how much you know abt cracking, asm or aspr... but if you havent done this, search and find a couple of tutorial about aspr, written within 2 years or so... read n gather as much info as possible abt aspr...

then i hope u got all the tools needed, just refer to the tutorials for tools required...

once u sort all that out... dump aspr.dll... how do u do that? the tutorials explain a bit but u will have to explore also... post questions as u encounter them...

cheers,
crUs

PS : i have already downloaded the prog...

padawan 02-21-2004 20:07

Tools and reading shouldn't be a problem.
Crusader, I'll be back in a couple of days with questions.


padawan

MaRKuS-DJM 02-21-2004 20:44

padawan, you used stripper??? then i understand. look here:

005996BA |. 8945 D4 MOV DWORD PTR SS:[EBP-2C],EAX ; |
005996BD |. C645 D8 0B MOV BYTE PTR SS:[EBP-28],0B ; |
005996C1 |. 8D55 D4 LEA EDX,DWORD PTR SS:[EBP-2C] ; |
005996C4 |. 33C9 XOR ECX,ECX ; |
005996C6 |. B8 74975900 MOV EAX,_PHPProc.00599774 ; |ASCII "Can't load language library: %s.lng"
005996CB |. E8 7016E7FF CALL _PHPProc.0040AD40 ; \_PHPProc.0040AD40
005996D0 |. 8B45 DC MOV EAX,DWORD PTR SS:[EBP-24]
005996D3 |. E8 A4B8E6FF CALL _PHPProc.00404F7C
005996D8 |. 8BD0 MOV EDX,EAX
005996DA |. B9 98975900 MOV ECX,_PHPProc.00599798 ; ASCII "Error!"
005996DF |. A1 D0735A00 MOV EAX,DWORD PTR DS:[5A73D0]
005996E4 |. 8B00 MOV EAX,DWORD PTR DS:[EAX]
005996E6 |. E8 9162EDFF CALL _PHPProc.0046F97C
005996EB |. E8 48B2E6FF CALL _PHPProc.00404938
005996F0 |> FF15 2C6F5A00 CALL DWORD PTR DS:[5A6F2C] if you use stripper, this DWORD will be 00598F3C. this means: program expired (this dword is set by aspr). you have to modify this offset to 00598E28 and all works perfect.
005996F6 |. A1 D0735A00 MOV EAX,DWORD PTR DS:[5A73D0]
005996FB |. 8B00 MOV EAX,DWORD PTR DS:[EAX]
005996FD |. E8 EA60EDFF CALL _PHPProc.0046F7EC
00599702 |. 33C0 XOR EAX,EAX
00599704 |. 5A POP EDX
00599705 |. 59 POP ECX
00599706 |. 59 POP ECX
00599707 |. 64:8910 MOV DWORD PTR FS:[EAX],EDX
0059970A |. 68 24975900 PUSH _PHPProc.00599724
0059970F |> 8D45 DC LEA EAX,DWORD PTR SS:[EBP-24]
00599712 |. BA 05000000 MOV EDX,5
00599717 |. E8 D4B3E6FF CALL _PHPProc.00404AF0
0059971C \. C3 RETN
0059971D .^E9 0AADE6FF JMP _PHPProc.0040442C
00599722 .^EB EB JMP SHORT _PHPProc.0059970F

MaRKuS TH-DJM / SnD TeaM

PS: it doesn't use any APIs like you mentioned. but all the parameters (or lets say: DWORDS) for the program are set while ASProtect unpacks the target. so it is able to lead the code to other location (like here) where the program says: unregistered. so you can't find a way to crack it. but as you see, it is possible.

padawan 02-21-2004 21:46

MaRKuS-DJM, you are indeed right.
Still, doesn't asprotect provide a library that developers may utilize inside their code??? Otherwise how could the initial nag screen print the remaining days to the trial.

Just a curiosity, did you already know such global variable needs setting to a given value or did you discover it on this specific target??? Also, how many of such global variables are there around that asprotect usually sets???

padawan

MaRKuS-DJM 02-21-2004 22:42

maybe there's a small library. haven't thought about this...

i know it because i saw many other ASPr-Targets with this technique before... AnyDVD is such a target, if you manual unpack, the value is right, if you unpack with stripper, the value is empty and AnyDVD does nothing more like showing errors.
it belongs to the programmers how many variables they set... it depends of registered/unregistered status of the program how they are set.

crusader 02-22-2004 12:51

sigh... how do u expect them to learn if u feed them like that Markus? so much for a project heh Padawan... u will not learn anything if u only listen n follow exactly what others tell you to...

padawan 02-22-2004 18:34

crusader, don't think MaRKuS lead me away from my intent of getting back here with questions. He just explained one of the mysteries ...

padawan

crusader 02-22-2004 19:20

lol.. tt is good to hear ... nice to see u so willing to learn... well if u actually finish the project as u set out to... u will be able to explain exactly why the is a difference between manual dump n asprstripper dump...

MaRKuS-DJM 02-22-2004 23:02

sorry crusader, you are right... but there's a easy way to find the right value for this... if your program is expired, go into that DWORD-Call, and scroll up... above should be the code for registered or not expired program :)

padawan 02-23-2004 07:29

Hello,

first of all a few generic questions on asprotect:

1) Does asprotect implement anti-debug, anti-tool or anti-dump code??? Does it remove memory and HW breakpoints???
2) Stolen bytes: when did asprotect (what version) introduce this further difficulty. What is the theory or rationale behind their "rescue"???

Now, from what I've read the following should be a reasonable approach to manually unpack the asprotected application:

Code:

1) Locate the OEP
2) when the application is completely decrypted (execution on the OEP) dump it
3) Fix the PE
  a) correct the dump EP
  b) find stolen bytes
  c) reconstruct the IAT
      c1) correct sections characteristics
      c2) set PSIZE == VSIZE and OFFSET == RVA

I'd like to investigate each step at a time.

As the first step I started looking for the OEP.
BTW, I'm sorry but on my machine softice just can't run (video adapter driver problems) so I'm using OllyDbg.

To find the OEP I used a process that seems to be effective, the "exception counting approach" (I don't know if someone has given it a name but if not this is its new name).
1) I counted the number of exceptions to the application showing up. I rerun the application stopping one exception before and getting into the exception this time. I ended up into winnt.dll.
2) I set a memory breakpoint on access of the application code section and continued the application execution ending up at 00599600:

00599600 PUSH EBP
00599601 MOV EBP,ESP
00599603 ADD ESP,-2C

Since this seems the typical prolog to a function I believe this could very well be the OEP.

Questions:
1) is this the correct OEP?
2) to find the OEP, counted the 19 exceptions, before resorting to placing a memory breakpoint on the application code section I tried to use OllyDbg's trace feature setting a stop condition such as EIP<500000. Well, this condition never stops the tracing!!! OllyDbg just goes on running even if the OEP should indeed stop the tracing (OEP is < 900000). I repeated this step tens of times thinking I was doing something wrong and in the end, frustrated, I just tried a different approach. Still, I'd like to know WHY is this happening??? Why is tracing not working??? BTW, I'm using a window 2000 OS.


MaRKuS-DJM, when you talk of scrolling up from the dword-call you are refering to the call at 005996F0 to the function starting at 00598E28??? I have taken a look up from that memory location but I don't see anything "interesting" ... or at least no clue to code dealing with the application being registered or not expired.


padawan

crusader 02-23-2004 08:28

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 :)

padawan 02-23-2004 17:42

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???

crusader 02-24-2004 02:21

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...

padawan 02-24-2004 04:39

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

crusader 02-24-2004 05:21

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

padawan 02-24-2004 06:34

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

crusader 02-24-2004 07:57

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... :)


All times are GMT +8. The time now is 10:03.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2026, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX