I unpacked an exe file (I posted about it a month ago), and it is a new packer...

So here cames the problem...

Here what I did:

1) Run the packed program and dump it using LordPE with no pe fix from lordPe
2) fixed the VSize and Rsize and bla bla in each section
3) Run ImportREC.exe to get the imports and fix the dump file

But now, when i run the unpacked file, it crashes...i dont know why :\
All that i got is the address that it crashes...

Here is the piece of code:
quartzo4:004286F2 call ds:GetCommandLineA ; as we can see, it is right after OEP
quartzo4:004286F8 mov ds:dword_460168, eax
quartzo4:004286FD call ___crtGetEnvironmentStringsA
quartzo4:00428702 mov ds:dword_45EA18, eax
quartzo4:00428707 call __setargv
quartzo4:0042870C call __setenvp
quartzo4:00428711 call __cinit ; This is the call that crashes!!

Folowing the call we see:

quartzo4:0043D0FA lea eax, [esi+1Ch]
quartzo4:0043D0FD push eax ; lpCriticalSection
quartzo4:0043D0FE mov [ebp+var_4], edi
quartzo4:0043D101 call ds:EnterCriticalSection ; crashes here!!!

Do you have any idea!?

Thank you very much!

quartzo4:0043D0FA lea eax, [esi+1Ch]
quartzo4:0043D0FD push eax ; lpCriticalSection
quartzo4:0043D0FE mov [ebp+var_4], edi
quartzo4:0043D101 call ds:EnterCriticalSection ; crashes here!!!


Break at 43d0fd, and post the value of eax.

regards,

tgodd

This is the value for eax, i got it using Ollydbg

Hexadecimal: 0045E74C
Signed: 4581196
Unsigned: 4581196
Char: \x00 E \xE7 L

Can be the resource data the problem? i cant read it using Exescope, nut i can read it with PEditor.

This program uses a DLL packed with the same packer, and i unpacked the dll and seems ok, no problem until now.

You should check to see which section eax is pointing too.

You are probably off on your resizing of your sections.

regards,

tgodd

EAX is pointing to: 0045E74C

Witch is inside the code section...

quartzo2:0045E74C db 4 ;
quartzo2:0045E74D db 0 ;
quartzo2:0045E74E db 0 ;
quartzo2:0045E74F db 0 ;
quartzo2:0045E750 db 3Ch ; <
quartzo2:0045E751 db 4Fh ; O
quartzo2:0045E752 db 6Bh ; k
quartzo2:0045E753 db 81h ; ü

Not to distrust your unpacking skills, but I've found time and time again that if a program I've unpacked is crashing when I just try to run it (or even sometimes after that, for that matter) 98% of the time it's because there's a bad import.

The import recovery tools are not perfect and sometimes you just have to go thru some of them manually to make sure. A few to check are

GetCommandLineA. This gets messed up a lot!
GetVersion.
GetProcAddress.

All of these calls should ALWAYS be very suspicious to you and I never trust them 100% unless I walk thru them myself. To do that, just set a breakpoint ANYWHERE in the program. The packed program. It can be after you run it, for example, set a breakpoint on CreateWindowExA and then show the about box. When it breaks, F12 back into the code.

Now you can go to the IAT table, since you now know where it is (since you managed to unpack it) and walk thru it manually. For example, if you used ImpREC it would have told you that there was a certain import call at <address>, so do a "DD <address>" to see where that call goes. Check that address you see now, in the IAT, in SI - "U <address you found now in IAT>". You can continue to walk thru code this way, without actually exectuting the code, in SI to see where all the calls eventually end up. Yes, you have to be able to read ASM, but being able to do the IAT this way is a very useful skill if you know you have a bad import but just don't know where to start looking.

Another hint: Imports in windows EXE's are usually always in alphabetical order. If you have one hanging out of place , be very suspicious of it and trace it manually to see if it's correct.

-nt20

Did you dump @OEP? This EnterCriticalSection thingie
usually pops up, when dump is done some instructions
later, after InitializeCriticalSection is done, and flag
is set. When you run a dumped proggy, this dumped flag
is checked, and program assumes, that Init is done, and
don't call it more. As result you will get an err, entering
not initialized crit. sect.
Neviens.

And how can i fixed it?

Either run the *packed* program under control of a debugger and pause at the OEP, or (for example, if your debugger is SoftIce) cause an infinite loop at OEP. This ensures no data is changed whilst the program is dumped.

Dumping a running program when it has proceeded past OEP is very dangerous as you can get all sorts of variables initialised that are not supposed to be in that state on startup, so the dumped program can randomly crash - as you have experienced.

newbie fault

It worked!!! thx for help you guys!!

I was dumping without doing a jmp eip in OEP address )

Thx a lot!