Хочу представить вам новую, кардинально переработанную версию pykd.
Страница для закачки: download
Сейчас ветка 0.1.x находится в статусе альфа и имеет ряд недоделок, которые будут постепенно устраняться. Мы очень надеемся, чтои вы найдете время протестировать новую версию и сообщить нам свое мнение о новом функционале и найденных ошибках. Это позволит быстрее довести продукт до стабильного состояния.
Основные фичи новой ветки:
1) Работа с символами через библиотеку MS DIA. Это позволило реализовать доступ к битовым полям, типам-энумераторам, работать с многомерными массивами и указателями на массивы
2) Доступ к DIA выведен в интерфейс для Python. Так что можно работать с отладочной информацией самостоятельно
3) Поддерживается работа с несколькими клиентами одновременно, т.е. можно из одного скрипта управлять отладкой нескольких приложений или систем.
4) Несколько изменен API
5) Для windbg команда !pycmd предоставляет теперь полноценную консоль python, идентичную стандартной. Для команды !py улучшен вывод информации об ошибках, в том числе синтаксических
Повторю еще раз, нам очень нужены ваши отзывы, в первую очередь по API. Так как мы отказались от полной обратной совместимости с предыдущей версией, мы сейчас имеем возможность исправить API и сделать его более понятным и удобным.
Дальнейший план развития такой:
Ветка 0.0.x больше развиваться не будет, будем только фиксить баги и, возможно, что-то потом интегрируем из 0.1.x.
Спасибо, что используете наш продукт :).
пятница, 16 декабря 2011 г.
понедельник, 10 октября 2011 г.
Обработка исключений и точек останова
В pykd v. 0.0.20 появился новый полезный функционал: обработка исключений и точек останова. Возможность обработки этих событий реализована новыми методами класса debugEvent: onBreakpoint и onException. Для использования этого функционала, как и в случае с событиями загрузки/выгрузки модулей, необходимо реализовать свои вышеописанные обработчики. Сведения о произошедшем событии передаются в эти методы словарями, ключи и типы значений которых указаны в документации. Следует отметить, что для события срабатывания точки останова количество сформированных пар, может быть меньше, чем описано: если точка останова не обладает каким-либо свойством, данные не заносятся в словарь. А состав словаря, передаваемого в обработчик исключения, более стабилен: варьируется только список параметров исключения. Но даже, если у исключения нет параметров, то в словаре все равно окажется список, который будет пуст.
У pykd уже был класс bp, который позволяет ставить/снимать точку останова и назначать собственный обработчик. Этот класс так остался, так как имеет более простой интерфейс, но он был расширен новым конструктором, в который передается только целевой адрес. При установке такой точки, вместо вызова обработчика просто возвращается статус DEBUG_STATUS_BREAK.
Новый функционал debugEvent::onBreakpoint реализован не как замена, а как альтернатива существующему механизму. То есть в одном и том же скрипте можно использовать как механизм bp, так и переопределение метода debugEvent::onBreakpoint. Это было сделано для того, что бы можно было управлять исключениями и точками останова из одного класса - debugEvent.
Мы достаточно мало освещаем тот факт, что pykd не только расширение к WinDbg, но и полноценный модуль для языка python, который позволяет получить доступ к API Debug Engine. Поэтому пример использования обработки исключений будет нацелен именно на такой подход: samples\watchDog.py. В начале скрипт, если переданы аргументы командной строки, стартует указанный отлаживаемый процесс. Затем он ставит обработчик исключения и ожидает возникновения исключения. Но это так же полноценный скрипт для pykd, функционирующего как расширение WinDbg. Например, при вызове из WinDbg можно не указывать параметров, тогда скрипт будет следить за исключениями на отлаживаемом объекте.
Важной особенностью логики скрипта является пропуск исключений, для которых FirstChance == True. Это необходимо для того, что бы пропускать исключения, которые возможно будут обработаны самим отлаживаемым объектом, например если исключение произошло в блоке SEH'а.
Теперь запускаем скрипт командной строкой "python watchDog.py test.exe". Тем самым pykd от лица процесса python.exe создаст отлаживаемый процесс test.exe, который запустится на исполнение с предварительно установленным обработчиком исключений. В test.exe специально был включен следующий код:
Результат исполнения скрипта следующий:
*** shit happens
Exception code : EXCEPTION_ACCESS_VIOLATION
Exception flags : 0
Exception record : 0x0
Exception address : 0x40122C(00401010) test!main+0x21c | (00401250) test!Define_the_symbol__ATL_MIXED::Thank_you::Thank_you
Parameters :
0x1
0x3
eax=00000000 ebx=0018fa64 ecx=00000000 edx=00000000 esi=00401222 edi=00000000eip=774c15ee esp=0018fa50 ebp=0018ff40 iopl=0 nv up ei pl zr na pe nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246ntdll!ZwRaiseException+0x12:774c15ee 83c404 add esp,4
ChildEBP RetAddr Args to Child
0018ff40 004017f3 00000001 00302330 00302370 ntdll!ZwRaiseException+0x120018ff88
76ae339a 7efde000 0018ffd4 774d9ed2 test!__tmainCRTStartup+0xfb0018ff94
774d9ed2 7efde000 62b6a849 00000000 kernel32!BaseThreadInitThunk+0x120018ffd4
774d9ea5 0040184a 7efde000 ffffffff ntdll!RtlInitializeExceptionChain+0x630018ffec
00000000 0040184a 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36
Как видно по второму параметру исключения (адрес памяти - 0x3) скрипт поймал именно необрабатываемое исключение: использования неверного указателя *(char *)3 = 1. Если включить дополнительную трассировку (например, вывод в консоль) для FirstChance == True, то можно увидеть, что onException срабатывает 3-а раза, первые 2-а из которых игнорируются, так как могут быть обработаны отлаживаемым объектом.
У pykd уже был класс bp, который позволяет ставить/снимать точку останова и назначать собственный обработчик. Этот класс так остался, так как имеет более простой интерфейс, но он был расширен новым конструктором, в который передается только целевой адрес. При установке такой точки, вместо вызова обработчика просто возвращается статус DEBUG_STATUS_BREAK.
Новый функционал debugEvent::onBreakpoint реализован не как замена, а как альтернатива существующему механизму. То есть в одном и том же скрипте можно использовать как механизм bp, так и переопределение метода debugEvent::onBreakpoint. Это было сделано для того, что бы можно было управлять исключениями и точками останова из одного класса - debugEvent.
Мы достаточно мало освещаем тот факт, что pykd не только расширение к WinDbg, но и полноценный модуль для языка python, который позволяет получить доступ к API Debug Engine. Поэтому пример использования обработки исключений будет нацелен именно на такой подход: samples\watchDog.py. В начале скрипт, если переданы аргументы командной строки, стартует указанный отлаживаемый процесс. Затем он ставит обработчик исключения и ожидает возникновения исключения. Но это так же полноценный скрипт для pykd, функционирующего как расширение WinDbg. Например, при вызове из WinDbg можно не указывать параметров, тогда скрипт будет следить за исключениями на отлаживаемом объекте.
Важной особенностью логики скрипта является пропуск исключений, для которых FirstChance == True. Это необходимо для того, что бы пропускать исключения, которые возможно будут обработаны самим отлаживаемым объектом, например если исключение произошло в блоке SEH'а.
Теперь запускаем скрипт командной строкой "python watchDog.py test.exe". Тем самым pykd от лица процесса python.exe создаст отлаживаемый процесс test.exe, который запустится на исполнение с предварительно установленным обработчиком исключений. В test.exe специально был включен следующий код:
__try { *(char *)0 = 1; } __except(EXCEPTION_EXECUTE_HANDLER) {}
*(char *)3 = 1;
Результат исполнения скрипта следующий:
*** shit happens
Exception code : EXCEPTION_ACCESS_VIOLATION
Exception flags : 0
Exception record : 0x0
Exception address : 0x40122C(00401010) test!main+0x21c | (00401250) test!Define_the_symbol__ATL_MIXED::Thank_you::Thank_you
Parameters :
0x1
0x3
eax=00000000 ebx=0018fa64 ecx=00000000 edx=00000000 esi=00401222 edi=00000000eip=774c15ee esp=0018fa50 ebp=0018ff40 iopl=0 nv up ei pl zr na pe nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246ntdll!ZwRaiseException+0x12:774c15ee 83c404 add esp,4
ChildEBP RetAddr Args to Child
0018ff40 004017f3 00000001 00302330 00302370 ntdll!ZwRaiseException+0x120018ff88
76ae339a 7efde000 0018ffd4 774d9ed2 test!__tmainCRTStartup+0xfb0018ff94
774d9ed2 7efde000 62b6a849 00000000 kernel32!BaseThreadInitThunk+0x120018ffd4
774d9ea5 0040184a 7efde000 ffffffff ntdll!RtlInitializeExceptionChain+0x630018ffec
00000000 0040184a 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36
Как видно по второму параметру исключения (адрес памяти - 0x3) скрипт поймал именно необрабатываемое исключение: использования неверного указателя *(char *)3 = 1. Если включить дополнительную трассировку (например, вывод в консоль) для FirstChance == True, то можно увидеть, что onException срабатывает 3-а раза, первые 2-а из которых игнорируются, так как могут быть обработаны отлаживаемым объектом.
воскресенье, 9 октября 2011 г.
Release 0.0.20
Всем доброго дня! Спешу представить очередной релиз pykd - версия 0.0.20.
Для тех, кто предпочитает словам дела, страница загрузки и удачи в использовании! Я же хотел кратко пробежаться по составу релиза:
Добавлены следующие функции: breakin, attachProcess, attachKernel, debuggerPath
Наличие функции breakin позволяет написать с помощью pykd свой отладчик. А функции attachProcess и attachKernel в этом помогут ( напомню, что ранее уже были реализованы функции loadDump и createProcess ).
Функция debuggerPath возвращает полный путь к исполняемому модулю программы, использующей pykd. Если вы, к примеру, захотите модифицировать файл symsrv.ini - она может быть полезна.
В ближайшее время мы опубликуем тутор по разработке отладчика на PySide. Следите за блогом!
Дополнен такой казалось бы малозначительной деталью, как конструктор с параметром "индекс регистра". Это позволяет реализовать перечисление всех регистров CPU:
Добавлен конструктор, принимающий имя переменной нужного типа. При этом сам тип указывать не надо, он будет взят из отладочной информации. Т.е достаточно написать:
var = typedVar( myModule.myVar )
Это особенно удобно при работе с переменными, тип которых заранее не известен. Например, с шаблонами С++.
Добавлен метод assembly, позволяющий изменять код по укзанному ( по умолчанию: по текущему ) смещению:
Возвращает тип процессора. Функция вернет строку, описывающую тип физического процессора. Сравните с getProcessorMode, которая возвращает текущий режим. Вот так, к примеру, можно было бы реализовать команду !sw из стандартного расширения wow64ext:
9219: улучшена поддержка многопоточности. Функции, которые могут надолго заблокировать исполнение python программы ( такие как go() и dbgCommand() ) сохраняют состояние потока, что позволяет планировщику python выполнять код в других потоках
9518: Исправлен баг с выводом текста через команду dprint(ln). До этого текст, содержащий символ '%' выводился неправильно ( обычно, обрезался ).
9555: Метод name() класса dbgModuleClass возвращал строку, содержащую нулевой символ. В итоге при использовании данного метода вывод мог повреждаться ( обрезаться )
Для тех, кто предпочитает словам дела, страница загрузки и удачи в использовании! Я же хотел кратко пробежаться по составу релиза:
Управление отладчиком:
Добавлены следующие функции: breakin, attachProcess, attachKernel, debuggerPath
Наличие функции breakin позволяет написать с помощью pykd свой отладчик. А функции attachProcess и attachKernel в этом помогут ( напомню, что ранее уже были реализованы функции loadDump и createProcess ).
Функция debuggerPath возвращает полный путь к исполняемому модулю программы, использующей pykd. Если вы, к примеру, захотите модифицировать файл symsrv.ini - она может быть полезна.
В ближайшее время мы опубликуем тутор по разработке отладчика на PySide. Следите за блогом!
класс cpuReg
Дополнен такой казалось бы малозначительной деталью, как конструктор с параметром "индекс регистра". Это позволяет реализовать перечисление всех регистров CPU:
def getRegisterSet(self): regSet=[] try: i = 0 while True: reg = pykd.cpuReg(i) regSet.append(reg) i += 1 except pykd.BaseException: pass return regSet
класс typedVar
Добавлен конструктор, принимающий имя переменной нужного типа. При этом сам тип указывать не надо, он будет взят из отладочной информации. Т.е достаточно написать:
var = typedVar( myModule.myVar )
Это особенно удобно при работе с переменными, тип которых заранее не известен. Например, с шаблонами С++.
класс disasm
Добавлен метод assembly, позволяющий изменять код по укзанному ( по умолчанию: по текущему ) смещению:
nt = loadModule( "nt" ) dasm = disasm( nt.NtCreateFile ) dasm.assembly( "int 3" )
getProcessorType
Возвращает тип процессора. Функция вернет строку, описывающую тип физического процессора. Сравните с getProcessorMode, которая возвращает текущий режим. Вот так, к примеру, можно было бы реализовать команду !sw из стандартного расширения wow64ext:
if getProcessorType() == "X64": setProcessorMode( {"X64": "X86", "X86": "X64"}[ getProcessorMode() ] )
багфикс
пятница, 29 июля 2011 г.
Release 0.0.19
Представляем ( не без затаенной гордости конечно ) очередной релиз pykd 0.0.19. Мы немного запоздали по срокам выпуска, надеемся на ваше понимание. И так, что новенького:
!pycmd теперь поддерживает многострочный ввод. Пробуем:
!py и !pycmd выводят теперь traceback при возникновении исключения при исполнении. Надеемся, это сделает отладку скриптов чуть-чуть удобнее.
Кстати, про исключения. В предыдущем релизе ( 0.0.18 ) был реализован механизм трансляции ошибок pykd в исключения python. В этом релизе мы провели рефакторинг некоторых модулей. Будьте готовы, что функции ранее возвращавшие 0, None или "" будут кидать исключение и некоторые скрипты перестанут работать. Возможно, вас утешит, что обработка ошибок через обработку исключений сделает код в итоге более надежным и понятным ( положа руку на сердце, это конечно спорный момент или, как минимум, обсуждаемый ).
Это дизассемблер. Конечно не полноценный, он не разбирает инструкции на операнды. Тем не менее, простые задачи ему вполне по силам. Пользоваться просто:
setMSR - функция меняет значение MSR регистра.
классу typedVar добавили метод data, возвращающий данные в виде питоновской строки. Такую строку можно обработать например с помощью ctypes или записать в файл
issue 8655
Игнорировались поля безымянных структур и объединений. Теперь - не игнорируются.
issue 8927
Если поле структуры имеет перечисляемый тип, то узнать его числовое значение нельзя. Т.е конечно можно с помощью такого трика:
val = ptrDword( structVar.enumField.getAddress() )
Хорошая новость, теперь можно писать:
val = structVar.enumField
Плохая новость: предыдущий трик перестал работать, потому что у типа long нет метода getAddress().
Но не все уж так плохо: в настоящий релиз вошел класс intBase, позволяющий включать его в операции с целыми числами. В следующей версии мы планируем переделать класс typedVar и хранить атрибуты, представляющие целые числа и указатели, в объектах-наследниках типа intBase. Это, к примеру позволит обращаться не только к членам структуры, но также и к данным, доступным по указателям. Короче говоря, планов много, будем стараться их осуществить.
В заключение хотел напомнить: Друзья, у вас все еще есть блестящая возможность поучаствовать в разработке pykd. Очень нужны: С++ кодер - для работы с ядром pykd, python кодер - для разработки тестов ( у нас есть тесты! целых два!!! ), python кодер - для разработки библиотеки, русско-англо-xxx-язычный технический писатель.
Доработан интерфейс для windbg
!pycmd теперь поддерживает многострочный ввод. Пробуем:
kd>!pycmd >>>def hello(): ... print "hello" ... >>>hello() hello
!py и !pycmd выводят теперь traceback при возникновении исключения при исполнении. Надеемся, это сделает отладку скриптов чуть-чуть удобнее.
Кстати, про исключения. В предыдущем релизе ( 0.0.18 ) был реализован механизм трансляции ошибок pykd в исключения python. В этом релизе мы провели рефакторинг некоторых модулей. Будьте готовы, что функции ранее возвращавшие 0, None или "" будут кидать исключение и некоторые скрипты перестанут работать. Возможно, вас утешит, что обработка ошибок через обработку исключений сделает код в итоге более надежным и понятным ( положа руку на сердце, это конечно спорный момент или, как минимум, обсуждаемый ).
class disasm
Это дизассемблер. Конечно не полноценный, он не разбирает инструкции на операнды. Тем не менее, простые задачи ему вполне по силам. Пользоваться просто:
kd>!pycmd
>>>nt = loadModule("nt")
>>>da = disasm( nt.ZwCreateFile )
>>>print da.next()
804fd55d 8d542404 lea edx,[esp+4]
>>>print da.next()
804fd561 9c pushfd
>>>print da.next()
804fd562 6a08 push 8
>>>print da.next()
804fd564 e8e8f00300 call nt!KiSystemService (8053c651)
Прочее:
setMSR - функция меняет значение MSR регистра.
классу typedVar добавили метод data, возвращающий данные в виде питоновской строки. Такую строку можно обработать например с помощью ctypes или записать в файл
Фиксы:
issue 8655
Игнорировались поля безымянных структур и объединений. Теперь - не игнорируются.
issue 8927
Если поле структуры имеет перечисляемый тип, то узнать его числовое значение нельзя. Т.е конечно можно с помощью такого трика:
val = ptrDword( structVar.enumField.getAddress() )
Хорошая новость, теперь можно писать:
val = structVar.enumField
Плохая новость: предыдущий трик перестал работать, потому что у типа long нет метода getAddress().
Но не все уж так плохо: в настоящий релиз вошел класс intBase, позволяющий включать его в операции с целыми числами. В следующей версии мы планируем переделать класс typedVar и хранить атрибуты, представляющие целые числа и указатели, в объектах-наследниках типа intBase. Это, к примеру позволит обращаться не только к членам структуры, но также и к данным, доступным по указателям. Короче говоря, планов много, будем стараться их осуществить.
В заключение хотел напомнить: Друзья, у вас все еще есть блестящая возможность поучаствовать в разработке pykd. Очень нужны: С++ кодер - для работы с ядром pykd, python кодер - для разработки тестов ( у нас есть тесты! целых два!!! ), python кодер - для разработки библиотеки, русско-англо-xxx-язычный технический писатель.
среда, 22 июня 2011 г.
Qt: "A QApplication instance already exists"
Не так давно мы публиковали пример графического плагина на основе связки Qt и PySide. Использование графического интерфейса предоставляет широчайшие возможности. К сожалению, приведенный код содержал один существенный недостаток: при повторном запуске скрипта появлялось сообщение: "A QApplication instance already exists".
Чтобы избежать этого, нужно совсем чуть-чуть переработать процедуру инициализации Qt. А именно: проверить существование синглтона QApplication c помощью вызова QCoreApplication::instance()
Таким образом, прототип расширения для windbg c графическим интерфейсом мог бы выглядеть примерно так:
Чтобы избежать этого, нужно совсем чуть-чуть переработать процедуру инициализации Qt. А именно: проверить существование синглтона QApplication c помощью вызова QCoreApplication::instance()
Таким образом, прототип расширения для windbg c графическим интерфейсом мог бы выглядеть примерно так:
from PySide.QtCore import * from PySide.QtGui import * class MainForm( QDialog ): def __init__( self ): QDialog.__init__( self, None ) self.setWindowTitle("Hello") def main(): app = QCoreApplication.instance() if app == None: app = QApplication( [] ) mainForm = MainForm() mainForm.show() exitres = app.exec_() if __name__ == "__main__": main()
четверг, 26 мая 2011 г.
Обработка событий загрузки и выгрузки модулей отлаживаемой системы
Одно из нововведений релиза pykd 0.0.18 это базовый класс для обработки событий от Debug Engine. В текущей версии реализованы только события загрузки и выгрузки модулей. Об этом было рассказано в обзоре релиза.
Реализация сделана через базовый класс debugEvent, реализация которого расположена в модуле pykd. Для обработки соответствующего события необходимо написать свой класс, в котором переопределить методы onLoadModule(...) или onUnloadModule(...), в зависимости от того, какие события необходимо обрабатывать. Входным параметром для этих методов выступает экземпляр класса загруженного модуля dbgModuleClass.
В качестве демонстрации этого функционала рассмотрим часть скрипта samples\goLoad.py:
Реализация сделана через базовый класс debugEvent, реализация которого расположена в модуле pykd. Для обработки соответствующего события необходимо написать свой класс, в котором переопределить методы onLoadModule(...) или onUnloadModule(...), в зависимости от того, какие события необходимо обрабатывать. Входным параметром для этих методов выступает экземпляр класса загруженного модуля dbgModuleClass.
В качестве демонстрации этого функционала рассмотрим часть скрипта samples\goLoad.py:
from pykd import *
import fnmatch
import sys
class loadHandler(debugEvent):
def __init__(self, mask):
debugEvent.__init__(self)
self.mask = mask
def onLoadModule(self, module):
if fnmatch.fnmatch( module.name(), self.mask ):
return DEBUG_STATUS_BREAK
return DEBUG_STATUS_NO_CHANGE
if __name__ == "__main__":
if len(sys.argv) == 2:
loadHandler = loadHandler( sys.argv[1] )
go()
Фактически, скрипт продолжает исполнение целевой системы, пока не будет загружен модуль, имя которого будет совпадать с указанной маской (передается первым параметром в скрипт). Передаваемая маска имени модуля может содержать wildcard'ы: символы * и ?. То есть, например, что бы при старте системы дождаться загрузки модуля beep.sys в память, нужно выполнять команду: "!py goLoad *beep*". Это может быть полезно, когда нужно, что бы отладчик остановился перед вызовом точки входа целевого модуля, но уже при загруженном целевом модуле. В этот момент можно расставлять точки останова в загруженном модуле или, например, дождаться исполнения точки входа в драйвер командой "g beep!DriverEntry"
P.S. Сейчас в планах развивать функционал фильтрации отладочных событий. Хотелось бы услышать мнение конечных пользователей о том, какие событий представляют наибольший интерес (соответственно, реализация этих событий будет более приоритетной задачи). В число событий, для которых в pykd планируется реализовать механизмы фильтрации, входят:
- Создание и уничтожение процесса
- Возникновение исключения
- Создание и уничтожение нити (thread)
- Изменение состояния отлаживаемой сесии
- Срабатывание точки останова. pykd уже предоставляет класс bp. Но планируется так же продублировать функционал в debugEvent, что бы была возможность написать единый диспетчер событий Debug Engine.
среда, 25 мая 2011 г.
Release 0.0.18
Хочу представить очередной релиз pykd. Хотя список изменений может показаться не впечатляющим, но за этими изменениями стоит напряженная работа. Были серьезно переработаны ключевые части проекта. Но сначала приведем формальный список изменений:
rdmsr - возвращает значение MSR регистра
MemoryException - класс исключений для ошибок чтения памяти
TypeException - класс исключений при работе с типами
typeInfo - переработанная версия класса typeClass
debugEvent - базовый класс для создания обработчиков событий отладчика
8669 - функция typedVar (теперь это класс ) создает объект для несуществующего типа
8655 - не поддерживается работа с неименованными членами структур
Теперь подробнее о ключевых моментах. Их три:
>>> typeInfo( "nt", "AAAAAAA" )
>>> typedVar( "nt", "AAAAAA", 0xDEADBEEF )
>>> typedVar( "nt", "_EPROCESS", 0xDEADBEEF )
>>> loadWChars( 0xDEADBEEF, 100 )
char_t
uchar_t
short_t
ushort_t
long_t
ulong_t
int_t
uint_t
ptr_t
double_t
longlong_t
ulonglong_t
Кроме того, говоря про класс typeInfo, хотелось бы отметить, что доступ полям описания типа возможен не только по имени, но и по индексу, в том числе с использованием нотации слайсов. Это может понадобится, если вы решите написать свою питоновскую версию команды отладчика dt.
Проиллюстрирую-ка я все это примером, а то слишком много слов и мало дела:
Данный код будет выводить имена загружаемых модулей на экран. Все просто.
На этом хотелось бы закончить обзор релиза 0.0.18. Спасибо вам за то, что внимательно прочли. Как всегда, ждем от вас вопросов, предложений, благодарности и/или кусочки ненависти - все сгодится :).
И спасибо разработчикам за их нелегкий труд.
Новые функции:
loadWChars - юникодная версия существующей loadCharsrdmsr - возвращает значение MSR регистра
Поддержка исключений:
BaseException - базовый класс для всех исключенийMemoryException - класс исключений для ошибок чтения памяти
TypeException - класс исключений при работе с типами
Новые классы:
typedVar - переработанная версия класса typedVarClasstypeInfo - переработанная версия класса typeClass
debugEvent - базовый класс для создания обработчиков событий отладчика
Bugs fixed:
Прочее:
Добавили мелкую, но очень удобную фичу для команды pycmd: теперь модуль pykd импортируется при старте расширения автоматически. Иными словами, не надо писать from pykd import *.Теперь подробнее о ключевых моментах. Их три:
Исключения
Начиная с этого релиза мы переходим к концепции возвращения ошибок через исключения. По нашему мнению, это упрощает и делает более стройным и логичным как код скриптов на питоне, так и внутреннюю реализацию на С++. В текущем релизе исключения возвращают все функции работы с типами ( через классы typeInfo и typedVar ) и все функции работы с памятью. Предлагаю попробовать выполнить в интерпретаторе python следующие команды:>>> typeInfo( "nt", "AAAAAAA" )
>>> typedVar( "nt", "AAAAAA", 0xDEADBEEF )
>>> typedVar( "nt", "_EPROCESS", 0xDEADBEEF )
>>> loadWChars( 0xDEADBEEF, 100 )
Динамическое определение типов
Теперь создать типизированную переменную можно, даже если нет соответствующей символьной информации. Для этого у класса typeInfo предусмотрен метод append. Работать с ним не сложно:>>>a = typeInfo() >>>a.append( ushort_t, "ShortField") >>>a.append( uchar_t, "CharArray", 10 ) >>>print a unnamed size = 12(0xc) +0 unsigned short ShortField +2 unsigned char[] CharArrayХочу обратить внимание на переменные uchar_t и ushort_t. Откуда они взялись? Для базовых типов в модуль pykd добавлены глобальные переменные с типом typeInfo. Вот их полный список:
char_t
uchar_t
short_t
ushort_t
long_t
ulong_t
int_t
uint_t
ptr_t
double_t
longlong_t
ulonglong_t
Кроме того, говоря про класс typeInfo, хотелось бы отметить, что доступ полям описания типа возможен не только по имени, но и по индексу, в том числе с использованием нотации слайсов. Это может понадобится, если вы решите написать свою питоновскую версию команды отладчика dt.
Обработка событий отладчика
Если вы планируете с помощью pykd написать автоотладочное средство, а может даже и полноценный отладчик, скорее всего вам понадобится получать и обрабатывать различные события: загрузку и выгрузку модулей, старт процессов и так далее. Для этого мы разработали класс debugEvent. Он содержит виртуальные функции-обработчики событий. Если вы хотите реализовать собственную обработку того или иного события, вам достаточно создать класс-наследник debugEvent и переопределить нужные вам методы-обработчики. Текущая реализация содержит только два обработчика: onLoadModule и onUnloadModule.Проиллюстрирую-ка я все это примером, а то слишком много слов и мало дела:
class ModuleEventMgr( debugEvent ): def onLoadModule( self, module ): dprintln( module.name() ) return DEBUG_STATUS_GO_HANDLED evnetMgr = ModuleEvent()
Данный код будет выводить имена загружаемых модулей на экран. Все просто.
На этом хотелось бы закончить обзор релиза 0.0.18. Спасибо вам за то, что внимательно прочли. Как всегда, ждем от вас вопросов, предложений, благодарности и/или кусочки ненависти - все сгодится :).
И спасибо разработчикам за их нелегкий труд.
воскресенье, 24 апреля 2011 г.
Анализ сетевых пакетов в Vista/Windows 7
Сетевые пакеты в Vista/Windows 7 описываются структурой NET_BUFFER и списками NET_BUFFER_LIST. Мы написали скрипт, который анализирует содержимое пакетов с учетом сетевых протоколов. Сам скрипт можно взять здесь: nbl.py
Использовать его просто. Установим брейкпойнт:
bp ndis!NdisFIndicateReceiveNetBufferLists
При его срабатывании (а это при наличии сетевого подключения случится очень быстро ) выполним команду:
!py nbl @rdx ( для amd64 в rdx лежит указатель на NET_BUFFER_LIST )
В результате получим что то вроде:
Поодерживается разбор заголовков Ethernet, IPv4, UDP, TCP. В будущем, возможно, добавим поддержку и других протоколов. Если кому то скрипт окажется полезен - пишите, и это будущее может стать настоящим :).
UPD1:
Eще у нас есть скрипт, отображающий внтуренние структуры NDIS ( минпорты, протоколы и.т.д ) и их взаимосвязь: ndis.py, иногда бывает полезно, надеемся, будет и вам.
Использовать его просто. Установим брейкпойнт:
bp ndis!NdisFIndicateReceiveNetBufferLists
При его срабатывании (а это при наличии сетевого подключения случится очень быстро ) выполним команду:
!py nbl @rdx ( для amd64 в rdx лежит указатель на NET_BUFFER_LIST )
В результате получим что то вроде:
Length: 92 bytes
Ethernet header: OK
Dest MAC: ff-ff-ff-ff-ff-ff
Src MAC: 20-cf-30-70-25-e2
Type: IPv4
IPv4 header: OK
version: 4
header length: 20 bytes
total length: 78 bytes
protocol: UDP
TTL: 128
Src addr: 10.244.0.50
Dest addr: 10.244.7.255
UDP header: OK
Src port: 137
Dest port: 137
Length: 58
Checksum: 0xec8a
Поодерживается разбор заголовков Ethernet, IPv4, UDP, TCP. В будущем, возможно, добавим поддержку и других протоколов. Если кому то скрипт окажется полезен - пишите, и это будущее может стать настоящим :).
UPD1:
Eще у нас есть скрипт, отображающий внтуренние структуры NDIS ( минпорты, протоколы и.т.д ) и их взаимосвязь: ndis.py, иногда бывает полезно, надеемся, будет и вам.
пятница, 22 апреля 2011 г.
Работа с памятью
Все данные лежат в памяти, это очевидно. Ранее, мы уже рассмотрели (ссылка), как с помощью фцнкции typedVar получить доступ к содержимому переменной с учетом ее типа. Но бывают ситуации, когда мы не знаем тип, или содержимое памяти представляет собой сырой нетипизированный массив. Для работы с такими массивами предназначены следующие функции:
loadBytes
loadWords
loadDWords
loadQWords
- эти функции возвращают списки ( list ) беззнаковых целых соответствующей разрядности;
loadSignBytes
loadSignWords
loadSignDWords
loadSignQWords
- эти функции возвращают списки целых чисел со знаком.
Все функции имеют одинаковый прототип:
list loadIntegerType( address, number, phyAddr = False )
address - адрес, по которому расположен массив
number - количество элементов массива
phyAddr - является ли адрес физическим ( не виртуальным ).
loadBytes
loadWords
loadDWords
loadQWords
- эти функции возвращают списки ( list ) беззнаковых целых соответствующей разрядности;
loadSignBytes
loadSignWords
loadSignDWords
loadSignQWords
- эти функции возвращают списки целых чисел со знаком.
Все функции имеют одинаковый прототип:
list loadIntegerType( address, number, phyAddr = False )
address - адрес, по которому расположен массив
number - количество элементов массива
phyAddr - является ли адрес физическим ( не виртуальным ).
Остается привести какой-нибудь разумный пример:
from pykd import * def dd( addr ): buf = loadDWords( addr, 16 ) for i in xrange( len(buf) ): dprint( "%08x" % buf[i] ) dprint( (i % 4 < 3) and " " or "\n" )Данный код выводит на экран дамп 4 байтных чисел. Можно доработать данный код и получить полный аналог команды отладчика dd.
Для обработки сырых буферов средставами станадртных или сторонних библиотек, добавлена функция loadChars. Она работает также как и loadBytes, но возвращает не список, а строку ( string ). К примеру, разбирать данные можно с помощью стандартного модуля struct:
from struct import unpack shortField1, shortField2, longField = unpack('hhl', loadChars( addr, 8 ) )
От функции loadChars плавно перейдем к функциям работы со строками: loadCStr и loadWStr. Эту функции предназначены для работы с 0-терминированными строками. Первая для работы с ANSI-строками, вторая - с UNICODE. На правах КО обращу внимание, что работа с этими функциями небезопасна в том смысле, что наличие терминирующего нуля никем не гарантируется.
Для горячо любимых нами разработчиков системного ПО для Windows есть еще две полезных функции: loadUnicodeString и loadAnsiString. Они трактуют переданный адрес как указатель на структуру ANSI_STRING или UNICODE_STRING и, соответственно, избавляют от необходимости в ручную разбирать эти стуркутры для получения строки.
понедельник, 18 апреля 2011 г.
Release 0.0.17
Представляем очередной релиз pykd: 0.0.17. И так что нового:
Документация
Прежде всего, мы сделали нечеловеческое усилие над собой и добавили документацию для всех функций и классов. Правда документация пока очень-очень-очень скупая, но мы обещаем над этим поработать. А чтобы продемонстрировать, как это работает, мы написали скрипт help.py ( его можно взять тут ) выводящий интерактивный хелп в windbg. Пробуем:
0. загружаем плагин .load pykd.pyd
1. нажимаем ctrl+N
2. в строке ввода набираем !py help
4. наслаждаемся.
Добавили в API несколько функций:
bool isDumpAnalyzing()
Позволяет определить, анализируется ли в данным момент дамп или производится отладка живой системы. Если в скрипте используются функции управления отладчиком ( go, управления точками останова и.т.д ), имеет смысл вставить данный вызов и уберечь пользователя от неизбежных ошибок при попытке исполнения скрипта во время анализа дампа
bool isWindbgExt()
Позволяет определить, исполняется ли скрипт внутри WinDbg или вызван процессом интерпретатором python. Ранее для этого использовался неявный метод и вызов isSesionStart. Теперь isSessionStart удалена, этот вызов следует заменить в коде на isWindbgExt.
string loadChars(address, number)
В стандартной библиотеке python существует ряд средств для работы с массивами "сырых" данных. Все они для представления буфера данных используют класс string. Для того, чтобы не заниматься преобразованием списка байт, которые возвращает функция loadBytes мы добавили функцию loadChars.
Ее удобно использовать, например, вместе с модулем struct:
Методы checksum() and timestamp() класса dbgModuleClass
Из названия методов должно быть ясно, их назначение. Если Вам придет в голову написать собственный загрузчик символов ( почему бы и нет? ), то они вам могут пригодится.
callbacks for bp class ( breakpoint )
Это, можно сказать, изюминка данного релиза. До сих пор, пользоваться точками останова ( breakpoint ) из pykd было не слишком удобно. Теперь при создании новой точки останова можно задать функцию обратного вызова и обрабатывать из в событийно-ориентированном стиле.
Пример:
typedVarList
При работе со связанными списками в (ядре) Windows часто используется структура LIST_ENTRY. Изначально функция typedVarList была ориентирована на такие списки. Однако, гораздо чаще используется другой подход для создания связанных списков: когда структура содержит указатель ( Next ) на начало следующей структуры. Теперь, typedVarList поддерживает оба случая. Какой вариант связного списка использовать, определяется по типу поля-указателя на следующий элемент.
Новый инсталлятор
К релизу 0.0.17 мы существенно переработали инсталятор:
Bug fixed
8470 ( python.exe crashes after first pykd call )
8614 ( go() works incorrectly while process is terminating )
8499 ( !py command crashs with wrong script's path )
8578 ( findModule returns None for WOW64 process )
8493 ( loadPtrs returns dict instead list )
8469 ( dprintln does not work in console mode )
Документация
Прежде всего, мы сделали нечеловеческое усилие над собой и добавили документацию для всех функций и классов. Правда документация пока очень-очень-очень скупая, но мы обещаем над этим поработать. А чтобы продемонстрировать, как это работает, мы написали скрипт help.py ( его можно взять тут ) выводящий интерактивный хелп в windbg. Пробуем:
0. загружаем плагин .load pykd.pyd
1. нажимаем ctrl+N
2. в строке ввода набираем !py help
4. наслаждаемся.
Добавили в API несколько функций:
bool isDumpAnalyzing()
Позволяет определить, анализируется ли в данным момент дамп или производится отладка живой системы. Если в скрипте используются функции управления отладчиком ( go, управления точками останова и.т.д ), имеет смысл вставить данный вызов и уберечь пользователя от неизбежных ошибок при попытке исполнения скрипта во время анализа дампа
bool isWindbgExt()
Позволяет определить, исполняется ли скрипт внутри WinDbg или вызван процессом интерпретатором python. Ранее для этого использовался неявный метод и вызов isSesionStart. Теперь isSessionStart удалена, этот вызов следует заменить в коде на isWindbgExt.
string loadChars(address, number)
В стандартной библиотеке python существует ряд средств для работы с массивами "сырых" данных. Все они для представления буфера данных используют класс string. Для того, чтобы не заниматься преобразованием списка байт, которые возвращает функция loadBytes мы добавили функцию loadChars.
Ее удобно использовать, например, вместе с модулем struct:
>>> from struct import unpack >>> shortField1, shortField2, longField = unpack('hhl', loadChars( addr, 8 ) )
Методы checksum() and timestamp() класса dbgModuleClass
Из названия методов должно быть ясно, их назначение. Если Вам придет в голову написать собственный загрузчик символов ( почему бы и нет? ), то они вам могут пригодится.
callbacks for bp class ( breakpoint )
Это, можно сказать, изюминка данного релиза. До сих пор, пользоваться точками останова ( breakpoint ) из pykd было не слишком удобно. Теперь при создании новой точки останова можно задать функцию обратного вызова и обрабатывать из в событийно-ориентированном стиле.
Пример:
from pykd import * def bpCallback(): if is64bitSystem(): objAttr = typedVar( "ntdll", "_OBJECT_ATTRIBUTES", reg("r8") ) else: objAttr = typedVar( "ntdll", "_OBJECT_ATTRIBUTES", ptrPtr(reg("esp") + 0xC) ) name = loadUnicodeString( objAttr.ObjectName ) dprintln( "NtCreateFile: " + name ) return DEBUG_STATUS_GO_HANDLED if not isWindbgExt(): startProcess("notepad.exe") if not isDumpAnalyzing() and not isKernelDebugging(): nt = loadModule("ntdll") b1 = bp( nt.NtCreateFile, bpCallback ) # wait for user break, exceptions or process exit go() dprintln( "stopped" ) else: dprintln( "The debugger must be connected to live usermode process" )
typedVarList
При работе со связанными списками в (ядре) Windows часто используется структура LIST_ENTRY. Изначально функция typedVarList была ориентирована на такие списки. Однако, гораздо чаще используется другой подход для создания связанных списков: когда структура содержит указатель ( Next ) на начало следующей структуры. Теперь, typedVarList поддерживает оба случая. Какой вариант связного списка использовать, определяется по типу поля-указателя на следующий элемент.
Новый инсталлятор
К релизу 0.0.17 мы существенно переработали инсталятор:
- Новый дизайн
- Добавили деинсталлятор ( вдруг кому-нибудь понадобится? )
- Добавили примеры в комплект иснталлятора
- Выбор дополнительных компонентов по желанию пользователя ( VCRedist, python, примеры )
Bug fixed
Надеемся, релиз 0.0.17 сделает вашу работу с pykd более приятной и плодотворной!
воскресенье, 3 апреля 2011 г.
HOWTO
1. Как получить указатель на PEB ?
Также, как и в любую команду windbg:
!py myscript @eax
Чтобы это работало, в скрипте нужно предусмотреть вычисление выражений:
6. Как получить размер структуры?
Проще всего так:
7. Как получить смещение поля структры?
Через класс, предсталяющий информацию о типе ( typeClass):
8. Есть ли в pykd команда help или другой способ получить справку?
В pykd - нет. Но такая возможность встроена в сам python! Пробуем:
9. Как отлаживать скрипт?
Небольшие скрипты можно отладить прямо в windbg ( или в консоле ). Для этого используем встроенный отладчик pdb:
10. Как сравнивать адреса?
Вопрос не так прост. DbgEng и все функции pykd возращают адреса в 64 битном формате, даже для x86 платформы. Адреса, находящиеся в верхней половине адресного пространства, расширяются:
0x804f8925 -> 0xFFFFFFFF'804f8925
В следствии этого, в коде могут возникнуть непрогнозируемые ошибки. Рассмотрим пример:
peb = typedVar( "ntdll", "_PEB", getCurrentProcess() )2. Какому модулю принадлежит адрес?
module = findModule( addr )
print module==None and "module not found" or module.name()3. Как вывести текст с DML разметкой?
dprintln( "<u>Hello <b>World</b></u>", True )4. Как передать в скрипт значение регистра?
Также, как и в любую команду windbg:
!py myscript @eax
Чтобы это работало, в скрипте нужно предусмотреть вычисление выражений:
param1 = expr( sys.argv[1] )5. Как выполнить команду отладчика и получить ее результат?
print dbgCommand("!for_each_module")Результат команды можно обработать к примеру с помощью RE.
6. Как получить размер структуры?
Проще всего так:
print hex( sizeof( "nt", "_ERESOURCE") )Можно с через класс, предсталяющий информацию о типе ( typeClass):
print hex(getTypeClass("nt", "_ERESOURCE").sizeof())Справедливо и для объектов дочернего класса typedVarClass, например:
print hex(typedVar("nt", "_ERESOURCE", getOffset("nt", "CmpRegistryLock")).sizeof())
7. Как получить смещение поля структры?
Через класс, предсталяющий информацию о типе ( typeClass):
print hex(getTypeClass("nt", "_ETHREAD").Tcb.ThreadListEntry.offset())Справедливо и для объектов дочернего класса typedVarClass, например:
print hex(typedVar("nt", "_ETHREAD", getImplicitThread()).Tcb.ThreadListEntry.offset())Но сравните результат выполнения двух команд:
print hex(getTypeClass("nt", "_ETHREAD").Tcb.ThreadListEntry.Flink.offset())
print hex(typedVar("nt", "_ETHREAD", getImplicitThread()).Tcb.ThreadListEntry.Flink. offset())Первая выводит ожидаемое значение, вторая - возвращает ошибку. Дело в том, что аттрибут 'Flink' в объекте typedVarClass имеет встроенный тип python-а long и, соответственно, не имеет метода offset ( а также, getAddress() )
8. Есть ли в pykd команда help или другой способ получить справку?
В pykd - нет. Но такая возможность встроена в сам python! Пробуем:
>!pycmd
>>> help()
help>pykd.typedVar
9. Как отлаживать скрипт?
Небольшие скрипты можно отладить прямо в windbg ( или в консоле ). Для этого используем встроенный отладчик pdb:
>!py pdb my_script.py
(pdb) s
-> import pykd
(pdb)
10. Как сравнивать адреса?
Вопрос не так прост. DbgEng и все функции pykd возращают адреса в 64 битном формате, даже для x86 платформы. Адреса, находящиеся в верхней половине адресного пространства, расширяются:
0x804f8925 -> 0xFFFFFFFF'804f8925
В следствии этого, в коде могут возникнуть непрогнозируемые ошибки. Рассмотрим пример:
if reg("eax")==getOffset( "nt", "NtCreateFile") print "eax point to NtCreateFile"На x86 платформе данный код будет работать неправильно. Переменная a будет трактоваться как 32 битное целое, а функция getOffset вернет адрес, расширенный до 64 бит. И даже если регистр eax действительно указывает на NtCreateFile, проверка на равенство не сработает. Чтобы избежать этого, скастим значение регистра к указателю с помощью функции addr64:
if addr64(reg("eax"))==getOffset("nt","NtCreateFile") print "eax point to NtCReateFile"
Надеюсь, эта информация поможет начать работу с pykd. На все вопросы мы с удовольствием ответим в этом блоге или по электронной почте: pykd@hotmail.com. понедельник, 21 марта 2011 г.
Автоматическая установка pykd
Установить pykd вручную не сложно. Однако есть как минимум один подводный камень: нужно также установить дистрибутив vcredist нужной версии. Но все заботы может взять на себя автоматический инсталлятор. Он найдет python нужной версии, а если его нет - скачает, установит рантайм библиотеки и, конечно, сэкономит вам время.
http://perfect-coding.blogspot.com/2011/03/pykd-python-windbg-extension.html
http://perfect-coding.blogspot.com/2011/03/pykd-python-windbg-extension.html
пятница, 18 марта 2011 г.
PySide+pykd: используем Qt в питоновских скриптах к WinDbg
pykd, как расширении к WinDbg, дает не только возможность использования мощного и гибкого языка Python, но и уже готовых сторонних проектов. Далее пойдет речь о PySide - библиотеке интеграции инструментария Qt в Python. Возьмем простой пример: нужно просмотреть статистику о процессах системы, в частноти размер виртуального адресного пространства и счетчики операций ввода/вывода. Не буду рассказывать об установке PySide, так как на официальной странице загрузок для Windows можно скачать инсталлятор. Набросаем небольшой скрипт, который средствами pykd получает и анализирует список процессов, а затем использует PySide для визуализации собранных данных в виде таблицы в GUI-окне:
import sysТеперь исполним его в WinDbg. После того, как скрипт построит список процессов, мы увидим окно результатов. Оно не является модальным по отношению к основному окну WinDbg, но отладчик терпеливо ждет завершения работы скрипта (в нашем случае - закрытия окна):
from pykd import *
from PySide import QtCore, QtGui
COL_PID = 0
COL_PRC_NAME = 1
COL_VSIZE = 2
COL_READ = 3
COL_WRITE = 4
COL_OTHER = 5
if __name__ == '__main__':
app = QtGui.QApplication(sys.argv)
nt = loadModule( "nt" )
lstProcesses = typedVarList(nt.PsActiveProcessHead, "nt", "_EPROCESS", "ActiveProcessLinks")
countOfProcesses = len(lstProcesses)
if (countOfProcesses == 0):
print "Build process list failed"
sys.exit()
model = QtGui.QStandardItemModel(countOfProcesses, COL_OTHER+1)
model.setHeaderData(COL_PID, QtCore.Qt.Horizontal, "PID")
model.setHeaderData(COL_PRC_NAME, QtCore.Qt.Horizontal, "Image")
model.setHeaderData(COL_VSIZE, QtCore.Qt.Horizontal, "VirtualSize")
model.setHeaderData(COL_READ, QtCore.Qt.Horizontal, "Read")
model.setHeaderData(COL_WRITE, QtCore.Qt.Horizontal, "Write")
model.setHeaderData(COL_OTHER, QtCore.Qt.Horizontal, "Other")
tableView = QtGui.QTableView()
tableView.setModel(model)
for row in range(countOfProcesses):
process = lstProcesses[row]
index_ = model.index(row, COL_PID, QtCore.QModelIndex())
model.setData(index_, process.UniqueProcessId)
index_ = model.index(row, COL_PRC_NAME, QtCore.QModelIndex())
model.setData(index_, "".join([chr(i) for i in process.ImageFileName.values()]))
index_ = model.index(row, COL_VSIZE, QtCore.QModelIndex())
model.setData(index_, process.VirtualSize)
index_ = model.index(row, COL_READ, QtCore.QModelIndex())
model.setData(index_, process.ReadOperationCount.QuadPart)
index_ = model.index(row, COL_WRITE, QtCore.QModelIndex())
model.setData(index_, process.WriteOperationCount.QuadPart)
index_ = model.index(row, COL_OTHER, QtCore.QModelIndex())
model.setData(index_, process.OtherOperationCount.QuadPart)
tableView.resizeColumnsToContents()
widthWidget = 0
for col in range(COL_OTHER+1): widthWidget += tableView.columnWidth(col)
widthWidget += 50
tableView.setSortingEnabled(True)
tableView.setWindowTitle("Processes table:")
tableView.resize(widthWidget, 500)
tableView.show()
app.exec_()
Конечно, можно было бы выдать эту информацию в текстовой форме. Но GUI таблица, например, позволяет одним кликом поменять колонку сортировки и можно наблюдать какой процесс активно более активно читает, а какой пишет.
Еще один приятный момент использования PySide - лицензия LGPL, позволяющая использовать и распространять библиотеку в любых проектах, включая коммерческие.
Еще один приятный момент использования PySide - лицензия LGPL, позволяющая использовать и распространять библиотеку в любых проектах, включая коммерческие.
среда, 16 марта 2011 г.
Исследуем ASLR
Сегодня неожиданно возник вопрос: одинаков ли адрес загрузки ntdll.dll во всех процессах. Поспорив немного, вопрос разбили на два: влияет ли ASLR на ntdll.dll и как, собственно, работает ASLR: отличаются ли адреса загрузки системных dll в разных процессах. Поскольку практика - мерило истинности, быстренько написали скрипт на питоне и все выяснили. Сам скрипт был написан очень быстро ( по сути, скопипастили пример proclist.py и слегка его модифицировали ). Вот быстрота написания скрипта и сподвигла меня написать этот пост. А заодно хочется продемонстрировать некоторые приемы работы с pykd.
Вот сам код:
Вот сам код:
import sys
from pykd import *
def moduleBase():
nt = loadModule( "nt" )
processList = typedVarList( nt.PsActiveProcessHead, "nt", "_EPROCESS", "ActiveProcessLinks" )
for process in processList:
dbgCommand( ".process /p %x" % process.getAddress() )
dbgCommand( ".reload /user" )
print "process %x " % process.getAddress(), "".join( [ chr(i) for i in process.ImageFileName.values() ] )
ntdll = loadModule("ntdll")
if ntdll != None: print "\tntdll: %x" % ntdll.begin()
kernel32 = loadModule("kernel32")
if kernel32 != None: print "\tkernel32: %x" % kernel32.begin()
if __name__ == "__main__":processList = typedVarList( nt.PsActiveProcessHead, "nt", "_EPROCESS", "ActiveProcessLinks" )
for process in processList:
dbgCommand( ".process /p %x" % process.getAddress() )
dbgCommand( ".reload /user" )
print "process %x " % process.getAddress(), "".join( [ chr(i) for i in process.ImageFileName.values() ] )
ntdll = loadModule("ntdll")
if ntdll != None: print "\tntdll: %x" % ntdll.begin()
kernel32 = loadModule("kernel32")
if kernel32 != None: print "\tkernel32: %x" % kernel32.begin()
moduleBase()
Запустив данный скрипт в отладчике ядра, мы получим что-то вроде:
process ffffffff859fbbb0 System
process ffffffff8bbf5460 smss.exe
ntdll: 77d50000
kernel32: 76b40000
process ffffffff81f6f6a8 csrss.exe
ntdll: 77d50000
kernel32: 76b40000
process ffffffff892435a8 wininit.exe
ntdll: 77d50000
kernel32: 76b40000
process ffffffff89269b98 csrss.exe
ntdll: 77d50000
kernel32: 76b40000
.......
и ответы на свои вопросы. Но не совсем сразу. Перезапустим систему и выполним скрипт еще раз - значения будет другие. Вот теперь уже все ясно. ASLR меняет адреса загрузки при каждом ребуте, в пределах одной загрузки адреса во всех процессах одинаковы.Хочу обратить внимание на использование функции dbgCommand. Она позволяет выполнять обычные команды windbg. И если какой-то функционал не реализован в pykd, его можно "позаимствовать".
В данном случае, мы позаимстовали команду .process c ключиком /p. Без этого ключика можно было бы использовать функцию setCurrentProcess. Но к сожалению, данная функция не включает неявную трансляцию адресов. В результате, мы не можем получить актуальный список модулей пользовательского режима для каждого процесса. Тут то нам на помощь и пришла спасительная функция dbgCommand.
пятница, 4 марта 2011 г.
Release 0.0.16
Хочу представить очередной релиз проекта pykd. Он примечателен тем, что над ним активно работало несколько участников и результат: количество внесенных нововведений, исправлений и улучшений значительно увеличилось. Хочу поблагодарить всех участников проекта и выразить надежду, что далее их работа в команде будет не менее плодотворной. И так, что же мы наделали:
Исправили ряд багов:
#8336: в некоторых ( довольно редких ) случаях функция typedVar возвращала переменную не того типа. Баг был в системе кеширования символьной информации, сделанной для ускорения работы с типизированными переменными
#8458: после завершения отладочной сессии и открытии новой весь вывод в консоль windbg удваивался.
#8467: при отладке х86 платформы функция typedVarList входила в бесконечный цикл при определенных значениях адреса начала списка.
Внесли ряд изменений в API:
семейство функций loadBytes, loadDWords и.т.д
Ранее, эта функции возвращали инфорамцию в виде питоновского dictinory: {0 : val1, 1 : val2, ...}.
Учитывая, что в данном случае ключ - это просто индекс в массиве, dictionary заменили на list.
typedVar
Если в функцию передать не корректный адрес ( в том числе 0x0 ), она вернет None. Это удобно при отладке.
loadDump
Функция возвращает теперь булевское значение. True - дамп загружен успешно, False - произошла ошибка.
createSession
Функция объявлена устаревшей и не желательной к использованию. Теперь функция loadDump ( и новая функция startProcess ), сами создадут сессию при необходимости ( когда скрипт исполняется в отдельном процессе python, а не в windbg ).
И наконец, что же нового:
isValid( addr )
Функция проверяет валидность адреса.
dbgModuleClass.image() и dbgModuleClass.pdb()
Метода класса возвращают пути к бинарному файлу и файлу с символьной информацией ( если они есть ) в локальном хранилище символов. Хочу отметить, что метод image() вернет полный путь, его можно использовать для открытия файла.
класс typeClass
Содержит информацию о типе без загрузки значения. Его удобно использовать, к примеру, если нужно определить смещение определенного поля и при этом нет нужды загружать переменную из памяти, а возможно, и адрес то этой переменной не известен
getTypeClass( moduleName, symbolName )
Возвращает объект типа typeClass
addSynSymbol( addr, size, name )
delAllSynSymbols()
delSynSymbols( addr )
delSyntheticSymbolsMask( moduleName, symbolName )
Функции для работы с т.н синтетическими символами - т.е символами объявленными пользователем динамически во время работы. О работе с синтетическими символами мы уже писали ранее. Хочу отметить, что pykd сохраняет установленные символы даже если пользователь сделал .reload для модуля.
Добавлен метод __str__ для всех классов, экспортируемых в python. В результате, работа с ними будет удобнее: можно написать print и получить более полезную информацию, чем просто адрес объекта.
startProcess( commandLine )
Позволяет начать отладку пользовательского процесса ( аналог команды отладчика .create ). Теперь можно из питона отлаживать программы, примерно так:
>>> startProcess( "myProgram.exe" )
>>> myProgram = loadModule( "myProgram")
>>> b1 = bp( myProgram.myFaultRoutine )
>>> go()
>>> trace()
>>> print reg("eax")
Конечно, пока о реальной отладке кода речь не идет. Но, возможно, в будущем на базе pykd можно будет сделать неплохую альтернативу windbg.
Исправили ряд багов:
#8336: в некоторых ( довольно редких ) случаях функция typedVar возвращала переменную не того типа. Баг был в системе кеширования символьной информации, сделанной для ускорения работы с типизированными переменными
#8458: после завершения отладочной сессии и открытии новой весь вывод в консоль windbg удваивался.
#8467: при отладке х86 платформы функция typedVarList входила в бесконечный цикл при определенных значениях адреса начала списка.
Внесли ряд изменений в API:
семейство функций loadBytes, loadDWords и.т.д
Ранее, эта функции возвращали инфорамцию в виде питоновского dictinory: {0 : val1, 1 : val2, ...}.
Учитывая, что в данном случае ключ - это просто индекс в массиве, dictionary заменили на list.
typedVar
Если в функцию передать не корректный адрес ( в том числе 0x0 ), она вернет None. Это удобно при отладке.
loadDump
Функция возвращает теперь булевское значение. True - дамп загружен успешно, False - произошла ошибка.
createSession
Функция объявлена устаревшей и не желательной к использованию. Теперь функция loadDump ( и новая функция startProcess ), сами создадут сессию при необходимости ( когда скрипт исполняется в отдельном процессе python, а не в windbg ).
И наконец, что же нового:
isValid( addr )
Функция проверяет валидность адреса.
dbgModuleClass.image() и dbgModuleClass.pdb()
Метода класса возвращают пути к бинарному файлу и файлу с символьной информацией ( если они есть ) в локальном хранилище символов. Хочу отметить, что метод image() вернет полный путь, его можно использовать для открытия файла.
класс typeClass
Содержит информацию о типе без загрузки значения. Его удобно использовать, к примеру, если нужно определить смещение определенного поля и при этом нет нужды загружать переменную из памяти, а возможно, и адрес то этой переменной не известен
getTypeClass( moduleName, symbolName )
Возвращает объект типа typeClass
addSynSymbol( addr, size, name )
delAllSynSymbols()
delSynSymbols( addr )
delSyntheticSymbolsMask( moduleName, symbolName )
Функции для работы с т.н синтетическими символами - т.е символами объявленными пользователем динамически во время работы. О работе с синтетическими символами мы уже писали ранее. Хочу отметить, что pykd сохраняет установленные символы даже если пользователь сделал .reload для модуля.
Добавлен метод __str__ для всех классов, экспортируемых в python. В результате, работа с ними будет удобнее: можно написать print и получить более полезную информацию, чем просто адрес объекта.
startProcess( commandLine )
Позволяет начать отладку пользовательского процесса ( аналог команды отладчика .create ). Теперь можно из питона отлаживать программы, примерно так:
>>> startProcess( "myProgram.exe" )
>>> myProgram = loadModule( "myProgram")
>>> b1 = bp( myProgram.myFaultRoutine )
>>> go()
>>> trace()
>>> print reg("eax")
Конечно, пока о реальной отладке кода речь не идет. Но, возможно, в будущем на базе pykd можно будет сделать неплохую альтернативу windbg.
понедельник, 28 февраля 2011 г.
Синтетические символы: делаем дизассемблер WinDbg дружелюбнее
Многие не любят использовать WinDbg для отладки "чужих" модулей, (т.е. тех, к которым нет символов) из-за его не самого дружелюбного дизассемблера. Простой пример это отображение импортов. Например, имеем небольшую функцию:
0:000> uf 00401090
00401090 51 push ecx
00401091 56 push esi
00401092 8b742410 mov esi,dword ptr [esp+10h]
00401096 6a00 push 0
00401098 6a00 push 0
0040109a 8d44240c lea eax,[esp+0Ch]
0040109e 50 push eax
0040109f 6800040000 push 400h
004010a4 56 push esi
004010a5 6a00 push 0
004010a7 6800110000 push 1100h
004010ac ff1510c04000 call dword ptr [image+0xc010 (0040c010)]
004010b2 8b4c2404 mov ecx,dword ptr [esp+4]
004010b6 8b54240c mov edx,dword ptr [esp+0Ch]
004010ba 51 push ecx
004010bb 56 push esi
004010bc 52 push edx
004010bd 6824c24000 push offset image+0xc224 (0040c224)
004010c2 6a10 push 10h
004010c4 68fcc14000 push offset image+0xc1fc (0040c1fc)
004010c9 e832ffffff call image+0x1000 (00401000)
004010ce 8b44241c mov eax,dword ptr [esp+1Ch]
004010d2 83c418 add esp,18h
004010d5 50 push eax
004010d6 ff1514c04000 call dword ptr [image+0xc014 (0040c014)]
004010dc 5e pop esi
004010dd 59 pop ecx
004010de c3 ret
Так мы ее видим в статике дизассемблера WinDbg. Но стоит дойти до адреса 004010ac, как WinDbg вычислит значение по адресу 0040c010 и выведет следующую строку:
call dword ptr [image+0xc010 (0040c010) ds:0023:0040c010={kernel32!FormatMessageW (77e4f831)]
На самом деле, по адресу 0040c010 расположен элемент IAT (директория импортов PE). При этом логика WinDbg ясна: значение по адресу 0040c010 может измениться, поэтому он и не вычисляет значение содержимого IAT при статическом дизассемблировании. Но если мы уверены, что содержимое таблицы импорта уже сформировано, то было бы неплохо добавить символы на обращения по этим адресам.
Для подобного рода задач в Debugger Engine расширений WinDbg введено понятие синтетических символов (Synthetic Symbols). Фактически, это символ, добавленный пользователем по заданному виртуальному адресу. Синтетический символ, как и любой другой символ модуля, имеет атрибуты имени и размера. Смысл атрибута имени очевиден, а размер символа нужен для формирования символов вида: module!SymName+33. Важная особенность: при перезагрузке символов для модуля (reload), все добавленные синтетические символы удаляются.
Для добавления синтетического имени в расширении pykd есть 2-а пути:
А теперь вернемся к примеру функции, дизассемблерный листинг которой был приведен ранее. Для демонстрации работы запустим скрипт ~\samples\synimp.py, который принимает на вход адрес внутри модуля. Скрипт, для указанного модуля, добавляет импорты, как синтетические символы с префиксом "_imp_". После работы скрипта функция выглядит намного понятнее и о ее назначении можно догадаться без трассировки:
0:000> uf 00401090
00401090 51 push ecx
00401091 56 push esi
00401092 8b742410 mov esi,dword ptr [esp+10h]
00401096 6a00 push 0
00401098 6a00 push 0
0040109a 8d44240c lea eax,[esp+0Ch]
0040109e 50 push eax
0040109f 6800040000 push 400h
004010a4 56 push esi
004010a5 6a00 push 0
004010a7 6800110000 push 1100h
004010ac ff1510c04000 call dword ptr [image!_imp_kernel32!FormatMessageW (0040c010)]
004010b2 8b4c2404 mov ecx,dword ptr [esp+4]
004010b6 8b54240c mov edx,dword ptr [esp+0Ch]
004010ba 51 push ecx
004010bb 56 push esi
004010bc 52 push edx
004010bd 6824c24000 push offset image+0xc224 (0040c224)
004010c2 6a10 push 10h
004010c4 68fcc14000 push offset image+0xc1fc (0040c1fc)
004010c9 e832ffffff call image+0x1000 (00401000)
004010ce 8b44241c mov eax,dword ptr [esp+1Ch]
004010d2 83c418 add esp,18h
004010d5 50 push eax
004010d6 ff1514c04000 call dword ptr [image!_imp_kernel32!LocalFree (0040c014)]
004010dc 5e pop esi
004010dd 59 pop ecx
004010de c3 ret
Стоит обратить внимание, что функционал синтетических символов будет включен в сборку pykd с версии 0.0.16
0:000> uf 00401090
00401090 51 push ecx
00401091 56 push esi
00401092 8b742410 mov esi,dword ptr [esp+10h]
00401096 6a00 push 0
00401098 6a00 push 0
0040109a 8d44240c lea eax,[esp+0Ch]
0040109e 50 push eax
0040109f 6800040000 push 400h
004010a4 56 push esi
004010a5 6a00 push 0
004010a7 6800110000 push 1100h
004010ac ff1510c04000 call dword ptr [image+0xc010 (0040c010)]
004010b2 8b4c2404 mov ecx,dword ptr [esp+4]
004010b6 8b54240c mov edx,dword ptr [esp+0Ch]
004010ba 51 push ecx
004010bb 56 push esi
004010bc 52 push edx
004010bd 6824c24000 push offset image+0xc224 (0040c224)
004010c2 6a10 push 10h
004010c4 68fcc14000 push offset image+0xc1fc (0040c1fc)
004010c9 e832ffffff call image+0x1000 (00401000)
004010ce 8b44241c mov eax,dword ptr [esp+1Ch]
004010d2 83c418 add esp,18h
004010d5 50 push eax
004010d6 ff1514c04000 call dword ptr [image+0xc014 (0040c014)]
004010dc 5e pop esi
004010dd 59 pop ecx
004010de c3 ret
Так мы ее видим в статике дизассемблера WinDbg. Но стоит дойти до адреса 004010ac, как WinDbg вычислит значение по адресу 0040c010 и выведет следующую строку:
call dword ptr [image+0xc010 (0040c010) ds:0023:0040c010={kernel32!FormatMessageW (77e4f831)]
На самом деле, по адресу 0040c010 расположен элемент IAT (директория импортов PE). При этом логика WinDbg ясна: значение по адресу 0040c010 может измениться, поэтому он и не вычисляет значение содержимого IAT при статическом дизассемблировании. Но если мы уверены, что содержимое таблицы импорта уже сформировано, то было бы неплохо добавить символы на обращения по этим адресам.
Для подобного рода задач в Debugger Engine расширений WinDbg введено понятие синтетических символов (Synthetic Symbols). Фактически, это символ, добавленный пользователем по заданному виртуальному адресу. Синтетический символ, как и любой другой символ модуля, имеет атрибуты имени и размера. Смысл атрибута имени очевиден, а размер символа нужен для формирования символов вида: module!SymName+33. Важная особенность: при перезагрузке символов для модуля (reload), все добавленные синтетические символы удаляются.
Для добавления синтетического имени в расширении pykd есть 2-а пути:
- Функция addSynSymbol(адрес_символа, размер_символа, имя_символа)
- Метод addSynSymbol(смещение_символа, размер_символа, имя_символа) класса dbgModuleClass
А теперь вернемся к примеру функции, дизассемблерный листинг которой был приведен ранее. Для демонстрации работы запустим скрипт ~\samples\synimp.py, который принимает на вход адрес внутри модуля. Скрипт, для указанного модуля, добавляет импорты, как синтетические символы с префиксом "_imp_". После работы скрипта функция выглядит намного понятнее и о ее назначении можно догадаться без трассировки:
0:000> uf 00401090
00401090 51 push ecx
00401091 56 push esi
00401092 8b742410 mov esi,dword ptr [esp+10h]
00401096 6a00 push 0
00401098 6a00 push 0
0040109a 8d44240c lea eax,[esp+0Ch]
0040109e 50 push eax
0040109f 6800040000 push 400h
004010a4 56 push esi
004010a5 6a00 push 0
004010a7 6800110000 push 1100h
004010ac ff1510c04000 call dword ptr [image!_imp_kernel32!FormatMessageW (0040c010)]
004010b2 8b4c2404 mov ecx,dword ptr [esp+4]
004010b6 8b54240c mov edx,dword ptr [esp+0Ch]
004010ba 51 push ecx
004010bb 56 push esi
004010bc 52 push edx
004010bd 6824c24000 push offset image+0xc224 (0040c224)
004010c2 6a10 push 10h
004010c4 68fcc14000 push offset image+0xc1fc (0040c1fc)
004010c9 e832ffffff call image+0x1000 (00401000)
004010ce 8b44241c mov eax,dword ptr [esp+1Ch]
004010d2 83c418 add esp,18h
004010d5 50 push eax
004010d6 ff1514c04000 call dword ptr [image!_imp_kernel32!LocalFree (0040c014)]
004010dc 5e pop esi
004010dd 59 pop ecx
004010de c3 ret
Стоит обратить внимание, что функционал синтетических символов будет включен в сборку pykd с версии 0.0.16
воскресенье, 6 февраля 2011 г.
Release 0.0.15
Вышел очередной релиз pykd.
Исправили ряд мелких и не очень багов:
#8229 - При вызове функции loadModule для модулей отличных от nt появлялось сообщение об ошибке. Теперь - все работает четко.
#8236 - Функции вывода текста ( dprint/dprintln ) не работали с UNICODE. В результате, приходилось писать:
dprint( str( loadUnicodeString( strAddr ) )
Теперь str - можно ( и нужно ) опустить.
#8239 - ф. ptrSignByte возвращала строку, а не число со знаком, что естсетвенно приводило к неправильной работе скриптов.
Добавили следующие функции:
a = locals().aИсправили ряд мелких и не очень багов:
#8229 - При вызове функции loadModule для модулей отличных от nt появлялось сообщение об ошибке. Теперь - все работает четко.
#8236 - Функции вывода текста ( dprint/dprintln ) не работали с UNICODE. В результате, приходилось писать:
dprint( str( loadUnicodeString( strAddr ) )
Теперь str - можно ( и нужно ) опустить.
#8239 - ф. ptrSignByte возвращала строку, а не число со знаком, что естсетвенно приводило к неправильной работе скриптов.
Добавили следующие функции:
locals()Возвращает коллекцию локальных переменных в текущей области видимости. Применять можно при отладке, например так:
while a > 10:
trace()
a = locals().a
Также, локальные переменные можно посмотреть для любого фрейма в коллекции, которую возвращает функция getCurrentStack. Примерно так:
frames = getCurrentStack() for f in frames: dprintln( f.locals )
typedVarArray( offset, moduleName, symbolName, arraySize )Возвращает коллекцию элементов типа moduleName!symbolName, которые располагались в памяти в виде массива размерностью arraySize. Использовать можно примерно так:
nt = loadModule("nt") poolVector = typedVarArray( nt.PoolVector, "nt", "_POOL_DESCRIPTOR*", 2 ) dprintln( "non paged pool: %x" % poolVector[0] ) dprintln( "paged pool: %x" % poolVector[1] )
Подписаться на:
Сообщения (Atom)