Python windbg extension

Обработка исключений в Boost.Python

2012-02-06T00:24:00.000-08:00

Мы в нашем проекте стараемся использовать исключения для сигнализации об ошибках. Почему? Причин несколько: удобно при отладке - если что-то пошло не так, мы сразу видим где и что произошло и можем перейти непосредственно к исправлению ошибки не теряя времени на отладку; пользователю приходится быть более дисциплинированным - ведь исключение нельзя проигнорировать, в отличие от проверки возвращаемого значения; удобно при разработке - вместо прокидывания кода ошибки через все функции, мы просто кидаем исключение, которое к тому же может быть гораздо информативнее. В результате, мы верим, что весь комплекс pykd + скрипт становится надежным инструментом.

Но разберемся, как же исключения попадают из С++ кода, написанного с помощью Boost::Python в виртуальную машину Python? Будем двигаться итеративно.

Итерация 0: Генерируем python исключение

Сгенерировать исключение в ВМ python просто. Для этого служит функция PyErr_SetString. В нее нужно передать указатель на тип исключения и сторку с описанием ошибки. Например так:

PyErr_SetString( PyExc_IndexError, "Index out of range" );

Не очень то удобно использовать эту конструкцию внтури С++ кода. Хотелось бы кидать С++ исключение и чтобы оно волшебным образом превращалось в python исключение. К счастью, boost::python предоставляет эту возможность.

Итерация 1: транслируем исключение из C++ в python

В общем все довольно просто. Любое исключение, возникшее во время выполнения python программы внутри модуля, использующего boost::python отлавливается. Существует механизм, с помощью которого можно поучаствовать в обработке такого исключения. Для этого необходимо зарегистрировать функцию-транслятор с помощью вызова register_exception_translator. Вот как это делается:

// класс исключения, для использования в C++ коде
class PyException : public std::exception
{
public:

    PyException( PyObject*  pyObj, const std::string &desc ) :
        std::exception( desc.c_str() ),
        m_typeObj( pyObj )
        {}    

    static
    void
    exceptionTranslate(const PyException &e ) {
        PyErr_SetString( e.m_typeObj, e.what() );
    }

private:

    PyObject*       m_typeObj;
};

void myFunc() {
    throw PyException( PyExc_IndexError, "Index out of range" );
}


BOOST_PYTHON_MODULE( my_module )
{
    // регистрируем транслятор
    boost::python::register_exception_translator<PyException>( &PyException::exceptionTranslate );

    // функция, вызываемая из python программы
    boost::python::def( "myFunc", &myFunc );
}

Прекрасно, генерировать исключения python теперь удобно. Но я хочу использовать собственный тип исключений. Возможно ли это? В общем да...

Итерация 2: Использование собственного типа исключений.

Идея простая. Boost::python дает возможность импортировать типы в python программу. Наш план таков: импортируем тип в python, регистрируем функцию-транслятор С++ исключения и в коде функции-трансялтора используем наш тип исключения, который мы ранее импортировали ( и запомнили! ) в python.

// класс исключения, для использования в C++ коде
class MyException : public std::exception
{
public:

    MyException ( const std::string &desc ) :
        std::exception( desc.c_str() )
        {}    

    static void setTypeObject(PyObject *p) {
        exceptTypeObject = p;
        python::register_exception_translator<MyException>( &exceptionTranslate );
    }

private:

   static PyObject  *exceptTypeObject;

    static
    void
    exceptionTranslate(const MyException &e ) {
        boost::python::object  pyExcept(e);
        PyErr_SetObject( exceptTypeObject , pyExcept.ptr());
    }
};

void myFunc() {
    throw MyException( "Something's wrong" );
}


BOOST_PYTHON_MODULE( my_module )
{
    // функция, вызываемая из python программы
    boost::python::def( "myFunc", &myFunc );

    // регистрирем тип исключения и его транслятор
    MyException::setTypeObject( 
        boost::python::class_<MyException>( "MyException", "MyException error" ).ptr()
    );
}

Вот на этом мы могли бы остановиться. Могли бы, если бы мир был совершенен. На самом деле, после чуть более тщательного тестирования, мы приходим к заключению, что работают наши исключения не совсем верно. А именно:
не работает инструкция raise MyException - вместо генерации исключения обозначенного типа генерирует питоновское исключение, общий смысл которого в двух словах сводится к тому, что тип MyException не пригоден для генерации исключений. Вторая проблема заключается в том, что при попытке сделать иерархию исключений мы сталкиваемся с тем, что неверно работает фильтрация исключений, а именно: инструкция except BaseException не ловит исключения дочерних типов. Короче говоря, имплементация наших исключений весьма далека не только от идеала, но и просто от обычных python исключений. Будем разбираться.

Итерация 3: разбираемся

Изучив внимательно текст ошибки при попытке возбудить исключение raise MyExceptionException. Кроме того, тут надо сделать небольшой ( самостоятельный ;) ) экскурс в анатомию питонов и изучить вопрос о типах и метатипах. Если в двух словах, то тип в питоне - это такой же объект и ,соответственно, может быть динамически создан вызовом конструктора у некого типа. Вот этот "некий" тип и является метатипом. Покопавшись внутрях boost::python можно придти к заключению, что все типы, которые он импортирует, создаются через один и тот же метаттип. В итоге наш MyException имеет метатип такой же, как и другие типы, импортированные из boost::python. И он не имеет родственных связей с типами питоновских исключений. А это негативно влияет на обработку исключений питоном. Наш дальнейший план каким-то образом унаследовать MyException от питоновского типа Exception. Как же это сделать то????

Итерация 4: Как же это сделать то????

Делать то нечего, приходится отказаться от регистрации типов исключений через бустовый class_. Подсмотрев в его исходники, находим место, где создается новый питоновский тип и переписываем его примерно так:

using boost::python;

// Базовым типом у нас будет PyExc_Exception
handle<>   basedtype = handle<>(PyExc_Exception);

// Всякий объект в питоне имеет свой список свойств
dict       ob_dict;
ob_dict["__doc__"] = "MyException"

// Объект в питоне кстате может иметь много пап. Но у нас будет один - самый лучший! 
tuple      ob_bases = make_tuple( basedtype );

// Вот тут весь оргазм: 
// Py_TYPE(basedtype.get()) - вернет нам тип от объекта PyExc_Exception. Тип типа - это метатип, мы это выясняли
// object( boost::python::handle<>(Py_TYPE(basedtype.get()) ) ) - это будет у нас объект меаттипа
// Что такоей вызов SomeType( a, b, c) ? - это конструирование объекта этого типа
// Теперь собираем пазл во-едино: мы создаем новый тип, который имеет такой же метатип как и PyExc_Exception
// и является наследником PyExc_Exception
object     ob = object( boost::python::handle<>(Py_TYPE(basedtype.get()) ) )( "MyException", ob_bases, ob_dict );

// остается пристроить новорожденного в приличное место, а именно в скоуп модуля
scope().attr( "MyException" ) = ob;

Теперь остается привести все в божеский вид.

Итерация 5: божеский вид

Для приведения в божеский вид нам надо написать какой то шаблон, по своим функциям хоть чуть-чуть напоминающий class_. Как минимум, хочется наследования, пусть даже не множественного. В результате, родился такой вот шаблон. Он далек от изящества к сожалению, но у него доброе сердце )).

template< class TExcept >
struct exceptPyType{

     static python::handle<>     pyExceptType;

};

template< class TExcept, class TBaseExcept = python::detail::not_specified >
class exception  {


public:

    exception( const std::string& className, const std::string& classDesc ) 
    {
        python::handle<>   basedtype;      

        if ( boost::is_same<TBaseExcept, python::detail::not_specified>::value )
        {
            basedtype = python::handle<>(PyExc_Exception);
        }
        else
        {
            basedtype = exceptPyType<TBaseExcept>::pyExceptType;
        }

        python::dict       ob_dict;
       
        ob_dict["__doc__"] = classDesc;

        python::tuple      ob_bases = python::make_tuple( basedtype );

        python::object     ob = python::object( python::handle<>(Py_TYPE(basedtype.get()) ) )( className, ob_bases, ob_dict );

        python::scope().attr( className.c_str() ) = ob;

        exceptPyType<TExcept>::pyExceptType = python::handle<>( ob.ptr() );

        python::register_exception_translator<TExcept>( &exceptionTranslate );
    }

    static
    void
    exceptionTranslate(const TExcept &e ) {

        python::object      exceptObj = python::object( exceptPyType<TExcept>::pyExceptType )( e.what() );

        PyErr_SetObject( exceptPyType<TExcept>::pyExceptType.get(), exceptObj.ptr());
    }

};

Но со стороны описания модуля выглядит все не так уж и плохо:

BOOST_PYTHON_MODULE( mymodule )
{
  exception<MyException>( "MyException", "description" );
  exception<MyExceptionEx,MyException>( "MyExceptionEx", "description" );
}

Заключение

Почему же нам пришлось прибегать к таким извращениям? Очевидно, что boost::python далек от совершенства )). Чего же в нем не хватает? Было бы классно, если бы существовала форма функции class_, позволяющая задать базовый класс через указатель на питоноский тип.

Новая линейка Pykd 0.1.x доступна для тестирования

2011-12-16T05:06:00.000-08:00

Хочу представить вам новую, кардинально переработанную версию 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.

Спасибо, что используете наш продукт :).

Обработка исключений и точек останова

2011-10-10T01:06:00.000-07:00

В 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 специально был включен следующий код:

__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-а из которых игнорируются, так как могут быть обработаны отлаживаемым объектом.

Release 0.0.20

2011-10-09T22:39:00.000-07:00

Всем доброго дня! Спешу представить очередной релиз pykd - версия 0.0.20.

Для тех, кто предпочитает словам дела, страница загрузки и удачи в использовании! Я же хотел кратко пробежаться по составу релиза:

Управление отладчиком:

Добавлены следующие функции: 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() ] )

багфикс

~~9219~~: улучшена поддержка многопоточности. Функции, которые могут надолго заблокировать исполнение python программы ( такие как go() и dbgCommand() ) сохраняют состояние потока, что позволяет планировщику python выполнять код в других потоках

~~9518~~: Исправлен баг с выводом текста через команду dprint(ln). До этого текст, содержащий символ '%' выводился неправильно ( обычно, обрезался ).

~~9555~~: Метод name() класса dbgModuleClass возвращал строку, содержащую нулевой символ. В итоге при использовании данного метода вывод мог повреждаться ( обрезаться )

Release 0.0.19

2011-07-29T00:03:00.000-07:00

Представляем ( не без затаенной гордости конечно ) очередной релиз pykd 0.0.19. Мы немного запоздали по срокам выпуска, надеемся на ваше понимание. И так, что новенького:

Доработан интерфейс для 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-язычный технический писатель.

Qt: "A QApplication instance already exists"

2011-06-22T06:18:00.000-07:00

Не так давно мы публиковали пример графического плагина на основе связки Qt и PySide. Использование графического интерфейса предоставляет широчайшие возможности. К сожалению, приведенный код содержал один существенный недостаток: при повторном запуске скрипта появлялось сообщение: "A QApplication instance already exists".

Чтобы избежать этого, нужно совсем чуть-чуть переработать процедуру инициализации 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()

Обработка событий загрузки и выгрузки модулей отлаживаемой системы

2011-05-26T06:08:00.000-07:00

Одно из нововведений релиза pykd 0.0.18 это базовый класс для обработки событий от Debug Engine. В текущей версии реализованы только события загрузки и выгрузки модулей. Об этом было рассказано в обзоре релиза.
Реализация сделана через базовый класс 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.

Release 0.0.18

2011-05-25T23:57:00.000-07:00

Хочу представить очередной релиз pykd. Хотя список изменений может показаться не впечатляющим, но за этими изменениями стоит напряженная работа. Были серьезно переработаны ключевые части проекта. Но сначала приведем формальный список изменений:

Новые функции:

loadWChars - юникодная версия существующей loadChars
rdmsr - возвращает значение MSR регистра

Поддержка исключений:

BaseException - базовый класс для всех исключений
MemoryException - класс исключений для ошибок чтения памяти
TypeException - класс исключений при работе с типами

Новые классы:

typedVar - переработанная версия класса typedVarClass
typeInfo - переработанная версия класса typeClass
debugEvent - базовый класс для создания обработчиков событий отладчика

Bugs fixed:

~~8669~~ - функция typedVar (теперь это класс ) создает объект для несуществующего типа
~~8655~~ - не поддерживается работа с неименованными членами структур

Прочее:

Добавили мелкую, но очень удобную фичу для команды 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. Спасибо вам за то, что внимательно прочли. Как всегда, ждем от вас вопросов, предложений, благодарности и/или кусочки ненависти - все сгодится :).

И спасибо разработчикам за их нелегкий труд.

Анализ сетевых пакетов в Vista/Windows 7

2011-04-24T06:10:00.000-07:00

Сетевые пакеты в Vista/Windows 7 описываются структурой NET_BUFFER и списками NET_BUFFER_LIST. Мы написали скрипт, который анализирует содержимое пакетов с учетом сетевых протоколов. Сам скрипт можно взять здесь: nbl.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, иногда бывает полезно, надеемся, будет и вам.

Работа с памятью

2011-04-22T00:47:00.000-07:00

Все данные лежат в памяти, это очевидно. Ранее, мы уже рассмотрели (ссылка), как с помощью фцнкции typedVar получить доступ к содержимому переменной с учетом ее типа. Но бывают ситуации, когда мы не знаем тип, или содержимое памяти представляет собой сырой нетипизированный массив. Для работы с такими массивами предназначены следующие функции:
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 и, соответственно, избавляют от необходимости в ручную разбирать эти стуркутры для получения строки.

Release 0.0.17

2011-04-18T00:04:00.000-07:00

Представляем очередной релиз 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:

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

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

Надеемся, релиз 0.0.17 сделает вашу работу с pykd более приятной и плодотворной!

HOWTO

2011-04-03T23:47:00.000-07:00

1. Как получить указатель на PEB ?

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)

В более сложных случаях можно использовать любой отладчик python кода. Например, eсlipse или Visual Studio 2010 с плагином pytools

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.

Автоматическая установка pykd

2011-03-21T00:55:00.000-07:00

Установить pykd вручную не сложно. Однако есть как минимум один подводный камень: нужно также установить дистрибутив vcredist нужной версии. Но все заботы может взять на себя автоматический инсталлятор. Он найдет python нужной версии, а если его нет - скачает, установит рантайм библиотеки и, конечно, сэкономит вам время.

http://perfect-coding.blogspot.com/2011/03/pykd-python-windbg-extension.html

PySide+pykd: используем Qt в питоновских скриптах к WinDbg

2011-03-18T07:52:00.000-07:00

pykd, как расширении к WinDbg, дает не только возможность использования мощного и гибкого языка Python, но и уже готовых сторонних проектов. Далее пойдет речь о PySide - библиотеке интеграции инструментария Qt в Python. Возьмем простой пример: нужно просмотреть статистику о процессах системы, в частноти размер виртуального адресного пространства и счетчики операций ввода/вывода. Не буду рассказывать об установке PySide, так как на официальной странице загрузок для Windows можно скачать инсталлятор. Набросаем небольшой скрипт, который средствами pykd получает и анализирует список процессов, а затем использует PySide для визуализации собранных данных в виде таблицы в GUI-окне:

import sys
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_()

Теперь исполним его в WinDbg. После того, как скрипт построит список процессов, мы увидим окно результатов. Оно не является модальным по отношению к основному окну WinDbg, но отладчик терпеливо ждет завершения работы скрипта (в нашем случае - закрытия окна):

Конечно, можно было бы выдать эту информацию в текстовой форме. Но GUI таблица, например, позволяет одним кликом поменять колонку сортировки и можно наблюдать какой процесс активно более активно читает, а какой пишет.
Еще один приятный момент использования PySide - лицензия LGPL, позволяющая использовать и распространять библиотеку в любых проектах, включая коммерческие.

Исследуем ASLR

2011-03-16T07:39:00.000-07:00

Сегодня неожиданно возник вопрос: одинаков ли адрес загрузки 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__":

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.

Release 0.0.16

2011-03-04T23:49:00.000-08:00

Хочу представить очередной релиз проекта 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.

Синтетические символы: делаем дизассемблер WinDbg дружелюбнее

2011-02-28T02:25:00.000-08:00

Многие не любят использовать 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-а пути:

Функция addSynSymbol(адрес_символа, размер_символа, имя_символа)
Метод addSynSymbol(смещение_символа, размер_символа, имя_символа) класса dbgModuleClass

Добавление синтетического символа через метод 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

Release 0.0.15

2011-02-06T22:51:00.000-08:00

Вышел очередной релиз pykd.

Исправили ряд мелких и не очень багов:

#8229 - При вызове функции loadModule для модулей отличных от nt появлялось сообщение об ошибке. Теперь - все работает четко.
#8236 - Функции вывода текста ( dprint/dprintln ) не работали с UNICODE. В результате, приходилось писать:
dprint( str( loadUnicodeString( strAddr ) )
Теперь str - можно ( и нужно ) опустить.
#8239 - ф. ptrSignByte возвращала строку, а не число со знаком, что естсетвенно приводило к неправильной работе скриптов.

Добавили следующие функции:

locals()

Возвращает коллекцию локальных переменных в текущей области видимости. Применять можно при отладке, например так:

a = locals().a
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] )

Сборка pykd вручную.

2011-02-03T01:03:00.000-08:00

Без лишней воды, по пунктам:

1. Забираем исходники

2. Настраиваем boost::python
2.1 Переменная окружения BOOST_ROOT
Должна указывать соответственно на каталог, где лежит используемая версия boost.
У меня это: С:\lib\boost_1_40_0
2.2 Сборка boost::python
В настройках проекта забиты следующие пути к собранным библиотекам:
$(BOOST_ROOT)\stage - для х86 сборки
$(BOOST_ROOT)\stage64 - для х64 сборки
Чтобы собрать соответствующие библиотеки, нужно выполнить следующие команды, установив текущую директорию в $(BOOST_ROOT)
Для x86:
bjam --stagedir=stage --with-python stage
И для x64:
bjam address-model=64 --stagedir=stage64 --with-python stage
Возможно, вам понадобится сначала установить bjam ( ссылка )
2.3 Указание версии python
Если у вас на машине есть несколько версий python и вы хотите явно указать, какую использовать, необходимо отредактировать файл user-config.jam и добавить в него строчки, к примеру, такие:
using python : 2.6 ;
using python : 2.7 ;
Теперь можно собрать библиотеки явно указав версию python
Для x86:
bjam --stagedir=stage --with-python stage python=2.7
И для x64:
bjam address-model=64 --stagedir=stage64 --with-python stage python=2.7
Тут можно подробнее почитать:
http://www.boost.org/doc/libs/1_45_0/libs/python/doc/building.html

3. Настройка путей к python
Для сборки понадобятся заголовочные файлы и библиотека экспорта от соответствующей версии python. Для указания путей используется переменная окружения PYTHON_ROOT, которая должна указывать на каталог установки Python. Если при сборки boost::python была задана конкртная версия python, то перемнная PYTHON_ROOT должна ссылаться на инсталляцию python соответствующей версии.
К примеру, у меня на машине переменная PYTHON_ROOT = C:\Python26. И установлены две версии ( x86 и x64) python:
C:\Python26\x86\
C:\Python26\x64\

4. Настройка путей к DBG SDK
Пути к DBG SDK задаются через переменную окружения DBG_SDK_ROOT. Сам DBG SDK находится в каталоге установки windbg.

Скрипты для windbg

2011-01-26T00:18:00.000-08:00

Целью проекта pykd является интеграция python в windbg. А целью интеграции python в windbg - замена стандартного скриптового движка на более удобный. А удобный скриптовый движок нам нужен, чтобы быстро и легко автоматизировать свои действия. По-моему, так?

В данном посте я хочу предствить ряд скриптов, написанных с помощью pykd, которые могут пригодится в повседневной работе многим. Описание их работы есть в wiki на сайте проекта ( ссылка ) и я не буду репостить текст. Допустим вы уже прочитали статью с wiki и уже хотите попробовать. Где взять сами скрипты? Через дистрибутив они не распространяются, единственный способ - скачать из репозитория исходного кода ( ссылка ). В каталоге samples лежат, как не трудно догадаться, разные демонстрационный примеры. А в каталоге snippets - как раз то, что мы ищем. Допустим вы скачали исходный код, куда теперь распаковать каталоги со скриптами? Это не важно - в любой каталог, куда есть доступ. Для удобства использования настоятельно рекомендуется добавить этот путь в переменную окружения $PYTHONPATH. В этом случае, для вызова скрипта не нужно указывать полный путь, даже расширение можно опустить, примерно так:
!py export nt Zw*SetInformation*

Если вы написали полезный скрпит и хотите поделится им - присылайте ссылки на опубликованный код или исходный код и мы опубликуем его на сайте проекта под действующий лицензией.

Почта: pykd.codeplex@hotmail.com

typedVar

2011-01-20T23:59:00.000-08:00

При разработке pykd мы старались не трансиловать механически функционал из Debug Engine, а реализвать API, удобный при повседневной работе в windbg. А что делает пользователь в отладчике чаще всего? Конечно, просматривает значение переменных! Соответственно, для автоматизации его работу в первую очередь нужна функция для удобной и быстрой работы с переменными. Для этого мы реализовали функцию typedVar.

Вот ее прототип:

typedVar( string moduleName, string typeName, long address )

moduleName - имя модуля, содержащего тип
typeName - имя типа переменной
address - виртуальный адрес переменной

Функция создает объект типа typedVarClass и динамически добавляет ему аттрибуты, с именами соответствующими именам полей структуры заданного типа. Если поле является сложным типом - операция повторяется рекурсивно. В результате, мы в python е получаем объект, с которым можем работать в той же манере, как и в Си:

p = typedVar( "nt", "_ETHREAD", threadAddr )
print "Wait time: %d" % p.Tcb.WaitTime

Данный код выведет значение счетчика ожидания потока, адрес которого задан в переменной threadAddr. Массивы тоже будут корректно обработаны. Обращаться к элементу массива можно также в стиле Си:

print p.Tcb.Alerted[1]

В работе часто приходится иметь дело с связанными списками структур. Конечно, можно в цикле вызвать ф. typedVar для получения значений списка. В pykd для этого реализована специальная функция: typedVarList.

Вот ее прототип:

typedVarList( long head_address, string moduleName, string typeName, fieldName)

head_address - адрес головы списка
moduleName - имя модуля, содержащего тип элемента списка
typeName - имя типа элемента списка
fieldName - имя поля, содержащего указатель на следующий элемент списка.

Функция возвращает питоновский лист, каждый элемент которого имеет тип typedVarClass. Соответственно, для элементов этого списка справедливо все, что сказано выше. Проиллюстрируем на примере, как это работает:

nt = loadModule( "nt" )
processList = typedVarList( nt.PsActiveProcessHead, "nt", "_EPROCESS", "ActiveProcessLinks" )
for process in processList:
dprintln( "".join( [ chr(i) for i in process.ImageFileName.values() ] ) )

Данный код выведет на экран список процессов

Третья полезная функция для работы с переменными: containingRecord. Это аналог макроса CONTAINING_RECORD.

Вот ее прототип:

containingRecord( long field_address, string moduleName, string typeName, fieldName)

field_address - адрес поля структуры.
moduleName - имя модуля, содержащего тип
typeName - имя типа элемента списка
fieldName - имя поля, адрес которого задан переменной field_address

Битовые поля

Функция typedVar не поддерживает работу с битовымии полями в полном объеме. Если в структуре объявлено битовое поле:

struct A {
int a : 10;
int b : 20;
};

Мы в питоне получим, что obj.a = obj.b. Т.е структура битового поля не сохраняется и придется дополнительно накладывать битовые маски. Интересно, что команда dt в windbg правильно отображает битовые поля. Так что тут есть над чем поработать!

PYKD: Getting Started

2011-01-18T23:58:00.000-08:00

Логично в самом начале жизни блога написать о том, как начать работу с PYKD.
Основная задача pykd - подружить windbg и python. А поэтому разумным кажется требование иметь на машине предустановленные версии этих продуктов. Если вы еще читаете это, я уверен, что у вас уже установлен windbg или по крайней мере, вы знаете о чем идет речь. На установке python остановимся чуть подробнее. Какую версию выбрать? 1) Разрядность ( 32 или 64 бита ) должна совпадать с разрядностью windbg 2) Версия python должна поддерживаться pykd. В настоящее время поддерживается только 2.6.х ( для других версий 2.x можно собрать самостоятельно ). Таким образом, мы однозначно определяем, какой именно пакет скачать с www.python.org.

Переходим к установке pykd. К сожалению, в настоящее время автоматический инсталлятор отсутствует и придется все делать вручную. Загружаем архив с последней версией: ссылка. В архиве два каталога - x64 и x86, в которых лежат сборки pykd.pyd соответствующей разрядности. Выбираем нужную версию и копируем ее. Только вот куда? В принципе, можно в любой каталог, из которого возможнен запуск исполняемых файлов. Наиболее удобным является подкаталог winext, расположенный в каталоге установки windbg. При выборе этого каталога при последующей загрузке расширения в windbg достаточно будет просто указать имя. В других случаях придется указывать полный путь.

Можно начинать работу? Не совсем. Для работы pykd необходимо, чтобы на машине был установлен Microsoft Visual C++ 2005 SP1 Redistributable Package нужной версии и разрядности. Загрузить его можно с сайта Microsoft или со страницы загрузки: ссылка, файл vcredist_x86 или vcredist_x64. С выбором нужного, надеюсь, понятно. Вот теперь - можно начинать!

Запускаем отладчик windbg и открываем любую отладочную сессию: начинаем отладку пользоватеьского процесса, загружаем креш-дамп или подключаемся к отладчику ядра удаленной машины. Далее необходимо загрузить расширение. Если вы установили его по рекомендованному пути, сделать это просто:
.load pykd.pyd
Проверим, что все заработало, вводим команду !pycmd для перехода в режим интерпретатора python
1>!pycmd
>>> print "hello world!"
hello world!
>>>
Для выхода из режима интерпретатора просто вводим пустую строку. Если у вас получилось вывести на экран приветственную строку, значит с установкой и настройкой все получилось. Теперь пора подумать, какую из этого можно извлечь пользу. Сам по себе интерпретатор python кончено очень занимательная штука, но нам он нужен для управления отладчиком. Поскольку pykd.pyd является не только расширением для windbg, но и модулем python, он нам в этом и поможет:
1>!pycmd
>>> from pykd import *
>>> eax = reg("eax")
>>> print eax
125
>>>
Мы использовали функцию reg, реализованную в модуле pykd. Полный список API приведен здесь.
Сессия интерпретатора питона длится, пока pykd не будет выгружен. Поэтому можно много позже сделать
1>!pycmd
>>> print eax
125
и получить сохраненное в контексте python значение.

Кроме глобальной сессии интерпретора python есть возможность выполнить скрипт в изолированной среде:
1>!py myscript.py "hello script"
hello from script
На сайте проекта приведены как небольшие демонстрационные примеры таких скриптов, так и скрипты, которые вы можете использовать в своей работе. Здесь можно получить подробную информацию.

И так, вы попробовали и:
1) вам понравилось. Тогда помогите проекту: примите участие в разработке, написании документации, пришлите свой полезный скрипт, киньте ссылку коллеге - он то наверняка сидит без дела целыми днями в инете. Да просто напишите нам свое мнение - для нас это будет очень ценно.
2) не понравилось. Очень вам просим, напишите, что именно! Это очень важно для нас.

Release 0.0.14

2011-01-17T09:28:00.000-08:00

В релизе 0.0.14 исправлен один серьезный баг, заключавшийся в нарушении изоляции выполнений скриптов через расширение отладчика !py. В результате, все скрипты исполнялись в контексте одного интерпретатора и появлялись некоторые странные артефакты. К примеру, если код импортированных модулей изменялся, это не отражалось на выполнение скрипта, импортирующего модуль.

В класс typedVarClass добавлен метод получения аттрибутов __getattr__. Получение аттрибута трактуется как вычисление адреса переменной(функции) модуля.
Сравните два фрагмента кода. В старой редакции для получения адреса переменной необходимо было явно вызывать функцию getOffset:

# Old version
nt = loadModule( "nt" )
nt.PsActiveProcessHead = getOffset( "nt", "PsActiveProcessHead" )
processList = typedVarList( nt.PsActiveProcessHead, "nt", "_EPROCESS", "ActiveProcessLinks" )

Теперь в этом нет нужды, при обращении к аттрибуту экземпляра класса модуля, эта функция будет вызвана автоматически

# New version
nt = loadModule( "nt" )
#nt.PsActiveProcessHead = getOffset( "nt", "PsActiveProcessHead" )
processList = typedVarList( nt.PsActiveProcessHead, "nt", "_EPROCESS", "ActiveProcessLinks" )

При использовании команды !pycmd часто возникает желание распечатать содержимое переменной, полученной через вызов typedVar. До этого единственным способом было явное обращение к аттрибутам ( соответствующим полям стурктуры ). Оператор print - не работал. Поэтому в класс typedVarClass был добавлен метод __str__, возвращающий текстовое представление класса:

p = typedVarList( "nt", "_EPROCESS", processAddr )
print p

Оставить отзыв

2011-01-01T00:00:00.000-08:00

Если у вас есть любые предложения, жалобы или слова благодарности, оставьте комментарий к этому сообщению.