Log in

View Full Version : general unpacker for almost all win32 exe


adrenal
November 3rd, 2004, 04:30
This is the source code of a general unpacker for almost all win32 exe
To download source code go to tinyurl.com/3u9xw
It is open source and the source code is included
The included binaries are packed themselves what reduces performance
Need to update for new versions of packers
Can you compile g u w . e x e from the included source code?
Tried everything to compile but I have only the visualbasic compiler and know how to work with only that compiler
Thanks

disavowed
November 3rd, 2004, 11:37
if it does what you say it can do, why not unpack the .exe with the program itself?

just some advice... any "generic unpacker" like this from 2001 isn't going to be very useful today (plus, he's using a very old version of imprec)

dELTA
November 3rd, 2004, 16:01
General unpacker for almost all executables... Tried everything to compile its assembler source with a Visual Basic compiler... OMFG.

NimDa2k3
November 3rd, 2004, 17:15
OK , It's a Project OF UNPACKING GOD'S Team !!

SL0rd
November 4th, 2004, 09:50
I would like to know what the guys working int the armadillo unpacker
project think about beasts like "General unpackers".

MaRKuS-DJM
November 6th, 2004, 08:58
Teddy Rogers and me had a discussion about generic unpacker some time before and he says the best to do this would be to develop some type of Virtual OS (running in VMWare) which does the neccessary steps to unpack a program completely

dELTA
November 6th, 2004, 16:48
There are still at least two problems with this:

1.
Knowing when you're at OEP.

2.
The executables are never fully unpacked with the more complex packers, so you really need specific knowledge to restore them to working exes, it practically cannot be done generically.

MaRKuS-DJM
November 7th, 2004, 08:56
hm... didn't thought about this. maybe it would fail on armadillo copymem first

Polaris
November 7th, 2004, 09:28
Quote:
[Originally Posted by dELTA]There are still at least two problems with this:

1.
Knowing when you're at OEP.

2.
The executables are never fully unpacked with the more complex packers, so you really need specific knowledge to restore them to working exes, it practically cannot be done generically.


If I do not recall wrongly, there were attempt to produce general unpackers that tried to find the OEP using compiler-startup code: they continuosly look for compiler startup code... If it is found, then OEp is reached, and every necessary action is performed.

And if I recall that correctly, the same author of GUW32 (which indeed is a very good tool, even if outdated) produced something that worked like this (called SCU).

Extending that concept could help in automated OEP search....

nikolatesla20
November 7th, 2004, 16:35
This was my idea for a generic OEP finder, was to look for compiler signatures. This might be defeated by protectors which rip OEP code though. Fortunately, you can't rip OEP code forever, and some protectors, like ASProtect, leave enough of it behind that you can still identify the entry point fairly well. ACProtect, on the other hand, has a pretty darn good OEP ripping method.

-nt20

T.H.A.O
November 8th, 2004, 14:10
Generic Un-Packer...???
So we don't need a Brain Any-more.?

SL0rd
November 9th, 2004, 09:28
Quote:
[Originally Posted by T.H.A.O]Generic Un-Packer...???
So we don't need a Brain Any-more.?

It doesnt matter if a "ultimate tool" is created and avaiable to us. We are always looking for learning and we will do manually things even if theres a tool that can make the job. Its like a vicious!