विफल हाइबरनेशन वेकअप से इन-मेमोरी पेज डेटा पुनर्प्राप्त करें

Question

हाइबरनेटेड फ़ाइल से पुनर्स्थापित करने का प्रयास करते समय मेरी प्रेमिका की मैकबुक दुर्घटनाग्रस्त हो गई। प्रगति बार ~ 10% पर बंद हो गया, जिसके बाद हमने कंप्यूटर को एक सामान्य स्टार्टअप के लिए फिर से शुरू किया।

इस हाइबरनेट की गई मेमोरी इमेज में पेज में एक सहेजा हुआ दस्तावेज़ खुला था, जिसे हम पुनर्प्राप्त करना चाहते हैं। वहाँ एक sleepimageहै /private/var/vm, जो मुझे लगता है कि हाइबरनेट छवि है जो कभी भी सही ढंग से बहाल नहीं हुई है। हमने इसे जीवित रखने के लिए इस चीज़ का समर्थन किया।

हमने कोशिश की strings sleepimage | grep known_substringलेकिन यह कुछ नहीं लौटा। grep -a known_substring sleepimageमैंने भी कुछ नहीं किया, इसलिए मैं यह मान रहा हूं कि पृष्ठ ने पाठ डेटा को सादे पाठ के रूप में स्मृति में नहीं रखा है।

संपादित करें: बाइनरी grep पर इस उत्तर को पढ़ने के बाद perl -ln0777e 'print unpack("H*",$1), "\n", pos() while /(null_padded_substring)/g' sleepimage, मैंने फिर से फलहीन होने की कोशिश की । मैंने इसे UTF-8 पाठ के लिए एक मैच का प्रयास करने के लिए नल के साथ गद्देदार किया। फिर मैंने .*प्रत्येक पात्र के बीच ग्लब्स के साथ कोशिश की- फिर भी कोई पासा नहीं।

इसलिए पेज संभवतः मेमोरी में किसी भी सामान्य एन्कोडिंग द्वारा टेक्स्ट को स्टोर नहीं करते हैं। मुझे ASCII स्ट्रिंग और पेज डेटा प्रतिनिधित्व के बीच एक अनुवाद नियम खोजने की आवश्यकता होगी - मैं सोच रहा हूं कि शायद किसी प्रकार का उद्देश्य सी स्ट्रिंग बफर है। मेरे लिए वर्णों के अनुक्रम के अलावा किसी अन्य चीज़ के रूप में वर्ण डेटा संग्रहीत करना बहुत अजीब लगता है, लेकिन ऐसा लगता है कि पृष्ठ क्या कर रहे हैं।

यदि आपके पास पेज के अंदर पाठ के इन-मेमोरी प्रतिनिधित्व का पता लगाने का कोई तरीका है, तो यह इस समस्या को हल करने में बहुत मददगार हो सकता है। शायद मैं प्रक्रिया मेमोरी को कुछ सरल तरीके से डंप और पढ़ सकता हूं?

एक और संभावित समाधान सरल है - मैं मान रहा हूं कि कंप्यूटर को इस से रिबूट करना किसी भी तरह संभव है sleepimage, लेकिन मुझे कोई दस्तावेज नहीं मिल सकता है कि आप इसके साथ कैसे आगे बढ़ेंगे। कुछ अन्य उपयोगकर्ताओं ( macrumors ) को इसका सामना करना पड़ा लगता है, लेकिन सभी फ़ोरम प्रश्नों के लिए, जिनमें से किसी का भी जवाब नहीं है।

ओएस एक्स संस्करण स्नो लेपर्ड है, 10.6.8।

प्रोग्रामिंग से जुड़े जटिल सुझावों का स्वागत है। मैं सी और पायथन करता हूं।

धन्यवाद।

Comments

उम्मीद है कि आपने उस फ़ाइल की एक प्रतिलिपि बनाई थी ताकि आप एक नए स्लीमेज की जांच न करें जो रिबूट के बाद लिखा गया था। तब आप अधिकतम मुक्त रैम के साथ स्थिति (क्रैश के बिना) को फिर से बनाना चाहते हैं - यानी केवल पृष्ठ खोलें एक अद्वितीय पाठ लिखें और ओएस को एक नई नींद लिखने दें; और फिर अपने अनूठे पाठ के लिए उसकी जांच शुरू करें।

— २०:२० पर

@ हिंसात्मक हाँ, सभी परीक्षणों की एक प्रति पर प्रदर्शन किया जाता है sleepimage। अद्वितीय टेक्स्ट की तलाश में एक और छवि के माध्यम से स्थानांतरण करना उतना ही मुश्किल होगा, क्योंकि छवि अभी भी 4GB आकार में होगी, और पेज मेमोरी ब्लॉक को उस फ़ाइल में कहीं यादृच्छिक रूप से आवंटित किया जाएगा। मुझे लगता है कि मैं राम को शून्य कर सकता हूं, फिर खुले पृष्ठ, और फिर नींद में गैर-शून्य दृश्यों की तलाश कर सकता हूं, हालांकि। लेकिन पेज 200 एमबी मेमोरी खा जाते हैं, भले ही - अभी भी एक छोटी सी सुई हैस्टैक में।

— सप्त २ s

आपका पाठ प्रत्येक वर्ण के बीच 0x00 के साथ संग्रहीत है, इसलिए आपको उसके लिए या इस स्ट्रिंग के लिए खोजना होगा: loobsdpkdbik; नीचे मेरा उत्तर भी देखें

— आइओस्मिट

क्या आपके पास टाइम मशीन बैकअप नहीं होने पर भी पृष्ठों को डिफ़ॉल्ट रूप से चालू नहीं किया जाता है (मोबाइल बैकअप के लिए देखें जहां सिस्टम बैकअप ड्राइव से जुड़े बिना भी चीजों को बैक करता है)? क्या आपने स्लीप इमेज फाइल फॉर्मेट पर फॉरेंसिक विश्लेषण किए बिना फाइल को वापस पाने के आसान तरीकों से इंकार किया है? (कोई फर्क नहीं पड़ता कि कैसे भयानक अगर आप इसे हटा हो जाएगा;)

— bmike

@bmike वर्जन केवल लायन के साथ आया था लेकिन वह मशीन स्नो लेपर्ड (10.6.8) पर है और मुझे याद है कि SL पर iWork के दुर्घटनाग्रस्त होने और ऑटो-सेव न होने की वजह से काफी काम खो रहा है ...

— iolsmit

Answer 1

तस्वीरों के साथ अपडेट करें:

• उस loobsdpkdbikपहचानकर्ता ने पहले उल्लेख किया है, एक नहीं है - बस अपने पाठ से पहले होने की ख़ुशी में मुट्ठी भर समय मैंने कोशिश की।

• पाठ का हिस्सा "खो" (एक निरंतर मेमोरी स्ट्रेच में सहेजा नहीं गया) प्राप्त करने के लिए लगता है और यह रैम उपयोग के साथ खराब हो सकता है

• आप नींद से सार्थक पाठ को पुनर्प्राप्त करने में सक्षम नहीं हो सकते हैं

अब मेरा मूल पाठ (1 पैराग्राफ में टाइपो के साथ, श्री मैटिस को भेजें):

छिपे हुए रत्न: 1953 में फिलिप जॉनसन द्वारा डिजाइन किए गए MoMa's Abby Aldrich Rockefeller Sculpture Garden, एक शानदार शहरी नखलिस्तान है, जहां इसके परावर्तक पूल और सुंदर लैंडस्केपिंग हैं। यह बाहरी गैलरी बाहरी मूर्तिकला के बदलते डिस्प्ले के साथ स्थापित की गई है, जिसमें अरिस्टाइड मैयोल, अलेक्जेंडर काल्डर, हेनरी माइसे, पाब्लो पिकासो और रिचर्ड सेरा द्वारा काम शामिल है।

MoMa में नई पेंटिंग और मूर्तिकला दीर्घाओं का दौरा करते समय, हेनरी मैटिस की खुशी और ऊर्जा, नृत्य (1909) की स्मारकीय छवि को देखने के लिए आगे और पांचवीं मंजिलों को पार करते हुए सीढ़ी को पार करना सुनिश्चित करें। पेंटिंग का मूल रूप से मॉस्को में एक रूसी महल के सीढ़ी हॉल में लटका हुआ था।

और बरामद पाठ:

छिपे हुए रत्न: मा एबी एबी एल्डरिक रॉकलर स्कल्पर जीएन, फिलिप जॉन 1953 द्वारा desigd, शानदार ursithtseflecting पूल ऑटिफ़िलस्पेंडग है। यह बाहरी गैलरी आउटडोर स्कल्पर के बदलते डिस्प्ले के साथ है, जिसमें वर्कबाय अरिस्टाइड मैयोल, अलेक्जेंडर काल्डर, हेनरी माइसे, पाब्लोइकासो, एचर्ड सी शामिल हैं।

मा पर नए पेंटग मूर्तिकला दीर्घाओं को घुमाते समय, यह सुनिश्चित करना चाहिए कि आगे पीछे fth flrsn ordeto s Henri Matse s mtal imagof आनंद और आंख, Dan (19) को देखते हुए t stase का पता लगाएं। पेंटिंग वियोरिनली रूप से रुपी महल मॉस्को के hg t सीढ़ी हॉल में प्रवेश करती है।

और स्क्रीन-शॉट्स:

---

ऐसा लगता है कि एक (सहेजे गए) पेज दस्तावेज़ के लिए (लगभग) अपने पाठ में सभी पात्रों से अलग होते हैं 0x00स्मृति में - इस प्रकार STRINGहो जाता है S.T.R.I.N.Gके साथ .किया जा रहा है 0x00। तो आपको या तो उसको खोजना होगा; मैं एक ग्राफिकल फ्रंट-एंड के लिए 0xED की सिफारिश कर सकता हूं … ..जिसके लिए आप एक खोजकर्ता के लिए (जिसका हिस्सा लगता है) खोजते हैं loobsdpkdbik, जो पाठ से पहले 5 बाइट्स (कम से कम केवल एक मामले में) आता है।

Comments

हम्म, मैंने "loobsdpkdbik" की खोज की, लेकिन अभी भी खाली है। क्या यह पहचानकर्ता बिना सहेजे गए दस्तावेज़ के प्रत्येक संस्करण से पहले दिखाई दिया था? हो सकता है कि यह दस्तावेज़ के बारे में कुछ संकेत देता हो - जैसे विंडो इनहेरिटेंस, डिफ़ॉल्ट फॉन्ट, आदि ... मैंने पहले-पहले पर्ल का उपयोग करके एक अशक्त-गद्देदार स्ट्रिंग की खोज की, अर्थात s\0u\0b\0s\0t\0r\0i\0n\0g, काम नहीं किया, अधिक विवरण मेरे मूल प्रश्न में है। ओह - आपको यह कैसे पता चला?

— सप्त

@sapht मैंने अपना उत्तर अपडेट किया; ऐसा लगता है कि पाठ स्मृति में एक निरंतर खिंचाव में संग्रहीत नहीं है, जिससे नींद से उबरना असंभव हो सकता है। और यह कि "loobsdpkdbik" पृष्ठ दस्तावेज़ से संबंधित नहीं है, बस मेरे पाठ से पहले होने के लिए खुश है।

— आईपीएस

हो सकता है कि विकल्पहीनता तब बंद स्मृति के गूंगे शब्दों में से थी। मुझे अभी भी नींद में कोई डेटा नहीं मिला है, लेकिन हमें बस सही विकल्प के लिए खोज करना होगा। या मेमोरी ब्लॉक कभी नहीं लिखा गया था। नींद की जांच के लिए अच्छा काम, धन्यवाद।

— सैपहट

@sapht यदि आपकी नींद पूरी नहीं होती है तो उसमें पेज डॉक्यूमेंट का पूरा टेक्स्ट होना चाहिए - क्योंकि रैम को रीस्टोर करने से यह लग जाएगा कि यह सिस्टम हाइबरनेट कब हुआ था। मैं एक वर्चुअल मशीन में स्लीपइमेज को आज़माने की सलाह दूंगा: वर्चुअल मशीन में किसी भी समर्थित ओएस एक्स को स्थापित करें (या वीएम फ्यूजन 4.1 का उपयोग करें ?) - फिर अपनी मशीन को वर्चुअल एचडीडी पर क्लोन करें और स्लीपिमेज से बूट करने का प्रयास करें।

— ३२ पर olsmit

Answer 2

पहले प्रयास करें, अगर IF_string WAS सादे पाठ में संग्रहीत है (मामला नहीं)

मुझे लगता है कि आप उपयोग करने की कोशिश कर सकते हैं

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

उस से, -U पैरामीटर बाइनरी फ़ाइलों पर खोज निर्दिष्ट करता है, -b निर्दिष्ट करता है कि बाइट्स में ऑफसेट मिलान वाले भाग को प्रदर्शित किया जाना चाहिए और, अंत में, -o निर्दिष्ट करता है कि केवल मिलान वाला भाग मुद्रित किया जाना चाहिए।

यदि वह काम करता है, तो आप उस क्षेत्र में जाने के लिए बाइट्स में ऑफसेट को जानते होंगे, लेकिन मुझे नहीं पता कि वहां कैसे आगे बढ़ना है। फ़िलाटाइप के आधार पर, आप संभवतः सूचित किए गए ऑफ़सेट के पास फ़िलाटाइप हस्ताक्षर की जांच कर सकते हैं और केवल उस बाइट को अलग करने की कोशिश कर सकते हैं जो उस फ़ाइल का हिस्सा बनाते हैं। इसके लिए, मुझे लगता है कि आप या तो ऐसा करने के लिए एक सी प्रोग्राम लिख सकते हैं, या हो सकता है निष्पादित करें hexdump -s known_offset sleepimageऔर केवल उन बाइट्स को प्राप्त करने का प्रयास करें जो आपकी ज़रूरत की फ़ाइल से संबंधित हैं।

उदाहरण के लिए, मान लीजिए कि मैं क्रोम के बारे में कुछ जानना चाहता था:

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

तो मुझे पता है कि मुझे बाइट ऑफसेट 3775011731 पर क्रोम की घटना मिली। इसलिए मैं यह कर सकता था:

$ 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

मुश्किल हिस्सा आप चाहते हैं केवल बाइट्स प्राप्त करने के लिए होगा। यदि फ़िलाटाइप में एक ज्ञात हेडर है, तो आप हेक्सडम्प ऑफ़सेट से हेडर के आकार को बाइट्स में घटा सकते हैं, इसलिए आपको फ़ाइल "शुरुआत से ही" मिल जाएगी। यदि फ़िलाटाइप में एक "EOF" हस्ताक्षर है, तो आप इसे भी खोज सकते हैं और इसलिए उस बिंदु तक केवल बाइट्स प्राप्त कर सकते हैं।

आपका फिलाटाइप क्या है? क्या आपको लगता है कि आपके मामले में इस तरह की कुछ प्रक्रिया का इस्तेमाल किया जा सकता है? ध्यान दें कि मैंने पहले कभी ऐसा नहीं किया है, और मैं खुद को बहुत सारे "अनुमान" पर आधारित कर रहा हूं, लेकिन मुझे लगता है कि इस तरह से काम करने का थोड़ा मौका है।

दूसरा प्रयास, सभी बाइट्स को पार्स करने के लिए एक धीमी विधि

इससे पहले की विधि काम नहीं करती है क्योंकि यह केवल सादे पाठ, मेरी शर्त के लिए खोज करती है। इस दूसरे पाठ के लिए मैंने एक सरल सी प्रोग्राम बनाया है:

#include <stdio.h>

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

इसलिए मैं "अस्सिम" की खोज कर सकता था, जो उस पाठ में आपका ज्ञात_स्ट्रीमिंग होगा। यह जानने के लिए कि मैंने क्या खोज किया था:

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

इसलिए, मुझे "61 73 73 69 6 डी" खोजना होगा। उस सरल सी स्रोत को "tt" प्रोग्राम में संकलित करने के बाद, मैंने निम्नलिखित कार्य किया:

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

जो मेरे पास लौटा:

यदि आपने ऐसा कुछ किया है, तो मुझे लगता है कि आप अपना डेटा प्राप्त कर सकते हैं .. हालांकि यह धीमी गति से 2 ~ 8GB बाइट्स के बराबर होगा ...

ध्यान दें कि इस दृष्टिकोण में आपको कैपिटल लेटर में हेक्स ढूंढना होगा (अंतिम grep पर 6d के बजाय 6D लिखें), अंडर-केस लेटर्स में नहीं, और व्हाइट-स्पेस के बजाय \ n का उपयोग करें (ताकि आप-और का उपयोग कर सकें बी grep के लिए)। आप उपयोग कर सकते हैं grep -iइसलिए यह केस-असंवेदनशील हो गया, लेकिन यह थोड़ा धीमा होगा। इसलिए, यदि यह उपयोग किया जाता है तो केवल राजधानियों का उपयोग करें।

या, यदि आप सभी स्वचालित "स्क्रिप्ट" चाहते हैं:

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

Comments

पाठ केवल मेमोरी में संग्रहीत है, क्योंकि फ़ाइल को कभी भी सहेजा नहीं गया था। इसलिए कोई वास्तविक फ़ाइल प्रकार नहीं है, केवल उस प्रकार का प्रतिनिधित्व जो पृष्ठ डेटा के लिए आंतरिक रूप से रख रहा है। पास -Uकरने grepसे बहुत अंतर नहीं लगता ( aकम है --binary-files=text)। यदि मेरे पास बाइट ऑफसेट होता, तो मैं निश्चित रूप से आगे बढ़ सकता था, लेकिन या तो फ़ाइल भ्रष्ट है, या पेज डेटा को कुछ गैर-एएससीआईआई तरीके से संग्रहीत कर रहे हैं। शायद UTF-8, लेकिन grepएक मैच चरित्र के लिए अशक्त बाइट्स स्वीकार नहीं करेंगे।

— सपथ

मैंने एक और कोशिश के साथ पोस्ट को संपादित किया .. यह काम करने के लिए लगता है .. लेकिन वास्तव में धीमा है और आपको "अनुमान" करना होगा कि ज्ञात_स्ट्रीमिंग की घटना से पहले और बाद में आपको कितने बाइट्स चाहिए। नोट: जब मुझे echo -n "assim" | hexdumpयूटीएफ -8 एन्कोडिंग के लिए हेक्सडंप मिल जाता है, तो आप echo -n "assim" | iconv -t UTF-16 | hexdumpअन्य एनकोडिंग के लिए प्रयास कर सकते हैं , इस मामले में यूटीएफ -16, मेरे पास कोई Idead नहीं है कि यह मेमोरी पर कैसे संग्रहीत किया जाता है .. लेकिन मेरे मामले में इसे संग्रहीत किया गया था UTF-8 के रूप में वास्तव में :)

— फर्नांडो

हम्म, ठीक है, आपके सी कार्यक्रम के लिए हेक्स डंप पाठ को प्रिंट करता है क्योंकि यह वास्तव में बाइनरी में संलग्न है - जीसी इस तरह से संकलित करता है ताकि सभी स्थिर चरित्र बफ़र्स को स्मृति में संदर्भ के लिए प्रोग्राम में ही संग्रहीत किया जाए। लेकिन पेज के लिए कि डेटा रनटी ई पर बनाया गया था। मैंने अपने जवाब को एक नए मैच के साथ अद्यतन किया, जिसे मैंने पर्ल के माध्यम से आज़माया, जो कि बेकार था, इसलिए मुझे पूरा यकीन है कि पाठ कुछ अजीब गैर-मानक तरीके से संग्रहीत है, क्योंकि ASCII बाइट्स भी समान नहीं हैं। शायद कुछ वस्तुनिष्ठ सी स्ट्रिंग बफर ...

— सप्त २ objective'१२ को २१:०२

हम्म .. अगर आपने स्ट्रिंग "Pages.app" के बजाय खोजने की कोशिश की तो क्या होगा? मुझे नहीं पता होगा कि अगर कुछ भी पाया गया था तो वहां से कैसे आगे बढ़ना है (जैसे कि, ऐप का क्या है और आपका दस्तावेज़ क्या है?), लेकिन अगर हम इस विचार की ट्रेन को रखने के लिए थे, तो यह एक कोशिश की शुरुआत हो सकती है। यद्यपि मुझे यह स्वीकार करना चाहिए कि आसान विकल्प होने चाहिए, यह एक बहुत ही श्रमसाध्य होगा

— फर्नांडो

दरअसल, क्या आपको उस पेपर फाइल के टुकड़े याद हैं? भले ही यह मेमोरी पर संग्रहीत किया गया था, अगर आपको कुछ सटीक वाक्य पता हैं जो वहां लिखे गए थे (यदि आपको याद है या यदि आपके पास फ़ाइल का पिछला संस्करण है), तो आप सीधे इनके लिए खोज करने का प्रयास कर सकते हैं! यह बहुत आसान होगा, मुझे लगता है :) और जैसा कि पेज एक शब्द संपादन कार्यक्रम है, मुझे लगता है कि आप जो लिखा गया था उसे ठीक करना चाहते हैं? यदि ऐसा है, तो मेटा जानकारी के बजाय सामग्री की खोज करें, यह आसान हो सकता है .. मुझे उम्मीद है, कम से कम ..

— फर्नांडो