반응형
babyhack@ubuntu:~/tmp$ sudo pip3 install pip --upgrade
Traceback (most recent call last):
  File "/usr/bin/pip3", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.5/dist-packages/pip/__init__.py", line 11, in main
    from pip._internal.utils.entrypoints import _wrapper
  File "/usr/local/lib/python3.5/dist-packages/pip/_internal/utils/entrypoints.py", line 12
    f"pip{sys.version_info.major}",
                                 ^
SyntaxError: invalid syntax
babyhack@ubuntu:~/tmp$ wget https://bootstrap.pypa.io/pip/3.5/get-pip.py
--2023-02-10 00:21:55--  https://bootstrap.pypa.io/pip/3.5/get-pip.py
Resolving bootstrap.pypa.io (bootstrap.pypa.io)... 151.101.0.175, 151.101.64.175, 151.101.128.175, ...
Connecting to bootstrap.pypa.io (bootstrap.pypa.io)|151.101.0.175|:443... connected.
HTTP request sent, awaiting response...
200 OK
Length: 1908223 (1.8M) [text/x-python]
Saving to: ‘get-pip.py’

get-pip.py                           100%[===================================================================>]   1.82M  6.01MB/s    in 0.3s

2023-02-10 00:21:55 (6.01 MB/s) - ‘get-pip.py’ saved [1908223/1908223]

babyhack@ubuntu:~/tmp$ python3 get-pip.py
DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.
Defaulting to user installation because normal site-packages is not writeable
Collecting pip<21.0
  Downloading pip-20.3.4-py2.py3-none-any.whl (1.5 MB)
     |████████████████████████████████| 1.5 MB 7.7 MB/s
Installing collected packages: pip
Successfully installed pip-20.3.4
babyhack@ubuntu:~/tmp$ sudo pip3 install pip --upgrade
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
DEPRECATION: Python 3.5 reached the end of its life on September 13th, 2020. Please upgrade your Python as Python 3.5 is no longer maintained. pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will remove support for this functionality.
WARNING: The directory '/home/babyhack/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Requirement already satisfied: pip in /home/babyhack/.local/lib/python3.5/site-packages (20.3.4)
Collecting pip
  Downloading pip-20.3.4-py2.py3-none-any.whl (1.5 MB)
     |████████████████████████████████| 1.5 MB 5.8 MB/s
  Downloading pip-20.3.3-py2.py3-none-any.whl (1.5 MB)
     |████████████████████████████████| 1.5 MB 9.4 MB/s
babyhack@ubuntu:~/tmp$

 

명령어

반응형

'프로그래밍 > Python' 카테고리의 다른 글

[codegate2016] compress 복호화  (0) 2016.03.16
File Fuzzer v.0.1  (2) 2013.08.11
danger_track를 이용한 crash dump 활용  (0) 2013.07.30
win7 에서 pydbg 이용한 snap 찍기  (0) 2013.07.29
Windows 7에서 pydbg 설치 하기  (0) 2013.07.26
반응형

삽질은 삽질로써 의미가 있다.

 

4byte 먼저 돌리고, 2byte씩 돌리는 방식

하지만, 동일한 값이 중간에 나오므로 이상한 문자가 나오면 따로 분리하여 결과물을 확인 해야함.

 

 

 

반응형
반응형

 

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

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

 

문제는 취약한 파일의 이슈

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

 

코드를 보고 계속 탐구 한 끝에 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)

ERROR_INVALID_PARAMETER
 

 

 

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

 

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

댓글 남겨주셈~~T-T

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

have a good day.

반응형
반응형

These instructions are for Windows XP => Windows 7 using Python 2.7 (though other versions should work too)

Thanks to louppen for the great starting point!

  1. Download and install MinGW Compilier v20101030
    • Make sure to use pre-packaged repo catalogs and the old version! PyDasm barfs when compiling because MinGW32 removed support for -mno-cygwin! Bug Report
    • On the "Select Components" dialog check C++ Compiler and ObjC Compiler in addition to selected by default set
  2. Download and install Python 2.7 (x64)
  3. Download and install Git for windows
    • Make sure it adds git to your path variable!
  4. Update $PATH to include C:\Python27 and C:\MinGW\bin KB article
  5. Checkout pydbg

    C:\sulley_build>git clone https://Fitblip@github.com/Fitblip/pydbg.git
    Cloning into 'pydbg'...
    remote: Counting objects: 17, done.
    remote: Compressing objects: 100% (12/12), done.
    remote: Total 17 (delta 4), reused 17 (delta 4)
    Unpacking objects: 100% (17/17), done.
    
  6. Build pydbg

    C:\sulley_build\pydbg>python setup.py install
    running install
    running build
    running build_py
    creating build
    creating build\lib
    creating build\lib\pydbg
    ...snip...
    running install_egg_info
    Removing C:\python27\Lib\site-packages\pydbg-0.0.0-py2.7.egg-info
    Writing C:\python27\Lib\site-packages\pydbg-0.0.0-py2.7.egg-info
    
  7. Download and extract libdasm

  8. Build the extention and install it (beware of gcc version 4.7.x removed support for -mno-cygwin, seehttp://stackoverflow.com/q/6034390/333353 and https://gist.github.com/4466320 for a fix)

    C:\sulley_build\libdisasm\pydasm>python setup.py build_ext -c mingw32
    running build_ext
    building 'pydasm' extension
    ...snip...
    C:\sulley_build\libdisasm\pydasm>python setup.py install
    running install
    running build
    running build_ext
    running install_lib
    copying build\lib.win32-2.7\pydasm.pyd -> C:\python27\Lib\site-packages
    running install_egg_info
    Writing C:\python27\Lib\site-packages\pydasm-1.5-py2.7.egg-info
    
  9. Checkout Sulley

    C:\sulley_build>git clone https://github.com/OpenRCE/sulley.git
    Cloning into 'sulley'...
    remote: Counting objects: 148, done.
    remote: Compressing objects: 100% (91/91), done.
    remote: Total 148 (delta 53), reused 146 (delta 51)
    Receiving objects: 100% (148/148), 267.03 KiB, done.
    Resolving deltas: 100% (53/53), done.
    
  10. Make sure process_monitor.py works (no import errors)

     C:\sulley_build\sulley>python process_monitor.py
     ERR> USAGE: process_monitor.py
         <-c|--crash_bin FILENAME> filename to serialize crash bin class to
         [-p|--proc_name NAME]     process name to search for and attach to
         [-i|--ignore_pid PID]     ignore this PID when searching for the target process
         [-l|--log_level LEVEL]    log level (default 1), increase for more verbosity
         [--port PORT]             TCP port to bind this agent to
    
  11. Download and extract PCapy

  12. Download and extract WinPcap Dev Kit (I put mine in C:\sulley_build\WpdPack)

  13. Build PCapy (pointing to WinPcap's include and lib directories) and install it

    C:\sulley_build\pcapy-0.10.5>python setup.py build_ext -c mingw32 -I "C:\sulley_build\WpdPack\Include" -L "C:\sulley_build\WpdPack\Lib"
    running build_ext
    building 'pcapy' extension
    creating build
    creating build\temp.win32-2.7
    creating build\temp.win32-2.7\Release
    creating build\temp.win32-2.7\Release\win32
    ...snip...
    C:\sulley_build\pcapy-0.10.5>python setup.py install
    running install
    running build
    running build_ext
    running install_lib
    copying build\lib.win32-2.7\pcapy.pyd -> C:\python27\Lib\site-packages
    running install_data
    creating C:\python27\share
    creating C:\python27\share\doc
    creating C:\python27\share\doc\pcapy
    copying README -> C:\python27\share\doc\pcapy
    copying LICENSE -> C:\python27\share\doc\pcapy
    copying pcapy.html -> C:\python27\share\doc\pcapy
    running install_egg_info
    Writing C:\python27\Lib\site-packages\pcapy-0.10.5-py2.7.egg-info
    
  14. Download and install WinPcap

  15. Download and extract Impacket

  16. Install Impacket

    C:\sulley_build\Impacket-0.9.6.0>python setup.py install
    running install
    running build
    running build_py
    creating build
    creating build\lib
    creating build\lib\impacket
    copying impacket\ImpactDecoder.py -> build\lib\impacket
    copying impacket\ImpactPacket.py -> build\lib\impacket
    copying impacket\nmb.py -> build\lib\impacket
    copying impacket\ntlm.py -> build\lib\impacket
    copying impacket\smb.py -> build\lib\impacket
    copying impacket\structure.py -> build\lib\impacket
    copying impacket\uuid.py -> build\lib\impacket
    copying impacket\__init__.py -> build\lib\impacket
    creating build\lib\impacket\dcerpc
    ...snip...
    
  17. Check to make sure network_monitor.py works

    C:\sulley_build\sulley>python network_monitor.py
    ERR> USAGE: network_monitor.py
        <-d|--device DEVICE #>    device to sniff on (see list below)
        [-f|--filter PCAP FILTER] BPF filter string
        [-P|--log_path PATH]      log directory to store pcaps to
        [-l|--log_level LEVEL]    log level (default 1), increase for more verbosity
    
        [--port PORT]             TCP port to bind this agent to
    
    Network Device List:
        [0] \Device\NPF_GenericDialupAdapter
        [1] {CF0B388B-8DF5-4BC4-8ECF-404F2A1B489C}  10.0.2.64


반응형
반응형


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


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 wanglong1982http://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))

 

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

반응형
반응형

 

 

 

 버전을 끊어가면서 해야할 것 같아

중간 중간 마무리 되면 버전을 남기기로 하였다.

 

W7PD by crattack. (v.0.3)

- 기능

  ★  Memory break point 적용

 

 

W7PD by crattack. (v.0.2)

- 기능

  ★  hardware break point 적용

 

 

 

Win7 Python Debugger by crattack. (v. 0.1) (- 이후 부턴 W7PD by crattack)

- 기능

  ★  GetModuleHandle 사용한 메모리 주소 찍기

  ★  해당 함수 주소 찍기

  ★  soft break point 적용

 

 

반응형
반응형

 

python 2.7.5 버전을 사용하다가 python 3.x 버전을 사용하니 has_key() 를 사용하지 못하게 되었다.

따라서, 이 것을 대응 할 수 있는 함수가 바로 in 어떻게 사용하는지 예시로 남긴다.

 

[초기 값] 

d = {'a': 1, 'b': 2}

 

 

[has_key 이용 - 3.x 이전 버전]

if d.has_key('a'):

    print "포함되어 있네"

else:

    print "포함되지 않음"

 

[in 이용 - 3.x 이후 버전]

if 'a' in d:

    print "포함되어 있네"

else:

    print "포함되지 않음"

 

이렇게 사용하면 된다.

누군가가 나와 같은 삽질이 안했으면 하는 바램으로....

반응형

+ Recent posts