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)
12086정성태12/20/201920971디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201918964오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201919397디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201922342Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920578오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922437개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919604.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921490오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921287Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920386Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201918914디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919720디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919407디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920908Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917688오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921221오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923135오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919527디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928203디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919601디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919263디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917569디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920498오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919429디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918912디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919356Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...