Восстановление данных страниц в памяти после неудачного спящего режима

9

Macbook моей девушки упал при попытке восстановить файл из спящего режима. Индикатор выполнения остановился на уровне ~ 10%, после чего мы перезагрузили компьютер для нормального запуска.

На этом спящем образе памяти был открыт несохраненный документ в Pages, который мы хотели бы восстановить. Существует sleepimageв /private/var/vm, который я предполагаю , это спящий режим изображения , который никогда не был корректно восстановлен. Мы поддержали эту вещь, чтобы сохранить ее.

Мы пытались, strings sleepimage | grep known_substringно ничего не вернулось. grep -a known_substring sleepimageтакже ничего не делал, поэтому я предполагаю, что Pages не сохраняли текстовые данные в памяти как обычный текст.

Изменить: После прочтения этого ответа на бинарный grep я попытался perl -ln0777e 'print unpack("H*",$1), "\n", pos() while /(null_padded_substring)/g' sleepimage, снова будучи бесплодным. Я дополнил его нулями, чтобы попытаться найти совпадение с текстом UTF-8. Затем я попробовал .*шарики между каждым персонажем - до сих пор не играли в кости.

Таким образом, Pages, вероятно, не хранит текст в виде какой-либо обычной кодировки в памяти. Мне нужно было бы найти правило перевода между строкой ASCII и представлением данных Pages - я думаю, может быть, какой-то строковый буфер Objective C. Мне кажется очень странным хранить символьные данные как что-либо еще, кроме последовательности символов, но, похоже, именно это и делает Pages.

Если у вас есть какие-либо идеи о том, как определить представление текста в памяти в Pages, это может быть очень полезно для решения этой проблемы. Может быть, я могу сбросить и прочитать память процесса некоторым простым способом?

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

Версия OS X - Snow Leopard, 10.6.8.

Сложные предложения, касающиеся программирования, приветствуются. Я делаю C и Python.

Спасибо.

sapht
источник
1
Надеемся, что вы сделали копию этого файла, чтобы не проверять более новый сон-образ, написанный после перезагрузки. Тогда вы можете захотеть воссоздать ситуацию (без сбоев) с максимально свободной оперативной памятью - т.е. открывайте только страницы, пишите уникальный текст и позволяйте ОС писать новый образ сна; и затем начните исследовать это для своего уникального текста.
iolsmit
@iolsmit Да, все тесты выполняются на копии sleepimage. Пролистывать другое изображение в поисках уникального текста было бы так же сложно, так как размер изображения все равно составлял бы 4 ГБ, а блок памяти Страницы размещался бы где-то случайно в этом файле. Я полагаю, что мог бы обнулить ОЗУ, затем открыть страницы и затем искать ненулевые последовательности в образе сна. Но Pages съедает 200 МБ памяти независимо - все еще маленькая иголка в стоге сена.
sapht
Ваш текст хранится с 0x00 между каждым символом, поэтому вы должны искать это или эту строку: loobsdpkdbik; Смотри также мой ответ ниже
iolsmit
Разве на страницах не включены версии, включенные по умолчанию, даже если у вас нет резервной копии машины времени (ищите резервные копии на мобильных устройствах, где система выполняет резервное копирование, даже если диск резервного копирования не подключен)? Вы исключили более простые способы вернуть файл без героического проведения криминалистического анализа формата файла спящего изображения? (не важно, как это будет здорово, если вы это
сделаете
Версии @bmike пришли только с Lion, но эта машина работает на Snow Leopard (10.6.8), и я помню, что потерял немало работы из-за сбоя iWork на SL и отсутствия автосохранения ...
iolsmit

Ответы:

1

Обновление с картинками:

  • этот loobsdpkdbikидентификатор, упомянутый первым, не один - просто случилось до того, как мой текст впервые попробовал.

  • кажется, что часть текста «теряется» (т.е. не сохраняется в одном непрерывном отрезке памяти), и это может ухудшиться при использовании ОЗУ

  • возможно, вы не сможете восстановить значимый текст из образа сна

Теперь мой оригинальный текст (с опечаткой в ​​первом абзаце, сэр мистер Матисс):

Hidden Gems: Сад скульптур Эбби Олдрича Рокфеллера от MoMa, спроектированный Филиппом Джонсоном в 1953 году, - это впечатляющий городской оазис с его отражающими бассейнами и красивым ландшафтом. В этой галерее под открытым небом установлены меняющиеся экспозиции скульптур под открытым небом, в том числе работы Аристида Майоля, Александра Колдера, Анри Майса, Пабло Пикассо и Ричарда Серра.

Посещая новые галереи живописи и скульптуры в МоМа, обязательно пройдите через лестницу, соединяющую четвертый и пятый этажи, чтобы увидеть монументальное изображение радости и энергии Анри Матисса «Танец» (1909). Первоначально картина предназначалась для вывешивания на лестничной площадке русского дворца в Москве.

И восстановленный текст:

Скрытые драгоценные камни: Ma s Abby Aldrich Rockeller Sculpre Gn, созданный Фипом Джоном в 1953 году, является впечатляющим ursithtseflecting бассейнами autifulandscapg. Эта галерея под открытым небом украшена изменяющимися экспозициями скульптора Аутора, включая работы Аристида Майоля, Александра Колдера, Анри Мейсса, Паблоикассо, Анчард Море.

В то время как вы будете встречаться с новыми скульптурами по рисованию в Ма, обязательно пройдите мост, соединяющий четвёртое воображение радости и эй, Дэн (19). Картина покоилась в лестничном зале Русского дворца Москва.

И скриншоты:

Оригинальный текст в страницах

Восстановленный текст из sleepimage


Кажется, что для (несохраненного) документа Pages (почти) все символы в вашем тексте разделены 0x00в памяти - таким образом, STRINGстановится S.T.R.I.N.Gс .существом 0x00. Так что вы либо должны искать это; Я могу порекомендовать 0xED для графического интерфейса ... ... или для поиска, loobsdpkdbikкоторый кажется (частью) идентификатора, который идет за 5 байтов до текста (по крайней мере, только в одном случае).

iolsmit
источник
Хм, я сделал поиск "loobsdpkdbik", но все еще пусто. Этот идентификатор появлялся перед каждым вариантом несохраненного документа? Возможно, это что-то означает в документе - например, наследование окон, шрифт по умолчанию и т. Д. Я искал строку с нулевым отступом ранее, используя perl, т. s\0u\0b\0s\0t\0r\0i\0n\0gЕ. Не работал, подробное описание в моем исходном вопросе. Ох - как ты это узнал?
sapht
@sapht Я обновил свой ответ; кажется, что текст не хранится в памяти непрерывно, что может сделать невозможным восстановление после сонного образа. И этот "loobsdpkdbik" не имеет отношения к документу Страницы, просто случилось раньше, чем мой текст.
iolsmit
Может быть, тогда подстрока была среди пробормотанных слов прерывистой памяти. Я до сих пор не нашел никаких данных в образе сна, но нам, возможно, придется просто найти правильную подстроку. Или блок памяти никогда не был записан. Хорошая работа по исследованию сонного образа, спасибо.
sapht
@sapht Если ваше sleepimage не повреждено, оно должно содержать полный текст документа Страницы - поскольку восстановление ОЗУ поместит его в то место, где находилась система, когда он находился в спящем режиме. Я бы порекомендовал попробовать sleepimage на виртуальной машине: установите любую поддерживаемую OS X на виртуальную машину (или используйте VMware fusion 4.1 ;) - затем клонируйте свою машину на виртуальный жесткий диск и попробуйте загрузиться с sleepimage.
iolsmit
2

Сначала попробуйте, если известная_строка БЫЛА сохранена в виде обычного текста (не так)

Я думаю, вы могли бы попробовать использовать

grep -Ubo --binary-files=text "known_substring" sleepimage 

Исходя из этого, параметр -U указывает поиск в двоичных файлах, -b указывает, что должно отображаться смещение в байтах для соответствующей части, и, наконец, -o указывает, что должна быть напечатана только соответствующая часть.

Если это сработает, вы будете знать смещение в байтах, чтобы добраться до этого региона, но я не знаю точно, как действовать там. В зависимости от типа файла вы, вероятно, можете проверить наличие сигнатуры типа файла рядом с этим информированным смещением и попытаться выделить только те байты, которые составляют часть этого файла. Для этого, я полагаю, вы могли бы либо написать для этого программу на C, либо выполнить ее hexdump -s known_offset sleepimageи попытаться получить только те байты, которые относятся к нужному файлу.

Например, предположим, что я хотел кое-что узнать о Chrome:

$ sudo grep -Ubo --binary-files=text -i "chrome" sleepimage
3775011731:chrome

Итак, я знаю, что у меня есть вхождение хрома по смещению байта 3775011731. Следовательно, я мог:

$ sudo hexdump -s 3775011731 sleepimage | head -n 3
e1021b93 09 09 3c 73 74 72 69 6e 67 3e 2e 63 68 72 6f 6d
e1021ba3 65 2e 67 6f 6f 67 6c 65 2e 63 6f 6d 3c 2f 73 74
e1021bb3 72 69 6e 67 3e 0a 09 09 3c 6b 65 79 3e 45 78 70

Сложнее было бы получить только те байты, которые вы хотите. Если тип файла имеет известный заголовок, вы можете вычесть размер заголовка в байтах из смещения hexdump, так что вы получите файл «с начала». Если тип файла имеет известную сигнатуру "EOF", вы также можете попытаться найти его и, следовательно, получить только байты до этой точки.

Какой у вас тип файла? Считаете ли вы, что такая процедура может быть использована в вашем случае? Обратите внимание, что я никогда не делал этого раньше, и я основываюсь на многих «догадках», но я полагаю, что что-то вроде этого имеет небольшой шанс работать ..

Вторая попытка, медленный метод для анализа всех байтов

Мой метод не работает, потому что он также ищет только простой текст, моя ставка. Для этого второго текста я создал простую программу на C, содержащую:

#include <stdio.h>

int main () {
  printf("assim");
  return 0;
}

Так что я мог бы найти в этом тексте «assim», который будет вашей известной строкой. Чтобы узнать, какие байты искать я сделал:

$ echo -n "assim" | hexdump
0000000 61 73 73 69 6d                                 
0000005

Следовательно, я должен найти «61 73 73 69 6d». После компиляции этого простого исходного кода C в программу "tt" я сделал следующее:

hexdump -v -e '/1 "%02X\n"' tt | # format output for hexdump of file tt
    pcregrep -M --color -A 3 -B 3 "61\n73\n73\n69\n6D" # get 3 bytes A-fter and 3 bytes B-fore the occurence

Который вернулся ко мне:

введите описание изображения здесь

Если бы вы сделали что-то подобное, я думаю, вы могли бы получить свои данные ... Хотя это было бы довольно медленно для анализа 2 ~ 8 ГБ байтов ...

Обратите внимание, что в этом подходе вы должны найти гексы заглавными буквами (напишите 6D вместо 6d на последнем grep), а не заглавными буквами, и используйте \ n вместо пробелов (так что вы можете использовать -A и - B для grep). Вы можете использовать, grep -iчтобы он стал без учета регистра, но это будет немного медленнее. Следовательно, просто используйте заглавные буквы, если это используется.

Или, если вам нужен универсальный «скрипт»:

FILENAME=tt # file to parse looking for string
BEFORE=3 # bytes before occurrence
AFER=3 # bytes after occurrence
KNOWNSTRING="assim" # string to search for

ks_bytes="$(echo -n "$KNOWNSTRING" | hexdump | head -n1 | cut -d " " -f2- | tr '[:lower:]' '[:upper:]' | sed -e 's/ *$//g' -e 's/ /\\n/g')"

hexdump -v -e '/1 "%02X\n"' $FILENAME | pcregrep -M --color -A $AFER -B $BEFORE $ks_bytes
FernandoH
источник
Текст сохраняется только в памяти, так как файл никогда не сохранялся. Таким образом, нет реального типа файла, только тот тип представления, который Pages хранит внутри для данных. Переход -Uк grep, казалось, не имел большого значения ( aсокращенно --binary-files=text). Если бы у меня было смещение в байтах, я бы определенно мог продолжить, но либо файл поврежден, либо Pages хранит данные не в ASCII-формате. Возможно UTF-8, но grepне будет принимать нулевые байты для символа совпадения.
sapht
Я отредактировал пост с другой попыткой ... кажется, что он работает ... но очень медленно, и вам придется "угадать", сколько байтов вы хотите до и после появления в известной строке. Примечание: когда я echo -n "assim" | hexdumpполучаю hexdump для кодировки UTF-8, вы можете попробовать echo -n "assim" | iconv -t UTF-16 | hexdumpдругие кодировки, в данном случае UTF-16, я понятия не имею, как он хранится в памяти. Но в моем случае он был сохранен как UTF-8 действительно :)
FernandoH
Хм, ну, шестнадцатеричный дамп для вашей программы на C печатает текст, так как он фактически встроен в двоичный файл - gcc компилируется таким образом, что все статические буферы символов хранятся в самой программе для ссылки в памяти. Но для Страниц эти данные были созданы при запуске. Я обновил свой ответ новым совпадением, которое я пробовал через perl, но это было бесполезно, поэтому я почти уверен, что текст хранится каким-то странным нестандартным образом, поскольку байты ASCII даже не совпадают. Возможно, какой-то объективный строковый буфер C ...
sapht
Хм ... Что если вы попытаетесь найти строку "Pages.app"? Я бы не знал, как поступить, если что-нибудь будет найдено (например, что принадлежит приложению и каков ваш документ?), Но если бы мы придерживались такой последовательности мыслей, это могло бы стать началом попытки. Хотя я должен признать, что должны быть более легкие альтернативы, это было бы довольно трудоемким
ФернандоХ
На самом деле, вы помните части из этого файла документов? Несмотря на то, что он был сохранен в памяти, если вы знаете некоторые точные предложения, которые были там написаны (если вы помните или у вас есть предыдущая версия файла), вы можете попробовать поискать их напрямую! Думаю, это было бы намного проще :) А поскольку Pages - это программа для редактирования слов, думаю, вы хотите восстановить написанное, верно? Если это так, ищите контент, а не мета-информацию, это может быть проще .. Надеюсь, по крайней мере ..
ФернандоХ,