Khôi phục dữ liệu Trang trong bộ nhớ từ đánh thức ngủ đông không thành công

Macbook của bạn gái tôi bị hỏng trong khi cố gắng khôi phục từ một tệp ngủ đông. Thanh tiến trình dừng ở mức ~ 10%, sau đó chúng tôi khởi động lại máy tính để khởi động bình thường.

Hình ảnh bộ nhớ ngủ đông này có một tài liệu chưa được lưu trong Trang mà chúng tôi muốn khôi phục. Có một sleepimagetrong /private/var/vm, mà tôi giả định là hình ảnh ngủ đông mà không bao giờ có được phục hồi một cách chính xác. Chúng tôi đã sao lưu điều này để giữ cho nó sống.

Chúng tôi đã cố gắng strings sleepimage | grep known_substringnhưng nó không trả lại được gì. grep -a known_substring sleepimagecũng không làm gì cả, vì vậy tôi cho rằng Trang không giữ dữ liệu văn bản trong bộ nhớ dưới dạng văn bản thuần túy.

Chỉnh sửa: Sau khi đọc câu trả lời này trên Grep nhị phân, tôi đã cố gắng perl -ln0777e 'print unpack("H*",$1), "\n", pos() while /(null_padded_substring)/g' sleepimage, một lần nữa không có kết quả. Tôi đã đệm nó bằng null để thử khớp với văn bản UTF-8. Sau đó, tôi đã cố gắng với sự .*ảm đạm giữa mỗi nhân vật - vẫn không có xúc xắc.

Vì vậy, Trang có thể không lưu trữ văn bản bằng bất kỳ mã hóa phổ biến nào trong bộ nhớ. Tôi sẽ cần tìm một quy tắc dịch giữa chuỗi ASCII và biểu diễn dữ liệu Trang - Tôi nghĩ có lẽ một loại bộ đệm chuỗi Objective C nào đó. Đối với tôi có vẻ rất kỳ lạ khi lưu trữ dữ liệu nhân vật như bất kỳ thứ gì khác ngoài một chuỗi các ký tự, nhưng đây dường như là những gì Trang đang làm.

Nếu bạn có bất kỳ ý tưởng nào về cách tìm ra cách thể hiện trong bộ nhớ của văn bản bên trong Trang, có thể rất hữu ích trong việc giải quyết vấn đề này. Có lẽ tôi có thể kết xuất và đọc bộ nhớ tiến trình theo một cách đơn giản nào đó?

Một giải pháp khả thi khác đơn giản hơn - Tôi cho rằng bằng cách nào đó có thể khởi động lại máy tính từ đây sleepimage, nhưng tôi không thể tìm thấy bất kỳ tài liệu nào về cách bạn sẽ tiến hành với điều đó. Một số người dùng khác ( macrumors ) dường như đã gặp phải điều này, nhưng đối với tất cả các câu hỏi của diễn đàn tôi đã tìm thấy, không ai trong số họ có câu trả lời.

Phiên bản OS X là Snow Leopard, 10.6.8.

Đề xuất phức tạp liên quan đến lập trình được chào đón. Tôi làm C và Python.

Cảm ơn bạn.

Cập nhật bằng hình ảnh:

• loobsdpkdbikđịnh danh đó được đề cập đầu tiên, không phải là một - chỉ là vui mừng trước văn bản của tôi trong lần đầu tiên tôi thử nó.

• một phần của văn bản dường như bị "mất" (nghĩa là không được lưu trong một lần kéo dài bộ nhớ liên tục) và điều này có thể trở nên tồi tệ hơn với việc sử dụng RAM

• bạn có thể không phục hồi được văn bản có ý nghĩa từ cơn buồn ngủ

Bây giờ văn bản gốc của tôi (với lỗi đánh máy trong đoạn 1, sry Mr. Matisse):

Viên ngọc ẩn: Vườn điêu khắc Abby Aldrich Rockefeller của MoMa, được thiết kế bởi Philip Johnson vào năm 1953, là một ốc đảo đô thị ngoạn mục với hồ bơi phản chiếu và cảnh quan tuyệt đẹp. Phòng trưng bày ngoài trời này được lắp đặt với các màn hình điêu khắc ngoài trời thay đổi, bao gồm các tác phẩm của Aristide Maillol, Alexander Calder, Henri Maisse, Pablo Picasso và Richard Serra.

Khi đến thăm phòng trưng bày tranh và điêu khắc mới tại MoMa, hãy chắc chắn đi qua cầu thang bắc qua tầng thứ năm và thứ năm để xem hình ảnh hoành tráng về niềm vui và năng lượng của Henri Matisse, Dance (1909). Bức tranh ban đầu được dự định treo trong sảnh cầu thang của một cung điện Nga ở Moscow.

Và văn bản phục hồi:

Viên ngọc ẩn: Ma s Abby Aldrich Rockeller Sculpre Gn, được mô tả bởi Phip John 1953, là hồ bơi ursithtseflecting ngoạn mục autitableandscapg. Phòng trưng bày ngoài trời này được trưng bày với sự thay đổi màn hình của sculpre outor, bao gồm cả công việc Aristide Maillol, Alexander Calder, Henri Maisse, Pabloicasso, Biển neo.

Trong khi ving các bức tượng điêu khắc paintg mới tại Ma, hãy chắc chắn rằng bạn sẽ bắt được cầu nối thứ năm thứ mười một của Flrsn ordeto s của Henri Matse s hình ảnh niềm vui và mắt, Dan (19). Bức tranh được vẽ rất đẹp mắt đến sảnh cầu thang của cung điện Rumani Moscow.

Và ảnh chụp màn hình:

Dường như đối với một (chưa được lưu) tài liệu Trang (gần như) tất cả các nhân vật trong văn bản của bạn được ngăn cách bởi 0x00trong bộ nhớ - do đó STRINGtrở nên S.T.R.I.N.Gcó .được 0x00. Vì vậy, bạn hoặc phải tìm kiếm điều đó; Tôi có thể đề xuất 0xED cho giao diện đồ họa ... .. hoặc bạn tìm kiếm loobsdpkdbikcó vẻ là (một phần) của mã định danh, xuất hiện 5 byte trước văn bản (ít nhất là trong một trường hợp).

Lần thử đầu tiên, NẾU biết_ chuỗi WAS được lưu trữ trong văn bản thuần túy (không phải trường hợp)

Tôi đoán bạn có thể thử sử dụng

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

Từ đó, tham số -U chỉ định tìm kiếm trên các tệp nhị phân, -b chỉ định rằng phần bù theo byte cho phần phù hợp sẽ được hiển thị và cuối cùng, -o chỉ định rằng chỉ nên in phần phù hợp.

Nếu điều đó hoạt động, bạn sẽ biết phần bù theo byte để đến vùng đó, nhưng tôi sẽ không biết chính xác cách tiến hành ở đó. Tùy thuộc vào kiểu tệp, bạn có thể kiểm tra chữ ký filetype gần phần bù được thông báo đó và cố gắng tách riêng các byte tạo thành một phần của tệp đó. Đối với điều này, tôi đoán bạn có thể viết chương trình C để làm điều đó hoặc có thể thực thi hexdump -s known_offset sleepimagevà thử chỉ nhận các byte liên quan đến tệp bạn cần.

Chẳng hạn, giả sử tôi muốn biết điều gì đó về Chrome:

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

Vì vậy, tôi biết rằng tôi đã xuất hiện chrome ở byte bù 3775011731. Do đó tôi có thể:

$ 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

Phần khó khăn sẽ chỉ nhận được các byte bạn muốn. Nếu filetype có một tiêu đề đã biết, bạn có thể trừ kích thước tiêu đề theo byte từ phần bù hexdump, do đó bạn có được tệp "kể từ đầu". Nếu filetype có chữ ký "EOF" đã biết, bạn cũng có thể thử tìm kiếm nó và do đó chỉ nhận được các byte cho đến thời điểm đó.

Filetype của bạn là gì? Bạn có nghĩ rằng một số thủ tục như thế này có thể được sử dụng trong trường hợp của bạn? Lưu ý rằng tôi chưa bao giờ làm điều này trước đây và tôi đang dựa vào rất nhiều "dự đoán", nhưng tôi cho rằng một cái gì đó như thế này có một chút cơ hội làm việc ..

Lần thử thứ hai, một phương thức chậm để phân tích tất cả các byte

Phương pháp trước đây không hoạt động vì nó cũng chỉ tìm kiếm văn bản đơn giản, đặt cược của tôi. Đối với văn bản thứ hai này, tôi đã tạo một chương trình C đơn giản chứa:

#include <stdio.h>

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

Vì vậy, tôi có thể tìm kiếm "assim", đó sẽ là know_ chuỗi của bạn, trong văn bản đó. Để biết byte nào cần tìm kiếm tôi đã làm:

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

Do đó, tôi phải tìm "61 73 73 69 6d". Sau khi biên dịch nguồn C đơn giản đó vào chương trình "tt", tôi đã làm như sau:

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

Trả lại cho tôi:

Nếu bạn đã làm một cái gì đó như vậy, tôi đoán bạn có thể lấy dữ liệu của mình .. Sẽ là chậm khi phân tích 2 ~ 8GB byte mặc dù ...

Lưu ý rằng trong cách tiếp cận này, bạn phải tìm các hình lục giác bằng chữ in hoa (viết 6D thay vì 6d trên grep cuối cùng), không phải trong các chữ cái in hoa và sử dụng \ n thay vì khoảng trắng (để bạn có thể sử dụng -A và - B cho grep). Bạn có thể sử dụng grep -iđể nó trở nên không phân biệt chữ hoa chữ thường, nhưng nó sẽ chậm hơn một chút. Do đó, chỉ cần sử dụng thủ đô nếu điều này được sử dụng.

Hoặc, nếu bạn muốn một "tập lệnh" tự động làm tất cả:

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