9 votes

Récupération des données Pages en mémoire en cas d'échec du réveil par hibernation.

Le Macbook de ma copine a planté alors qu'il tentait de restaurer un fichier en hibernation. La barre de progression s'est arrêtée à ~10%, après quoi nous avons redémarré l'ordinateur pour un démarrage normal.

Cette image mémoire en hibernation avait un document non sauvegardé ouvert dans Pages, que nous aimerions récupérer. Il y a un sleepimage sur /private/var/vm qui je suppose est l'image d'hibernation qui n'a jamais été correctement restaurée. On a sauvegardé ce truc pour le garder en vie.

Nous avons essayé de strings sleepimage | grep known_substring mais cela n'a rien donné. grep -a known_substring sleepimage n'a rien fait non plus, donc je suppose que Pages n'a pas gardé les données en mémoire en tant que texte brut.

Edit : Après avoir lu cette réponse sur Grep binaire J'ai essayé de perl -ln0777e 'print unpack("H*",$1), "\n", pos() while /(null_padded_substring)/g' sleepimage encore une fois sans résultat. Je l'ai complété par des nuls afin de tenter une correspondance avec le texte UTF-8. J'ai ensuite essayé avec .* entre chaque caractère -- toujours pas de dé.

Donc, Pages ne stocke probablement pas le texte par un encodage commun en mémoire. Il faudrait trouver une règle de traduction entre la chaîne ASCII et la représentation des données de Pages -- je pense peut-être à une sorte de tampon de chaîne Objective C. Il me semble très étrange de stocker des données de caractères autrement que sous la forme d'une séquence de caractères, mais c'est ce que semble faire Pages.

Si vous avez une idée sur la façon de comprendre la représentation en mémoire du texte dans Pages, cela pourrait être très utile pour résoudre ce problème. Peut-être que je peux vider et lire la mémoire du processus d'une manière simple ?

Une autre solution possible est plus simple. Je suppose qu'il est possible de redémarrer l'ordinateur à partir de cette page. sleepimage mais je ne trouve pas de documentation sur la manière de procéder. D'autres utilisateurs ( macrumors ) semblent avoir rencontré ce problème, mais pour toutes les questions du forum que j'ai trouvées, aucune n'a de réponse.

La version d'OS X est Snow Leopard, 10.6.8.

Les suggestions complexes impliquant la programmation sont les bienvenues. Je fais du C et du Python.

Merci.

2voto

FernandoH Points 149

Premier essai, SI la chaîne connue était stockée en texte brut (ce n'est pas le cas)

Je suppose que vous pourriez essayer d'utiliser

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

Le paramètre -U spécifie la recherche sur les fichiers binaires, -b spécifie que le décalage en octets de la partie correspondante doit être affiché et, enfin, -o spécifie que seule la partie correspondante doit être imprimée.

Si cela fonctionne, vous connaîtrez le décalage en octets pour accéder à cette région, mais je ne saurai pas exactement comment procéder. Selon le type de fichier, vous pourriez probablement rechercher la signature du type de fichier à proximité de ce décalage et essayer d'isoler uniquement les octets qui font partie de ce fichier. Pour cela, je suppose que vous pourriez soit écrire un programme en C, soit exécuter le processus suivant hexdump -s known_offset sleepimage et essayez de récupérer uniquement les octets qui concernent le fichier dont vous avez besoin.

Par exemple, supposons que je veuille savoir quelque chose sur Chrome :

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

Je sais donc que j'ai obtenu une occurrence de chrome à l'octet de décalage 3775011731. Donc je pourrais :

$ 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 partie délicate serait d'obtenir seulement les octets que vous voulez. Si le type de fichier a un en-tête connu, vous pourriez peut-être soustraire la taille de l'en-tête en octets de l'offset hexdump, afin d'obtenir le fichier "depuis le début". Si le type de fichier a une signature "EOF" connue, vous pourriez essayer de la rechercher également et ainsi obtenir uniquement les octets jusqu'à ce point.

Quel est votre type de fichier ? Pensez-vous qu'une procédure comme celle-ci pourrait être utilisée dans votre cas ? Notez que je n'ai jamais fait cela auparavant, et je me base sur beaucoup de "suppositions", mais je suppose que quelque chose comme cela a une petite chance de fonctionner

Deuxième essai, une méthode lente pour analyser tous les octets

La méthode précédente ne fonctionne pas car elle ne recherche également que le texte brut, ma foi. Pour ce deuxième texte j'ai créé un simple programme C contenant :

#include <stdio.h>

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

Je pourrais donc rechercher "assim", qui serait votre chaîne_connue, dans ce texte. Afin de savoir quels octets rechercher, j'ai fait :

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

Je dois donc trouver "61 73 73 69 6d". Après avoir compilé ce simple source C dans le programme "tt", j'ai fait ce qui suit :

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

Ce qui me ramène à moi :

enter image description here

Si tu faisais quelque chose comme ça, je suppose que tu pourrais obtenir tes données... Mais ce serait un peu lent pour analyser 2~8GB d'octets...

Notez que dans cette approche vous devez trouver les hexagones en majuscule (écrivez 6D au lieu de 6d sur le dernier grep), pas en minuscule, et utiliser \n au lieu des espaces blancs (pour que vous puissiez utiliser -A et -B pour le grep). Vous pouvez utiliser grep -i donc il est devenu insensible à la casse, mais il serait un peu plus lent. Par conséquent, il suffit d'utiliser les majuscules si cela est utilisé.

Ou, si vous voulez un "script" automatique :

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

1voto

iolsmit Points 4325

Mise à jour avec des photos :

  • que loobsdpkdbik L'identifiant mentionné en premier n'en est pas un - il s'est simplement trouvé devant mon texte la première fois que je l'ai essayé.

  • une partie du texte semble se "perdre" (c'est-à-dire qu'elle n'est pas sauvegardée en une seule fois dans la mémoire) et cela peut s'aggraver avec l'utilisation de la RAM

  • il se peut que vous ne puissiez pas récupérer de texte significatif à partir de l'image du sommeil.

Maintenant mon texte original (avec une coquille dans le 1er paragraphe, désolé M. Matisse) :

Des joyaux cachés : Le jardin de sculptures Abby Aldrich Rockefeller du MoMa, conçu par Philip Johnson en 1953, est une oasis urbaine spectaculaire avec ses bassins réfléchissants et son magnifique aménagement paysager. Cette galerie extérieure présente des expositions changeantes de sculptures en plein air, notamment des œuvres d'Aristide Maillol, Alexander Calder, Henri Maisse, Pablo Picasso et Richard Serra.

Lors de votre visite des nouvelles galeries de peinture et de sculpture du MoMa, ne manquez pas de franchir l'escalier qui relie le quatrième et le cinquième étage pour voir l'image monumentale de joie et d'énergie d'Henri Matisse, Danse (1909). À l'origine, ce tableau devait être accroché dans la cage d'escalier d'un palais russe à Moscou.

Et le texte récupéré :

Des joyaux cachés : Ma s Abby Aldrich Rockeller Sculpre Gn, conçue par Phip John en 1953, est spectaculaire : elle reflète les piscines et les paysages. Cette galerie extérieure présente des expositions temporaires de sculptures extérieures, notamment des œuvres d'Aristide Maillol, d'Alexander Calder, d'Henri Maisse, de Pabloicasso et d'anchard Sea.

En visitant les nouvelles galeries de peinture et de sculpture de Ma, ne manquez pas de parcourir la stase qui enjambe le quatrième étage, afin d'admirer l'image murale de la joie et de la joie d'Henri Matse, Dan (19). Le tableau était initialement destiné à la salle d'escalier du palais russe de Moscou.

Et les captures d'écran :

Original text in Pages

Recovered text from sleepimage


Il semble que dans un document Pages (non sauvegardé), presque tous les caractères de votre texte sont séparés par des espaces. 0x00 en mémoire - ainsi STRING devient S.T.R.I.N.G con . être 0x00 . Donc, soit vous devez chercher pour cela ; je peux recommander 0xED pour un front-end graphique... ou vous cherchez loobsdpkdbik qui semble être (une partie d') un identifiant, qui vient 5 octets avant le texte (au moins dans un seul cas).

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X