inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux는 유형 확인을 위해 기호 서버를 사용합니다. 작동합니다. ;)
Linux(또는 CORECLR이 실행되는 모든 곳, OSX 및 FBSD)에서 XEN 및 VMWare에 대한 무결성을 제공하는 inVteroCore 릴리스를 확인하세요.
##$ 중요(.NET의 Windows 사용자) => msdia140.dll을 "cmd /c regsvr32 msdia140.dll"로 등록해야 합니다(zip 참조).
구성이 필요하지 않으며 완전히 동적/오리 타이핑
메모리 편집(분해/조립 및 패치)을 위한 새로운 UI가 지원되는 형식입니다. 다음과 같은 vtero 인스턴스에서 "Loader()"를 사용하십시오.
Loader(test(MemList))
메모리 덤프를 가리키도록 MemoryDump 문자열을 변경합니다. analyze.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 또는 NOT PRESENT 페이지에 대해 물리적 저장소를 사용하지 않는 경우) 마일리지가 달라질 수 있습니다. 메모리 덤프, 변동성 변환을 위한 많은 도구가 있습니다. rekal은 시작하기 좋은 곳입니다. 비트맵. liveump 분석을 더 쉽게 하기 위해 DMP 파일이 준비되어 있습니다(현재는 전체 덤프가 구성된 상태에서 수동으로 시작한 블루 스크린을 수행하거나 타사 원시 dd 유형 도구를 사용하는 경우 가장 잘 작동합니다).
필요한 경우에만 사용자와 상호 작용할 수 있도록 몇 가지 개념이 사용됩니다. 마찬가지로 Actaeon github 프로젝트 @eurecom-s3/actaeon의 주요 목표는 VMCS 페이지를 찾아 활용하여 구성된 EPTP(확장 페이지 테이블 포인터)를 찾는 것입니다. 게스트 OS 인스턴스. Google @google/rekall rekal은 이후에 사용자가 특정 메모리 덤프가 발생한 시스템에서 Linux 커널 모듈을 실행해야 하는 보다 광범위한 구현을 구현했습니다. 이는 로컬 rekal로 가져오는 데 사용할 수 있는 특수 프로필을 구성하기 위한 것입니다. 물리적 호스트 덤프에서 게스트 메모리를 분리/추출할 수 있는 프로필입니다.
CanSecWest/DC22에서는 물리적 메모리 스냅샷을 검사하여 시스템에서 실행 중인 모든 프로세스를 식별하는 고품질 기술(CPU와 OS mm 계층 간의 가장 낮은 계층 상호 작용 기반)을 제시했습니다. 이 메커니즘은 항상 발견될 것으로 예상되는 자체 포인터(Windows) 또는 재귀 페이지 디렉터리 포인터(*BSD)를 기반으로 합니다(Windows 시스템에 크게 수정/패치된 mm 또는 단순히 *용 사용자 정의 커널이 없는 경우). BSD). 이것의 최종 결과는 우리가 주어진 모든 CR3 레지스터 값을 알고 있다는 것입니다. VMCS에는 알려진 CR3 값이 하나 이상 포함되어 있으므로(두 번째 값은 에뮬레이트되거나 동적으로 다시 매핑될 수 있음) 기본 OS 버전(예: XP(64비트)->Win2016은 일관성) 또는 마이크로아키텍처.
결국에는 무차별 대입이 승리합니다! 아니면... 어쨌든 알 수 없는 VMCS 매핑(EPTP 인덱스)이 발견되면 퀵 덤프는 가능한 값/인덱스 세트를 내보냅니다. 목록은 일반적으로 작으며 최대 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]
위의 예에서 VMWARE의 EPTP는 해당 VMCS의 인덱스 14에 있습니다.
* 이 항목이 녹아웃되는지 확인하겠지만 지금은 각 레이어에서 커널 메모리만 덤프하고 있습니다. 게스트 OS VM의 사용자 공간에서 작업합니다.
TODO가 많지만 최대한 빨리 추가하겠습니다. 지금 당장 가장 큰 문제는 큰 도움이 되더라도 OS에서 제공하는 어떤 것을 추가하는 것을 정말 주저한다는 것입니다. 논리적 OS 종속성을 추가하지 않도록 충분한 컨텍스트를 사용할 수 있다고 생각합니다. 나는 Rekal이 이것을 약속하는 방식을 좋아하지만 그들의 프로필 아카이브도 매우 큰 것 같아서 둘 다 약간 있습니다.
아직 정리할 부분이 좀 남았습니다. 아직은 알파 단계이지만 적극적으로 개발될 예정입니다.
더 잘 알려진 EPTP 유형으로 확장하므로 무차별 대입이 필요하지 않습니다.
실행을 자동으로 결정하기 위해 PFN 비트맵 인덱스를 생성하려고 합니다(현재 실행 후 덤프/쿼리를 시도하면 문제가 발생하거나 누락될 수 있습니다. 100% 포괄적인 덤프를 얻을 수 있도록 다음에 이것을 추가할 예정입니다. .
메모리 분석을 지원하기 위해 OS 논리 구조를 사용하지 않습니다. 분석가의 노력을 잘못된 방향으로 유도하기 위해 공격자가 대부분의 OS 계층 구조, 데이터, 코드 및 개체를 조작할 가능성이 높습니다.
암호화된 보안 블록/페이지 해시 값(예: SHA256 또는 TIGER192)에 다시 매핑될 수 있는 코드 페이지에 대한 무결성 맵을 렌더링하는 향후 기능입니다. 우리의 결과는 Win10 이전의 검증 비율이 99%가 넘는 것으로 나타났으며, Win10 이후의 휘발성 메모리는 사실상 100% 입증 가능합니다. 이는 수 기가바이트의 입력을 감지/분석하려고 할 때 메모리를 수동으로 처리/검토/분해하여 발생하는 실질적인 추측 작업과 알 수 없는 작업을 제거합니다.
선적 서류 비치
GUI 구현
