WEBDIENSTE/volatility3
1
0
Fork 0
mirror of https://github.com/volatilityfoundation/volatility3.git synced 2026-10-20 15:01:34 +02:00
Code Issues Packages Projects Releases Wiki Activity

automagic/windows: merge DTB fast-path ranges into one contiguous span

Browse Source 
Windows places the DTB at the lowest free physical page at boot, making the
address a high water mark of early loader allocations.  winload.efi has grown
from 1.52 MiB at build 14393 to 3.62 MiB at build 28000, so the DTB slides to
higher addresses with each release.

The three fast-path ranges in test_sets left two gaps:
  0x2a0000 -- 0x550000  (2.7 MiB)
  0x6f0000 -- 0x900000  (2.1 MiB)

A Windows 11 25H2 image (build 26200.8037, 8 GiB Hyper-V Gen2) has its System
DTB at 0x7b5000, inside the 2.1 MiB gap, causing every plugin to fail.

Merge the three ranges into a single contiguous span:

  (0x150000, 0x150000),  |
  (0x550000, 0x1A0000),  |->  (0x150000, 0x8B0000)
  (0x900000, 0x100000),  |

The merged range ends at 0xa00000, which is the start of the 'very large memory'
range added by PR #1971, so 0x150000--0x5a00000 is now one unbroken 84.7 MiB
span with no gaps.

Widening the fast path is safe because PR #1992 added translation-based DTB
validation: extra candidates cost scan time and nothing else.
This commit is contained in:
Brian McKinney
2026-09-14 12:33:26 -05:00
parent 08875b690a
commit 43bca6019e
1 changed files with 8 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
volatility3/framework/automagic/windows.py
+8 -10
View File
@@ -10,9 +10,9 @@ have a single offset that will allow manipulation of the page tables themselves.
In older windows version the self-referential pointer was at a specific fixed index within the table,
which was different for each architecture. In very recent Windows versions, the self-referential pointer
index has been randomized, so a different heuristic must be used. In these versions of windows it was found
that the physical offset for the DTB was always within the range of 0x1a0000 to 0x1b0000. As such, a search
for any self-referential pointer within these pages gives a high probability of being an accurate DTB.
index has been randomized, so a different heuristic must be used. In these versions of windows the physical
offset for the DTB falls within a set of observed ranges near the start of physical memory. A search for any
self-referential pointer within these ranges gives a high probability of being an accurate DTB.
The self-referential indices for older versions of windows are listed below:
@@ -254,9 +254,7 @@ class WindowsIntelStacker(interfaces.automagic.StackerLayerInterface):
"Detecting Self-referential pointer for recent windows",
[DtbSelfRef64bit()],
[
(0x150000, 0x150000),
(0x550000, 0x1A0000),
(0x900000, 0x100000),
(0x150000, 0x8B0000),
],
),
(
@@ -284,11 +282,11 @@ class WindowsIntelStacker(interfaces.automagic.StackerLayerInterface):
where possible.
Where the DTB scan fails, it attempts a heuristic of checking
for the DTB within a specific range. New versions of windows,
for the DTB within a set of physical address ranges. New versions of windows,
with randomized self-referential pointers, appear to always load
their dtb within a small specific range (`0x1a0000` and
`0x1b0000`), so instead we scan for all self-referential
pointers in that range, and ignore any that contain multiple
their dtb within observed ranges near the start of physical memory,
so instead we scan for all self-referential
pointers in those ranges, and ignore any that contain multiple
self-references (since the DTB is very unlikely to point to
itself more than once).
"""