PS. Знал бы об этом пять лет назад – день жизни сэкономил бы уже наверное. Хотя мог бы и сам догадаться…

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

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

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

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 утилит.

А что плохого в телекоммьюте?

телекоммют плох там, где работает команда, где есть постоянный обмен идеями, где восклицание “@#$#@$@#$!!!!”, сказанное в адрес чьего-то кода, слышит весь тим.

Напишите “@#$#@$@#$!!!!” в комментариях.

Народ почитает-посмеётся. Это кто найдет. И всё.

А вот когда тоже самое бывает сказано тихим рыком на басах, с варварским восточно-европейским акцентом, то эффект совсем другой. Виновный нервно дергается, судорожно просматривает свои последние коммиты, одновременно собирает в жменю блокнот и карандаш, т.к. знает что сейчас к нему придут и начнутся подвалы лубянки. Прочие (пока) непричастные вжимаются в клавиатуры, можно сказать врастая в код, и делая вид что их тут совсем почти нет. Ну разве в телекоммюте такое возможно?

Само собой однозначного ответа на этот вопрос не существует, тем более что этот вопрос вторгается в область coding guidelines, а последних, как известно, существует ровно столько, сколько есть программистов на Земле. Или около того. Как минимум ответ зависит от следующих факторов:

1. Языка программирования, операционной системы и программного окружения;
2. Степени доверия вызываемой функции к вызывающему коду.

Пункт №1 мы, во избежание священной войны, положим константой – язык C/C++, OS – Windows, окружение – «обычный» user/kernel mode код.

А вот пункт №2 стоит обсудить детально. Сравним два случая:

1. Вызов функции внутри одного бинарного модуля;
2. Вызов сервиса ядра из пользовательского кода.

В отличие от «доверенного» вызова, службы ядра дополнительно проверяют, что:

1. Все буфера целиком находятся в user space (ProbeXxx функции);
2. Чтение/запись в user space завершается успешно (все операции с ними помещаются в блок try-except);
3. Чтение любых данных из user space выполняется только один раз (данные копируются в локальный буфер);
4. Все параметры, после того, как они были скопированы в kernel space, содержат допустимые значения (проверки на выход на пределы диапазона и прочее).

Очевидно, что дополнительные проверки нужны потому, что пользовательский код менее привилегирован, чем код ядра, и более подвержен сбоям/атакам. Несколько менее очевидно, что дополнительные проверки на самом деле нужны потому, что сами данные приходят из менее привилегированного источника. О том, почему это важно – чуть ниже.

Далее, данные никогда не представлены сами по себе. Данные всегда упаковываются в некий «контейнер». Контейнером могут быть языковые конструкции, например объект или переменная типа «int», или другие данные, например TCP пакет упаковывается в IP пакет. Следует различать проверки целостности контейнера и проверки целостности данных. В примере выше, пункты №№1 – 3 представляют ни что иное, как проверку целостности контейнера (буфера в user space). Проверка целостности самих данных представлена единственным пунктом №4.

Нужно ли при каждом вызове выполнять все проверки? Конечно - нет. Какие проверки можно опустить? В приведенном примере с вызовом функции в пределах одного модуля, можно ожидать, что свойства контейнера с данными не изменятся. А если и изменятся, то только под воздействием внешних факторов, которые мы все равно не в состоянии контролировать (в пределах данного модуля). Соответственно, при «доверенном» вызове проверять целостность контейнера нецелесообразно.

Если отвлечься от абстрактных контейнеров, это означает что большинство указателей при «доверенном» вызове не проверяется. Более того, такая проверка может быть вредна, так как затрудняет отлов ошибок, пряча попытки некорректного разыменования указателей.

Количество проверок целостности самих данных тоже можно сократить до минимума – до одной. В теории, конечно. Для этого используется анализ потоков данных (Data Flow Analysis, DFD), суть которого состоит в том, что:

1. Идентифицируются все участники обмена данными (т.е. все компоненты кода и внешние источники);
2. Определяются характер передаваемых данных, а также, откуда и куда они передаются;
3. Определяется уровень привилегированности каждого участника обмена данными.

Передача данных от менее привилегированного к более привилегированному участнику считается передачей через границу доверия (Trust Boundary), при которой принимающая сторона должна проверить целостность полученных данных, включая как целостность контейнера, так и целостность данных. При составлении DFD диаграммы следует помнить, что данные (например, IP пакет) могут сами выступать в роли контейнера для другого компонента. В таком случае, для инкапсулированных данных граница доверия будет пролегать на один или несколько компонентов дальше.

Итак, резюме:

1. Следует различать контейнер и сами данные, и понимать, что проверка их целостности может выполняться разными компонентами;
2. Проверка целостности контейнера выполняется только в случае, если передача данных идет через границу доверия. DFD диаграмма должна помочь в обнаружении всех границ доверия;
3. Проверка целостности данных производится первым потребителем этих данных.

Подсмотрел у Реймонда Чена. Безумный ученый доктор Ужасный ведёт блог и непримирумую борьбу с капитаном Молотком за контроль над миром сердцем Копейки – девушки из прачечной «Отмывка Монет», с которой доктор уже месяц пытается заговорить. Кроме того, доктор Ужасный мечтает о вступлении в Лигу Зла, возглавляемой злодеем Хреновая Лошадь, однако чтобы его прошение было одобрено, он должен совершить что-то по настоящему ужасное…

Просмотр сего шедевра у меня выпал как раз на следующий день после просмотра последнего Бетмена. В общем, очень удачно наложилось. Третья часть выходит 19-ого.

PS: Видео хорошего качества – читай много мегабайт.

Update: Ролики убрали из свободного доступа. Кто не успел, тот опоздал.

Update: Дверь открыта! Конфеты свободны!

Тогда корректно-ли следующее утверждение: если в пространстве приборы фиксируют хотя бы одно явление, это пространство не является ПУСТОТОЙ.

Некорректно. Даже если приборы в пространстве не фиксируют ни одного явления, оно не является пустотой. В нем есть приборы.

И действительно.

PS: Забавно наблюдать за собой со стороны. Столько ляпов, просто жуть!