Recupera i dati delle pagine in memoria da un wake-up di ibernazione non riuscito

Aggiorna con immagini:

• quell'identificatore loobsdpkdbik menzionato per primo, non è uno - è appena successo di essere prima del mio testo, la prima volta che l'ho provato.

• parte del testo sembra essere "persa" (cioè non salvata in un tratto di memoria continua) e questo potrebbe peggiorare con l'utilizzo della RAM

• potresti non essere in grado di recuperare testo significativo dall'immagine sleep

Ora il mio testo originale (con errore di battitura nel primo paragrafo, signor Matisse):

Hidden Gems: MoMa’s Abby Aldrich Rockefeller Sculpture Garden, designed by Philip Johnson in 1953, is a spectacular urban oasis with its reflecting pools and beautiful landscaping. This outdoor gallery is installed with changing displays of outdoor sculpture, including works by Aristide Maillol, Alexander Calder, Henri Maisse, Pablo Picasso, and Richard Serra.

While visiting the new painting and sculpture galleries at MoMa, be sure to traverse the staircase bridging the forth and fifth floors in order to see Henri Matisse’s monumental image of joy and energy, Dance (1909). The painting was originally intended to hang in the stair hall of a Russian palace in Moscow.

E il testo recuperato:

Hidden Gems: Ma s Abby Aldrich Rockeller Sculpre Gn, desigd by Phip John 1953, is spectacular ursithtseflecting pools autifulandscapg. This outdoor gallery is italled with changing displays of outor sculpre, includg workby Aristide Maillol, Alexander Calder, Henri Maisse, Pabloicasso, anchard Sea.

While ving the new paintg sculpture gallies at Ma, be sure to traver t stase bridging the forth fth flrsn ordeto s Henri Matse s mtal imagof joy and ey, Dan (19). The painting waorinally intded to hg t stair hall of Rsian palace Moscow.

E le schermate:

Sembra che per un documento Pages (quasi) non salvato (quasi) tutti i caratteri nel testo siano separati da 0x00 in memoria - quindi STRING diventa S.T.R.I.N.G con . essendo 0x00 . Quindi devi cercarlo; Posso consigliare 0xED per un front-end grafico ... ..o cerchi loobsdpkdbik che sembra essere (parte di) un identificatore, che viene 5 byte prima del testo (almeno solo in un caso).

Prima prova, SE known_string è stato salvato in testo normale (non il caso)

Immagino che potresti provare a usare

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

Da ciò, -U parametro specifica la ricerca sui file binari, -b specifica che l'offset in byte alla parte corrispondente deve essere visualizzato e, infine, -o specifica che deve essere stampata solo la parte corrispondente.

Se funziona, dovresti conoscere l'offset in byte per arrivare a quella regione, ma non saprei esattamente come procedere lì. A seconda del tipo di file, è possibile verificare la firma del tipo di file in prossimità di tale offset informato e provare a isolare solo i byte che fanno parte di quel file. Per questo, immagino che potresti scrivere un programma in C per farlo, o magari eseguire hexdump -s known_offset sleepimage e provare ad ottenere solo i byte che si riferiscono al file che ti serve.

Ad esempio, supponiamo che volessi sapere qualcosa su Chrome:

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

Quindi so di avere un'occorrenza di cromo all'offset di byte 3775011731. Quindi ho potuto:

$ 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

La parte difficile sarebbe ottenere solo i byte che desideri. Se il tipo di file ha un'intestazione conosciuta, potresti sottrarre la dimensione dell'intestazione in byte dall'offset di hexdump, in modo da ottenere il file "dall'inizio". Se il tipo di file ha una firma "EOF" nota, puoi provare a cercarlo anche tu e quindi ottenere solo i byte fino a quel punto.

Qual è il tuo tipo di file? Pensi che alcune procedure come questa potrebbero essere utilizzate nel tuo caso? Nota che non l'ho mai fatto prima, e mi sto basando su un sacco di "supposizioni", ma suppongo che una cosa del genere abbia una piccola possibilità di lavorare ..

Secondo tentativo, un metodo lento per analizzare tutti i byte

Il metodo precedente non funziona perché cerca anche solo testo normale, la mia scommessa. Per questo secondo testo ho creato un semplice programma C contenente:

#include <stdio.h>

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

Quindi potrei cercare "assim", che sarebbe la stringa known_string, in quel testo. Per sapere quali byte cercare, ho fatto:

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

Quindi, devo trovare "61 73 73 69 6d". Dopo aver compilato quella semplice sorgente C nel programma "tt", ho fatto quanto segue:

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

Che mi ha restituito:

Sehaifattoqualcosadelgenere,suppongochepotrestiottenereituoidati...Sarebbeunpo'lentoanalizzare2~8GBdibyteperò...

Notacheinquestoapprocciodevitrovaregliesagoniinmaiuscolo(scrivi6Dinvecedi6dsull'ultimogrep),noninlettereminuscole,eusa\ninvecedispazibianchi(cosìpuoiusare-Ae-Bperilgrep).Potrestiusaregrep-iinmodochediventasseinsensibilealladistinzionetramaiuscoleeminuscole,masarebbeunpo'piùlento.Quindi,usasolomaiuscolesequestoèusato.

Oppure,sevuoiuno"script" tutto-automatico:

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