Not a kernel guy

На днях свалился в inbox вопрос:

The documentation for QueueUserApc states "an APC cannot be queued from a 64-bit process to a 32-bit process or vice versa."

However on Vista Ultimate x64, we can queue a user APC from a 32-bit process to a 64-bit process. In our test application the 64-bit recipient crashes, we haven’t explored why just yet, but the point is that the operation should not succeed and the 64-bit application’s APC queue should never have the APC inserted.

Is it an OS bug?

Документация к функции QueueUserApc утверждает, что асинхронный вызов процедуры (APC) не может быть запрошен из 64-х битного процесса для выполнения в 32-х битном и наоборот.

Однако на Vista Ultimate x64 мы можем выполнить асинхронный вызов пользовательского режима из 32-х битного процесса в 64-х битном процессе. В нашем тестовом приложении 64-х битный получатель падает и мы еще не выяснили почему, но дело в том, что операция (QueueUserApc) не должна завершаться успешно и асинхронный вызов не должен вставляться в очередь вызовов 64-х разрядного процесса.

Это баг ОС?

Вопрос примечателен тем, что это уже третье письмо на эту тему за последние два месяца, хотя функция QueueUserApc далеко не самая широко используемая функция Win32. Не иначе какой настойчивый клиент эту функцию мучает.

(more…)

В комментариях к предыдущем посте про исключения верно заметили, что exception chain в TEB используется только в x86 коде. И x64, и ia64 exception chain не используют вообще. Как же, в таком случае, выполняется «раскрутка» стека при обработке исключения?

(more…)

Набор команд x86-совместимых процессоров за годы эволюции набрал немалое количество всякой экзотики. Один из примеров такой экзотики – инструкция UD2. Задача этой инструкции состоит в том, чтобы… быть несуществующей инструкцией. Выполнение UD2 всегда приводит к генерации исключения «Invalid opcode». Отличие UD2 от любой другой несуществующей инструкции в том, что эта инструкция гарантированно не станет корректной инструкцией в будущем.

(more…)

Тема жёванная-пережёванная, так что я не буду подробно останавливаться на том, зачем нужен единый стиль кодирования в команде (или проекте). Основные тезисы:

• Унифицированный стиль кодирования упрощает сопровождение кода. Это, кажется, единственная причина, зачем он вообще нужен. Все остальное, включая меньшее количество мигреней в минуту на одного эталонного разработчика, - побочные эффекты, направленные опять же на упрощение (читай - повышение эффективности) сопровождения кода.
• Кажется, нет никакой разницы между разными стилями с точки зрения легкости понимания и написания кода. Любой выбранный стиль, будучи принят в команде упрощает сопровождение кода, при условии, что он один и используется.
• Единственный способ выработать единый стиль – диктатура в том или ином виде. Можно месяцами спорить о том, где правильно ставить скобки, какие отступы должны быть, можно ли использовать две пустые строки в качестве разделителя и т.д. и т.п. В один прекрасный момент терпение лопается и волевым решением назначается «правильный» стиль.

(more…)

Сижу, разбираюсь как Detours перехватывает функции Win32 API. Сама идея известна. В начало функции пишется безусловный JMP на функцию перехватчик. Для того, чтобы вызвать оригинальную функции, её код, на место которого помещается JMP, копируется в буфер и дополняется безусловным JMP на первую нетронутую инструкцию.

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

1. Поверяется, не указывает ли указатель на перехватываемую функцию, не на саму функцию, а на элемент таблицы импорта. Если так, то в качестве указателя берется imm32 из JMP;
2. Проверяется длина функции, причем считается, что функция может завершаться RET, JMP (разные варианты) или INT3. Последние два варианта не очень очевидны, хотя при взгляде на код становится ясно, что к чему;
3. После JMP, завершающего скопированный из функции код, пишется INT3. То же, на всякий случай;
4. Код установки перехватчиков завернут в транзакцию. Устанавливаются (или снимаются) либо все перехватчики, либо транзакция откатывается. Впрочем, 100% гарантии это все равно не дает;
5. Ну и плюс ко всему поддерживается статическая установка перехватчиков, как раз чтобы избежать проблем с динамическим перехватом.

В этом списке не хватает только поддержки hotpatching. Код, скомпилированный с поддержкой hotpatching можно править прямо на ходу, не останавливая потоки в процессе.

Наткнулся на хороший open source disassembler, понимающий и 80×86 и amd64, и распространяемый под BSD лицензией: diStorm64.

diStorm is a binary stream disassembler. It’s capable of disassembling 80×86 instructions in 64 bits (AMD64, X86-64) and both in 16 and 32 bits. In addition, it disassembles FPU, MMX, SSE, SSE2, SSE3, SSSE3, SSE4, 3DNow! (w/ extensions), new x86-64 instruction sets, VMX, and AMD’s SVM! diStorm was written to decode quickly every instruction as accurately as possible. Robust decoding, while taking special care for valid or unused prefixes, is what makes this disassembler powerful, especially for research. Another benefit that might come in handy is that the module was written as multi-threaded, which means you could disassemble several streams or more simultaneously.

В использовании прост как двери: на входе даётся кусок кода, разрядность и его виртуальный адрес, на выходе получается набор инструкций. Для каждой указывается мнемоника, операнды, префиксы и размер. В комплекте идет интерфейсный модуль для Python, что может быть полезно для всяких reverse engineering утилит.

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

(more…)