inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux ใช้เซิร์ฟเวอร์สัญลักษณ์สำหรับการแก้ไขประเภท มันใช้งานได้ ;)
ลองดูรุ่น inVteroCore เพื่อความสมบูรณ์สำหรับ XEN และ VMWare บน Linux (หรือที่ใดก็ตามที่ CORECLR รัน, OSX และ FBSD)
##$ สำคัญ (ผู้ใช้ Windows บน .NET) => คุณต้องลงทะเบียน msdia140.dll "cmd /c regsvr32 msdia140.dll" (ดู zip)
ไม่จำเป็นต้องกำหนดค่าใด ๆ การพิมพ์แบบไดนามิก / เป็ดอย่างสมบูรณ์
UI ใหม่สำหรับรูปแบบที่รองรับการแก้ไขหน่วยความจำ (dis/assemble และ patch) ใช้ "Loader()" บนอินสแตนซ์ vtero เช่น;
Loader(test(MemList))
เปลี่ยนสตริง MemoryDump เพื่อชี้ไปที่การถ่ายโอนข้อมูลหน่วยความจำ ตัวอย่างการเดินดัมพ์หน่วยความจำและพิมพ์คำอธิบายระบบใน analyse.py ดูที่ WalkProcListExample()
quickdumps
>>> MemList = [ "c:\temp\win10.64.xendump" ]
>>> test(MemList)
++++++++++++++++++++++++++++++ ANALYZING INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
PART RUNTIME: 00:00:08.5211677 (seconds), INPUT DUMP SIZE: 4,303,692,448.00 bytes.
SPEED: 466,980 KB / second (all phases aggregate time)
++++++++++++++++++++++++++++++ DONE WITH INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
>>> Loader(vtero)
ค้นหา/แยกกระบวนการ ไฮเปอร์ไวเซอร์ (รวมถึงการซ้อน) ในการถ่ายโอนข้อมูลหน่วยความจำโดยใช้เทคนิค Virtual Machine Introspection ที่ไม่ขึ้นกับสถาปัตยกรรมไมโคร เครื่องมือวิเคราะห์หน่วยความจำกายภาพประสิทธิภาพสูงแบบหลายสถาปัตยกรรมข้ามแพลตฟอร์ม
| x64 ปล่อย |
|---|
Quickdumps เป็นตัวอย่างของการใช้ inVtero.net API เพื่อแยกและตรวจสอบความถูกต้องของหน่วยความจำกายภาพ
วิธีที่เราเริ่มต้นการแปลที่อยู่เสมือนเป็นที่อยู่ทางกายภาพ ไม่มีการพึ่งพารูปแบบไฟล์อินพุต .DMP, .RAW, .DD ใดๆ ก็น่าจะใช้ได้ โชคไม่ดีที่รูปแบบการจับภาพพื้นฐานใช้รูปแบบการจัดเก็บขอบเขตบางรูปแบบ (เช่น ไม่ใช้พื้นที่จัดเก็บจริงสำหรับหน้า NULL หรือไม่แสดง) ระยะทางของคุณอาจแตกต่างกันไป มีเครื่องมือมากมายสำหรับการแปลงดัมพ์หน่วยความจำ ความผันผวน - rekal เป็นจุดเริ่มต้นที่ดี บิตแมป ไฟล์ DMP อยู่ในสิ่งที่ต้องทำเพื่อทำให้การวิเคราะห์ของ Liveump ง่ายขึ้น (ขณะนี้สิ่งต่างๆ จะทำงานได้ดีที่สุดหากคุณสร้างหน้าจอสีน้ำเงินที่เริ่มต้นด้วยตนเองโดยกำหนดค่าดัมพ์ทั้งหมด หรือใช้เครื่องมือประเภท raw dd ของบุคคลที่สาม)
มีการใช้แนวคิดหลายประการเพื่อให้แน่ใจว่าเราจะโต้ตอบกับผู้ใช้เมื่อจำเป็นเท่านั้น ในทำนองเดียวกัน สำหรับโปรเจ็กต์ Actaeon github @eurecom-s3/actaeon เป้าหมายหลักคือการค้นหาและใช้ประโยชน์จากเพจ VMCS เพื่อค้นหา EPTP (ตัวชี้ตารางเพจแบบขยาย) ที่กำหนดค่าไว้ ซึ่งจำเป็นในการค้นหาเพจฟิสิคัลที่เป็นของ อินสแตนซ์ OS ของแขก Google @google/rekall rekal ต่อมาได้ปรับใช้การใช้งานที่กว้างขวางมากขึ้น ซึ่งต้องการให้ผู้ใช้เรียกใช้โมดูลเคอร์เนล Linux บนระบบที่มีการถ่ายโอนข้อมูลหน่วยความจำที่กำหนดซึ่งมีจุดประสงค์เพื่อสร้างโปรไฟล์พิเศษที่สามารถใช้เพื่อนำเข้าสู่ rekal ท้องถิ่น โปรไฟล์ซึ่งจะช่วยให้คุณสามารถแยก/แยกหน่วยความจำของแขกออกจากการถ่ายโอนข้อมูลโฮสต์จริงได้
ในระหว่าง CanSecWest/DC22 ฉันนำเสนอเทคนิคคุณภาพสูง (ตามการโต้ตอบของเลเยอร์ต่ำสุดระหว่างเลเยอร์ CPU และ OS มม.) เพื่อระบุกระบวนการใด ๆ ที่ทำงานบนระบบโดยการตรวจสอบสแนปช็อตของหน่วยความจำกายภาพ กลไกนี้ขึ้นอยู่กับสิ่งที่เรียกว่าตัวชี้ตัวเอง (Windows) หรือตัวชี้ไดเรกทอรีหน้าแบบเรียกซ้ำ (*BSD) ที่คาดว่าจะพบได้เสมอ (เว้นแต่ระบบ Windows ของคุณจะมีการแก้ไข/แพตช์ mm อย่างมาก หรือเพียงแค่เคอร์เนลที่กำหนดเองสำหรับ * บีเอสดี) ผลลัพธ์สุทธิคือเราทราบค่ารีจิสเตอร์ CR3 ที่กำหนดทั้งหมด เนื่องจาก VMCS มีค่า CR3 ที่ทราบอย่างน้อย 1 ค่า (ค่าที่สองอาจถูกจำลองหรือแมปใหม่แบบไดนามิก) เราจึงมั่นใจว่าสามารถถ่ายโอนข้อมูลหน่วยความจำแบบครอบคลุมได้โดยไม่ต้องรู้อะไรเกี่ยวกับเวอร์ชันของระบบปฏิบัติการพื้นฐาน (เช่น XP(64bit)->Win2016 เป็น สอดคล้องกัน) หรือสถาปัตยกรรมไมโคร
การใช้กำลังดุร้ายจะชนะในตอนท้ายของวันเสมอ! หรืออย่างที่ฉันได้ยินมา... ไม่ว่าในกรณีใด หากพบการแมป VMCS ที่ไม่รู้จัก (ดัชนี EPTP) Quickdumps จะปล่อยชุดของค่า/ดัชนีที่เป็นไปได้ โดยปกติรายการจะมีขนาดเล็ก โดยมากสุด 10-20 รายการ คุณลักษณะที่กำลังจะเกิดขึ้นคือการพยายามโดยอัตโนมัติสำหรับแต่ละค่าที่เป็นไปได้จนกว่าจะพบค่าที่ 'ใช้งานได้' สิ่งนี้น่าจะทำให้แน่ใจได้ว่าเราจะทำงานกับสถาปัตยกรรมไมโคร CPU ที่กำลังจะมาถึงโดยไม่มีการเปลี่ยนแปลงโค้ดใดๆ (หรือฉันอาจจะตั้งค่าคลาสบางคลาสที่ระบุสิ่งเหล่านี้เพื่อทำให้ชีวิตง่ายขึ้น) ไม่ว่าจะด้วยวิธีใด การใช้กำลังอย่างดุร้ายควรจะค่อนข้างรวดเร็ว ฉันพยายามใช้ CPU แบบมัลติคอร์ให้เกิดประโยชน์สูงสุด ดังนั้น หากคุณมีคอร์เพิ่มเติม พวกเขาก็น่าจะได้ออกกำลังกายหากคุณวิเคราะห์ดัมพ์ขนาดใหญ่ด้วย VM จำนวนมาก
ตัวอย่างการเรียกใช้จากแล็ปท็อป:
Process CR3 [00000002DD41F000] File Offset [0000000293A12000] Diff [FFFFFFFFB65F3000] Type [Windows]
159 candiate process page tables. Time so far: 00:01:01.4826693, second pass starting. rate: 32588.149 MB/s
Hypervisor: VMCS revision field: 16384 [00004000] abort indicator: NO_ABORT [00000000]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [00000001262DA000]
[435][00000000006F0054]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001308D3000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000130AD1000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001314CF000]
[14][000000007433301E]
Hypervisor: VMCS revision field: 0 [00000000] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [0000000160643000]
[106][00000000001E001C]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000195922000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001959A3000]
[14][000000007433301E]
159 candiate VMCS pages. Time to process: 00:02:51.8973861
Data scanned: 34,171,150,654.00Second pass done. rate: 1277.967 MB/s▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
grouping and joinging all memory
Scanning for group correlations
MemberProces: Groupt 1 Type [Windows] Group Correlation [100.000 %] PID [1AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [16A0000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [1FCA000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [62AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [34CE8000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [37300000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [7DCC6000]
Finished Group 1 collected size 48 next group
Scanning for group correlations
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [65C8000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6B51000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6CC9000]
ในตัวอย่างข้างต้น EPTP ของ VMWARE อยู่ที่ดัชนี 14 ใน VMCS
* เราจะดูว่าฉันทำอันนี้สำเร็จหรือไม่ แต่ตอนนี้มันแค่ทิ้งหน่วยความจำเคอร์เนลจากแต่ละเลเยอร์เท่านั้น ทำงานบนพื้นที่ผู้ใช้จาก guest OS VM
มีสิ่งที่ต้องทำมากมาย แต่ฉันจะเพิ่มโดยเร็วที่สุด ปัญหาหลักในตอนนี้คือฉันลังเลจริงๆ ที่จะเพิ่มอะไรก็ตามที่มี OS มาให้ แม้ว่าจะช่วยได้มากก็ตาม ฉันคิดว่ามีบริบทที่เพียงพอเพื่อหลีกเลี่ยงการเพิ่มการพึ่งพาระบบปฏิบัติการแบบลอจิคัล ฉันชอบที่ Rekal ให้คำมั่นสัญญาในเรื่องนี้ แต่ดูเหมือนว่าคลังโปรไฟล์ของพวกเขาจะใหญ่มากเช่นกัน ดังนั้นจึงมีทั้งสองอย่างเล็กน้อย
ยังมีการทำความสะอาดอีกเล็กน้อยที่ต้องทำ นี่ยังคงเป็นอัลฟ่า แต่จะพัฒนาอย่างแข็งขัน
ขยายไปสู่ประเภท EPTP ที่เป็นที่รู้จักมากขึ้น ดังนั้นจึงไม่จำเป็นต้องใช้กำลังดุร้าย
จะสร้างดัชนีบิตแมป PFN เพื่อกำหนดการรันโดยอัตโนมัติ (ในปัจจุบัน หากคุณพยายามดัมพ์/ค้นหาสิ่งใดๆ หลังจากการรัน มันจะทำให้เกิดปัญหาหรือพลาดไป ฯลฯ จะเพิ่มสิ่งนี้ในครั้งต่อไปเพื่อให้แน่ใจว่าเราได้รับการดัมพ์แบบครอบคลุม 100% .
เพื่อละเว้นจากการใช้โครงสร้างเชิงตรรกะของ OS เพื่อรองรับการวิเคราะห์หน่วยความจำ มีแนวโน้มว่าโครงสร้างเลเยอร์ OS ข้อมูล โค้ด และอ็อบเจ็กต์ส่วนใหญ่อาจถูกจัดการโดยผู้โจมตีเพื่อชักนำความพยายามของนักวิเคราะห์ในทางที่ผิด
ฟังก์ชันการทำงานที่กำลังจะมีขึ้นเพื่อเรนเดอร์แผนที่ความสมบูรณ์สำหรับโค้ดเพจที่สามารถแมปกลับไปยังค่าแฮชของบล็อก/เพจที่ปลอดภัยด้วยการเข้ารหัส (เช่น SHA256 หรือ TIGER192) ผลลัพธ์ของเราระบุว่ามีอัตราการตรวจสอบก่อน win10 มากกว่า 99% หน่วยความจำชั่วคราวหลัง win10 สามารถตรวจสอบได้ 100% ซึ่งช่วยลดการคาดเดาและไม่ทราบสาเหตุเนื่องจากการจัดการ/การตรวจสอบ/การแยกชิ้นส่วนหน่วยความจำแบบแมนนวลแบบดั้งเดิม เมื่อพยายามตรวจจับ/วิเคราะห์อินพุตหลายกิกะไบต์
เอกสารประกอบ
การใช้งาน GUI
