I just noticed the following patcher, claiming to be able to "directly patch packed files" (by a large number of different packers), without having to unpack them first.

Cool tool, and quite coveted by debugger-only crackers who don't want to unpack/rebuild the exe files (or use loaders) just to be able to distribute their patch I would assume.

But exactly how does it work (mainly referring to the method it uses to find OEP in all those packed files, i.e. to know when it should patch, because it can't very well decompress-patch-recompress all those formats with all the problems this brings with it, right?), has anyone taken a look? Considering the impressing list of packers it's compatible with, I'd guess it's some kind of relatively generic method (it can't really have deeply analyzed all those packers, especially not over different versions, huh?), but which? Lack of time sadly prevents me from analyzing it to any greater extent myself for the moment. :/

Anyway, see it as both a tip for a cool patcher, and a question.

the aPE:
http://programmerstools.org/node/171

i haven't taken a look, but my guess would be that it creates a wrapper around the packed exe. when executed, the wrapper-stub launches the contained packed program and then does its patching in memory like a loader.

In talking with Ape0 a while back - it started out as a usefull crackme - and evolved from there, he's quite an nice person, I'm sure he'd be willing to share the details - his E-mail address is usually included with the patcher, he does reply.

SiGiNT

Disavowed, yes, that would be my guess too, but still, as I mention above, in this case the question remains how to reliably find and break at OEP (or at least somewhere right before, when the target has been fully unpacked in memory) for each existing version of each of those packers, to be able to carry out the patches before any target code executes. That's the interesting question!

Sigint33, ok, sounds good, I have invited ap0x to this thread, so let's see if he shows up and is willing to shed some light on the mysteries if this nice program of his.

Take a look at:

http://www.hexblog.com/2005/11/the_ultimate_stealth_method_1.html#more

Tom

you're assuming that it does this reliably
perhaps it just uses a timer ("execute original program, wait one second, apply patches".

and perhaps i should spend 5 minutes to reverse it to see what it really does instead of conjecturing

i just took a look. it appears that it uses a scriptable debugging engine to find the OEP of targets packed with supported packers.

pretty cool

OOPS! apologies to ap0x for not remembering his handle!

PS: Visit his home page he has a few other kewl t00ls there, among other things.

First thanks for taking interest in my program, and for inviting me to join the discussion. And now the explanation, how the program works.
There are three methods:
- Inline patching via direct packer/protector code patching
- Inline patching via direct patching of encrypted .code section data
- Generic inline patching

Inline patching via direct packer/protector code patching is the method that designed to patch specific packer/protector. This means that for every packer/protector i write a special patching module (yes i reverse every single patcher/protector and it`s subversions). These modules are designed to be as general as possible, so the same module can be used on several versions of the same product. This means that there are no offsets, and that the aPE searches for specific byte patterns in "dead" code. No actual debugging or process creation code is needed!

Inline patching via direct patching of encrypted .code section data is more simpler method and it can be applied on small number of packers/protector. This means that patch bytes are encrypted in a way that ensures the right patch byte decryption when crypter does it`s thing. So these modules just change bytes at their location to the value which when decrypted gives desired output. Also these modules deactivate any CRC checking code.

Generic inline patching is the "smartes" module. This module gives possibility to inline patch number of packers/protector. This module works by insertion of the aPE code which creates a patching thread inside the packed/protected .exe. This means that OEP is redirected to my code which starts original code as a thread and watches for byte patterns. When byte pattern is found patchin occures, also this module gives oportunity to modify CRC on the fly the same way the patching is done. So the CRC address is watched at all times, and when the address gets the right value the aPE changes that value to desired one! This is the same inline patching method already seen in DZA patcher and dUP, but my code is smaller and more effective.

I hope this answers some of you questions, if you have more ask-away

Damn, so you did do it the cool way (or even, all the cool ways ), I'm impressed, really nice tool ap0x.

Feel free to continue hanging around here btw, we always appreciate the presence of another class A reverser.

Whell there is another cool way i know of. The best way is to create a ring0 driver which will monitor selected memory... But this will not be coded any time soon. As for the forum i think i will stick around as much as possible. Greets...