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

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.

Спасибо.

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

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

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

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

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

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

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

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

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

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

И скриншоты:

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

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

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

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