Question

从RAM转储中提取屏幕截图

一些传统的安全/黑客攻击挑战包括必须分析系统物理RAM的转储。 volatility在提取有用信息方面做得很好，包括当时显示的窗口的线视图（使用命令screenshot）。但我想进一步找到窗口的实际内容。

因此，我想将问题重新表述为在大文件中查找原始图像（想象像素矩阵）。如果我能做到这一点，我希望至少能部分地找到窗口的内容。

我的想法是依赖一行像素类似于下一个像素的事实。如果我找到相同大小的足够大的行数，那么我让用户使用交互式工具摆弄它，看看它是否解码为有趣的东西。

为此，我会计算一种谱图。更准确的是heatmap，其中阴影显示数据块＃ x 成为宽度 y 字节的图像的一部分的可能性，其中< em> x 和 y 频谱图的轴。然后我只需要在其中寻找水平线。（参见下面的例子。）

我现在遇到的问题是找到一种准确快速地计算“光谱图”的方法。作为一个数量级，我希望能够在几分钟内在4GB文件中找到RGBA（每行8192个字节）的宽度为2048的图像。这意味着每秒处理几十MB。

我尝试过使用FFT和自相关，但它们并没有表现出我所追求的那种准确性。

FFT

的问题

由于找到大多数重复模式的长度看起来像寻找频率，我尝试使用1字节= 1样本的傅立叶变换并绘制光谱的绝对值。

但主要问题是周期分辨率。由于我有兴趣找到信号的周期（一行像素的字节长度），我想在 y 轴上绘制具有周期长度的频谱图，而不是频率。但离散傅里叶变换的工作方式是它计算 1 / n 的频率倍数（对于 n 数据点）。这使我在很长一段时间内分辨率非常低，而在短时间内分辨率高于所需分辨率。

这是使用此方法在144x90 RGB BMP文件上计算的光谱图。我们期望在偏移量432处出现峰值.FFT的窗口大小为4320字节。

第一个数据块的分段图。

我计算过，如果我需要区分句间 k 和 k + 1 ，那么我需要一个大致k²的窗口大小。因此，对于8192个字节，这使得FFT窗口大约为16MB。这会太慢了。

因此，FFT会计算出我不需要的太多信息，而且我不需要足够的信息。但是如果窗口大小合理，它通常会在恰当的时期出现一个尖峰。

我尝试的另一种方法是使用一种离散自相关来绘制频谱图。

更确切地说，我计算的是一块数据与一半数据之间的互相关。并且仅针对小块完全位于大块内的偏移计算它。大块的大小必须比绘制的最大周期大两倍。

以下是使用此方法在与之前相同的图像上计算的光谱图的示例。

第一个数据块自相关的分段图。

尽管它产生了适量的数据，但自相关的值变化缓慢，因此在正确的时期内没有达到尖峰。

有没有办法在大周期内获得尖峰和正确周期以及足够的精度？通过调整前面提到的算法或使用完全不同的算法。

Answer 1

我无法判断FFT部分。从标题（“在RAM转储中查找图像”）看来，你似乎正试图解决一个更大的问题而FFT只是其中的一部分，所以让我回答一下我有一些知识的部分。

分析系统的RAM转储

这听起来很像物理RAM。如果应用程序截取屏幕截图，则该屏幕截图位于虚拟RAM中。这导致两个问题：

a）截图可能不完整，因为它的部分内容被分页到磁盘

b）您需要为虚拟地址映射执行物理地址，以便将屏幕截图的字节按正确顺序排列

从内存转储中找到原始图像

对我而言，原始图像的定义尚不清楚。存储图像的任何应用程序都将使用图像文件格式。仅存储数据会使截图无效。

为了对数据执行FFT，您应该知道它是使用每像素24位还是每像素32位。

我希望找到截图或当前窗口的内容

这需要一个截屏的应用程序。你当然可以希望。我不能判断它的可能性。

依赖于一行像素类似于下一个像素的事实

你可能希望在白色文字上找到一些黑色。为此，假设可能没问题。如果用户正在查看他的假日照片，则可能会有所不同。

另请注意，PC中的许多值都是32位（整数，浮点数），而0x00000000是一个非常常见的值。您的算法可能会检测到这一点。

宽度为2048的图像

这只是猜测吗？或者你最终会强制所有常见的屏幕尺寸？

RGBA中的

为何选择RGBA？屏幕截图通常没有透明度。

综上所述，我想知道在转储中搜索JPEG，BMP或PNG标头等图像签名是否效率更高，然后分析这些标题并简单地从元数据中获取图片。

请注意，此操作之前已完成，例如WinDbg在 ext 调试器扩展中有一些命令，默认加载

!findgifs
!findjpegs
!findjpgs
!findpngs