Crash Dump Analysis Patterns (Part 10)
Crash Dump Analysis Patterns (Part 10)
번역: 김희준 (drost@naver.com , https://insidekernel.net )
번역일: 2007-11-01
때로는 운영체제 버전을 바꾸거나 후킹 소프트웨어 설치하는 것이 기존에는 완벽하게 동작하고 있었던 소프트웨어에서의 숨겨진 버그를 찾아내기도 합니다.
새로운 소프트웨어를 설치하면 어떤 일이 벌어질까요? 프로세스 덤프를 살펴보시면 그들만의 특정한 가상 주소에 로드되어 있는 여러 DLL들을 볼 수 있습니다. 아래는 제 Windows XP SP2 시스템에서 iexplore.exe 프로세스에 attach 한 후 lm WinDbg 명령어를 실행한 결과입니다:
0:000> lm
start end module name
00400000 00419000 iexplore
01c80000 01d08000 shdoclc
01d10000 01fd5000 xpsp2res
022b0000 022cd000 xpsp3res
02680000 02946000 msi
031f0000 031fd000 LvHook
03520000 03578000 PortableDeviceApi
037e0000 037f7000 odbcint
0ffd0000 0fff8000 rsaenh
20000000 20012000 browselc
30000000 302ee000 Flash9b
325c0000 325d2000 msohev
4d4f0000 4d548000 WINHTTP
5ad70000 5ada8000 UxTheme
5b860000 5b8b4000 NETAPI32
5d090000 5d12a000 comctl32_5d090000
5e310000 5e31c000 pngfilt
63000000 63014000 SynTPFcs
662b0000 66308000 hnetcfg
66880000 6688c000 ImgUtil
6bdd0000 6be06000 dxtrans
6be10000 6be6a000 dxtmsft
6d430000 6d43a000 ddrawex
71a50000 71a8f000 mswsock
71a90000 71a98000 wshtcpip
71aa0000 71aa8000 WS2HELP
71ab0000 71ac7000 WS2_32
71ad0000 71ad9000 wsock32
71b20000 71b32000 MPR
71bf0000 71c03000 SAMLIB
71c10000 71c1e000 ntlanman
71c80000 71c87000 NETRAP
71c90000 71cd0000 NETUI1
71cd0000 71ce7000 NETUI0
71d40000 71d5c000 actxprxy
722b0000 722b5000 sensapi
72d10000 72d18000 msacm32
72d20000 72d29000 wdmaud
73300000 73367000 vbscript
73760000 737a9000 DDRAW
73bc0000 73bc6000 DCIMAN32
73dd0000 73ece000 MFC42
74320000 7435d000 ODBC32
746c0000 746e7000 msls31
746f0000 7471a000 msimtf
74720000 7476b000 MSCTF
754d0000 75550000 CRYPTUI
75970000 75a67000 MSGINA
75c50000 75cbe000 jscript
75cf0000 75d81000 mlang
75e90000 75f40000 SXS
75f60000 75f67000 drprov
75f70000 75f79000 davclnt
75f80000 7607d000 BROWSEUI
76200000 76271000 mshtmled
76360000 76370000 WINSTA
76390000 763ad000 IMM32
763b0000 763f9000 comdlg32
76600000 7661d000 CSCDLL
767f0000 76817000 schannel
769c0000 76a73000 USERENV
76b20000 76b31000 ATL
76b40000 76b6d000 WINMM
76bf0000 76bfb000 PSAPI
76c30000 76c5e000 WINTRUST
76c90000 76cb8000 IMAGEHLP
76d60000 76d79000 iphlpapi
76e80000 76e8e000 rtutils
76e90000 76ea2000 rasman
76eb0000 76edf000 TAPI32
76ee0000 76f1c000 RASAPI32
76f20000 76f47000 DNSAPI
76f60000 76f8c000 WLDAP32
76fc0000 76fc6000 rasadhlp
76fd0000 7704f000 CLBCATQ
77050000 77115000 COMRes
77120000 771ac000 OLEAUT32
771b0000 77256000 WININET
773d0000 774d3000 comctl32
774e0000 7761d000 ole32
77920000 77a13000 SETUPAPI
77a20000 77a74000 cscui
77a80000 77b14000 CRYPT32
77b20000 77b32000 MSASN1
77b40000 77b62000 appHelp
77bd0000 77bd7000 midimap
77be0000 77bf5000 MSACM32_77be0000
77c00000 77c08000 VERSION
77c10000 77c68000 msvcrt
77c70000 77c93000 msv1_0
77d40000 77dd0000 USER32
77dd0000 77e6b000 ADVAPI32
77e70000 77f01000 RPCRT4
77f10000 77f57000 GDI32
77f60000 77fd6000 SHLWAPI
77fe0000 77ff1000 Secur32
7c800000 7c8f4000 kernel32
7c900000 7c9b0000 ntdll
7c9c0000 7d1d5000 SHELL32
7dc30000 7df20000 mshtml
7e1e0000 7e280000 urlmon
7e290000 7e3ff000 SHDOCVW
소프트웨어를 설치하거나 업그레이드 하는 것은 로드되는 DLL들의 파일이나 주소를 변경할 수 있습니다. 이것은 또한 모든 프로세스마다 그들만의 DLL들을 inject하는 모니터링 소프트웨어를 설치하면 발생하기도 합니다. 그 결과로 어떤 DLL들은 relocated 될 수 있고, 새로 로드되는 DLL이 있을 수도 있습니다. 그리고 이것은 서드파티 프로그램의 동작에 영향을 미칠 수 있어서 따라서 이전의 환경에서 프로세스를 실행할 때에는 숨겨져 있던 버그를 드러내게 합니다. 저는 이것을 바뀐 환경(Changed Environment) 패턴이라고 부릅니다.
가상의 예를 살펴봅시다. 여러분의 프로그램이 아래와 같은 코드를 가지고 있다고 가정해봅시다.
if (*p)
{
// do something useful
}
포인터 p가 invalid 하고, 그 값이 어떤 버그 때문에 덮어 쓰여졌다고 가정해봅시다. Invalid한 포인터는 유효한(valid) 메모리 위치를 가리킬 수 있고 그것이 가리키는 값은 대부분 0이 아닌 값입니다. 그래서 “if” 문장의 바디가 실행될 것입니다. 여러분들이 프로그램을 매번 실행할 때마다 포인터의 값이 우연하게도 같다고 가정해봅시다. 여기 포인터를 보여주는 그림이 있습니다:
포인터 값 0x40010024는 어떠한 이유 때문에 항상 0x00BADBAD 값을 가리키고 있습니다. 올바른 프로그램에서는 그 포인터 자체가 완전히 다른 값을 가지고 있어서 0x1이란 원래 값을 가리키고 있었다고 하더라도, 현재 포인터 p가 올바르지 않은 값을 참조하는 것은 프로세스를 크래쉬 시키지 않습니다.
새로운 소프트웨어를 설치한 후에, NewComponent DLL은 이전에 ComponentC에 의해 차지하고 있었던 주소 범위에 로드되어집니다:
이제 주소 0x40010024는 완전히 invalid하게 되었고 access violation과 크래쉬 덤프가 발생할 것입니다.
- Dmitry Vostokov -