Skip to content

MemPE v0.3.0

Choose a tag to compare

@techlinn techlinn released this 31 Jul 18:44
· 19 commits to main since this release

Two fixes about the main image, and they pull in opposite directions in a way that
turns out to be the point.

The first is that mempe stops guessing. If the process path doesn't match anything in
the loader's module list, it used to just take the first module and dump that under
the target's name. It now tries the exact path, falls back to a unique basename, and
refuses with an error if neither is conclusive. Two modules with the same basename
count as inconclusive.

The second is that it stops giving up. An unmapped main image used to abort the whole
dump, which is the worst possible moment to throw everything away, because a hollowed
process is exactly when the surviving modules matter. Unmapping the main image of a
live process now produces all 33 remaining DLLs and exit code 3 instead of nothing and
exit code 2.

Import recovery accepts a lone resolved pointer when the IAT directory actually points
at the range it sits in. Requiring two adjacent entries makes sense for a range found
only by matching a section name, and is too strict for one the header vouches for.

Delay-load slots that were declared but never called are now counted and reported
rather than quietly skipped. A normal target shows 3319 unresolved against the 3959 its
modules declare on disk, which is roughly what you'd expect from a process that has
only just started. Two other silent drops also became visible: executable sections that
came out entirely zero, and unreadable pages inside raw regions.

Tests went from 56 to 66, and every new one was checked by deliberately breaking the
code it covers to confirm it actually fails.

Worth knowing: the basename fallback and the lone-pointer recovery are both correct and
neither fires on the test corpus. Import counts are unchanged at 1342, 816, 819 and 816.
The all-zero-section warning does fire, on a deliberately early dump of the VMProtect
sample.