I am using ollydbg as a debugger and the ollydump to dump the exe.
what i am trying to do is unpack a molebox 2.5.7 packed exe. i found the OEP. so i set a bp on the OEP, dump the exe using ollydump. then trying to run the dump, it crashes.
the reason it crashes is because it is trying to call a kernel32 function. the problem is, the dump does not contain the kernel32 module. it's missing all modules that used to be in the original executable, as far as i can tell. the dump is significantly smaller than the original executable.

so i open the dump in ollydbg, pause at EP, then open the dump process with ImpRec. i set the OEP and then i try to find the imports using Auto Search and Get Imports. it finds none.
so i think the problem is that the executable lacks those modules. how do i dump the executable along with the modules it contains? how do i fix this?
i just need someone to point me in the right direction, since i'm still new at reversing.
the rest i think i can do myself.

thank you in advance

Up until my my semi-retirement from reversing due to employment commitments, and now full time scrambling for contract work to get me by until a full time gig pops up, I never once ran into anything truly packed with MoleBox, actually one of the older versions of a popular packer detector would always report MoleBox on unpacked files during a deep scan - so my guess is your target is either not packed, or packed with something else, always have at least 2 packer detectors on hand to verify questionable results. in the mean time open your target (unpacked) and do a binary search for ff25 from the begining, if you run into an import then it's not packed - MoleBox is very old and not likely used today.

SiGiNT

it is packed with molebox, that i know for certain. two reasons:
1) packer detector reported molebox
2) i tried to modify the executable, but when i ran it, a messagebox with the title MoleBox poped up saying executable is corrupted, which led me to believe molebox does a CRC check on the exe.
in any case i manually unpacked molebox, so i'm not having any problems with unpacking.
my problem is with dumping the unpacked executable and fixing the IAT.
like i said, the dump is smaller than the executable, which is not normal right?

just seen post about script for molebox unpacking.
http://www.woodmann.com/forum/showthread.php?t=12672

thanx but the program fails to dump the executable.
besides i am not interested in automating the process. i'm not a script kiddie you know. i want to do it myself.
in any case that program found the same OEP as i did manually. like i said, the OEP is found.
both I and that program have problems dumping the executable.
the original executable has 4163 kb and my dump only has 440 kb.
when i dump it using ollydump, the Size textbox has the value 6E000 which is 440kb.
i am really stuck on this and i am starting to hate the executable

but..
Does that program run normally!? (without debugger)

the dumped one no, of course not.
the normal, unpacked executable runs fine.(the 4163 kb one)
but when i dump it (while on the OEP), the dump is smaller (440 kb).
I have no idea how to go about this.

don't understood!

so normal = unpacked ??
or normal is NOT packed??

i meant to say the normal, PACKED executable runs fine.
just that when i dump it when on OEP, the dump is too small.
sorry

okey!
that mostly means, packer detects Debugger.

see IsDebuggerPresent call or that byte..

yeah but the packed executable runs fine even in debugger. doesn't that mean it doesn't care if it's debugged or not?

yes i can confirm now, there is no call to IsDebuggerPresent.

then you have to more precise step in unpacker code & see WHY.
look also at that IdDebug byte.
if cool program, PM me it

i tried dumping while on the EP of the PACKED executable. dump size still the same.
the problem has nothing to do with whether the executable is packed or not.

the problem is clear to me now. when ollydump dumps the executable, it only dumps the main module. but it doesn't dump all the other loaded modules.
What can i do?

no, it must not dump other modules.

but it needs those modules so it can run. they are already loaded when i load the program in ollydbg. when i look in ollydbg View->executable modules they are there, kernel32.dll and 6 more modules found in system32.

but the dump file only contains two of those 7 modules when it starts.

what do I need to do?

Those modules are SYSTEM modules, at least kernel32.dll is. They are part of the windows OS and all programs call them. They are not part of the program and they are already in your computer.

you wrote, olly 1.10.
but there is newer olly 2. ok?

ok, u need dump @ 45bff4.

then set IAT is @ 0438d4

then, this file-dump is little, bcoz data is attached at end of EXE. you must attach again that data to dumped file.

so that is the OEP?
are you sure that address is correct? because the program execution never reaches that address.
this is the executable
http://www.mediafire.com/download.php?nyvkvwjemyj

because i believe the OEP is at address 00422901

so i debug the dump, and it reaches a call at address 0042da09 and i can't step over it.
the error i get is:
"don't know how to step because memory at address whatever is not readable. try to change the eip or pass exception to program."
when i step into that function, no code appears, CPU is blank.
at that address used to be kernel32.GetSystemTimeAsFileTime in the original executable. but in the dump, it's not there anymore.

ok i think i am on the right track. how do i attach back that data to the dumped file?

OEP = 00422901

i said dump there. dump should be realigned.
you can try LordPE "Full dump"

copy all from offset 038A00 and append to dump

i don't really understand what you mean. could you explain the process in more detail please? And where did you get the address 038a00 from? also what do you mean by append to dump, and how do i do that?

nowwwwwwwwwwwwwww

you are taping veeeeeeery laaaaaaaaameeeeeee qqqqqqqqqqqqqqqqqqqqqueeeeeeeeestionsssssssssssss

that was so helpful...

You need to read a lot more about the inner workings of Windows especially about the critical components in general as well as API's - when you dump a file -only that file or in this case a portion of that file is dumped the rest of your file is not packed showing entopy around 70%, there are excellent tutorials on all that you need to know, before you start trying to dump Kernel32 - the heart of your OS - if you would have dumped it you wouldn't be posting here you'd frantically trying to get your computer to boot - Kernal32 missing or damaged message.

Good reading!

SiGiNT