Recuperar los datos de las páginas en memoria de la reactivación de hibernación fallida

Actualizar con fotos:

• ese loobsdpkdbik identifier mencionado primero, no es uno, solo debe pasar antes de mi texto la primera vez que lo probé.

• parte del texto parece "perderse" (es decir, no se guarda en una extensión de memoria continua) y esto puede empeorar con el uso de RAM

• es posible que no puedas recuperar texto significativo de sleepimage

Ahora mi texto original (con error tipográfico en el primer párrafo, sry Sr. Matisse):

  

Gemas ocultas: el jardín de esculturas Abby Aldrich Rockefeller de MoMa, diseñado por Philip Johnson en 1953, es un espectacular oasis urbano con sus piscinas reflectantes y hermosos paisajes. Esta galería al aire libre se instala con exhibiciones cambiantes de esculturas al aire libre, que incluyen obras de Aristide Maillol, Alexander Calder, Henri Maisse, Pablo Picasso y Richard Serra.

     

Mientras visita las nuevas galerías de pintura y escultura en MoMa, asegúrese de cruzar la escalera que une los pisos cuarto y quinto para ver la imagen monumental de alegría y energía de Henri Matisse, Dance (1909). La pintura estaba originalmente destinada a colgarse en la sala de la escalera de un palacio ruso en Moscú.

Y el texto recuperado:

  

Gemas ocultas: Ms Abby Aldrich Rockeller Sculpre Gn, diseñada por Phip John en 1953, es una ursithtsflecting pools autifulandscapg espectacular. Esta galería al aire libre está repleta de exhibiciones cambiantes de outor sculpre, incluido el trabajo realizado por Aristide Maillol, Alexander Calder, Henri Maisse, Pabloicasso, y el Mar del Ancho.

     

Mientras ves las nuevas galerías de esculturas de pintura en Ma, asegúrate de recorrer el cuarto puente de la cuarta imagen de Henri Matse, que es la alegría y la felicidad, Dan (19). El cuadro está destinado a la sala de la escalera del palacio Rsian de Moscú.

Y las capturas de pantalla:

Parece que para un documento de Páginas (sin guardar) (casi) todos los caracteres en su texto están separados por 0x00 en la memoria, por lo tanto STRING se convierte en S.T.R.I.N.G con . siendo 0x00 . Así que o tienes que buscar eso; Puedo recomendar 0xED para un front-end gráfico ... ... o busca loobsdpkdbik que parece ser (parte de) un identificador, que viene 5 bytes antes del texto (al menos solo en un caso).

Primer intento, SI se conoce la cadena conocida se guardó en texto sin formato (no es el caso)

Supongo que podrías intentar usar

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

A partir de eso, el parámetro -U especifica la búsqueda en archivos binarios, -b especifica que se debe mostrar el desplazamiento en bytes a la parte correspondiente y, por último, -o especifica que solo se debe imprimir la parte correspondiente.

Si eso funciona, sabrías el desplazamiento en bytes para llegar a esa región, pero no sabría exactamente cómo proceder allí. Dependiendo del tipo de archivo, probablemente podría verificar la firma del tipo de archivo cerca de ese desplazamiento informado e intentar aislar solo los bytes que sí forman parte de ese archivo. Para esto, supongo que puedes escribir un programa en C para hacerlo, o tal vez ejecutar hexdump -s known_offset sleepimage e intentar obtener solo los bytes relacionados con el archivo que necesitas.

Por ejemplo, supongamos que quisiera saber algo sobre Chrome:

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

Así que sé que tengo una aparición de cromo en el byte offset 3775011731. Por lo tanto, podría:

$ 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 difícil sería obtener solo los bytes que deseas. Si el tipo de archivo tiene un encabezado conocido, tal vez pueda restar el tamaño del encabezado en bytes del desplazamiento de volcado hexadecimal, de modo que obtenga el archivo "desde el principio". Si el tipo de archivo tiene una firma "EOF" conocida, también puede intentar buscarlo y obtener solo los bytes hasta ese punto.

¿Cuál es tu tipo de archivo? ¿Crees que algún procedimiento como este podría usarse en tu caso? Tenga en cuenta que nunca he hecho esto antes, y me estoy basando en muchas "conjeturas", pero supongo que algo como esto tiene pocas posibilidades de funcionar ...

Segundo intento, un método lento para analizar todos los bytes

El método anterior no funciona porque también busca solo texto sin formato, mi apuesta. Para este segundo texto creé un programa de C simple que contiene:

#include <stdio.h>

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

Por lo tanto, podría buscar "assim", que sería tu cadena_conocida, en ese texto. Para saber qué bytes para buscar hice:

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

Por lo tanto, debo encontrar "61 73 73 69 6d". Después de compilar esa fuente de C simple en el programa "tt", hice lo siguiente:

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

Lo que me regresó:

Sihicierasalgoasí,supongoquepodríasobtenertusdatos...Sinembargo,seríaunpocolentoanalizar2~8GBdebytes...

Tengaencuentaqueenesteenfoquedebeencontrarloshexágonosenmayúscula(escriba6Denlugarde6denelúltimogrep),noenletrasminúsculas,yuse\nenlugardeespaciosenblanco(paraquepuedausar-Ay-Bparaelgrep).Podríausargrep-iparaquenodistingamayúsculasdeminúsculas,peroseríaunpocomáslento.Porlotanto,solousemayúsculassiseusa.

O,siquieresun"script" automatizado de do-all:

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