ฉันจะถ่ายโอนข้อมูลหน่วยความจำระบบเต็มได้อย่างไร

หลังจากเริ่ม VirtualBox คอมพิวเตอร์เริ่มทำงานช้าลงและหยุดทำงานอย่างสมบูรณ์เนื่องจาก OOM โดยปกติแล้ว OOM ควรเริ่มต้นกระบวนการฆ่าเพื่อเพิ่มพื้นที่ว่าง แต่สิ่งนี้ไม่ได้เกิดขึ้น (นี่เป็นครั้งที่สองที่ฉันมีประสบการณ์นี้)

ฉันมีบางงานที่สำคัญยังไม่ได้บันทึกในโปรแกรมแก้ไขข้อความดังนั้นผมหวังที่จะพบว่ามันกลับมาอยู่ในแรมระบบหลังจากที่ฆ่ากระบวนการทั้งหมดในคอนโซลปัจจุบันใช้+SysRq Kเครื่องดังกล่าวเป็นแล็ปท็อปที่มี 8 GiB RAM ใช้ Linux x86_64 3.7.5 พร้อม SSD เป็นดิสก์เป้าหมาย

ความพยายามครั้งแรกของฉันคือdd if=/dev/mem of=memoryแต่สิ่งนี้ล้มเหลวหลังจากอ่านข้อมูล 1MiB ต่อไปฉันลองdd if=/dev/fmem of=memory bs=1Mแต่สิ่งนี้หยุดลงหลังจากอ่าน 3010461696 ไบต์ (ตรง 2871 MiB) หลังจากดูที่/proc/mtrr(แสดงด้านล่าง) skip=4096ฉันตัดสินใจที่จะลองเพิ่ม ในที่สุดสิ่งนี้ก็ช้าลงโดยการอ่านด้วยความเร็วเพียง 3 MiB / วินาทีดังนั้นฉันจึงขัดจังหวะ (ให้ไฟล์ 5.8 GiB) (อย่างน้อย 100 MiB ล่าสุดของไฟล์มีFFs)

reg01: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg05: base=0x23c000000 ( 9152MB), size=   64MB, count=1: uncachable
reg06: base=0x0b4000000 ( 2880MB), size=   64MB, count=1: uncachable
reg07: base=0x0b8000000 ( 2944MB), size=  128MB, count=1: uncachable

ฉันไม่พบข้อมูลที่ฉันเปิดมาเป็นเวลาหลายชั่วโมงในเท็กซ์เอดิเตอร์ดังนั้นฉันเชื่อว่าฉันได้ข้ามหน่วยความจำบางส่วนขณะทำการดัมพ์ ดังนั้นด้วยเป้าหมายของฉัน (การกู้คืนข้อมูลจากโปรแกรม userspace) วิธีที่มีประสิทธิภาพที่สุดในการถ่ายโอนข้อมูลหน่วยความจำระบบไปยังไฟล์คืออะไร? มีประเด็นอะไรบ้างที่ต้องพิจารณาขณะทำการดัมพ์

memory data-recovery ram

— Lekensteyn
แหล่งที่มา

คุณเคยลอง / proc / kmem ด้วยหรือไม่? มันไม่คุ้มค่ามากนักเพราะมันเปลี่ยนแปลงในขณะที่คุณกำลังคัดลอก

— ott--

@ ott-- CONFIG_DEVKMEMถูกปิดการใช้งานโดยดูที่ซอร์สโค้ดซึ่งดูเหมือนว่าจะอนุญาตการเข้าถึงแบบไม่ จำกัด แต่ฉันก็ยังไม่มั่นใจว่านี่เป็นวิธีที่ดีที่สุดในการทำ (การเข้าถึง IO mem?)

— Lekensteyn

บางทีคุณอาจได้รับหน่วยความจำของตัวแก้ไข แต่คุณจำไม่ได้ การสร้างโครงสร้างข้อมูลใหม่จากการถ่ายโอนข้อมูลหน่วยความจำอาจเป็นเรื่องยาก สิ่งแรกที่คุณต้องทำคือสร้างการแมปหน่วยความจำใหม่จากโครงสร้างข้อมูลเคอร์เนล (อาจมีเครื่องมือทางนิติวิทยาศาสตร์ที่มีอยู่แล้ว) เพื่อรับหน่วยความจำเสมือนของกระบวนการที่คุณสนใจ (ซึ่งน่าจะเป็น แพร่กระจายไปทั่วหน้า disjoint 4kB จำนวนมากในหน่วยความจำกายภาพ) จากนั้นข้อความอาจไม่อยู่ในหยดเดียวติดต่อกันและอาจใช้ UCS4 หรือการรับรองอื่นและอาจจัดเก็บบรรทัดหรือบล็อกอื่น ๆ ในกลุ่มแยกต่างหาก

— Gilles 'หยุดชั่วร้าย'

@Gilles +1 เมื่อกระบวนการหยุดทำงานฉันคาดว่าเคอร์เนลจะปล่อยตัวอธิบายงาน -> ลืมทั้งหมดเกี่ยวกับการแมปพื้นที่ที่อยู่ สำหรับการแสดงข้อมูลมันสามารถเป็นต้นไม้ได้ (โดยมีโชคที่จัดสรรโดย JVM :)

— เตอร์

ดังนั้นคุณจะขุดผ่านกิกะไบต์ของข้อมูลเพื่อค้นหาข้อความบางส่วนที่อาจไม่ได้อยู่ที่นั่น? เข็มพบกองหญ้า ในเวลาที่คุณใช้ไปกับสิ่งนี้คุณสามารถพิมพ์ข้อความซ้ำได้ หากมีสิ่งนั้นมากในตอนแรกคุณควรตรวจสอบให้แน่ใจว่าเครื่องมือแก้ไขข้อความของคุณได้รับการกำหนดค่าให้บันทึกข้อมูลสำรองเป็นระยะเพื่อให้คุณไม่สูญเสียมากหากเกิดปัญหา

— psusi

คำตอบ:

ตรวจสอบโครงการนี้: foriana

Foriana คือ (FOrensic Ram Image ANAlyzer)

อินพุต: ดัมพ์ของเอาต์พุต RAM (ฟิสิคัล): ข้อมูลต่างๆ

เวอร์ชัน 1.0 สามารถแสดงรายการกระบวนการและโมดูลจากการถ่ายโอนข้อมูลหน่วยความจำของเมล็ด i386 / x86_64 / arm linux / bsd และให้ตัวเลือกสำหรับการอ่านหน่วยความจำเชิงเส้นจากการทิ้ง

มีโมดูลเคอร์เนล fmem:

Fmem เป็นไดรเวอร์เคอร์เนลที่สร้าง / dev / fmem อุปกรณ์ / dev / fmem ทำงานในลักษณะเดียวกับที่ / dev / mem (เข้าถึงโดยตรงไปยังหน่วยความจำกายภาพ) แต่ไม่มีข้อ จำกัด ที่ / dev / mem มี เป็นไปได้ที่จะดัมพ์หน่วยความจำฟิสิคัลทั้งหมดผ่าน / dev / fmem

ฉันใช้มันเรียบง่ายมาก

— stackterminator
แหล่งที่มา

ผู้/dev/fmemถามพยายาม

— Tobu

คุณอาจต้องการใช้ddrescueหรือโปรแกรมที่คล้ายกันซึ่งสามารถข้ามข้อมูลที่ไม่สามารถเข้าถึงได้ dd conv=noerrorอาจเป็นประโยชน์เช่นกัน นอกจากนี้ยังตรวจสอบเรื่องนี้คำถามเกี่ยวกับ superuser

สิ่งที่สำคัญกว่านั้นคือถ้าคุณเข้าสู่สถานการณ์ OOM ความเกียจคร้านอาจเกิดจากเคอร์เนลที่สลับหน้าจากสิ่งอื่นนอกเหนือจากแอปพลิเคชันที่ร้องขอ ดังนั้นหากคุณต้องการข้อมูลของคุณให้ตรวจสอบการสลับแทน/dev/mem- โอกาสที่มันจะอยู่ที่นั่น ในทำนองเดียวกันถ้านักฆ่า OOM ไม่เตะและคุณฆ่ากระบวนการด้วยมือเมื่อตัวแก้ไขของคุณถูกฆ่าก่อนกระบวนการหิวหน่วยความจำอาจยังคงเกิดขึ้นเพื่อให้ได้เวลาในการคว้าหน้าเหล่านั้น

ดังกล่าวโดยกิลส์ในความคิดเห็นของข้อมูลที่สามารถจะอยู่ในโครงสร้างพิเศษบางอย่างดังนั้นคุณจะไม่สามารถที่จะพบพวกเขาได้อย่างง่ายดายแม้ว่าคุณจะจัดการเพื่อสร้างการแมปพื้นที่ที่อยู่ในกระบวนการฆ่าของและมีโชคพอที่จะหาทั้งหมดของที่จำเป็น หน้ายังคงเหมือนเดิม

— peterph
แหล่งที่มา

ฉันเคยเห็นคำตอบของ SU มาก่อนนั่นคือวิธีที่ฉันพบ fmem ddrescueจะไม่ช่วยฉันตั้งแต่ 256 หน้า (1 MiB) เป็นขีด จำกัด ฮาร์ดโค้ด ฉันคาดหวังว่าจะได้รับเงื่อนไขของ OOM แต่นักฆ่า OOM ไม่ได้เตะ ( pastebin.com/DvYTCcRK ) หนึ่งสัปดาห์ที่ผ่านมาฉันมีปัญหาเดียวกัน (ยัง Linux 3.7.5 ฉันไม่ได้รีบูตเครื่องเท่านั้นที่จะ ram) ไม่มีไฟล์สลับ / พาร์ติชั่นตั้งแต่ฉันมี SSD (swappiness = 60 (ค่าเริ่มต้น))

— Lekensteyn