디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
[링크 복사]
,
[링크+제목 복사],
12537
windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
;
https://www.sysnet.pe.kr/2/0/12062
Visual Studio를 이용해 RtlReportCriticalFailure와 관련한 "parameters"를 쉽게 구해 heap 관련 정보를 얻을 수 있었는데요. 그렇다면 windbg로는 어떻게 처리할 수 있을지 설명해 보겠습니다. ^^
우선, windbg에서 RtlReportCriticalFailure 예외가 발생한 덤프를 열면 곧바로 이런 메시지가 나옵니다.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(11e4.8e0): Unknown exception - code c0000374 (first/second chance not available)
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`05d882d3 eb00 jmp ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)
메시지에서 보이는 것처럼 ".ecxr" 명령어를 수행해도 되지만 어차피 지금 문제가 발생한 스레드의 문맥에 있으므로 그냥 "r" 명령어로 봐도 무방합니다.
0:016>
.ecxr
rax=0000000000000000 rbx=0000002cab7fe470 rcx=0000002cab7fea18
rdx=0000000000000008 rsi=0000002cab7fdf80 rdi=0000002cab7fdf80
rip=00007ffd05d882d3 rsp=0000002cab7fed40 rbp=0000000000000000
r8=fffffff800000021 r9=0000000000000000 r10=0000000000000000
r11=0000002cab7feaa0 r12=0000000000000000 r13=0000002cab7ff2e0
r14=0000014e8cba0000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000204
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`05d882d3 eb00 jmp ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)
0:016>
r
Last set context:
rax=0000000000000000 rbx=0000002cab7fe470 rcx=0000002cab7fea18
rdx=0000000000000008 rsi=0000002cab7fdf80 rdi=0000002cab7fdf80
rip=00007ffd05d882d3 rsp=0000002cab7fed40 rbp=0000000000000000
r8=fffffff800000021 r9=0000000000000000 r10=0000000000000000
r11=0000002cab7feaa0 r12=0000000000000000 r13=0000002cab7ff2e0
r14=0000014e8cba0000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000204
ntdll!RtlReportCriticalFailure+0x97:
00007ffd`05d882d3 eb00 jmp ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5)
자, 그럼 우리가 여기서 궁금한 것은 Visual Studio에서 보여준 "parameters"에 해당하는 정보입니다. 이를 위해 우선 k 명령어로 callstack을 보고,
0:016>
k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 0000002c`ab7fed40 00007ffd`05d88c2a ntdll!RtlReportCriticalFailure+0x97
01 0000002c`ab7fee50 00007ffd`05d35b7a ntdll!RtlpHeapHandleError+0x12
02 0000002c`ab7fee80 00007ffd`05cccc33 ntdll!RtlpLogHeapFailure+0x96
03 0000002c`ab7feeb0 00007ffc`f061fbaf ntdll!RtlFreeHeap+0x823
04 0000002c`ab7fef60 00007ffc`f0628a29 OraOps19!ssmem_free+0xf
05 0000002c`ab7fef90 00007ffc`99b372fe OraOps19!OpsMetFreeValCtx+0x89
06 0000002c`ab7fefc0 00007ffc`99b7d635 0x00007ffc`99b372fe
07 0000002c`ab7ff070 00007ffc`f85757c6 0x00007ffc`99b7d635
08 0000002c`ab7ff0b0 00007ffc`f8606a91 clr!FastCallFinalizeWorker+0x6
09 0000002c`ab7ff0e0 00007ffc`f8606a19 clr!FastCallFinalize+0x55
...[생략]...
1c 0000002c`ab7ffad0 00007ffd`03228364 clr!Thread::intermediateThreadProc+0x86
1d 0000002c`ab7ffb90 00007ffd`05cf7091 kernel32!BaseThreadInitThunk+0x14
1e 0000002c`ab7ffbc0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
ntdll!RtlReportCriticalFailure의 코드를 살펴보면,
0:016>
uf ntdll!RtlReportCriticalFailure
ntdll!RtlReportCriticalFailure:
00007ffd`05d8823c 48895c2418 mov qword ptr [rsp+18h],rbx
...[생략]...
00007ffd`05d88278 7427 je ntdll!RtlReportCriticalFailure+0x65 (00007ffd`05d882a1) Branch
...[생략]...
ntdll!RtlReportCriticalFailure+0x65:
00007ffd`05d882a1 895c2450 mov dword ptr [rsp+50h],ebx
00007ffd`05d882a5 b901000000 mov ecx,1
00007ffd`05d882aa 894c2454 mov dword ptr [rsp+54h],ecx
00007ffd`05d882ae 488364245800 and qword ptr [rsp+58h],0
00007ffd`05d882b4 488d05452df5ff lea rax,[ntdll!RtlRaiseException (00007ffd`05cdb000)]
00007ffd`05d882bb 4889442460 mov qword ptr [rsp+60h],rax
00007ffd`05d882c0 894c2468 mov dword ptr [rsp+68h],ecx
00007ffd`05d882c4 48897c2470 mov qword ptr [rsp+70h],rdi
00007ffd`05d882c9 488d4c2450 lea rcx,[rsp+50h]
00007ffd`05d882ce e82d2df5ff call ntdll!RtlRaiseException (00007ffd`05cdb000)
00007ffd`05d882d3 eb00 jmp ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5) Branch
ntdll!RtlReportCriticalFailure+0x99:
00007ffd`05d882d5 488b8c24f0000000 mov rcx,qword ptr [rsp+0F0h]
00007ffd`05d882dd 4833cc xor rcx,rsp
00007ffd`05d882e0 e8cbe5f9ff call ntdll!_security_check_cookie (00007ffd`05d268b0)
00007ffd`05d882e5 4c8d9c2400010000 lea r11,[rsp+100h]
00007ffd`05d882ed 498b5b20 mov rbx,qword ptr [r11+20h]
00007ffd`05d882f1 498b7328 mov rsi,qword ptr [r11+28h]
00007ffd`05d882f5 498be3 mov rsp,r11
00007ffd`05d882f8 5f pop rdi
00007ffd`05d882f9 c3 ret
k 명령어로 본 "RtlReportCriticalFailure+0x97"의 0x97 위치에 해당하는 기계어 코드를 확인할 수 있습니다. 그리고 그것은 RtlRaiseException이고,
RtlRaiseException function
;
https://learn.microsoft.com/en-us/windows/win32/api/rtlsupportapi/nf-rtlsupportapi-rtlraiseexception
NTSYSAPI __analysis_noreturn VOID RtlRaiseException(PEXCEPTION_RECORD ExceptionRecord);
전달받는 인자가 EXCEPTION_RECORD에 대한 포인터 하나입니다. 간단해서 좋군요. ^^ 그렇다면 "call ntdll!RtlRaiseException"을 호출하기 전 수행한 "lea rcx, [rsp+50h]"의 "rcx" 레지스터에 담긴 값이 바로 EXCEPTION_RECORD 포인터 인자로 예상할 수 있습니다. 여기서 문제는, 비록 k 명령어의 결과에는 없지만 어쨌든 "RtlRaiseException" 함수가 수행 중이므로 현재 "r" 명령어로 출력한 "rcx" 값은 이미 RtlRaiseException 함수의 내부 코드에 의해서 변조되었을 가능성이 높다는 점입니다.
대신 frame 문맥 자체는 RtlReportCriticalFailure 함수 실행 시로 바뀐 상태이므로 "rsp" 레지스터의 값은 유효하므로 "lea rcx, [rsp+50h]"의 결과를 "r" 명령어에 출력된 rsp == 0000002cab7fed40 값에 +50h를 해 "2CAB7FED90"로 쉽게(?) EXCEPTION_RECORD의 포인터를 구할 수 있습니다.
이쯤에서 잠시 EXCEPTION_RECORD를 한번 살펴볼까요? ^^
EXCEPTION_RECORD structure
;
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-exception_record
typedef struct _EXCEPTION_RECORD {
DWORD ExceptionCode;
DWORD ExceptionFlags;
struct _EXCEPTION_RECORD *ExceptionRecord;
PVOID ExceptionAddress;
DWORD
NumberParameters
;
ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;
오호~~~ 우리에게 익숙한 필드명 NumberParameters가 보이는군요. ^^ 아마도 저 값이 Visual Studio에서 보여줬던 바로 그 "parameters"일 것입니다. 이러한 레코드 정보에 기반을 둬 ntdll!RtlReportCriticalFailure+0x65 위치의 코드를 다시 보면,
ntdll!RtlReportCriticalFailure+0x65:
00007ffd`05d882a1 895c2450
mov dword ptr [rsp+50h],ebx
00007ffd`05d882a5 b901000000 mov ecx,1
00007ffd`05d882aa 894c2454
mov dword ptr [rsp+54h],ecx
00007ffd`05d882ae 488364245800
and qword ptr [rsp+58h],0
00007ffd`05d882b4 488d05452df5ff lea rax,[ntdll!RtlRaiseException (00007ffd`05cdb000)]
00007ffd`05d882bb 4889442460
mov qword ptr [rsp+60h],rax
00007ffd`05d882c0 894c2468
mov dword ptr [rsp+68h],ecx
00007ffd`05d882c4 48897c2470
mov qword ptr [rsp+70h],rdi
00007ffd`05d882c9 488d4c2450 lea rcx,[rsp+50h]
00007ffd`05d882ce e82d2df5ff call ntdll!RtlRaiseException (00007ffd`05cdb000)
00007ffd`05d882d3 eb00 jmp ntdll!RtlReportCriticalFailure+0x99 (00007ffd`05d882d5) Branch
결국, EXCEPTION_RECORD의 구조체 위치가 "rsp+50h"이고 그곳에 다음과 같이 필드를 채운 것과 같습니다.
typedef struct _EXCEPTION_RECORD {
DWORD ExceptionCode; // mov dword ptr [rsp+50h],ebx
// mov dword ptr [rsp+54h],ecx
DWORD ExceptionFlags; // and qword ptr [rsp+58h],0 // [rsp+58h] == 0
struct _EXCEPTION_RECORD *ExceptionRecord; // mov qword ptr [rsp+60h],rax // rax == 00007ffd`05cdb000
PVOID ExceptionAddress; // mov dword ptr [rsp+68h],ecx // (int)[rsp+68h] == 1
DWORD NumberParameters; // mov qword ptr [rsp+70h],rdi // (int)[rsp+70h] == 전달된 두 번째 인자
ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;
따라서 이전에 구했던 rsp+50h 주솟값인 2CAB7FED90 위치를 덤프해 보면,
0:016> dq rsp+50h
0000002c`ab7fed90 00000001`c0000374 00000000`00000000
0000002c`ab7feda0 00007ffd`05d882d3 00007ffc`00000001
0000002c`ab7fedb0
00007ffd`05ddf6b0
00007ffc`f8575191
0000002c`ab7fedc0 00000ec4`00000000 0000014e`8dc53610
0000002c`ab7fedd0 00000000`00000000 00007ffd`05d042e3
0000002c`ab7fede0 00007a66`762bbd2a 0000002c`ab7fef30
0000002c`ab7fedf0 00000000`00000000 0000014e`8cba0000
0000002c`ab7fee00 00000000`00000000 00000000`00000000
NumberParameters의 위치(rsp+70h)에 해당하는 값을 구할 수 있고, 실제로 Visual Studio가 출력했던 parameters 값과 일치합니다. 게임 끝났군요. ^^ 이 값을 메모리 창에 보면 HeapFree에 전달되었던 hHandle과 해제하려는 메모리 주소를 알아낼 수 있습니다.
// [00007ffd05ddf6b0]
00007ffd`05ddf6b0 000006e000000002
00007ffd`05ddf6b8 0000000000000004
00007ffd`05ddf6c0 00000286f28f0000 // hHandle
00007ffd`05ddf6c8 0000028b412d3be0 // pVoid - 0x10
00007ffd`05ddf6d0 0000000000000000
여기까지 읽으신 분은 다소 허무하겠지만 ^^ windbg에는 EXCEPTION_RECORD에 대한 정보를 출력할 수 있는 명령어가 이미 있어서 ^^ 위와 같이 복잡하게 작업하지 마시고 RtlReportCriticalFailure가 발생한 경우 처음부터 ".exr -1" 명령어를 수행하면 됩니다.
0:016>
.exr -1
ExceptionAddress:
00007ffd05d882d3
(ntdll!RtlReportCriticalFailure+0x0000000000000097)
ExceptionCode:
c0000374
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]:
00007ffd05ddf6b0
보는 바와 같이 Visual Studio가 출력했던 예외 메시지의,
Unhandled exception at
0x00007FFD05D882D3
(ntdll.dll) in dump4580.dmp:
0xC0000374
: A heap has been corrupted (parameters:
0x00007FFD05DDF6B0
)
바로 그 정보들을 동일하게 구할 수 있습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]
[다음 글]
오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
[이전 글]
디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
[연관 글]
디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
[1]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
...
[1]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
...
] @정성태 개인 블로그인데도 거의 커뮤니티 급 인 것 같아요. 요...
1