Odzyskaj dane stron w pamięci z nieudanego wznowienia hibernacji

Macbook mojej dziewczyny zawiesił się podczas próby przywrócenia ze hibernowanego pliku. Pasek postępu zatrzymał się na poziomie ~ 10%, po czym ponownie uruchomiliśmy komputer w celu normalnego uruchomienia.

Ten hibernowany obraz pamięci miał niezapisany dokument otwarty w Pages, który chcielibyśmy odzyskać. Jest taki, sleepimagew /private/var/vmktórym, jak zakładam, jest obraz hibernacji, który nigdy nie został poprawnie przywrócony. Stworzyliśmy kopię zapasową tego elementu, aby utrzymać go przy życiu.

Próbowaliśmy, strings sleepimage | grep known_substringale nic nie zwróciło. grep -a known_substring sleepimageteż nic nie zrobił, więc zakładam, że Pages nie zachował danych tekstowych w pamięci jako zwykłego tekstu.

Edycja: Po przeczytaniu tej odpowiedzi na temat binarnego grepa spróbowałem perl -ln0777e 'print unpack("H*",$1), "\n", pos() while /(null_padded_substring)/g' sleepimage, znów będąc bezowocnym. Wypełniłem go zerami, aby spróbować dopasować tekst UTF-8. Potem spróbowałem z .*kulami między każdą postacią - wciąż nie ma kości.

Tak więc Pages prawdopodobnie nie przechowują tekstu w zwykłym kodowaniu w pamięci. Musiałbym znaleźć regułę tłumaczenia między ciągiem ASCII a reprezentacją danych Pages - myślę, że może jakiś bufor ciągu Objective C. Wydaje mi się, że przechowywanie danych o postaciach jako sekwencji innych niż sekwencja znaków wydaje się dziwne, ale wydaje się, że to właśnie robi Pages.

Jeśli masz jakiś pomysł, jak znaleźć reprezentację tekstu w pamięci Pages, może być bardzo pomocny w rozwiązaniu tego problemu. Może mogę zrzucić i odczytać pamięć procesu w prosty sposób?

Inne możliwe rozwiązanie jest prostsze - zakładam, że w jakiś sposób można zrestartować komputer sleepimage, ale nie mogę znaleźć żadnej dokumentacji dotyczącej tego, jak byś to zrobił. Wygląda na to, że niektórzy użytkownicy ( makrumory ) zetknęli się z tym problemem , ale na wszystkie pytania z forum, które znalazłem, żaden z nich nie odpowiedział.

Wersja OS X to Snow Leopard, 10.6.8.

Mile widziane są złożone sugestie dotyczące programowania. Robię C i Python.

Dziękuję Ci.

Zaktualizuj ze zdjęciami:

• ten loobsdpkdbikidentyfikator wymieniony jako pierwszy nie jest jeden - po prostu zdarzyło mi się być przed moim tekstem przy pierwszej próbie.

• część tekstu wydaje się „zagubiona” (tzn. nie zapisana w jednym ciągłym odcinku pamięci), co może się pogorszyć przy użyciu pamięci RAM

• możesz nie być w stanie odzyskać znaczącego tekstu ze snu

Teraz mój oryginalny tekst (z literówką w pierwszym akapicie, proszę pana Matisse):

Ukryte klejnoty: Ogród rzeźby Abby Aldrich Rockefeller firmy MoMa, zaprojektowany przez Philipa Johnsona w 1953 roku, jest spektakularną miejską oazą z odbijającymi basenami i pięknym krajobrazem. Ta galeria zewnętrzna jest instalowana ze zmieniającymi się pokazami rzeźby plenerowej, w tym pracami Aristide Maillola, Alexandra Caldera, Henri Maisse, Pablo Picasso i Richarda Serry.

Odwiedzając nowe galerie malarstwa i rzeźby w MoMa, koniecznie przejdź przez schody łączące czwarte i piąte piętro, aby zobaczyć monumentalny obraz radości i energii Henri Matisse, Taniec (1909). Obraz pierwotnie miał wisieć w holu schodowym rosyjskiego pałacu w Moskwie.

I odzyskany tekst:

Hidden Gems: Ma s Abby Aldrich Rockeller Sculpre Gn, zaprojektowany przez Phip John 1953, to spektakularne ursithtseflecting baseny autiful landscapeapg. Ta galeria zewnętrzna jest wyposażona w zmieniające się eksponaty outor sculpre, w tym prace Aristide Maillola, Alexandra Caldera, Henri Maisse, Pabloicasso, kotwicę morską.

Podczas zwiedzania nowych galerii rzeźby w Ma, pamiętaj, aby przejść przez most piąty czwarty obraz Henri Matse, który przedstawia radość i oczy, Dan (19). Obraz ten obłędnie przystawił się do hali schodowej pałacu Rsian w Moskwie.

I zrzuty ekranu:

Wydaje się, że w (niezapisanym) dokumencie Pages (prawie) wszystkie znaki w tekście są oddzielone 0x00w pamięci - w ten sposób STRINGstaje S.T.R.I.N.Gsię .istnieniem 0x00. Więc albo musicie tego poszukać; Mogę polecić 0xED dla graficznego interfejsu ... lub szukania, loobsdpkdbikktóry wydaje się (częścią) identyfikatora, który pojawia się 5 bajtów przed tekstem (przynajmniej w jednym przypadku).

Pierwsza próba, JEŚLI znany ciąg znaków był przechowywany jako zwykły tekst (nie w tym przypadku)

Myślę, że możesz spróbować użyć

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

Z tego parametru -U określa wyszukiwanie plików binarnych, -b określa, że ​​należy wyświetlić przesunięcie w bajtach do pasującej części, a na koniec -o określa, że ​​należy wydrukować tylko pasującą część.

Jeśli to zadziała, poznasz przesunięcie w bajtach, aby dostać się do tego regionu, ale nie wiedziałbym dokładnie, jak tam postępować. W zależności od rodzaju pliku można prawdopodobnie sprawdzić podpis typu pliku w pobliżu tego świadomego przesunięcia i spróbować izolować tylko bajty, które stanowią część tego pliku. Wydaje mi się, że w tym celu można napisać program w języku C lub wykonać hexdump -s known_offset sleepimagei spróbować pobrać tylko bajty związane z plikiem, którego potrzebujesz.

Załóżmy na przykład, że chcę wiedzieć coś o Chrome:

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

Wiem, że wystąpił błąd chromu przy przesunięciu bajtu 3775011731. W związku z tym mogłem:

$ 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

Trudną częścią byłoby uzyskanie tylko bajtów, które chcesz. Jeśli typ pliku ma znany nagłówek, możesz odjąć rozmiar nagłówka w bajtach od przesunięcia zrzutu heksadecymalnego, aby otrzymać plik „od początku”. Jeśli typ pliku ma znany podpis „EOF”, możesz spróbować go wyszukać, a tym samym pobrać tylko bajty do tego momentu.

Jaki jest twój typ pliku? Czy uważasz, że w twoim przypadku można zastosować taką procedurę? Zauważ, że nigdy wcześniej tego nie robiłem i opieram się na wielu „domysłach”, ale przypuszczam, że coś takiego ma małe szanse na działanie…

Druga próba, powolna metoda analizowania wszystkich bajtów

Ta metoda wcześniej nie działa, ponieważ wyszukuje również tylko zwykły tekst, mój zakład. Dla tego drugiego tekstu stworzyłem prosty program C zawierający:

#include <stdio.h>

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

Chciałbym więc wyszukać w tym tekście wyrażenie „assim”, które byłoby twoim znanym ciągiem znaków. Aby wiedzieć, jakie bajty wyszukać, zrobiłem:

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

Dlatego muszę znaleźć „61 73 73 69 6d”. Po skompilowaniu tego prostego źródła C w programie „tt” zrobiłem następujące:

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

Który wrócił do mnie:

Gdybyś zrobił coś takiego, myślę, że mógłbyś zdobyć swoje dane. Parsowanie 2 ~ 8 GB bajtów byłoby jednak trochę powolne ...

Zauważ, że w tym podejściu musisz znaleźć heksy dużymi literami (na ostatnim grepie wpisz 6D zamiast 6d), a nie małymi literami i użyj \ n zamiast białych spacji (abyś mógł użyć -A i - B jak grep). Możesz użyć, grep -iaby stała się niewrażliwa na wielkość liter, ale byłoby to trochę wolniejsze. Dlatego używaj po prostu wielkich liter, jeśli są one używane.

Lub, jeśli chcesz zrobić automatyczny „skrypt”:

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