지금 카드 정보 유출이 카드사 만의 문제일까요?

여러 분들의 정보가 카드사에서만 유출되고 있을까요?

엄청난 많은 정보들이 지금 인터넷에 떠돌고 있으며, 굳이 카드사가 아니더라도

손 쉽게 얻을 수 있습니다.

@.@

금일 키사에 신고는 해놓았는데 어떻게 처리되는지 봐야겠네요.

Name Mangling 이라고 하면 저에게 생소한 부분이였습니다.

Cod, Map 파일을 분석하면서 연계가 되어 Name Mangling 까지 가게 되었네요.

이후 부터는 반어를 사용합니다. 이점 양해해 주시길 바랍니다.

////////////////////////////////////////////////////////////

1. Name Mangling 이란?

   프로그램에서 함수를 선언하거나 전역 변수 등의 선언 했을때, 실제 생성된 함수는 컴파일러의 특징에 따라서 일정한 규칙을 통하여 함수, 변수명이 변경 된다. 이것을 Name Mangling 또는 Name Decoration 이라고 한다. 

   즉, 임의로 Test() 함수가 !Test@@YAXHAPAK 와 같이 변경되는 것을 의미한다.

2. 바뀌는 이유가 무엇인가?

   Function Overloading과 관련이 있다. Function Overloading이란 동일한 이름으로 다른 기능을 수행하는 함수를 여러개 만들었다고 치자. 그럴 경우 어떤 함수를 불렀는지 확인 할 수 없으므로 동일한 이름이라고 하더라도 따른 이름을 부여하여 프로그램이 동작하는데 있어서 문제가 발생하지 않도록 하기 위한 하나의 방지 책이다. 그림으로 쉽게 설명하도록 하겠다.

< 출처 : http://spikez.tistory.com/19 >

3. Name Mangling을 적용 / 미 적용 방법

  위와 같이 extern "C"를 붙이게 되면 C Type으로 함수명을 Naming을 하겠다는 선언이다. C Type의 Naming은 코드 상에서 사용하는 함수명 그대로 사용하는 것을 의미 한다.

4. Name Mangling 적용된 파일 분석 하는 방법

   undname 이라는 유틸리티가 있습니다. undname 프로그램은 Visual Studio를 설치하게 되면

   존재 할 것이다. 해당 파일을 그냥 때려 막으면 Name Mangling가 복원되어 화면에 출력해 준다. 그때 아래의 명령으로

   파일로 생성하여 분석에 활용하면 Name Mangling으로 된 함수로 인해서 눈 아픈 일은 없어질 것이다.

  이와 같이 할 경우 아래와 같은 결과 물을 얻을 수 있어서 분석하는데 도움이 될 것이다.

/////////////////////////////////////////////////////////

이번 기회에 undname을 통하여 Name Mangling이 적용된 함수를 C Type의 함수로 변경하는 방법을 알 수 있었습니다.

굳이, 파일이 아니더라도 문자열을 넣어도 변환 되므로 편의에 맞게 사용하면 좋을 것 같습니다.

사용 방법은 동일 합니다.

오랜만에 글을 올리는 것 같네요.

그 동안 잘 지내셨습니까?

이 글을 어느 분들이 보실지 모르겠지만 저에게 영감을 주신 달토끼님에게 감사 드립니다.

(달토끼님이 잘 정리하신 걸 제 나름대로 정리 해 보았습니다. 그래야지 내꺼가 되니까^^)

☞ http://kuaaan.tistory.com/102

우선, 이 글은 개발에 필요한 디버깅 기술이 아닌 분석자의 입장에서 분석을 할 때 유용할 정보를 언급하는데 초점을 맞췄습니다. 따라서 "왜 Map, Cod 파일을 생성하면 되는데 이렇게 할까?" 라고 생각이 들겠지만 보안팀에서는 회사의 소스에 대한 접근 권한이 없는 경우가 많으므로 그럴 때 분석을 효과적으로 하기 위해서 필요한 내용을 정리하는 것이니 이점을 감안하여 보시길 바랍니다.

제 블로그를 보시면 아시겠지만 반어로 작성하니 이점 참고 하시길 바랍니다.

무례하다면 먼저 사과 드립니다.

////////////////////////////////////////////////////////////

1. Cod 파일이란? Map 파일이란?

Cod 파일은 확실하게 분석하는 입장에서는 반드시 확인하고 봐야하는 내용중에 하나 이다.

Map의 경우는 pdb와 연결되면 유용하지만 없을 경우에는 Map 파일이 있다면 해석하기 좋을 것이다.

2. Cod 파일 / Map 파일 생성 방법

  1) Cod 파일 생성 방법

     Cod 파일은 어셈을 공부하는 학생 및 어셈에 대해서 더 알고 싶은 사람이라면 꼭 봐야하는 파일이므로 모든 코딩을 할 때

     해당 파일을 생성하여 분석하는 것을 추천한다.

  2) Map 파일 생성 방법

     Map 파일은 PDB 파일은 전달 해주지 못할 경우 요청할 수 있는 파일이다.

3. 생성된 Cod / Map 파일

  1) Cod 파일

  2) Map 파일

4. Map 파일 활용

5. Cod 파일 활용

  Cod 파일을 열어 보면 이게 몬지 잘 모를 것이다. 그럴땐 우선 Notepad++ 나 소스 코드의 하일라이트를 제공하는 프로그램을 이용하여 분석하면 수월하게 진행 할 수 있을 것이다. (언어 -> A -> Assembly)

그리고 또 하나의 팁은 SEGMENT/ENDS, PROC/ENDP 단위로 보면 된다.

즉,

???? SEGMENT

@@@ PROC

~~~~~

@@@ ENDP

???? ENDS

////////////////////////////////////////////////////////

Map 파일은 알고 있었는데 Cod 파일에 대해서는 VS 에서 디버깅할 때 어셈도 같이 보는 방식 이였는데

이렇게 파일로 생성 할 수 있다니 즐거운 경험을 하였습니다.

다시 한번 이 글을 빌어 달토끼님(http://kuaaan.tistory.com) 에게 감사 드립니다.

안녕하세요.

crattack 입니다.

홈페이지를 활용하는 방법에 대해서 미흡하여,

댓글을 남겨주시는 것을 잘 확인을 못하고 있었습니다.

그래서 댓글에 대한 충실한 답을 못드린 점 사과 드립니다.

향후엔 더 꼼꼼이 체크하여 답변을 남기도록 노력하겠습니다.

저의 부족한 홈페이지를 방문해 주신 여러분께 감사드리며, 좋은 정보를 공유할 수 있도록

노력 하겠습니다.

행복한 하루...

즐거운 인생을 위하여....

도대체 왜 안되는 걸까에서 보름을 잡아 먹은 것 같다.

이런 저런 고민 끝에 문제가 해결 됐다.

문제는 취약한 파일의 이슈

그리고 전체적인 구조 파악을 하지 못 한 것들....

코드를 보고 계속 탐구 한 끝에 File Fuzzer v.0.1을 만들었다.

아직, 수정해야 하는 부분이 남아 있다.

crash가 발생하고 먼저 죽어버리는 상황이 발생 한다.

모니터링 함수 내부에서 종료 하는 함수로 인해서 비정상적으로 종료 되어 해당 내용을 수정 해야 한다.

그래도 성공 하였으니, 일단 v.0.1 버전으로 올리도록 하겠다.

환경은 Windows 7/Python v.2.7을 사용하였다.

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')

이늠의 pydbg는 언제쯤 내 맘대로 움직일까..ㅡ.ㅡ;;

일단 동작은 하는데 영 찜찜하게 끝났네....

우선, MEM_IMAGE를 snap 을 안 떠서 crash 계속 나고 원인 찾는다고

삽질의 삽질 한 끝에 좋은 사이트 하나 얻었고, 해당 내용을 적용하니 되긴 된다.

http://linkc.tistory.com/entry/Analysis-about-Pydbg-Snapshot

            # do not snapshot blocks of memory that match the following characteristics.
            # XXX - might want to drop the MEM_IMAGE check to accomodate for self modifying code.
            #if mbi.State != MEM_COMMIT or mbi.Type == MEM_IMAGE:
            if mbi.State != MEM_COMMIT:

- pydbg.py 수정 -

또한, pydbg에서 self._log()를 출력하는데 내용이 안나오는 이유는 상단에 아래와 같은 코드로 막아 놓았기 때문이다.

self._log = lambda msg: None #sys.stderr.write("PDBG_LOG> " + msg + "\n")

-> self._log = lambda msg: sys.stderr.write("PDBG_LOG> " + msg + "\n")

XP에서는 잘 되는데....Win 7에서는 안되는 이유...ㅡ.ㅡ

파라매터가 잘못 됐다????

GetLastError : 87 (0x57)

위와 같은 에러가 발생하지만 정상적으로 동작은 된다.

적용은 되는데, 저 에러코드를 못 잡겠는데 누가 잡은 사람 있는 사람~~~

댓글 남겨주셈~~T-T

please. anybody is request me to solution picture T-T

have a good day.

이걸 가지고 얼마나 삽질을 했던가...

msvcrt.printf ("Count : %d", count++)

msvcrt.printf("Count : %d" % count++)

도대체 무엇이 틀린까 고민하던 끝에 ollydbg를 통해서 스택 구조를 확인 해 보았다.

이런...이런....된장~~!!

겁나 삽질 할 필요도 없는 내용이 나오게 되었다.

msvcrt.printf ("Count : %d", count++)

    # CPU Stack

    # Address   Value      ASCII Comments

    # 0021FB0C  /1D1ADC9A  ; RETURN to _ctypes_pyd.1D1ADC9A

    # 0021FB10  |01A16BA4  ; ASCII "Loop iteration %d!"

    # 0021FB14  |00000002   ; 

msvcrt.printf("Count : %d" % count++)

    # CPU Stack

    # Address   Value      ASCII Comments

    # 0021FB20  /1D1ADC9A  ; RETURN to _ctypes_pyd.1D1ADC9A

    # 0021FB24  |019A88A4  ; ASCII "Loop iteration 0!"

자, 보이시는가?

C방식으로 호출 할 때는 ESP + 0x08 위치에 2번째 아큐먼트 값이 들어가고,

python 방식으로 호출할 때는 ESP + 0x04 위치에 이미 만들어진 아큐먼트 값이 들어가 있다.

따라서, python pydbg를 이용한 예제에서 아무리 ESP+0x08의 값을 가지고 삽질을 해봐야 답이 나오지 않는다.

그래서 아래와 같이 수정을 해야 한다.

(해당 내용은 나보다 먼저 고민하고 작성한 중국인이 있었다. 그 분에게 다시 한번 감사를 표한다. 

thank you so much wanglong1982 - http://shellcodes.sinaapp.com/articles/date/2013/05)

   # python 방식(printf "%s" % buff)에서는 ESP+0x04가 인자의 위치이다.

    # CPU Stack

    # Address   Value      ASCII Comments

    # 0021FB20  /1D1ADC9A  ; RETURN to _ctypes_pyd.1D1ADC9A

    # 0021FB24  |019A88A4  ; ASCII "Loop iteration 0!"

    # 또한, 인자는 이미 합쳐진 내용이 표현되며, c 호출 방식과 차이가 난다.

    # ESP + 0x04 인자의 주소를 읽어 드림.

    parameter_addr = dbg.context.Esp + 0x04

    print ('context EIP : 0x%08x' % dbg.context.Eip)

    print ('context ESP : 0x%08x' % dbg.context.Esp)

    print ('parameter address : 0x%08x' % parameter_addr)

    counter = dbg.read_process_memory(parameter_addr, 4)

    # read_process_memory는 패킹된 바이너리 문자열을 리턴한다.

    # 따라서 그것을 사용하기 전에 먼저 언팩을 수행해야 한다.

    string_addr = struct.unpack("L", counter)[0]

    # "Loop iteration %d!\n" = 20byte

    # 다 문자열 이기 때문에 공백까지 포함해서 20byte 계산

    str_len = 15 + 3 + 2

# 문자열이 존재하는 위치를 알았으니, 해당 문자열의 주소에 문자열 사이즈 만큼 얻어옮.

    counter_string = dbg.read_process_memory(string_addr, int(str_len))

    counter_string = struct.unpack(str(str_len) + "s", counter_string)[0]

# "!\n" 내용은 필요 없으므로 제거.

    counter_string = counter_string.split("!\n")[0]

    # counter_string 에서 앞에서 15 자리까지 버리고 다음부터 자리 가지고 옴.

    counter = counter_string[15:]

    print "Counter: %d" % int(counter)

# 랜덤한 숫자를 생성

    random_counter = str(random.randint(1, 100))

# 생성된 숫자를 "Loop iteration" 이후 주소에 기록

    dbg.write_process_memory(string_addr + 0x0F, random_counter)

위와 같은 코드를 이용하면 아래와 같은 내용을 얻을 수 있다.

C로 호출하는 방식은 책에 있는 내용을 그대로 인용하면 되므로 추가적으로 언급하지 않겠다.

python 형태로 호출할 때 유념하고, 또한 python 형태로 호출하더라도 수정 될 수 있는 내용이 이므로 포기하지 말고 

마무리 짓길 바란다.

파이썬 디버기를 만들다 보면 GetSystemInfo 함수를 사용하려고 하는데

Windows 7에서는 사용하지 못하게 된다.

따라서, 해당 내용을 찾아 보면 GetSystemInfo는 Windows 7에서는 지원하지 않는 API 함수 이다.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724381(v=vs.85).aspx

하지만 다행히도 GetSystemInfo와 동일한 함수가 있다.

wow64에서 돌아가는 application에서 사용하는 함수~~!!

"GetNativeSystemInfo"

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724340(v=vs.85).aspx

GetSystemInfo와 동일한 함수이므로

스크립트를 짜는데 아무 문제가 없게 된다.

적용한 내용이다.

        system_infor = SYSTEM_INFO()

        # wow64에서 사용하는 함수
        # wow64가 아닌 환경 GetSystemInfo 함수를 사용하면 된다.
        kernel32.GetNativeSystemInfo(byref(system_infor))

그럼 오늘도 즐거운 삽질이 되시길...