Hi All,

What is the recommended dump tool to use after an executable inflates itself with a packer such as UPX?

Also, is it possible to stop execution of the target after the decompression without a debugger/debuggee relationship?

Thanks,
Jeff
Jeffrey Walton

My favorite is PE tools, Lord PE also works OK. Ollydump a plugin for Olly also works OK.

Question 2: ? I don't know. My own question would be why is using a debugger not an option?
One alternative, convoluted as it might be: if you know the last few instructions of the unpacker code, change them to an infinite loop jump -02 (EBFE) using a hex editor. The file will undergo unpacking, then wait idling until you dump it. . .

Hi naides,


Academic reasons - purely speculative. However, it occured to me: a Windowed program provides this service. After a Windowed program upacks and executes, it sits in a message loop waiting for input or a WM_CLOSE (if not computing).

Jeff
Jeffrey Walton

I see. In principle, there is nothing fundamentally wrong with running a program, let it unpack and run until it goes into its initial screen, and sets itself in the message loop, waiting for an event to happen. You can at that point, dump the program and analyze its code, and learn a lot, and be happy

The problem is that, chances are, the dump image itself will not load correctly if you tried to run it. after the Original entry point was executed, the program would have initialized a bunch of structures, classes, loaded a lot of run time modules and other minutia that only happens if and when a program is run from its original beginning (OEP)

I think it really depends on what compiler was used, naides. I remember running a game, waiting until it got to the main menu, then dumping, fixing imports with imprec, and setting EP to correct place. After I ran the game, it functioned normally. While I don't doubt what you are saying concerning all the junk being initialized, sometimes that is all just ignored and overwritten when the program starts up.

ImpREC, now go read more articles about unpacking.

Hi LLXX,

I'm not interested in the operation. For that I'd go to SourceForge and download UPX to study Packing/Unpacking. I was more interested in the tools used to automate the process.

Thanks,
Jeff
Jeffrey Walton

what do you mean by dumping (dumping as in getting a standalone executable dump or just dumping process memory as a whole for forensics )

if you are interested in the latter variety of dumping

you can attach an external application non invasively and dump the whole memory

for a sample
use ..//.//debuggingtool//ntsd.exe -pv /ma -pn notepad.exe mydumpednote.dmp
pv is non invasive attach , pn is processname /ma is usermode minidump (64 kb dump that gets generated by WER on erring applications ) notepad is notepad mydumpnotepad.dmp is an arbitrary name for the process memory dump

you can tweak them as you like to get a whole memory dump

also checkout adplus in ms debugging tools on way to dump a complete process including dlls memory

and checkout debuginfo.com by oleg starodumov for converting dump memory to real executables

But to understand how to automate unpacking, you must know how to unpack... same with anything else you want to write a computer program for.

Programmers cant understand the concept, LLXX. Dont waste time

When you program, you get out with an analysis and you need to (find a way to) implement it, usually coding thousands, millions of code lines. And it often requires good programmers.

Coding a basic tool is a thing almost everyone can do after you read X for dummies, or very little more.

What programmers cant grasp is 'where' the difficult work really is -exactly where they are not specialized about.

Coding a tool (i.e. a loader) is a thing even one with 0 programming knowledge can do... because understanding what to do and how, that is the problem of creating a loader, not coding it.

Still i remember one funny that roared he was a good coder, so he wanted to build tools -if a teenager with 0 knowledge can, while an advanced coder couldnt?!!?
eheh, so funny

Hi Maximus,


I don't program. I've never had a programming job. I use it as a tool to supplement my other it skills...


I humbly disagree.


Another interesting statement. I've worked with some very good Programmaer Analyst. Perhaps we can restrict the set to "all the programmers in the region where you reside"? (If I am reading your statement correctly).


Another brazen statement. I would beg to differ with your opinion.

Jeff
Jeffrey Walton

Hi LLXX,

I do partially agree with you. As far as the automation part, it was not a requirement. I apologize that the previous statement of "...tools used to automate the process" was misleading.

Jeff

You can disagree, but that changes facts very little.
Actually, most of the tool has a very low algorithmic complexity compared to many other applications. And it takes little expertise to code it.
Crafting a loader is, for example, a thing you can often do by just editing an existing template or much more. Even coding it would not require a big programming effort/skill.
Formalize the inherent page of algo you need for a loader/basic tool and, for example, the tons of pages you need for an average application.
More complex tools might require a bit more windows' knowledge, like i.e. a tool that need to patch nanomites, but the result is the same -the programming skill required is low.

The reversing skill is what is required to understand what and how. Which is absolutely not part of the programming one. A practical sample? Take any good programmer around, give him olly, a lvl 2-3 crackme of crackmes.de and give him 1-2 hours to solve it. My hybris allows me to know the result without trying....
Give a debugger template/object to a good programmer (in case he's not good with debuggers), tell him to start&stop app here, patch this with a proper call, restart, stop there and patch that... 10 minutes of work maybe?

Flat and simple.

I must agree with Maximus. Every win32 coder knows ReadProcessMemory(), even he can have full documentation with in clicks, but knowing where to use, is the catch, and that requires some study.
And regarding the question:
What is the recommended dump tool to use after an executable inflates itself with a packer such as UPX?

Best way : Code ur own, it clears the problem with theory of simple packers and helps u get better understanding of the situations.

Regards,
Cyclo