Log in

View Full Version : Packers Signatures! (Or another lame thought?)


foxthree
March 13th, 2002, 10:48
Hi fellow RCEs:

Out of sheer curiosity (or boredom ), I thought I'd start up a collection of various packers and their OEiP Sigs. That way we can have a comprehensive way of dumping at OEiP (instead of debugging the polymorphic engine itself!).

What I wanted to know from your experience is that:

1. Has this already been attempted (i'm sure FileScanners already implement some form of this)
2. What has been the success rates (sigs have to be fairly invariant for this project to be successful... note: I use the term "fairly"
3. Any other thoughts (...including calling this one a lame idea )

Thanks for sharing your wisdom,

Signed,
-- FoxThree

PS: Kayayker: If one can compile such information and write an app that can identify OEiP given the executable, is it worth a mini-project in RCE? Thanks!

crUsAdEr
March 13th, 2002, 13:37
Hi fox3,

SplAj did started some sort of packer signature bytes some time ago, i dont know when but before i came to join this board... you might wanan check with him if he is still compliling them... think he'll be glad to let you try and carry the job...

Search the board, ya will find his signature bytes list :>, not so updated though...

Regards,

foxthree
March 13th, 2002, 13:57
Hi binh81:

Thanks once again for your insightful tip!

Keep up the good work!

Signed,
-- FoxThree

Kayaker
March 14th, 2002, 08:41
Quote:
Originally posted by foxthree


PS: Kayayker: If one can compile such information and write an app that can identify OEiP given the executable, is it worth a mini-project in RCE? Thanks!


Hi FoxThree

Could be interesting... What are you thinking of, an app which loads the target program, allows it to run to decrypt the signature bytes, then searches for and retrieves the address of the signature bytes pointing to the OEP? I don't usually do the signature byte thing myself, but I assume they're not identifiable in a hex dump of the packed file, so you might have to implement some sort of dll injection so that your program runs in the same address space as the target program so that it can search its memory in a valid context.

One problem with the dll injection idea though is that the addresses of the high memory unpacking code (and the 'jmp eax' or whatever signature bytes) will be different if you *don't* have an injected dll. This is one thing I've noticed with at least Asprotect, so you'd be giving the user false information if you give them that address, unless they also used your loader to run/unpack the program.

Binh81 is right, you might want to build on the work of Splaj (if that was cool), because he definitely had the definitive list of sigs at one time. You might want to consider allowing the user to edit the list to add new ones as well as they are discovered, rather than hardcoding them all and having to worry about updating it yourself.

There may be easier ways to do what it is you want to do, but then that's what the project discussions would be about wouldn't they? I had said that I'd be happy to see people using the mini project forum to develop and get feedback on their own reversing tools, seems a perfect venue for that, so I can't see any problem in using it to start discussing your project ideas if you want.

I or one of the other mods can move this thread there, or you can start a new one when you're ready if you like. I'll help however I can.

Regards,
Kayaker

foxthree
March 14th, 2002, 17:05
Hi Kayaker:

Thanks for your informative words of wisdom. Now, I'm even more motivated. I have a *slightly* better idea than injecting a dll. I'll have a beta soon (atleast for ASPR). I'll start the thread then.

Thanks again,

Signed,
-- FoxThree