Відновлення даних із сторінок пам'яті внаслідок невдалого сну в режимі сплячки

Макбук моєї подруги зазнав аварії під час спроби відновлення зі сплячого файла. Рядок прогресу зупинився на рівні ~ 10%, після чого ми перезапустили комп'ютер для нормального запуску.

Це зображення в режимі сплячої пам’яті відкрило збережений документ на Сторінках, який ми хотіли б відновити. Є sleepimageв /private/var/vm, яке, я припускаю, є сплячим зображенням, яке ніколи не було відновлено правильно. Ми створили резервну копію цієї речі, щоб зберегти її в живих.

Ми намагалися, strings sleepimage | grep known_substringале нічого не повернулося. grep -a known_substring sleepimageтакож нічого не робив, тому я припускаю, що Сторінки не зберігали текстові дані в пам'яті як звичайний текст.

Редагувати: Прочитавши цю відповідь на Binary grep, я спробував perl -ln0777e 'print unpack("H*",$1), "\n", pos() while /(null_padded_substring)/g' sleepimage, знову безрезультатно. Я підбив її нулями, щоб спробувати відповідати тексту UTF-8. Потім я спробував з .*глобусами між кожним символом - все ще немає кісток.

Тож Сторінки, ймовірно, не зберігають текст за допомогою будь-якого загального кодування в пам'яті. Мені потрібно знайти правило перекладу між рядком ASCII і представленням даних Pages - я думаю, можливо, якийсь буфер рядка Objective C. Мені здається, дуже дивно зберігати дані символів як будь-що інше, ніж послідовність символів, але це, здається, те, що робить Сторінки.

Якщо у вас є ідеї, як розібрати в пам'яті подання тексту всередині сторінки, це може бути дуже корисним у вирішенні цієї проблеми. Можливо, я можу скинути і прочитати пам'ять процесів якимось простим способом?

Ще одне можливе рішення є простішим - я припускаю, що можна якось перезавантажити комп’ютер з цього sleepimage, але я не можу знайти жодної документації щодо того, як би ви діяли з цим. Деякі інші користувачі ( макромотори ), схоже, стикалися з цим, але на всі знайдені на форумі запитання жоден з них не має відповідей.

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

Вітаються складні пропозиції щодо програмування. Я роблю C і Python.

Дякую.

Оновити фотографіями:

• той loobsdpkdbikідентифікатор, згаданий першим, не один - просто випадковий перед моїм текстом у перший раз, коли я його спробував.

• частина тексту, здається, "втрачається" (тобто не зберігається в одному безперервному розтягуванні пам'яті), і це може погіршитися при використанні оперативної пам'яті

• можливо, ви не зможете відновити змістовний текст із сну

Тепер мій оригінальний текст (з помилкою друку в 1-му абзаці, вибачте містера Матісса):

Приховані дорогоцінні камені: Сад скульптур Еббі Олдріха Рокфеллера MoMa, розроблений Філіпом Джонсоном у 1953 році, - вражаючий міський оазис із віддзеркалюючими басейнами та прекрасним ландшафтним дизайном. Ця відкрита галерея встановлена ​​зі змінними експонатами скульптури на свіжому повітрі, включаючи роботи Арістіда Майллола, Олександра Калдера, Анрі Мейса, Пабло Пікассо та Річарда Серри.

Відвідуючи нові галереї живопису та скульптури на MoMa, не забудьте пройти сходи, що перетинають четвертий та п'ятий поверхи, щоб побачити монументальний образ радості та енергії Анрі Матісса, Танець (1909). Картина спочатку мала на меті висіти у сходовій залі російського палацу в Москві.

І відновлений текст:

Приховані дорогоцінні камені: Ma s Abby Aldrich Rockeller Sculpre Gn, розроблений Phip John 1953, є вражаючим урядом зібранням басейнів autifulandscapg. Ця відкрита галерея оснащена мінливими експонатами зовнішньої скульптури, включаючи роботи Арістіда Майллола, Олександра Калдера, Анрі Мейса, Паблоїкассо, причального моря.

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

І знімки екрана:

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

Спершу спробуйте, АБО, якщо відомий строковий запис був збережений у простому тексті (не так)

Я думаю, ви можете спробувати використовувати

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

З цього параметра -U вказує пошук у бінарних файлах, -b вказує, що зміщення в байтах до відповідної частини повинно відображатися, і, нарешті, -o визначає, що повинна друкуватися тільки відповідна частина.

Якщо це працює, ви знаєте, як зсув у байтах потрапить до цього регіону, але я не знаю, як саме діяти там. Залежно від типу файлу, ви, ймовірно, можете перевірити наявність підпису файлів поблизу відомого зміщення та спробувати виділити лише ті байти, які є частиною цього файлу. З цього hexdump -s known_offset sleepimageприводу , я думаю, ви можете або написати програму C для цього, або, можливо, виконати і спробувати отримати лише ті байти, які стосуються потрібного вам файлу.

Наприклад, припустимо, що я хотів щось знати про 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

Складною частиною було б отримати лише потрібні байти. Якщо тип файлу має відомий заголовок, можливо, ви можете відняти розмір заголовка в байтах від зміщення шістнадцяткової передачі, тож ви отримаєте файл "з початку". Якщо тип файлу має відомий підпис "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". Після компіляції цього простого джерела С у програму "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 на останньому греппі), а не малі літери, і використовуйте \ n замість пробілів (так що ви можете використовувати -A і - Б для грепу). Ви можете використовувати 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