Поиск изображений в дампе оперативной памяти

Извлечение скриншотов из дампов оперативной памяти

Некоторые классические проблемы безопасности/взлома включают необходимость анализа дампа физической оперативной памяти системы. volatility отлично справляется с извлечением полезной информации, в том числе с проводным просмотром окон, отображаемых в данный момент (используя команду скриншот). Но я хотел бы пойти дальше и найти фактическое содержимое окон.

Поэтому я хотел бы переформулировать проблему как поиск необработанных изображений (думаю, матрица пикселей) в большом файле. Если я смогу это сделать, я надеюсь найти содержимое окон, хотя бы частично.

Моя идея заключалась в том, чтобы полагаться на тот факт, что ряд пикселей похож на следующий. Если я нахожу достаточно большое количество строк одинакового размера, я позволяю пользователю возиться с интерактивным инструментом и смотреть, декодирует ли он что-нибудь интересное.

Для этого я вычислил своего рода спектрограмму. Более точная тепловая карта, где тень показывает, насколько вероятно это для блока данных #x быть частью изображения шириной y байт, с x и y осями спектрограммы. Тогда мне просто нужно было бы искать в нем горизонтальные линии. (См. примеры ниже.)

Проблема, с которой я столкнулся сейчас, состоит в том, чтобы найти метод для точного и быстрого вычисления такого рода спектрограммы. По порядку, я хотел бы иметь возможность находить изображения шириной 2048 в RGBA (8192 байта на строку) в файле размером 4 ГБ за несколько минут. Это означает обработку нескольких десятков МБ в секунду.

Я пытался использовать БПФ и автокорреляцию, но они не показывают той точности, которая мне нужна.

Проблема с БПФ

Поскольку нахождение длины в основном повторяющегося паттерна похоже на нахождение частоты, я попытался использовать преобразование Фурье с 1 байтом = 1 выборке и построить абсолютное значение спектра.

Но главная проблема — разрешение периода. Поскольку мне нужно найти период сигнала (длина строки пикселей в байтах), я хочу построить спектрограмму с длиной периода по оси y, а не по частоте. Но способ работы дискретного преобразования Фурье заключается в том, что оно вычисляет частоты, кратные 1/n (для n точек данных). Это дает мне очень низкое разрешение для больших периодов и более высокое, чем необходимо, разрешение для коротких периодов.

Вот спектрограмма, рассчитанная с помощью этого метода для файла RGB BMP размером 144x90. Мы ожидаем пик по смещению 432. Размер окна для БПФ составил 4320 байт.

Спектрограмма с БПФ

И сегментный график первого блока данных.

Сегментный график первого блока БПФ

Я подсчитал, что если мне нужно различать периоды k и k+1, то мне нужен размер окна примерно . Таким образом, для 8192 байт размер окна БПФ составляет около 16 МБ. Что было бы слишком медленно.

Таким образом, БПФ вычисляет слишком много информации, которая мне не нужна, и недостаточно информации, которая мне понадобится. Но при разумном размере окна он обычно показывает резкий пик примерно в нужный период.

Проблема с автокорреляцией

Другой метод, который я пробовал, — это использование дискретной автокорреляции для построения спектрограммы.

Точнее, я вычисляю взаимную корреляцию между блоком данных и его половиной. И вычисляйте его только для смещений, где маленький блок полностью находится внутри большого блока. Размер большого блока должен быть в два раза больше, чем максимальный период для построения.

Вот пример спектрограммы, рассчитанной этим методом на том же изображении, что и раньше.

Спектрограмма с использованием корреляции

И сегментный график автокорреляции первого блока данных.

Сегментный график автокорреляции первого блока

Несмотря на то, что он выдает нужное количество данных, значение автокорреляции изменяется медленно, поэтому не возникает резкого пика для нужного периода.

Вопрос

Есть ли способ получить как острый пик, так и правильный период и достаточную точность для больших периодов? Либо подправив упомянутые алгоритмы, либо используя совершенно другой.


person Celelibi    schedule 16.06.2016    source источник
comment
Вы никогда не сможете получить снимок экрана текущего окна из ОЗУ, за исключением случаев, когда вы сбрасываете ОЗУ видеокарты и читаете в правильном месте. Так что, по моему мнению, забудьте об этом.   -  person reuns    schedule 05.10.2016


Ответы (1)


Я не могу много судить о части FFT. Из заголовка («Поиск изображений в дампе ОЗУ») кажется, что вы пытаетесь решить большую проблему, и БПФ — это только часть ее, поэтому позвольте мне ответить на те части, в которых у меня есть некоторые знания.

анализировать дамп оперативной памяти системы

Это очень похоже на физическую оперативную память. Если приложение делает снимок экрана, этот снимок экрана находится в виртуальной оперативной памяти. Это приводит к двум проблемам:

а) снимок экрана может быть неполным, так как его части выгружаются на диск

б) вам необходимо выполнить сопоставление физического адреса с виртуальным адресом, чтобы привести байты снимка экрана в правильный порядок

найти необработанные изображения из дампа памяти

Для меня определение того, что такое необработанное изображение, неясно. Любое приложение, хранящее изображение, будет использовать формат файла изображения. Хранение только данных делает скриншот бесполезным.

Чтобы выполнить БПФ для данных, вы, вероятно, должны знать, использует ли он 24 бита на пиксель или 32 бита на пиксель.

Надеюсь найти скриншот или содержимое текущих окон

Для этого потребуется приложение, которое делает скриншоты. Можно конечно надеяться. Я не могу судить о вероятности этого.

полагаться на тот факт, что ряд пикселей похож на следующий

Вероятно, вы надеетесь найти черный текст на белом фоне. Для этого предположение может быть в порядке. Если пользователь просматривает свои праздничные фотографии, это может быть иначе.

Также обратите внимание, что многие значения на ПК являются 32-битными (целое число, число с плавающей запятой), а 0x00000000 является очень распространенным значением. Ваш алгоритм может обнаружить это.

изображения шириной 2048

Это просто предположение? Или вы, наконец, переборщите все распространенные размеры экрана?

в RGBA

Почему РГБА? Скриншот обычно не имеет прозрачности.


Учитывая все вышесказанное, мне интересно, не будет ли эффективнее искать сигнатуры изображений, такие как заголовки JPEG, BMP или PNG, в дампе, а затем анализировать эти заголовки и просто получать картинку из метаданных.

Обратите внимание, что это было сделано раньше, например. WinDbg имеет некоторые команды в расширении отладчика ext, которое загружается по умолчанию.

!findgifs
!findjpegs
!findjpgs
!findpngs
person Thomas Weller    schedule 07.09.2016
comment
скриншот текущего окна находится в памяти видео карты, где пиксель равен rgba(8) - person reuns; 05.10.2016
comment
@user1952009 user1952009: графические карты имеют собственную оперативную память. ИМХО оперативная память графической карты не обязательно находится в оперативной памяти ПК, даже с DMA. - person Thomas Weller; 05.10.2016
comment
Это именно то, что я сказал (и вы можете сбросить выделенную графическую память процесса, в котором вы находитесь, поэтому вы можете сбросить всю (выделенную) графическую память, когда вы находитесь в ядре) - person reuns; 05.10.2016
comment
@user1952009: Я вхожу в число двух лучших ответивших на тег windbg (stackoverflow.com/tags/windbg/topusers, посмотрите для Томаса Веллера), но я не знаю, как это сделать. У вас есть ссылка на учебник или описание того, как это делается? - person Thomas Weller; 05.10.2016
comment
Для OpenGL я думал, что будет функция, но я ее не нашел. Вероятно, он спрятан где-то на opengl.org/wiki/Creating_an_OpenGL_Context_(WGL). Для других низкоуровневых графических библиотек все должно быть точно так же. Для win32 GDI это должно быть что-то вроде msdn.microsoft.com/en-us/library/windows/desktop/ - person reuns; 05.10.2016
comment
GetDC() — это метод, который вы можете вызывать во время работы ОС. Вы не можете вызвать его в файле дампа. - person Thomas Weller; 05.10.2016
comment
Да, я знаю. Для сброса действительно графической карты я не знаю, и мне все равно. Может быть, выполнение segfault в драйвере спровоцирует дамп? :) - person reuns; 05.10.2016
comment
Теперь я в полном замешательстве. У тебя есть дамп или нет? Если вам не нужно сбрасывать содержимое видеокарты, что еще вы сбрасываете? Вы также знаете, что дамп ядра может не содержать информации. Вы все еще где-то ищете растровые изображения, но где? - person Thomas Weller; 05.10.2016
comment
@ user1952009: о, извини, я только что понял, что ты не ОП. - person Thomas Weller; 05.10.2016
comment
Segfault не поможет в Windows. Это будет обрабатываться ОС, и ОС будет генерировать синий экран, выгружая память ядра, а не память видеокарты. - person Thomas Weller; 05.10.2016
comment
@Thomas Я отредактировал вступление к вопросу, чтобы уточнить, что я имею в виду под необработанными изображениями, я также упомянул волатильность. Дело не в поиске файлов, а в пиксельных матрицах. Меня интересует то, что есть в дампе, если некоторых окон нет в ОЗУ, то их нет, и я иду дальше. Нет, на самом деле мне не нужно знать, являются ли изображения 24 или 32 битами на пиксель. Если я выполняю БПФ для байтов, он просто покажет дополнительный пик на период 3 или 4 байта. Так же, как мне не нужно знать ширину экрана, мне нужна только верхняя граница, БПФ найдет ширину изображения. - person Celelibi; 05.10.2016