danger_track를 이용한 crash dump 활용

 

gray hat python의 마지막 부분인 pydbg를 이용한 danger_track.py을 실행하게 되면

어떻게 테스트 해야 할지 모르게 된다.

 

그래서 간단한 buffer_overflow.py를 이용하여, 찍히는 로그를 확인 할 수 있다.

 

# -*- coding: cp949 -*-

from ctypes import *
import os

msvcrt = cdll.msvcrt

print ('this is process : %d (0x%04x)' % (os.getpid(), os.getpid()) )
raw_input ('Once the dubber is attached, press any key.')

buffer = c_char_p("AAAAA")
overflow = "A" * 1000000

msvcrt.strcpy(buffer, overflow)

 

위의 내용을 기반으로 돌리게 되면, bof는 발생하나 EIP 부분이 바뀌지 않는 것을 확인 할 수 있다.

 

CONTEXT DUMP
  EIP: 1e0acf39 mov esi,[eax]
  EAX: 41414141 (1094795585) -> N/A
  EBX: 00000009 (         9) -> N/A
  ECX: 00bc6000 (  12345344) -> BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (heap)
  EDX: 41414141 (1094795585) -> N/A
  EDI: 0000004c (        76) -> N/A
  ESI: 1d1b0dca ( 488312266) -> N/A
  EBP: 1d1b0dc8 ( 488312264) -> N/A
  ESP: 0021fb1c (   2226972) -> 7>L747,!STx!,!8Tx!!p;p!P!`wp?@W$!P!=!! (stack)
  +00: 1d1b0dca ( 488312266) -> N/A
  +04: 00000000 (         0) -> N/A
  +08: 00000037 (        55) -> N/A
  +0c: 1e0b3e9e ( 504053406) -> N/A
  +10: 0000004c (        76) -> N/A
  +14: 1d1b0dca ( 488312266) -> N/A

 

EIP가 바뀌지 않으면 까다로운 작업이 되므로, 눈으로 쉽게 확인 할 수 있는 방법은 EIP가 덮이느냐, 덮히지 않느냐를 확인하는 것이 나에겐 무지 중요한 부분이다.

(이후에서는 crash만 나더라도 더 명확하게 되는건지 확인 할 수 있겠지만 현재로는 EIP를 기반으로 찾고 있다.)

 

그러던 중, war-ftpd v.1.65 프로그램을 구한 뒤 테스트를 진행 하였다.

war-ftpd는 다행히도 EIP가 덮어졌다.

CONTEXT DUMP
  EIP: 41414141 Unable to disassemble at 41414141
  EAX: 00000000 (         0) -> N/A
  EBX: 00000000 (         0) -> N/A
  ECX: 41414141 (1094795585) -> N/A
  EDX: 7c9332bc (2090021564) -> N/A
  EDI: 00000000 (         0) -> N/A
  ESI: 00000000 (         0) -> N/A
  EBP: 00aebf18 (  11452184) -> N/A
  ESP: 00aebef8 (  11452152) -> 2|2|z2|AAAA|AAAAkc~`LPD@;hL@;|x;x;j|AAAA (heap)
  +00: 7c9332a8 (2090021544) -> N/A
  +04: 00aebfe0 (  11452384) -> AAAAAAAA?@=&HZppppeH8x???;##2|AAAAAAAAF#@=&HZ (heap)
  +08: 00aefd94 (  11468180) -> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (stack)
  +0c: 00aebffc (  11452412) -> ?@=&HZppppeH8x???;##2|AAAAAAAAF#@=&HZpppp (heap)
  +10: 00aebfb4 (  11452340) -> j|AAAAAAAA?@=&HZppppeH8x???;##2|AAAA (heap)
  +14: 00aec2dc (  11453148) -> 2|z2|AAAA|AAAAj|AAAAAAAA? (stack)

 

아주 ESP까지 덕지 덕지 붙어져 있는 것을 확인 할 수 있다.

danger_track은 tracking을 하기 위한 모니터링 툴이다. 즉, 어디에서 크래쉬가 발생하였는지에 대한 메모리 참조를 하기 위한 도구이지 fuzzing 도구가 아닌다. (fuzzing 도구인지 알고 무쟈게 즐거워했는데..ㅡㅡ;;)

 

이 것으로 danger_track 테스트를 마무리 하겠다.

즐거운 하루 되시길....

 

Tip : 누구든 생각하겠죠? danger_track은 print로 출력 하고 있습니다. 그 부분을 파일로 떨구면 보기도 편하고

또한, 파일명으로 dump 파일을 생성하면 추후에 다양한 내용들을 dump 하더라도 섞일 염려가 없으니 참고하시길....

관련 코드는 아래와 같습니다.

 

proc_name = psutil.Process(pid)
targetFile_Name = proc_name.name + '_crash_dump.txt'
output_fw = file(targetFile_Name, 'w')