Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일
 

windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법

이전 글에서는,

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://docs.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://docs.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)


바로 그 정보들을 동일하게 구할 수 있습니다.




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 11/22/2019 ]

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

비밀번호

댓글 쓴 사람
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12122정성태1/22/202050.NET Framework: 879. C/C++의 UNREFERENCED_PARAMETER 매크로를 C#에서 우회하는 방법(IDE0060 - Remove unused parameter '...')파일 다운로드1
12121정성태1/20/202040VS.NET IDE: 139. Visual Studio - Error List: "Could not find schema information for the ..."파일 다운로드1
12120정성태1/20/202064.NET Framework: 878. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)파일 다운로드1
12119정성태1/17/202069디버깅 기술: 160. Windbg 확장 DLL 만들기 (3) - C#으로 만드는 방법
12118정성태1/17/202082개발 환경 구성: 466. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 세 번째 이야기
12117정성태1/15/202056디버깅 기술: 159. C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법파일 다운로드1
12116정성태1/15/202061디버깅 기술: 158. Visual Studio로 디버깅 시 sos.dll 확장 명령어를 (비롯한 windbg의 다양한 기능을) 수행하는 방법
12115정성태1/14/202033디버깅 기술: 157. C# - PEB.ProcessHeap을 이용해 디버깅 중인지 확인하는 방법파일 다운로드1
12114정성태1/13/202078디버깅 기술: 156. C# - PDB 파일로부터 심벌(Symbol) 및 타입(Type) 정보 열거파일 다운로드3
12113정성태1/12/202047오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib'
12112정성태1/12/202029오류 유형: 589. PowerShell - 원격 Invoke-Command 실행 시 "WinRM cannot complete the operation" 오류 발생
12111정성태1/12/202078디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification)
12110정성태1/12/202075디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례파일 다운로드1
12109정성태1/10/202021오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/202027오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/2020101.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/202081VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작
12105정성태1/8/202083디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/9/2020175DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [2]
12103정성태1/12/2020115DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/2020137디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/8/2020118.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
12100정성태1/3/202073.NET Framework: 875. .NET 3.5 이하에서 IntPtr.Add 사용
12099정성태1/3/2020108디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회
12098정성태1/2/2020120.NET Framework: 874. C# - 커널 구조체의 Offset 값을 하드 코딩하지 않고 사용하는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...