glmcdona / process-dump Goto Github PK

WARNING: module '10ffb3c50370dc3eec3490b667e5aee152d774dbf4f46604c7b5b4e3c666041
0.exe' at 0x400000. Large section size for section 2 of 0x17e9 being truncated t
o 0x7ec33f5a to fit within the image size. This could be as a result of a custom
code to load a library by means other than LoadLibrary().
How to by pass this error to dump unpacked version?

hi any chance we can do drag and drop a .exe file into program to dump and then it all once done instead of running the .exe file first and also adding on 64bit to be able to dump 32bit apps instead of having 32bit version

Eg, the following does not work:
pd.exe -db add "c:\program files"

But the following works:
pd.exe -db add "c:\program files"

For some reason with the new Process Dump version no modules are being dumped. They are being found, but not dumped.

Attached the logfile 'pd.exe -system -verbose':
pd_log.txt

When you generate the full clean hash database:
pd.exe -db gen

It crashes soon after starting to add the files in %USERPROFILE% to the clean hash database.

In pe_header::process_disk_image method, I see _header_pe64->OptionalHeader.ImageBase = (DWORD) _original_base;, which I believe is wrong since the ImageBase for 64bit header is indeed a 64bit value so it should be _header_pe64->OptionalHeader.ImageBase = reinterpret_cast<__int64>(_original_base);.

I had this weird problem for a long time that the ImageBase is somehow truncated but I didn't realize it might be a bug. Now I think I found out what the problem was and it seems to be fixed by the change mentioned above.

Here is the code: https://github.com/glmcdona/Process-Dump/blob/master/pd/dump_process.cpp#L793
The code is import_summary.COUNT_UNIQUE_IMPORT_ADDRESSES >= 2 but idk is this should be >= 5 to match the comment
But my real question is why it needs this condition to dump codechunk, can i just ignore this condition?

Thank you

Process Dump hooks NtTerminateProcess and injects a executable region used to handle the hook. When Process Dump then dumps this process on terminate, it will find it's own executable region added for the hook and dump it as a codechunk. Ideally, we wan't to ignore Process Dump's own injections.

Don't know if I should post a question here but I get zeros in some regions of the dump file when there is clearly executable code in those regions according to CE. I know little about segments and how they are arranged and loaded into memory and I've been struggling figuring out what the problem was.

Sometimes a process starts and closes before process dump and dump it. Add a hook or something to CreateProcess to add a delay before resuming on start.

If another app tries to close it abnormally, it can create a state where process dump gets stuck at the closing state.

Latest version of Process Dump close monitor (pd64.exe -closemon) is crashing csrss.exe on both x86 and x64.

An option to dump closed modules that were loaded AFTER -closemon was initiated would be great for detecting and dumping modules... it seems this program only hooks and dumps modules that were loaded at the time closemon was initiated.

what do you think, should this be most effective for detecting malware if it only dumped unhashed modules?

Great little program! This thing is very useful.

Dumping the main Spotify.exe is creating a ~2GB file. Investigate why this is and add more smart safety limits.

Kindly why i can not dump .net packed process, it generates only hidden modules?

below is the bugfix patch:

  
diff --git "a/Z:\\Temp\\TortoiseGit\\pe_header-413a51b.001.cpp" "b/M:\\Open_Code\\Process-Dump\\pd\\pe_header.cpp"
index c55a956..29d613d 100644
--- "a/Z:\\Temp\\TortoiseGit\\pe_header-413a51b.001.cpp"
+++ "b/M:\\Open_Code\\Process-Dump\\pd\\pe_header.cpp"
@@ -720,10 +720,14 @@ bool pe_header::process_pe_header( )
 						{
 							// We are unsure if we need to process this as a 32bit or 64bit PE header, lets figure it out.
 							// The first part is independent of the 32 or 64 bit definition.
-							if( ((IMAGE_NT_HEADERS64*) base_pe)->FileHeader.Machine == IMAGE_FILE_MACHINE_I386 )
+							
+							// previous conditional judgment is wrong, now need to be commented out
+							// previous can not dump some  .net exe module,like Reflector.exe
+							//if( ((IMAGE_NT_HEADERS64*) base_pe)->FileHeader.Machine == IMAGE_FILE_MACHINE_I386 )
 							{
 								// 32bit module
 								this->_header_pe32 = ((IMAGE_NT_HEADERS32*) base_pe);
+								this->_header_pe64 = NULL;
 
 								if( _header_pe32->Signature == 0x4550 && _header_pe32->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC )
 								{
@@ -733,11 +737,12 @@ bool pe_header::process_pe_header( )
 									return true;
 								}
 							}
-							else if( ((IMAGE_NT_HEADERS64*) base_pe)->FileHeader.Machine == IMAGE_FILE_MACHINE_IA64 ||
-								((IMAGE_NT_HEADERS64*) base_pe)->FileHeader.Machine == IMAGE_FILE_MACHINE_AMD64)
+							//else if( ((IMAGE_NT_HEADERS64*) base_pe)->FileHeader.Machine == IMAGE_FILE_MACHINE_IA64 ||
+							//	((IMAGE_NT_HEADERS64*) base_pe)->FileHeader.Machine == IMAGE_FILE_MACHINE_AMD64)
 							{
 								// 64bit module
 								this->_header_pe64 = ((IMAGE_NT_HEADERS64*) base_pe);
+								this->_header_pe32 = NULL;
 
 								if( _header_pe64->Signature == 0x4550 && _header_pe64->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR64_MAGIC )
 								{
@@ -747,7 +752,7 @@ bool pe_header::process_pe_header( )
 									return true;
 								}
 							}
-							else
+							//else
 							{
 								// error
 							}

  

Repeated error being printed in PD when in terminate monitor mode:
"Failed to allocate space for NtTerminateProcess hook. failed with error 5: Access is denied."

Looks like it is for one or two processes on the system that might not have permission.

As I couldn't get the -eprec flag to work in the latest distributed release, I thought I would compile the program myself to see what's wrong, but now I'm getting a compiler error.

Process-Dump/pd/pe_header.h

Line 126 in 4984e46

bool process_disk_image(export_list* exports, pe_hash_database* hash_database);

For some reason, it does not like the identifier 'pe_hash_database' here.

Any help would be appreciated. Thanks!

Hello,

I'm trying to dump the packed executable, and among other things, I encounter OEP set to 0x00000000 and IAT messed up. I currently do the following,

1. Close all apps
2. pd -db genquick
3. Run my target
4. pd -pid <pid>

The dumper dumps the best possible, sure; but is there a way to restore the OEP (so I can run the executable) and IAT (run anywhere else aside from the VM)? Thanks heaps <3

One suggestion I came up with inspired by https://reverseengineering.stackexchange.com/a/11272
Since the dump stores the IAT that was present at a runtime, I can either find the imports string representation in the dump (if present, which is always True in my case) or listen to the program's API calls. Either way, I do not get how can I translate the API call names to their static addresses. Any help will be appreciated