2017. 7. 9. 15:22
[Windows] Crash-dump Analysis in Windbg Security/Analysis2017. 7. 9. 15:22
Windbg를 활용한 크래시 덤프 분석을 간단히 정리한 것!!
1. 진행 환경
OS : Windows 8.1 K
Debugger : WinDbg 6.3.9600.17298 AMD64
2. 크래쉬 덤프 생성
시스템 속성 > 시작 및 복구 > 설정 > 디버깅 정보 쓰기 설정
[그림 1]
3. 덤프 파일이 생성될 때까지 기다리거나 외부에서 구해온다.
4. WinDbg 를 이용하여 분석한다.
4.1. File > Symbol file path 설정
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
4.2. File > Open Crash Dump
크래쉬 덤프 파일을 Windbg에서 연다.
4.3. 덤프파일 분석시 유용하게 사용되는 명령어
> .bugcheck
해당 명령어는 버그체크 코드와 파라미터가 무엇을 나타내는지 알려준다. 버그체크 코드에 대한 정보는 windbg 에서 F1키를 누른 다음에 Bug Check Code Reference 를 검색해보면 된다.
> !drivers // lm t n
해당 명령어는 Windows XP 이전 버전에서 동작한다. 이는 타겟 컴퓨터에 로드된 모든 드라이버의 정보를 보여주며 드라이버의 메모리 사용에 대한 요약 정보를 포함한다.
이후의 버전에서는 해당 명령어를 사용할 수 없고 그와 비슷한 lm 명령어를 사용할 수 있다. lm 명령어는 로드된 모듈과 드라이버 정보를 보여준다. 이전의 !drivers 명령어와 유사하게 사용하기 위해선 lm 명령어에 t n 옵션을 주어 사용하면 된다(lm t n). 그러나 해당 명령어는 드라이버가 사용한 메모리 정보까지 포함하진 않는다. lm t n 명령어가 포함하는 정보는 start, end addresses, image names, timestamps 이다.
[그림 2]
> !analyze (-v)
해당 명령어를 이용할 경우, 디버거 자체가 분석하여 결과를 출력해준다. 이 정보를 가지고 대략적인 예외 상황을 파악할 수 있다.
> 기타 명령어
(!kdext*.locks , !memusage , !vm , !errlog , !process , .ecxr , ln)
5. 실습
시나리오 : 블루스크린이 발생하며 해당 크래쉬 덤프파일을 생성하였다. 이를 분석하여라.
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above. The offending component can usually be
identified with a stack trace.
Arg2: 0000000000001e00, The watchdog period.
Arg3: 0000000000000000
Arg4: 0000000000000000
// 크래쉬가 발생한 원인과 파라미터 종류
// 위 사항은 도움말(.bugcheck)에 나와있는 Bug Check Code Reference 부분에 자세히 나와있다.
[그림 3]
Debugging Details:
------------------
// 이하 내용은 발생되는 에러에 따라 다양하게 변경될 수 있다.
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
// 일반적인 failure에 대한 정의다.
BUGCHECK_STR: 0x133
// 예외코드를 나타낸다.
PROCESS_NAME: System
// 예외를 발생시킨 프로세스의 이름이다.
CURRENT_IRQL: d
// 인터럽트 요청 레벨을 표시한다.
ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre
// 디버거의 버전정보를 나타낸다.
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80277d511a0
// 스택에서의 마지막 콜을 보여준다. 이 부분을 예로 들 경우, 0x0000000000000000 주소에 있는 코드가 0xfffff80277d511a0 주소를 가지고 있는 함수를 호출 한 경우다. 이 내용은 ln(List Nearest Symbols) 명령어를 사용해서도 볼 수 있다.
STACK_TEXT:
ffffd001`94a37c88 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
STACK_COMMAND: kb
// STACK_TEXT에 포함되어 있는 정보를 다시 보고싶을 때 사용할 수 있는 명령어를 포함한다.
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
IMAGE_VERSION:
BUCKET_ID: ZEROED_STACK
// 현재 failure가 속한 명확한 카테고리를 보여준다. 이 카테고리는 디버거가 분석 결과에 어떠한 정보를 담아야 할지에 대해서 결정하는데 도움을 준다.
FAILURE_BUCKET_ID: ZEROED_STACK
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:zeroed_stack
FAILURE_ID_HASH: {4af92c9d-8968-8d00-06f5-868dfba32e9a}
Followup: MachineOwner
---------
♧ 틀린 내용은 혼자만 아시지 마시고 저도 알려주세요 - ㅅ-!
