Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

(시리즈 글이 8개 있습니다.)
디버깅 기술: 194. Windbg - x64 가상 주소를 물리 주소로 변환
; https://www.sysnet.pe.kr/2/0/13500

디버깅 기술: 203. Windbg - x64 가상 주소를 물리 주소로 변환 (페이지 크기가 2MB인 경우)
; https://www.sysnet.pe.kr/2/0/13836

디버깅 기술: 206. Windbg로 알아보는 PFN (_MMPFN)
; https://www.sysnet.pe.kr/2/0/13844

디버깅 기술: 207. Windbg로 알아보는 PTE (_MMPTE)
; https://www.sysnet.pe.kr/2/0/13845

디버깅 기술: 208. Windbg로 알아보는 Trans/Soft PTE와 2가지 Page Fault 유형
; https://www.sysnet.pe.kr/2/0/13846

디버깅 기술: 209. Windbg로 알아보는 Prototype PTE
; https://www.sysnet.pe.kr/2/0/13848

디버깅 기술: 210. Windbg - 논리(가상) 주소를 Segmentation을 거쳐 선형 주소로 변경
; https://www.sysnet.pe.kr/2/0/13849

디버깅 기술: 212. Windbg - (Ring 3 사용자 모드의) FS, GS Segment 레지스터
; https://www.sysnet.pe.kr/2/0/13852




Windbg - x64 가상 주소를 물리 주소로 변환 (페이지 크기가 2MB인 경우)

지난 글에서,

Windbg - x64 가상 주소를 물리 주소로 변환
; https://www.sysnet.pe.kr/2/0/13500

설명한 내용은 페이지 크기가 4KB인 경우였습니다. 반면, 페이지 크기가 2MB로 할당된 경우도 있을 텐데요,

C# - Windows 운영체제의 2MB Large 페이지 크기 할당 방법
; https://www.sysnet.pe.kr/2/0/13208

이번에는 저렇게 된 경우에 대한 실습을 해보겠습니다. ^^




자, 그럼 실습을 위해 2MB 페이지 크기로 할당된 메모리를 찾아야 하는데요, 다행히 _EPROCESS 구조체가 대개의 경우 2MB 페이지 크기로 할당된 곳에 위치하고 있는 듯합니다.

// Windows 10 x64 (10.0.19045)에서 Local Kernel Debug로 실행 + notepad.exe 하나 띄워 놓고!

lkd>  !process 0 0 notepad.exe
PROCESS ffffd282e4819080
    SessionId: 2  Cid: 277c    Peb: f9fec99000  ParentCid: 1438
    DirBase: 15c4ff000  ObjectTable: ffffe0042587a040  HandleCount: 261.
    Image: notepad.exe

lkd> !pte ffffd282e4819080
                                           VA ffffd282e4819080
PXE at FFFFFEFF7FBFDD28    PPE at FFFFFEFF7FBA5058    PDE at FFFFFEFF74A0B920    PTE at FFFFFEE9417240C8
contains 0A00000207E43863  contains 0A00000207E44863  contains 8A000001302009E3  contains 0000000000000000
pfn 207e43    ---DA--KWEV  pfn 207e44    ---DA--KWEV  pfn 130200    -GLDA--KW-V  LARGE PAGE pfn 130219    

위의 결과를 보면, _EPROCESS 구조체가 담긴 ffffd282e4819080 주소가 PDE 수준에서 pfn 130200을 담고 있으며 "LARGE PAGE"라는 의미에 맞게 "-GLDA--KW-V"에 "L" 비트가 켜져 있습니다. 즉, 2MB 페이지 크기로 할당된 메모리에 위치해 있는 것입니다.

이런 경우에는, 기존의 4KB 페이지 크기에서 offset 값을 9-9-9-9-12로 분해해 계산했던 것을, 대신 마지막 PTE의 offset 값인 9bit도 뒤의 12비트와 결합해 2MB 영역 내에서의 offset 값으로 계산을 해야 합니다.

ulong addr = 0xffffd282e4819080;

ulong mask = 0b_0000_0000_0000_0000_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111;

ulong result = addr & mask;
Console.WriteLine($"Virtual Address: {result:x}");

mask = 0b_1_1111_1111_1111_1111_1111; // 21 bits
result = addr & mask;
Console.WriteLine($"Offset at page: {result:x3}");

addr = addr >> 21;
mask = 0b_1_1111_1111; // 9 bits
result = addr & mask;
Console.WriteLine($"Page Table Selector: {result:x3}");

addr = addr >> 9;
mask = 0b_1_1111_1111; // 9 bits
result = addr & mask;
Console.WriteLine($"Page Directory Pointer Selector: {result:x3}");

addr = addr >> 9;
mask = 0b_1_1111_1111; // 9 bits
result = addr & mask;
Console.WriteLine($"Page Map Level 4 Selector: {result:x3}");

/* 출력 결과:
Virtual Address: d282e4819080
Offset at page: 19080
Page Table Selector: 124
Page Directory Pointer Selector: 00b
Page Map Level 4 Selector: 1a5
*/

정말 그런지 DirBase로부터 물리 주소를 계산해 볼까요? ^^

"!process ..." 문맥의 결과로 나온 (CR3 레지스터의 값인) 15c4ff000을 기준으로 PML4E 값을 덤프하고,

lkd> ? 1a5*8 // 1개의 항목 크기가 8바이트이므로!
Evaluate expression: 3368 = 00000000`00000d28

lkd> dq /p 15c4ff000+d28 L1 // 또는 !dq 15c4ff000+d28 L1
00000001`5c4ffd28  0a000002`07e43863

// PML4E의 12 ~ 51 영역이 가리키는 Page Directory Pointer == 207e43000

그럼 다시 8바이트 크기의 Page Directory Pointer Selector: 00b 값을 더해서 덤프한 후,

lkd> !dq 207e43000 + (0b * 8) L1
#207e43058 0a000002`07e44863

// PDPE의 12 ~ 51 영역이 가리키는 Page Directory == 207e44000

마지막으로 "Page Table Selector: 124" 값을 더해서 덤프해 보면,

lkd> !dq 207e44000 + (0x124 * 8) L1
#207e44920 8a000001`302009e3

// PDE의 12 ~ 51 영역이 가리키는 Page Table == 130200000

위의 값이 나왔는데요, 이번엔 저 단계가 끝입니다. 왜냐하면 하위 12비트에 해당하는 0x9e3을 플래그로 분석해 보면,

// 0x9e3 == 1001 1110 0011

0: Present (1)
1: Read/Write (1)
2: User/Supervisor (0)
3: Write-through (0) 
4: Cache disabled (0)
5: Accessed (1)
6: Dirty (1)
7: Page Size (1) // 2MB 페이지 크기
8: Global (1)
9~11: AVL (100)

"L" 비트에 해당하는 Page Size가 1로 설정돼 있으므로 2MB 페이지 크기가 됩니다. 따라서, 130200000 주소를 base로 해서 가상 주소의 마지막 21비트를 더하면,

lkd> ? 130200000 + 19080
Evaluate expression: 5102473344 = 00000001`30219080

물리 주소 00000001`30219080 값이 나옵니다. 실제로 이 값이 물리 주소에 해당하는지 !vtop 명령어로 확인해 보면 됩니다. ^^

lkd> !vtop 0 ffffd282e4819080
Amd64VtoP: Virt ffffd282e4819080, pagedir 00000000007d4000
Amd64VtoP: PML4E 00000000007d4d28
Amd64VtoP: PDPE 0000000207e43058
Amd64VtoP: PDE 0000000207e44920
Amd64VtoP: Large page mapped phys 0000000130219080
Virtual address ffffd282e4819080 translates to physical address 130219080.

정확히 일치하는군요. ^^ 위의 과정을 간단하게 설명하면 이렇게 압축할 수 있습니다.

물리 주소 == (!pte의 마지막 PFN) * page size + offset




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 12/14/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  69  70  71  72  [73]  74  75  ...
NoWriterDateCnt.TitleFile(s)
12111정성태1/12/202020537디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification) [16]파일 다운로드1
12110정성태1/11/202019843디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례 [5]파일 다운로드1
12109정성태1/10/202016578오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/202017415오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/202018596.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/202019634VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작 [1]
12105정성태1/8/202018139디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/7/202019343DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [4]
12103정성태1/7/202022453DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/202018798디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/5/202019055.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
12100정성태1/3/202016545.NET Framework: 875. .NET 3.5 이하에서 IntPtr.Add 사용
12099정성태1/3/202019410디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회 [1]
12098정성태1/2/202019147.NET Framework: 874. C# - 커널 구조체의 Offset 값을 하드 코딩하지 않고 사용하는 방법 [3]
12097정성태1/2/202017208디버깅 기술: 150. windbg - Wow64, x86, x64에서의 커널 구조체(예: TEB) 구조체 확인
12096정성태12/30/201919875디버깅 기술: 149. C# - DbgEng.dll을 이용한 간단한 디버거 제작 [1]
12095정성태12/27/201921582VC++: 135. C++ - string_view의 동작 방식
12094정성태12/26/201919333.NET Framework: 873. C# - 코드를 통해 PDB 심벌 파일 다운로드 방법
12093정성태12/26/201918893.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력파일 다운로드1
12092정성태12/25/201917666디버깅 기술: 148. cdb.exe를 이용해 (ntdll.dll 등에 정의된) 커널 구조체 출력하는 방법
12091정성태12/25/201919966디버깅 기술: 147. pdb 파일을 다운로드하기 위한 symchk.exe 실행에 필요한 최소 파일 [1]
12090정성태12/24/201920075.NET Framework: 871. .NET AnyCPU로 빌드된 PE 헤더의 로딩 전/후 차이점 [1]파일 다운로드1
12089정성태12/23/201919010디버깅 기술: 146. gflags와 _CrtIsMemoryBlock을 이용한 Heap 메모리 손상 여부 체크
12088정성태12/23/201917968Linux: 28. Linux - 윈도우의 "Run as different user" 기능을 shell에서 실행하는 방법
12087정성태12/21/201918431디버깅 기술: 145. windbg/sos - Dictionary의 entries 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12086정성태12/20/201920949디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
... 61  62  63  64  65  66  67  68  69  70  71  72  [73]  74  75  ...