RunPE无法加载特定PE文件的原因及两类PE差异咨询

1. What’s the Difference Between These Two Types of 32-bit PE Files? #

The core difference lies in the DOS Stub—the small, DOS-compatible section at the very start of every PE file, originally designed to give feedback if the program is run on an old DOS system. Here’s the breakdown:

• Standard 32-bit PE Files:
  • Start with the standard MZ DOS signature (hex 0x4D5A), and their DOS Stub displays the message "This program cannot be run in DOS mode."
  • This stub is a minimal, compiler-generated placeholder; Windows PE loaders skip it entirely and jump straight to the PE header to load the actual program.
• Win32-Locked PE Files (Like Darkcomet):
  • While they’re still valid 32-bit PEs, their DOS Stub has been modified:
    • The MZP start you noticed is likely a side effect of tweaked DOS header fields (e.g., the e_cblp field set to 0x50, ASCII 'P') making the first three bytes read as MZP in a text editor—but the core MZ signature required for PE validity is still intact.
    • The stub displays "This program must be run under Win32" and includes extra logic beyond just a message. This often checks if the program is loaded by a legitimate Windows loader (not a custom in-memory loader like your RunPE) or if the executable exists on physical disk (not just in memory).

2. Why Can’t Your RunPE Load These Win32-Locked Programs? #

Your RunPE implementation is likely following the standard in-memory loading workflow (create suspended process, write PE sections, set EIP to the PE’s entry point, resume process)—but these modified PEs are explicitly designed to block exactly this kind of loading. Here’s why it fails:

• Entry Point Redirection to DOS Stub:
  Many obfuscated PEs (like Darkcomet) don’t set their AddressOfEntryPoint to the actual Win32 entry point. Instead, they point it to code inside the DOS Stub. This stub runs anti-loading checks first (e.g., verifying the loader is legitimate, checking for a valid disk path) before jumping to the real Win32 entry. Your RunPE skips the DOS Stub entirely, so it’s either executing invalid code or triggering these checks immediately.
• PE Header Obfuscation:
  These malware samples often tweak PE header fields (like SizeOfImage, SectionAlignment, or PointerToRawData) to break naive loaders. If your RunPE doesn’t validate or correct these fields before mapping the PE into memory, the memory layout will be incorrect, causing the program to crash or exit silently.
• In-Memory Loading Detection:
  The DOS Stub or early Win32 code may check for signs of in-memory loading:
  • Verifying if the process’s PEB->ImageBaseAddress maps to a valid disk file path (RunPE-loaded images won’t have this).
  • Checking memory page attributes (RunPE typically writes sections as RW then changes to RX, while natively loaded PEs use memory-mapped files with different attributes).
  • Detecting suspended process creation (a common RunPE step) via debug flags or process state checks.

Fixes to Try #

If you want to get these programs loading in your RunPE, here are some steps to adjust your implementation:

• Don’t Skip the DOS Stub:
  If the AddressOfEntryPoint points to the DOS Stub (a small offset, e.g., 0x100), let the stub execute instead of jumping directly to the Win32 entry. Simulate the Windows loader’s behavior of running the stub until it jumps to the PE header’s e_lfanew offset.
• Validate and Repair PE Headers:
  Add logic to check if header fields like SizeOfImage match the actual total size of all sections. If not, correct them before mapping the PE into memory.
• Spoof Legitimate Loader Context:
  Modify the suspended process’s PEB (Process Environment Block) to fill in a fake valid disk path for the loaded image. You can also adjust memory page attributes to match those of natively loaded executables.
• Use a Process Hollowing Alternative:
  Instead of creating a suspended process and overwriting it, try modifying your own process’s memory space to load the PE—this avoids some common anti-loading checks that target external process creation.

内容的提问来源于stack exchange，提问作者4sens