Git Product home page Git Product logo

x64dbgpylib's Introduction

x64dbgpylib

Port of windbglib to x64dbgpy, in an effort to support mona.py in x64dbg.

This is a work in progress, see the issues or contact us to find out how you can help. In particular, this issue has the current state of support for mona commands; any help on the remaining commands would be appreciated.

x64dbgpylib's People

Contributors

jmreyes avatar mrexodia avatar ngo avatar realgam3 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

x64dbgpylib's Issues

State of support for mona commands

I tried out all the Mona commands using latest snapshot (2017-11-20) of x64dbg and latest release of x64dbgpy. Fixed some minor issues, but some commands that should be implemented cause x64dbg to hang.

Works, but has performance issues:

  • rop
  • compare
  • hidedebug
  • fwptr

Correctness bugs:

Not yet tested:

  • suggest — Should produce a metasploit module, can someone test?
  • skeleton — not a Metasploit user, unsure about this one

Mona WinDBG-specific Commands ( haven't checked these)

  • calltrace
  • fillchunk
  • dumpobj
  • dumplog
  • changeacl
  • allocmem
  • tobp
  • flow

Supported:

  • kb
  • heap
  • nosafesehaslr
  • noaslr
  • seh
  • config
  • jmp
  • ropfunc
  • jop
  • stackpivot
  • modules
  • filecompare
  • pattern_create
  • pattern_offset
  • find
  • findwild
  • assemble
  • info
  • dump
  • offset
  • nosafeseh
  • findmsp
  • bytearray
  • header
  • getpc
  • egghunter
  • stacks
  • breakfunc
  • getiat
  • geteat
  • pageacl
  • bpseh
  • encode
  • unicodealign
  • sehchain
  • gflags
  • infodump
  • peb
  • teb
  • string
  • copy
  • ?
  • deferbp

Commented out in mona

  • #diffheap
  • #heapcookie

porting windbglib

x64dbgpylib

Port of windbglib to x64dbgpy, in an effort to support mona.py in x64dbg.

This is a work in progress, see the issues or contact us to find out how you can help.

The original code of windbglib is around 1800 lines. This means that the effort of a full rewrite should be small, except in cases where the underlying functionality is not yet exposed by x64dbg. Contact me if you stumble across missing functionality. I will not work on the porting myself since I have no interest in doing so. I am however available if you need assistance.

Here follows an overview of the things that have to be ported (essentially a summary of the code):

Utility functions

  • getOSVersion
  • getArchitecture
  • getNtHeaders
  • clearvars
  • getPEBInfo
  • getPEBAddress
  • getTEBInfo
  • getTEBAddress
  • bin2hex
  • hexptr2bin
  • hexStrToInt
  • addrToInt
  • isAddress
  • intToHex
  • toHexByte
  • hex2bin
  • getPyKDVersion
  • isPyKDVersionCompatible
  • checkVersion
  • getModulesFromPEB
  • getModuleFromAddress

Debugger (class)

  • setKBDB
  • getKBDB
  • remoteVirtualAlloc
  • rVirtualAlloc
  • rVirtualProtect
  • getAddress
  • getCurrentTEBAddress

AsmCache

  • fillAsmCache

Knowledge

  • addKnowledge
  • getKnowledge
  • readKnowledgeDB
  • listKnowledge
  • cleanKnowledge
  • forgetKnowledge
  • cleanUp

Placeholders

  • analysecode
  • isAnalysed

LOGGING

  • toAsciiOnly
  • createLogWindow
  • log
  • logLines
  • updateLog
  • setStatusBar
  • error

Process stuff

  • getDebuggedName
  • getDebuggedPid

OS stuff

  • getOsRelease
  • getOsVersion
  • getPyKDVersionNr

Registers

  • getRegs

Commands

  • nativeCommand

SEH

  • getSehChain

Memory

  • readMemory
  • readString
  • readWString
  • readUntil
  • readLong
  • writeMemory
  • writeLong
  • getMemoryPages
  • getMemoryPageByAddress
  • getMemoryPageByOwner
  • getPageContains
  • getHeapsAddress
  • getHeap
  • getPEBAddress
  • getAllThreads

Modules

  • getModule
  • getAllModules
  • getImageNameForModule

Assembly & Disassembly related route

  • disasm
  • disasmSizeOnly
  • disasmForward
  • disasmForwardAddressOnly
  • disasmBackward
  • assemble
  • getOpcode

strings

  • readString

Breakpoints

  • setBreakpoint
  • deleteBreakpoint
  • setMemBreakpoint

Tables

  • createTable

Symbols

  • resolveSymbol

wmodule

  • wmodule class
  • getIssystemdll
  • getSymbols
  • getIATList
  • getEATList
  • getSectionAddress

Other classes

  • wtable class
  • wsymbol
  • wpage
  • Function
  • opcode
  • wthread
  • wheap
  • LogBpHook

Error in getDebuggedName that prevents mona's find from working

When trying to use mona's find feature I get the following error:

mona.mona("find -s '\xff\xe4' -m binary.exe")
=>

<b>  File "C:\tools\pwn\x64dbg\release\x32\plugins\x64dbgpy\mona.py", line 18391, in main</b>
<b>    commands[command].parseProc(opts)</b>
<b>  File "C:\tools\pwn\x64dbg\release\x32\plugins\x64dbgpy\mona.py", line 11814, in procFind</b>
<b>    thislog = logfile.reset()</b>
<b>  File "C:\tools\pwn\x64dbg\release\x32\plugins\x64dbgpy\mona.py", line 2454, in reset</b>
<b>    debuggedname = dbg.getDebuggedName()</b>
<b>  File "C:\tools\pwn\x64dbg\release\x32\plugins\x64dbgpy\x64dbgpylib.py", line 900, in getDebuggedName</b>
<b>    print offset</b>
<b>  File "C:\tools\pwn\x64dbg\release\x32\plugins\x64dbgpy\pykd.py", line 262, in loadUnicodeString</b>
<b>    raise DbgException("Corrupted UNICODE_STRING structure")</b>
<b>DbgException: Corrupted UNICODE_STRING structure</b>

The exception happens because of an error on parsing the PEB in x64dbgpylib.
In getDebuggedName, x64dbgpylib uses getPEBInfo().ProcessParameters from pykd, which returns an object of type typePtr (a pointer to a struct RTL_USER_PROCESS_PARAMETERS). It then needs to dereference the pointer and get the ImagePathName member.
So the code uses the __add__ operation of typePtr, which resolves to __add__ of typeBase, which uses the address of the typePtr itsel, instead of using the address of the struct that it points to. So, python code ProcessParameters + offset results in PEB->process_parameters + offset, but we need *(PEB->process_parameters) + offset.

Demonstration (x32 app):

  1. Get the peb addr:
Command: peb()
002FB000
  1. Get the result of the __add__ (as you can see this is peb + 0x48, which is not what we want)
Command: print hex(x64dbgpylib.getPEBInfo().ProcessParameters + 0x38)
0x2fb048

In order to have the correct pointer we have to cast ProcessParameters to int, because it will cause the __int__ method of class typePrimitive to be used (which dereferences the pointer). Verification:

Command: print hex(x64dbgpylib.getPEBInfo().ProcessParameters) + 0x38)
0x5818e8

So, the line

sImageFile = pykd.loadUnicodeString(ProcessParameters + offset).encode("utf8")

shold be changed as follows:

sImageFile = pykd.loadUnicodeString(int(ProcessParameters) + offset).encode("utf8")

After this fix mona's find command starts to work for me.

sImageFile = pykd.loadUnicodeString(ProcessParameters + offset).encode("utf8")

Need to reload mona and x64dbgpylib when new exe is opened

Right now, loading a new file does not clear the global variables in x64dbgpylib, so mona will return old values. I have to manually reload with reload(mona); reload(mona.dbglib), etc...

@mrexodia Maybe leave it to x64dbgpy to blow away all state and modules when a new exe is loaded?

Performance issues

Most of the remaining issues in mona are performance issues. Some commands, usually ones that read or write a lot of memory, simply take too long to run, or cause x64dbg to hang. I could use some help investigating.

See #5

Exception when not debugger attached to a process

Hi,

First of all, thanks so much for working on mona support for x64dbg - awesome job!

I got mona up and running successfully in x64dbg, and one of the first commands I tried was pc:

[+] Command used:
!mona pc 100
Creating cyclic pattern of 100 bytes
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
[+] Preparing output file 'pattern.txt'
<pykd.typePtr object at 0x05AA0770>
<b>********************************************************************************</b>
<b>Traceback (most recent call last):</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\mona.py", line 18398, in main</b>
<b>    commands[cmd].parseProc(opts)</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\mona.py", line 11601, in procCreatePATTERN</b>
<b>    patternfile = objpatternfile.reset()</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\mona.py", line 2454, in reset</b>
<b>    debuggedname = dbg.getDebuggedName()</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\x64dbgpylib.py", line 901, in getDebuggedName</b>
<b>    sImageFile = pykd.loadUnicodeString(ProcessParameters + offset).encode("utf8")</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\pykd.py", line 261, in loadUnicodeString</b>
<b>    raise DbgException("Corrupted UNICODE_STRING structure")</b>
<b>DbgException: Corrupted UNICODE_STRING structure</b>
<b></b>
<b>********************************************************************************</b>

The root cause here seems to be that there was nothing being debugged at the time, and so the pointer returned by getPEBInfo is garbage (which is then used to try and get the name of the process being debugged). I had a bit of a dig around to try and make a fix for this but was a bit unsure how to proceed - ideally I thought there might be a flag to check in x64dbgpylib.Debugger as to whether the debugger is attached to something, but I coudn't see anything (I may just have missed it!)

I also checked getDebuggedPid, which did return a value which I assume is also garbage. I noticed that the equivalent code in windbglib didn't have any extra checks, so I assume that the backend there behaves differently in this case?

Cheers,
Ben

Might be reading wrong value from ImageBase in NT Header

To determine whether a module has been rebased, mona checks whether ntHeader.OptionalHeader.ImageBase is equal to the actual base address in memory. However, for all the Microsoft DLLs, it seems the ImageBase field is changed to its base address in memory?

Somehow, Immunity gets the ImageBase field of the DLLs before they're changed, correctly marking all the Microsoft DLLs as rebased.

x64dbg:

 Module info :
-----------------------------------------------------------------------------------------------------------------------------------------
 Base       | Top        | Size       | Rebase | SafeSEH | ASLR  | NXCompat | OS Dll | Version, Modulename & Path
-----------------------------------------------------------------------------------------------------------------------------------------
 0x00020000 | 0x0002e000 | 0x0000e000 | True   | False   | False |  False   | False  | -1.0- [DLL2.dll] (dll2.dll)
 0x6b130000 | 0x6b139000 | 0x00009000 | False  | False   | True  |  True    | False  | -1.0- [SCHEDCLI.DLL] (schedcli.dll)
 0x00400000 | 0x00409000 | 0x00009000 | False  | False   | False |  False   | False  | -1.0- [Lab09-03.exe] (lab09-03.exe)
 0x6b7c0000 | 0x6b7ca000 | 0x0000a000 | False  | False   | True  |  True    | False  | -1.0- [netutils.dll] (netutils.dll)
 0x74d10000 | 0x74de7000 | 0x000d7000 | False  | False   | True  |  True    | False  | -1.0- [KERNELBASE.dll] (kernelbase.dll)
 0x74ca0000 | 0x74cf4000 | 0x00054000 | False  | False   | True  |  True    | False  | -1.0- [bcryptPrimitives.dll] (bcryptprimitives.dll)
 0x6b440000 | 0x6b45d000 | 0x0001d000 | False  | False   | True  |  True    | False  | -1.0- [srvcli.dll] (srvcli.dll)
 0x755d0000 | 0x75710000 | 0x00140000 | False  | False   | True  |  True    | False  | -1.0- [KERNEL32.DLL] (kernel32.dll)
 0x75ab0000 | 0x75b73000 | 0x000c3000 | False  | False   | True  |  True    | False  | -1.0- [msvcrt.dll] (msvcrt.dll)
 0x74d00000 | 0x74d0a000 | 0x0000a000 | False  | True    | True  |  True    | False  | -1.0- [CRYPTBASE.dll] (cryptbase.dll)
 0x75b80000 | 0x75b9e000 | 0x0001e000 | False  | False   | True  |  True    | False  | -1.0- [SspiCli.dll] (sspicli.dll)
 0x77520000 | 0x7768f000 | 0x0016f000 | False  | False   | True  |  True    | True   | -1.0- [ntdll.dll] (ntdll.dll)
 0x750b0000 | 0x7516a000 | 0x000ba000 | False  | False   | True  |  True    | False  | -1.0- [RPCRT4.dll] (rpcrt4.dll)
 0x6b140000 | 0x6b153000 | 0x00013000 | False  | False   | True  |  True    | False  | -1.0- [NETAPI32.dll] (netapi32.dll)
 0x75330000 | 0x75371000 | 0x00041000 | False  | False   | True  |  True    | False  | -1.0- [sechost.dll] (sechost.dll)
 0x6b5f0000 | 0x6b601000 | 0x00011000 | False  | False   | True  |  True    | False  | -1.0- [wkscli.dll] (wkscli.dll)
 0x10000000 | 0x1000e000 | 0x0000e000 | False  | False   | False |  False   | False  | -1.0- [DLL1.dll] (dll1.dll)
-----------------------------------------------------------------------------------------------------------------------------------------

Immunity:

0BADF0   Module info :
0BADF0  -----------------------------------------------------------------------------------------------------------------------------------------
0BADF0   Base       | Top        | Size       | Rebase | SafeSEH | ASLR  | NXCompat | OS Dll | Version, Modulename & Path
0BADF0  -----------------------------------------------------------------------------------------------------------------------------------------
0BADF0   0x00020000 | 0x0002e000 | 0x0000e000 | True   | False   | False |  False   | False  | -1.0- [DLL2.dll] (C:\Users\raywang\Documents\Practical Malware Analysis Labs\BinaryCollection\Chapter_9L\DLL2.dll)
0BADF0   0x71620000 | 0x71634000 | 0x00014000 | True   | False   | True  |  True    | True   | 6.3.9600.17415 [cryptdll.dll] (C:\Windows\SYSTEM32\cryptdll.dll)
0BADF0   0x00400000 | 0x00409000 | 0x00009000 | False  | False   | False |  False   | False  | -1.0- [Lab09-03.exe] (C:\Users\raywang\Documents\Practical Malware Analysis Labs\BinaryCollection\Chapter_9L\Lab09-03.exe)
0BADF0   0x6b7c0000 | 0x6b7ca000 | 0x0000a000 | True   | False   | True  |  True    | True   | 6.3.9600.17415 [netutils.dll] (C:\Windows\SYSTEM32\netutils.dll)
0BADF0   0x74d10000 | 0x74de7000 | 0x000d7000 | True   | False   | True  |  True    | True   | 6.3.9600.18217 [KERNELBASE.dll] (C:\Windows\SYSTEM32\KERNELBASE.dll)
0BADF0   0x74ca0000 | 0x74cf4000 | 0x00054000 | True   | False   | True  |  True    | True   | 6.3.9600.18344 [bcryptPrimitives.dll] (C:\Windows\SYSTEM32\bcryptPrimitives.dll)
0BADF0   0x6b440000 | 0x6b45d000 | 0x0001d000 | True   | False   | True  |  True    | True   | 6.3.9600.17415 [srvcli.dll] (C:\Windows\SYSTEM32\srvcli.dll)
0BADF0   0x00030000 | 0x0003e000 | 0x0000e000 | True   | False   | False |  False   | False  | -1.0- [DLL3.dll] (C:\Users\raywang\Documents\Practical Malware Analysis Labs\BinaryCollection\Chapter_9L\DLL3.dll)
0BADF0   0x755d0000 | 0x75710000 | 0x00140000 | True   | False   | True  |  True    | True   | 6.3.9600.18217 [KERNEL32.DLL] (C:\Windows\SYSTEM32\KERNEL32.DLL)
0BADF0   0x71640000 | 0x71692000 | 0x00052000 | True   | False   | True  |  True    | True   | 6.3.9600.16384 [msv1_0.DLL] (C:\Windows\SYSTEM32\msv1_0.DLL)
0BADF0   0x6b130000 | 0x6b139000 | 0x00009000 | True   | False   | True  |  True    | True   | 6.3.9600.17415 [SCHEDCLI.DLL] (C:\Windows\SYSTEM32\SCHEDCLI.DLL)
0BADF0   0x75ab0000 | 0x75b73000 | 0x000c3000 | True   | False   | True  |  True    | True   | 7.0.9600.17415 [msvcrt.dll] (C:\Windows\SYSTEM32\msvcrt.dll)
0BADF0   0x75b80000 | 0x75b9e000 | 0x0001e000 | True   | False   | True  |  True    | True   | 6.3.9600.18454 [SspiCli.dll] (C:\Windows\SYSTEM32\SspiCli.dll)
0BADF0   0x750b0000 | 0x7516a000 | 0x000ba000 | True   | False   | True  |  True    | True   | 6.3.9600.16384 [RPCRT4.dll] (C:\Windows\SYSTEM32\RPCRT4.dll)
0BADF0   0x77520000 | 0x7768f000 | 0x0016f000 | True   | False   | True  |  True    | True   | 6.3.9600.18217 [ntdll.dll] (C:\Windows\SYSTEM32\ntdll.dll)
0BADF0   0x74d00000 | 0x74d0a000 | 0x0000a000 | True   | True    | True  |  True    | True   | 6.3.9600.17415 [CRYPTBASE.dll] (C:\Windows\SYSTEM32\CRYPTBASE.dll)
0BADF0   0x6b140000 | 0x6b153000 | 0x00013000 | True   | False   | True  |  True    | True   | 6.3.9600.17415 [NETAPI32.dll] (C:\Windows\SYSTEM32\NETAPI32.dll)
0BADF0   0x75330000 | 0x75371000 | 0x00041000 | True   | False   | True  |  True    | True   | 6.3.9600.16384 [sechost.dll] (C:\Windows\SYSTEM32\sechost.dll)
0BADF0   0x6b5f0000 | 0x6b601000 | 0x00011000 | True   | False   | True  |  True    | True   | 6.3.9600.17415 [wkscli.dll] (C:\Windows\SYSTEM32\wkscli.dll)
0BADF0   0x10000000 | 0x1000e000 | 0x0000e000 | False  | False   | False |  False   | False  | -1.0- [DLL1.dll] (C:\Users\raywang\Documents\Practical Malware Analysis Labs\BinaryCollection\Chapter_9L\DLL1.dll)
0BADF0  -----------------------------------------------------------------------------------------------------------------------------------------
0BADF0
0BADF0
0BADF0  [+] This mona.py action took 0:00:00.282000

How do we get the same behavior as Immunity?

make appropriate changes to mona.py

More specifically

try:
	import immlib as dbglib
	from immlib import LogBpHook
	__DEBUGGERAPP__ = "Immunity Debugger"
except:		
	try:
		from pykd import *
		import windbglib as dbglib
		from windbglib import LogBpHook
		dbglib.checkVersion()
		arch = dbglib.getArchitecture()
		__DEBUGGERAPP__ = "WinDBG"
	except SystemExit, e:
		print "-Exit."
		import sys
		sys.exit(e)
	except Exception:
		#import traceback
		print "Do not run this script outside of a debugger !"
		#print traceback.format_exc()
		import sys
		exit(1)

And various usages of __DEBUGGERAPP__.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.