Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 194. Windbg - x64 가상 주소를 물리 주소로 변환 [링크 복사], [링크+제목 복사],
조회: 2371
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 5개 있습니다.)
디버깅 기술: 28. Windbg - 윈도우 핸들 테이블
; https://www.sysnet.pe.kr/2/0/935

디버깅 기술: 55. Windbg - 윈도우 핸들 테이블 (2)
; https://www.sysnet.pe.kr/2/0/1476

디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회
; https://www.sysnet.pe.kr/2/0/12099

디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd)
; https://www.sysnet.pe.kr/2/0/12283

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




Windbg - x64 가상 주소를 물리 주소로 변환

(x86의 경우 Converting Virtual Addresses to Physical Addresses)


예를 하나 들어 볼까요? Local Kernel Debug 모드로 실행한 Windbg에서 다음과 같이 프로세스를 열거한 다음,

lkd> !process 0 0
...[생략]...

적절한 프로세스, 여기서는 notepad.exe를 예로 들어,

lkd> !process ffffbe896a188080 0
PROCESS ffffbe896a188080
    SessionId: 2  Cid: 0ac0    Peb: 350676d000  ParentCid: 1fa0
    DirBase: c2121000  ObjectTable: ffffc9859133dc00  HandleCount: 241.
    Image: notepad.exe

PEB로부터 환경변수를 담고 있는 가상 주소를 얻어내겠습니다.

lkd> .process /p ffffbe896a188080; !peb 350676d000
Implicit process is now ffffbe89`6a188080
PEB at 000000350676d000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
...[생략]...
    Environment:  0000018f35df1040
...[생략]...

0000018f35df1040 가상주소는, 각각의 비트별로 다음과 같이 분해될 수 있습니다.

long addr = 0x0000018f35df1040;

long mask = 0b_0000_0000_0000_0000_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111;

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

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

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

addr = addr >> 9;
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: 18f35df1040
Offset at page: 040
Page Table Entry Selector: 1f1
Page Table Selector: 1ae
Page Directory Pointer Selector: 03c
Page Map Level 4 Selector: 003

자, 그럼 여기서 가장 첫 번째로 Page Map Level 4 Selector가 가리키는 값을 통해 Page Directory Pointer 주소를 구해야 하는데요, 이를 위해 Page Map Level 4 위치를 가리키는 주솟값을 구해야 합니다. 보통 이 값은 해당 프로세스가 프로세서에서 실행될 때 CR3 레지스터에 로드되는데요, 사실 이것은 !process 명령어에도 DirBase라고 나온 그 값입니다.

lkd> !process ffffbe896a188080 0
PROCESS ffffbe896a188080
    SessionId: 2  Cid: 0ac0    Peb: 350676d000  ParentCid: 1fa0
    DirBase: c2121000  ObjectTable: ffffc9859133dc00  HandleCount: 241.
    Image: notepad.exe

자, 그럼 c2121000 "물리 주소"를 덤프해 보면,

lkd> !dq c2121000
#c2121000 0a000001`1c83b867 00000000`00000000
#c2121010 00000000`00000000 0a000001`39d47867
#c2121020 00000000`00000000 00000000`00000000

"Page Map Level 4 Selector: 003"의 인덱스 3에 위치한 값이 "0a000001`39d47867"로 나옵니다. 대충 공식화하면 다음과 같이 정리할 수 있습니다.

PML4 엔트리 주소: 00000000c2121018 = c2121000 + (0x03 * (8바이트 Entry 크기))

lkd> !dq 00000000c2121018 L1
#c2121018 0a000001`39d47867

Page Map Level 4 Entry의 구조는 다음과 같은데,

// https://wiki.osdev.org/File:64-bit_page_tables1.png

0: P
1: R/W
2: U/S
3: PWT
4: PCD
5: A
6: AVL
7: RSVD(0)
8~11: AVL
12~(M-1): Bits 12 ~ (M-1) of address
M~51: Reserved (0)
52~62: AVL
63: XD

현재 M은 52비트를 지원하기 때문에, 12 ~ 51 영역이 Page Directory Pointer 영역을 가리키는 주솟값이 됩니다.

[0a000001`39d47867 값의 12 ~ 51 영역]

Page Directory Pointer: 139d47000

자, 그럼 저 주소에 다시 "Page Directory Pointer Selector: 03c"가 가리키는 위치를 8바이트 엔트리 크기만큼 곱한 위치에,

00000001`39d471e0 = 139d47000 + (0x3c * 8)

lkd> !dq 00000001`39d471e0 L1
#139d471e0 0a000001`d3b48867

PDPE 값이 나옵니다. (이제 대충 느낌을 아시겠죠? 남은 작업들이 모두 이런 식의 계산을 반복하는 것입니다.)

저 PDPE 값을 Entry 포맷에 따라 분석하면 되는데, 현재는 PML4E나 PDPE나 포맷이 7비트 영역만 "PS(0)"이라는 점만 빼고 같으므로 역시 같은 방법으로 그다음 Page Directory의 주소를 구하면,

[0a000001`d3b48867 값의 12 ~ 51 영역]

Page Directory: 1d3b48000

값이 나옵니다. 순서에 따라 가상 주소의 "Page Table Selector: 1ae" 값을 8바이트 엔트리 크기만큼 인덱스로 구하면,

00000001`d3b48d70 = 1d3b48000 + (0x1ae * 8)

lkd> !dq 00000001`d3b48d70 L1
#1d3b48d70 0a000001`e9849867

이렇게 구한 0a000001`e9849867 PTE 값도 구조는 PDPE와 완전히 같으므로 같은 방식으로 해석하면, 페이지 테이블의 주소를 얻을 수 있고,

[0a000001`e9849867 값의 12 ~ 51 영역]

Page Table: 1e9849000

여기에 다시 "Page Table Entry Selector: 1f1" 값을 인덱스로 구하면,

00000001`e9849f88 =  1e9849000 + (0x1f1 * 8)

lkd> !dq 00000001`e9849f88 L1
#1e9849f88 81000000`d4818805

최종 PTE 값(81000000`d4818805)을 구할 수 있습니다. 이 값을 다시 "12 ~ 51 영역"으로 분석하면, d4818000 값이 나오고 여기에 마지막 가상 주소의 12비트 값을 더하면,

d4818040 = d4818000 + 0x040

최종 물리 주소인 d4818040 값이 나옵니다. 확인을 해봐야죠. ^^ 물리 주소를 대상으로 값을 덤프해 보면,

lkd> !dc d4818040
#d4818040 003a003d 003d003a 003a003a 0000005c =.:.:.=.:.:.\...
#d4818050 004c0041 0055004c 00450053 00530052 A.L.L.U.S.E.R.S.
#d4818060 00520050 0046004f 004c0049 003d0045 P.R.O.F.I.L.E.=.
#d4818070 003a0043 0050005c 006f0072 00720067 C.:.\.P.r.o.g.r.
#d4818080 006d0061 00610044 00610074 00410000 a.m.D.a.t.a...A.
#d4818090 00500050 00410044 00410054 0043003d P.P.D.A.T.A.=.C.
#d48180a0 005c003a 00730055 00720065 005c0073 :.\.U.s.e.r.s.\.
#d48180b0 0065006b 00690076 005c006e 00700041 k.e.v.i.n.\.A.p.

가상 주소를 덤프했던 값과 완전히 동일한 값을 얻을 수 있습니다.

lkd> dc 0000018f35df1040
0000018f`35df1040  003a003d 003d003a 003a003a 0000005c  =.:.:.=.:.:.\...
0000018f`35df1050  004c0041 0055004c 00450053 00530052  A.L.L.U.S.E.R.S.
0000018f`35df1060  00520050 0046004f 004c0049 003d0045  P.R.O.F.I.L.E.=.
0000018f`35df1070  003a0043 0050005c 006f0072 00720067  C.:.\.P.r.o.g.r.
0000018f`35df1080  006d0061 00610044 00610074 00410000  a.m.D.a.t.a...A.
0000018f`35df1090  00500050 00410044 00410054 0043003d  P.P.D.A.T.A.=.C.
0000018f`35df10a0  005c003a 00730055 00720065 005c0073  :.\.U.s.e.r.s.\.
0000018f`35df10b0  0065006b 00690076 005c006e 00700041  k.e.v.i.n.\.A.p.




위와 같은 번거로운 작업을 Windbg에서 한방에 해주는 명령어가 바로 vtop입니다.

!vtop
; https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-vtop

위의 실습과 같은 경우라면 다음과 같이 명령어를 수행하면 됩니다.

lkd>  !vtop c2121000 0000018f35df1040
Amd64VtoP: Virt 0000018f35df1040, pagedir 00000000c2121000
Amd64VtoP: PML4E 00000000c2121018
Amd64VtoP: PDPE 0000000139d471e0
Amd64VtoP: PDE 00000001d3b48d70
Amd64VtoP: PTE 00000001e9849f88
Amd64VtoP: Mapped phys 00000000d4818040
Virtual address 18f35df1040 translates to physical address d4818040.

또는, 프로세스 문맥을 고정하는 경우 첫 번째 인자에 0을 주는 것도 가능합니다.

lkd> .process /p ffffbe896a188080
Implicit process is now ffffbe89`6a188080

lkd> .context
User-mode page directory base is c2121000

lkd> !vtop 0 0000018f35df1040
...[생략]...
Virtual address 18f35df1040 translates to physical address d4818040.

출력에서 나온 PML4E, PDPE, PDE, PTE는 모두 우리가 이미 위에서 구했던 값을 그대로 보여주고 있는 것입니다. 유사하게 "!pte" 명령어를 통해서 구할 수 있는데, Local Kernel Debug 모드라서 그런지 정상적인 값을 출력하지 못하고 있습니다.

lkd> !pte 0000018f35df1040
                                           VA 0000018f35df1040
PXE at FFFFC6E371B8D018    PPE at FFFFC6E371A031E0    PDE at FFFFC6E34063CD70    PTE at FFFFC680C79AEF88
contains 0000000000000000
contains 0000000000000000
not valid

참고로, 아래의 글을 보면,

Turning the Pages: Introduction to Memory Paging on Windows 10 x64
; https://connormcgarr.github.io/paging/

!pte 명령어의 결과에 나오는 필드의 의미가 각각 PXE == PML4E, PPE == PDPE라고 합니다. 그런 의미에서 !pte의 출력 결과에서 PML4E가 FFFFC6E371B8D018로 나오는데요, 우리가 구했던 값이 물리 주소인 반면 !pte는 가상 주소를 반환하기 때문입니다. 따라서 이 값을 vtop으로 다시 바꾸면,

lkd> !vtop 0 FFFFC6E371B8D018
Amd64VtoP: Virt ffffc6e371b8d018, pagedir 00000000c2121000
Amd64VtoP: PML4E 00000000c2121c68
Amd64VtoP: PDPE 00000000c2121c68
Amd64VtoP: PDE 00000000c2121c68
Amd64VtoP: PTE 00000000c2121c68
Amd64VtoP: Mapped phys 00000000c2121018
Virtual address ffffc6e371b8d018 translates to physical address c2121018.

우리가 구했던 c2121018과 정확히 같은 값이 나옵니다.




마지막으로, 종종 위와 같은 테스트를 하다 보면 환경변수가 다음과 같이 안 읽히는 경우가 있습니다.

lkd> .process /p ffffbe896a188080; !peb 350676d000
Implicit process is now ffffbe89`6a188080
PEB at 000000350676d000
...[생략]...
    CommandLine:  '"C:\WINDOWS\system32\notepad.exe" '
    DllPath:      '< Name not readable >'
    Environment:  0000018f35df1040
       Unable to read Environment string.

아울러 이런 상태에서 vtop 명령어를 수행하면 물리 주소를 구하지 못하게 됩니다.

lkd> !vtop c2121000 0000018f35df1040
Amd64VtoP: Virt 0000018f35df1040, pagedir 00000000c2121000
Amd64VtoP: PML4E 00000000c2121018
Amd64VtoP: PDPE 0000000139d471e0
Amd64VtoP: PDE 00000001d3b48d70
Amd64VtoP: PTE 00000001e9849f88
Amd64VtoP: PTE not present, pagefile 2:000000000025988c
Virtual address 18f35df1040 translation fails, error 0x10000114.

왜냐하면, 해당 주소의 물리 페이지가 paged-out 되었기 때문인데요, 이런 경우 그 페이지를 접근하는 동작이 있어야 합니다. 예를 들어, Process Explorer를 이용해 환경변수를 보는 뷰를 들어가주면 다시 0000018f35df1040 가상 주소는 물리 주소로 매핑이 됩니다. 단지 주의할 것은, 이때는 (높은 확률로) 다른 물리 주소로 올라오게 됩니다.




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







[최초 등록일: ]
[최종 수정일: 12/24/2023]

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

비밀번호

댓글 작성자
 




... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13232정성태1/27/20234860스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233786오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20234143개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20235158.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20235255.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20234951개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234674.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20233904개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234264Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234471오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20234144개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234374Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234471오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20234020Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20233952VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20234536디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
13216정성태1/12/20234792디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
13215정성태1/11/20236374Linux: 56. 리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법 [1]
13214정성태1/10/20235915.NET Framework: 2087. .NET 6부터 SourceGenerator와 통합된 System.Text.Json [1]파일 다운로드1
13213정성태1/9/20235442오류 유형: 836. docker 이미지 빌드 시 "RUN apt install ..." 명령어가 실패하는 이유
13212정성태1/8/20235199기타: 85. 단정도/배정도 부동 소수점의 정밀도(Precision)에 따른 형변환 손실
13211정성태1/6/20235226웹: 42. (https가 아닌) http 다운로드를 막는 웹 브라우저
13210정성태1/5/20234312Windows: 219. 윈도우 x64의 경우 0x00000000`7ffe0000 아래의 주소는 왜 사용하지 않을까요?
13209정성태1/4/20234228Windows: 218. 왜 윈도우에서 가상 메모리 공간은 64KB 정렬이 된 걸까요?
13208정성태1/3/20234189.NET Framework: 2086. C# - Windows 운영체제의 2MB Large 페이지 크기 할당 방법파일 다운로드1
13207정성태12/26/20224459.NET Framework: 2085. C# - gpedit.msc의 "User Rights Assignment" 특권을 코드로 설정/해제하는 방법파일 다운로드1
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...