Потому что в таком случае это равноценно отсутствию сетевого нейтралитета. У вас будет базовый канал со скоростью 5 kbps и возможность за жалкие 40$ ускорить себе youtube до 10 Mbps. Нейтрально? Нейтрально.
для предотвращения срабатывания дистанционных взрывных устройств
Но ведь в фильмах, террорист нажимает на кнопку взрывателя и держит — пока не отожмет, т.е. пока живой, бимба не взорвется. Разве было бы не логично, чтобы радиоуправляемые бимбы работали по тому же принципу — не взрываться, пока есть соединение с центром управления?
Тут есть террористы, чтобы помочь разобраться в этом всем?
А сколько она должна выполняться на самом деле, например? С учетом того, что поток в любой момент может переключиться и что операционная система, в принципе, не обязана совсем честно обслуживать все потоки, с учетом того, что кому-то может придти в голову сожрать всю оперативку и начать свопиться, или вообще в системе есть антивирус… Мало ли по какой причине функции могут выполняться неодинаковое время :) Эта защита надежно работает только против трассировки процессов — когда между двумя вызовами должно пройти, скажем, порядка 20 мс, а проходит 5 сек — значит, кто-то сидит и вдумчиво жмет F10 в софтайсе.
Ну так и на KiDispatchException иначе, чем через ядро, не сядешь — потому что в SEH chain встраиваться хоть и можно, но бессмысленно, т.к. у процесса есть контроль над своим SEH chain, и при желании процесс может посмотреть, кто там есть чужой и всех оттуда попросить. С другой стороны — разве сейчас для кого-то проблема сделать простейший драйвер-перехватчик?
И, как выше верно заметили, сам себя отладить не получится. К счастью, в нашем случае необязательно отлаживать процесс официально — т.к. мы уже в ядре, нам не нужны привилегии отладчика чтобы поменять контекст потока, добавить туда отладочные регистры и словить брекпоинт.
В том, что, фигурально выражаясь, кто раньше встал — того и тапки. В ring3 эти регистры нельзя прочитать напрямую (будет #GP), поэтому в Win32 для usermode-приложения есть только один способ — через структуру CONTEXT, которую можно получить несколькими путями. Самый очевидный — GetThreadContext(), чтобы задетектить отладку, и SetThreadContext(), чтобы ее снять. Второй способ — спровоцировать SEH-исключение, посмотреть CONTEXT *ContextRecord в _except_handler() и поменять при необходимости.
В первом случае достаточно сесть поверх этих двух функций, и игнорировать Dr#. Во втором надежнее всего будет сесть поверх KiDispatchException и просто возвращать копию контекста вместо самого контекста, с которой потом поступать по усмотрению.
Что касается обнаружения самого факта отладки — если не садиться внутри кода приложения, а только на экспорты, то анализ времени выполнения ничего не даст — приложение принципиально не может гарантировать, сколько будет выполняться тот или иной вызов DirectX. Есть еще всякие экзотические способы типа недокументированного изменения EAX после вызова OutputDebugString, но это тоже, в принципе, просто обходится.
Автор, вы не могли бы выложить программу без инсталлятора? Или отдельно файл со словарем — на компьютерах без Windows залезть внутрь инсталлятора небольшая проблема.
Между прочим, ученые до сих пор не доказали вред героина в небольших количествах. Да, конечно, если колоть сразу и помногу, можно сторчаться или вообще умереть — ну так никто ж и не спорит, что во всем нужно знать меру! Я вот просто не могу расслабиться, если не ужалюсь хотя бы 100 мг. Стресс снимает отлично, а вредно-не вредно — идут они нафиг со своими исследованиями))) Употребляю третий месяц, зависимости никакой, рекомендую всем однозначно!
Тут есть террористы, чтобы помочь разобраться в этом всем?
И, как выше верно заметили, сам себя отладить не получится. К счастью, в нашем случае необязательно отлаживать процесс официально — т.к. мы уже в ядре, нам не нужны привилегии отладчика чтобы поменять контекст потока, добавить туда отладочные регистры и словить брекпоинт.
CONTEXT, которую можно получить несколькими путями. Самый очевидный —GetThreadContext(), чтобы задетектить отладку, иSetThreadContext(), чтобы ее снять. Второй способ — спровоцировать SEH-исключение, посмотретьCONTEXT *ContextRecordв_except_handler()и поменять при необходимости.В первом случае достаточно сесть поверх этих двух функций, и игнорировать Dr#. Во втором надежнее всего будет сесть поверх
KiDispatchExceptionи просто возвращать копию контекста вместо самого контекста, с которой потом поступать по усмотрению.Что касается обнаружения самого факта отладки — если не садиться внутри кода приложения, а только на экспорты, то анализ времени выполнения ничего не даст — приложение принципиально не может гарантировать, сколько будет выполняться тот или иной вызов DirectX. Есть еще всякие экзотические способы типа недокументированного изменения EAX после вызова
OutputDebugString, но это тоже, в принципе, просто обходится.