Memory dump, disk image and registry hive analysis

A .raw, .mem, .vmem or .dmp file is usually a raw physical memory image, and the question asked of it is almost always one of three: what was running, what was typed, and what was on disk. All three are answerable without Volatility, without a symbol download, and without the file leaving the tab.

pslist versus psscan, and why this is a scanner

Volatility's pslist walks the ActiveProcessLinks list from a KDBG pointer. That needs the exact _EPROCESS field offsets for the Windows build the dump came from, which is why Volatility ships a symbol database - and why a browser tool cannot reasonably reproduce it.

psscan does something different: it scans the whole image for Proc pool allocations and validates what it finds. It needs no symbols, and - more usefully - it finds terminated processes that are no longer on the list, which in a CTF is very often the one that matters. That is the approach here.

The pid, parent pid and creation time are recovered by shape rather than by offset. In every _EPROCESS from XP to 11 the creation time comes before the pid pair and the pid pair comes before the image name, all within a few hundred bytes - so looking for a plausible FILETIME followed by a small multiple of four is build-independent in a way that a table of offsets is not.

A parent pid is only reported when it can be corroborated - when the value matches a pid seen elsewhere in the same dump. InheritedFromUniqueProcessId sits a long way from UniqueProcessId and the distance differs by build, so taking the next pid-shaped value picks up whatever intervening field happens to be a small multiple of four. A process whose parent has been overwritten simply shows no parent, which is the honest answer.

What else comes out of the same scan

• Command lines. Windows keeps them as UTF-16, which a byte-oriented strings pass sees as nothing at all. This is usually where a challenge hides what was run - an -enc PowerShell blob, a certutil download, a path to the flag file.
• File objects, from Fil pool allocations, with the path taken from the same allocation. In a raw dump the FileName pointer cannot be followed without page tables, so the nearby path-shaped string is what you get - and it is nearly always the right one.
• Registry hives. A regf header carries the hive's own path, so SAM, SYSTEM, SOFTWARE and each user's NTUSER.DAT are identified by name. Carve one out at the offset given and open it on the Registry tab: run keys, mounted devices, typed URLs and UserAssist all live there.

Disk images and hives

The same tab reads ext2/3/4 (including files that need the singly- and doubly-indirect block pointers), FAT12/16/32, the NTFS $MFT (resident data included, which is where a small flag file lives entirely inside its own record), and registry hives on their own.

The volatility3 option, and why it is not the default

There is a disclosure at the bottom of the memory view that loads Pyodide from a CDN and pip-installs volatility3. It is the only thing in this project that fetches anything from a third party, it is best-effort, and it is deliberately not the default: volatility3's C-extension dependencies may not resolve as wheels, and the path works under this site's cross-origin isolation policy only because the CDN happens to send a permissive header. The native scan is the supported one and needs no network at all.