Dump and Analyze Memory with UEFI Shell Commands

This guide provides an overview and step-by-step instructions for inspecting, dumping, and analyzing physical system memory using standard UEFI Shell debugging commands. By leveraging built-in tools such as memmap and dmem, system developers and firmware analysts can locate critical data structures, save memory contents directly to persistent storage, and inspect raw firmware runtime states before an operating system initializes.

Prerequisites

To execute these debugging routines, you need:

Access to an interactive UEFI Shell (version 2.0 or later).
A writable FAT32 partition (typically mounted as a USB drive labeled FS0: or FS1:) to export memory dumps for offline analysis.

Mapping the Physical Memory Space

Before dumping memory, you must locate the relevant regions allocated by the firmware.

Run the memmap command to display the system's memory layout:

memmap

This command outputs a table of memory descriptors containing:

Type: Identifies the region purpose (e.g., EfiReservedMemoryType, EfiBootServicesData, EfiRuntimeServicesCode, EfiACPIReclaimMemory).
Start / End Addresses: The physical hex addresses where the blocks reside.
Number of Pages: The size of the allocation in 4 KB units.
Attributes: Cacheability and protection attributes (e.g., UC, WC, WT, WB).

Identify the starting address and range of the region you need to investigate (such as an ACPI table or a driver's runtime buffer).

Inspecting Memory Directly (`dmem`)

The dmem (Dump Memory) command displays memory contents directly in the shell using a standard hex and ASCII view.

Basic Syntax:

dmem [address] [size]

address: The physical hex address to begin the dump (e.g., 0x7E000000).
size: The number of bytes to display (in hexadecimal).

Example: To inspect 256 bytes (0x100) starting at 0x7BFFE000:

dmem 0x7BFFE000 0x100

To display memory non-stop without interactive pagination prompts, append the -b flag:

dmem -b 0x7BFFE000 0x100

Exporting Memory to File

The UEFI Shell supports standard output redirection, allowing you to write hex dumps directly to a connected storage device.

List available file systems to verify your target media:
```
map -u
```
Navigate to your writable media (e.g., FS0:):
```
fs0:
```

Redirect the output of dmem to a text file:

dmem -b 0x7BFFE000 0x2000 > memory_dump.txt

Note: Output redirection produces an ASCII hex representation of the data. To generate raw binary files rather than text representations, dedicated shell utilities or custom EFI applications calling the gBS->CopyMem() API are required, as native shell dmem formats its output with addresses and ASCII decodes.

Locating Known Firmware Signatures

When analyzing memory dumps, searching for distinct magic bytes helps isolate critical tables:

ACPI RSDP: Search for the string RSD PTR (ASCII).
SMBIOS Entry Point: Search for _SM_ (32-bit legacy) or _SM3_ (64-bit SMBIOS 3.x).
UEFI System Table: Identified indirectly via the EFI PART string on GPT disks or system table pointers initialized in the Boot Services pool.

To inspect SMBIOS tables specifically without manually hunting addresses, you can verify data parsed by the shell using:

smbiosview

Analyzing Dump Files Offline

After exporting the text dump to a FAT32 filesystem:

Convert to Raw Binary (if required): Use tools like Python or xxd -r on a host system to convert ASCII hex dump logs back into raw binary images:

# Example parsing formatted UEFI dmem output to raw binary
python3 -c "import sys, re; data = re.findall(r'^[0-9A-Fa-f]{8}:\s+((?:[0-9A-Fa-f]{2}\s*){1,16})', open('memory_dump.txt').read(), re.M); sys.stdout.buffer.write(bytes.fromhex(''.join(data)))" > memory_dump.bin

Hex and Structure Analysis: Open the binary in a hex editor (e.g., ImHex, 010 Editor) and apply UEFI structure templates to validate table headers, checksums, and pointer references.
Disassembly: Load the binary into tools like Ghidra or IDA Pro mapped to the original base address to reverse engineer runtime services code or loaded SMM/DXE drivers.