exe32pack unpacker/dumper with source [Archive] - RCE Messageboard's Regroupment

View Full Version : exe32pack unpacker/dumper with source

bedrock

September 27th, 2003, 07:44

I hope this little tool i wrote will be useful to some, probably not many though. This has mostly just been a learning exercise for me. I have read and learnt much informations from this board, i have especially learnt much information from the boards regulars such as squidge and nikolatesla20. This thread in particular was a great help:

http://www.woodmann.net/forum/showthread.php?t=4512 (wasn't sure if i could make it clicky back to board)

I am sharing source with my little tool to help others develop, i found it very difficult to find example sources for developing this little unpacker/dumper so hopefully this will be useful to others. My source isn't brilliant, but it seems to be functional (at least for me).

Now exe32pack isn't a particularly complex packer, but i have a couple of targets that use this packer so i thought i would write my tool for it. A brilliant tutorial by snyper helped in the initial stages, and allowed me to programatically read OEP from within the packed file. Essentially all i have done is automate the manual unpacking process for this packer.

I use the Win32 debugging API's to create a debugger loop, and then use the debug registers (DRx) to set a hardware breakpoint on execute at the OEP address, from here, it's simple ReadProcessMemory and dump the target to disk, a simple fix correct EP and RA = VA in the header and there you go.

One thing i would like to do in the furture of this tool is to remove the exe32pack section from the dump (this will make it significantly smaller), but doing this will mean that i need to fixup IAT, or require external use of ImpREC, i still need to learn more about IAT and first thunks etc...

Hope this is useful to someone...

Hmm, dont seem to be able to add as attachement, only 45k

I'll find some webspace and upload it and post link back here soon

edit: as attachments are now working on the board, and my bandwidth is steadily being consumed, i've added file to this thread.

ps. Should've also mentioned i've only tested this on WinXP SP1, would imagine it would work on other NT based systems though

--
bedrock

dELTA

September 27th, 2003, 08:44

There is some strange problem with attachments since the board was upgraded, hopefully it will be resolved soon anyway.

squidge

September 27th, 2003, 08:46

Nice work. I normally cheat when removing packer sections from a dump however. Instead of removing the chunk completely, I just set the rawsize to 0 & realign the file. It makes the file a lot smaller, but still takes up the same amount of memory. Yes, I know this is not the best way, but I had already written an align function, and really didn't want to start modifying all sections that could come after the packer section (as I like my code to be generic so I can use it elsewhere)

Hellraiser

November 25th, 2003, 17:29

thanks for this tool, dude! I appreciate your work

rnd

December 26th, 2003, 05:35

I found it very interesting. I didn't know that the winapi would allow you to handle hardware breakpoints. What I didn't understand was how you place the BPM. changing the DRx registers, okay, but why are you able to read a CONTEXT structure from (ctx.esp+4) in your SetBreakpoint function? Is it undocumented, or do I miss something?

I tried to write my own BPM handler in C++, without the esp+4 readprocessmemory stuff, so only by modifying DR0 and DR7, but it didn't work at all

doug

December 26th, 2003, 13:29

Code:



typedef struct _EXCEPTION_POINTERS { // exp  

    PEXCEPTION_RECORD ExceptionRecord; 

    PCONTEXT ContextRecord; 

} EXCEPTION_POINTERS;

ContextRecord

Points to a CONTEXT structure that contains a processor-specific description of the state of the processor at the time of the exception.

--
(SetBreakPoint is called from a function that waits for a DebugEvent.)

rnd

December 27th, 2003, 13:20

this is what I make of it:

Code:



void CE32UnpackDlg::SetBreakPoint(PROCESS_INFORMATION* pi, DWORD dwBreakPointAddress)

{

	CONTEXT ctx;

	CONTEXT ntctx;

	DWORD ctxptr;



	ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;



             //place the debug registers from the debuggee in ctx

	GetThreadContext(pi->hThread, &ctx);								



	ctx.Dr0 = dwBreakPointAddress;

	ctx.Dr7 |= 0x00000001;



             //read the dword at ctx.esp + 4 into ctxptr

	ReadProcessMemory(pi->hProcess,

					  (void*)(ctx.Esp + 0x4),

					  &ctxptr,

					  4,

					  0);



             //read from ctxptr into ntctx

	ReadProcessMemory(pi->hProcess,

					  (void*)(ctxptr),

					  &ntctx,

					  sizeof(ntctx),

					  0);



//etc... }

the comments were added by me. so if i am right, he obtains the place where ESP in the debuggee points to, adds 4 to it, and read a dword from there. that dword is the address of a debugging registers context.

i think there are 3 possibilities:

1. i am wrong and don't understand a ... of it

2. it is something undocumented

3. or the SetBreakPoint should only be called when the debuggee is halted on a very special address where the conditions needed to work (*(esp+4)=context thing) are true...

i don't know if i should pick 1,2 or 3, but 1 or 2 seem to be the most likely to me

LouisSolomon

February 9th, 2004, 20:33

cute :-)

I should write a defeat for this one day :-)
but not worth my time.

Louis
www.SteelBytes.com

bedrock

February 11th, 2004, 15:46

Quote:

[Originally Posted by LouisSolomon]cute :-)

I should write a defeat for this one day :-)
but not worth my time.

Louis
www.SteelBytes.com

Thanks Louis,

Funny thing is all the effort i put into this for one particular program being protected by your exe32pack, and in recent builds of that particular program they seem to have not bothered protecting anymore

--
bedrock

LouisSolomon

February 11th, 2004, 22:00

:-)

the reason I ended up here was a did a google for ollydbg + PEiD after a user told me that it was apparently easy to unpack exe32pack using said tools.

the user also asked me if I could improve exe32pack so as to make it unpackable, I replied with:

> I would also like that, but it is unlikely to ever happen.
> it currently stops newbies, but it is not worth my time to make it much better.
> anything worth cracking will be cracked.
> if it runs, it can be cracked.

dELTA

February 11th, 2004, 22:03

Hehe, true, honest and to the point.

JMI

February 11th, 2004, 22:29

A rare thing to find in protection software authors these days.

Regards,