Compartilhar via

Crash Dump Analysis Patterns (Part 4)

  • Artigo

Crash Dump Analysis 네번째 패턴에 대한 번역입니다.
간략히 설명을 드리자면, Part 4는 접하게 되었을 경우 선택의 여지가 별로 없는 상황입니다. Lateral Damage 패턴이라고 하는데, 받은 덤프에서 봐야할 중요 데이터들이 손상된 상황에서는 한번 다른 컴포넌트들(드라이버 후킹)을 살펴보라고 조언합니다.

Crash Dump Analysis Patterns (Part 4)

원문링크

번역: 김희준(https://insidekernel.net, drost@naver.com), 2007-06-16

오늘 덤프 하나를 받아보았는데, 모든 스레드의 TEB 내용이 비어있고, import table은 깨져 있었습니다. 이것은 예전에 접했던 비슷한 다른 케이스들을 떠올리게 했고, 그래서 전 다음 패턴을 Lateral Damage로 정했습니다.

이 문제가 발생하면 여러분은 별로 선택의 여지가 없습니다. 가장 우선 시도해볼 것은 덤프에서 모듈리스트가 깨지지 않았다면 외부 컴포넌트(Alien Component 안티패턴) 안티패턴을 적용해 보는 것이고, 또는 다음에 다룰 ‘깨진 덤프 패턴(Corrupt Dump)’일 수도 있습니다.

추가적인 검증과 경험에 의해 받쳐주기만 한다면 안티 패턴도 그렇게 늘 나쁜 선택은 아닙니다. 만약 덤프를 받았는데 프로세스와 스레드 구조체가 깨져있다면 (raw 스택 분석과 경험에 의한 추측과 같은 증거를 활용해서) 의심 가는 컴포넌트를 찾아볼 수 있고 희망을 갖고 그 컴포넌트를 다시 살펴보고 프로세스나 스레드 영역이 덜 손상된 추가 덤프 요청을 할 수도 있을 것입니다. 그리고 마지막에 그 부분을 수정한 뒤에 고객사의 환경이 안정화된다면 여러분이 맞았다는 것을 증명해주겠지요.

- Dmitry Vostokov -

Comments