TaskManeger

← →
TOLTEC (2002-03-01 17:17) [0]

Как отловить событие отрубание моей программы TaskMeneger - ом

← →
VuDZ (2002-03-01 17:51) [1]

если есть главное окно - WM_CLOSE,
иначе - никак, так как при этом вызывается TerminateProcess(), которая ни чего не говорит, она просто убивает.

← →
TOLTEC (2002-03-01 17:57) [2]

А Можно какой - нибуть примерчик.

← →
Tosov (2002-03-01 23:37) [3]

> А Можно какой - нибуть примерчик

так как при этом вызывается TerminateProcess(), которая ни чего не говорит, она просто убивает.

Ну и какой тебе примерчик?

← →
Keymaster (2002-03-01 23:53) [4]

у главной формы ловишь событие OnClose и когда оно наступает, значит тебя хочут закрыть Task manager"ом

← →
Tosov (2002-03-02 00:00) [5]

TOLTEC
Какая часть диспетчера задач тебя интересует : Список процессов или приложений?

← →
TOLTEC (2002-03-02 16:48) [6]

И то и другое.

← →
Алексей Петров (2002-03-02 17:35) [7]

Если убивают из списков процессов - на прямую в процессе этого отловить нельзя.

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

Можно обработать DLL_PROCESS_DETACH в DLLMain-е dll-ки с Hook-ом.

пример кода не проси - его 3 тонны будет.

← →
TOLTEC (2002-03-02 18:47) [8]

А Как сделать чтобы ее нельзя было вырубить из списка процессов?

← →
Алексей Петров (2002-03-03 00:13) [9]

Запустить под системной учетной записью.

Вирус пишеш?

← →
TOLTEC (2002-03-04 13:43) [10]

Нет не вирус, просто надо

← →
Алексей Петров (2002-03-04 14:23) [11]

Правда, если процесс работает под "SYSTEM" его можно убить TaskManager-ом работающим из под "SYSTEM"

Единственный способ гарантировать невозможность убийства процесса - сделать так, чтоб процесса не было. Это не шутка, а вполне рабочая рекомендация.

← →
Tosov (2002-03-04 18:17) [12]

Алексей Петров
Процесс под SYSTEM может убить и админ.

TOLTEC
Может расскажешь зачем надо? Интересно стало..

← →
VuDZ (2002-03-04 23:07) [13]

> Процесс под SYSTEM может убить и админ.

да, только для этого надо запустить taskman с привилегиями системы, а это не каждый могёт :>

> Может расскажешь зачем надо? Интересно стало..

может он делает супер-невырубаемый вирус на делфи, со своей программой установки (внимание: сейчас на ваш комп будет устновлен новый вирус, за дополнениями патчами обращайтесь сюда ....... :>)

← →
Tosov (2002-03-06 00:37) [14]

>да, только для этого надо запустить taskman с привилегиями системы
Да вроде не обязательно.. Из своей проги - SeDebugPrivilege + TermitateProcess. Из чужих,например, Far (версия 1.70) очень легко грохает почти все системные процессы.

>со своей программой установки
И ведь установят же :)

← →
VuDZ (2002-03-06 19:27) [15]

мне проще набрать at 7:28PM /INTERACTIVE taskmgr.exe :>

← →
Tosov (2002-03-06 19:39) [16]

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

← →
Alex_LG (2002-03-13 23:42) [17]

> Алексей Петров © (04.03.02 14:23)
> Единственный способ гарантировать невозможность убийства
> процесса - сделать так, чтоб процесса не было. Это не шутка,
> а вполне рабочая рекомендация.

можно чуть расшифровать, плз? то есть "закосить" под чужой процесс или как?

← →
Gluka (2002-03-14 01:04) [18]

For Alex_LG (13.03.02 23:42)

Если сможешь перехватить вызовы функции, то можешь
идти далее:
http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1011513000&n=5

← →
Алексей Петров (2002-03-14 08:47) [19]

Нет не "закосить" и не спрятать, а именно чтоб не было :)

Т.е. запускаешь программу, она влезает в соседний процесс и выгружается. А все работу делает уже "там".

← →
VuDZ (2002-03-14 18:46) [20]

можно CreateRemoteThread - но это сложнее

← →
Алексей Петров (2002-03-14 23:35) [21]

> VuDZ © (14.03.02 18:46)
> можно CreateRemoteThread - но это сложнее
Это не проще и не сложнее. Я написал что делать, не уточняя как.
CreateRemoteThread - это один из вариантов "как"..
Другой вариант - с помощью hook-ов - он попроще и более универсальный (он и под Win9x работать будет).

← →
VuDZ (2002-03-15 03:53) [22]

ещё вариант - пишем некое подобие вируса, который следит - шансы, что его убьют - очень малы.

кстати - делаем у проги окно, нивидимое - тогда taskMan, по правилам посылает ему WM_QUIT - запускаем другой экземпляр приложения-монитора и закрываемся. Как мысль?

← →
paul_shmakov (2002-03-15 07:02) [23]

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

← →
paul_shmakov (2002-03-15 07:02) [24]

Концепция контейнеров и компонент в последнее время становиться все моднее - компоненты Delphi, ActiveX, Enterprise JavaBeans, CORBAcomponents. И не случайно. Это действительно очень удобная парадигма, когда компонента занимается только своей бизнес-функцией, а остальные задачи ложаться на контейнер. Распространить эту концепцию можно и на традиционные приложения с несколько нетрадиционной стороны. В этой статье будет описан способ реализации приложения в виде динамической библиотеки (dll) (компонента), которая будет выполняться в контексте чужого процесса (контейнер).
Для чего все это нужно? Ответы могут быть различными. Например, ваше приложение выполняет не совсем «легальную» функцию, и вы, соответственно, не хотите, чтобы пользователь видел запущенный незнакомый процесс. В данном случае применяются всевозможные техники для скрытия процесса из списка работающих приложений (например, RegisterServiceProcess для Windows 9x), которые сильно ограничены в своих возможностях. И задача остается нерешенной (о чем свидетельствует статистика, по которой вопрос «Как скрыть процесс из списка работающих приложений?» появляется в форумах не реже, чем раз в две недели).
Вот здесь-то и может помочь техника реализации приложения в виде dll и внедрения ее в адресное пространство некоего процесса. Примером такого процесса может служить программа internat.exe, которая отвечает за переключение раскладки клавиатуры. Удобна она тем, что постоянно загружена, и не у кого из пользователей не вызывает никаких подозрений и желания ее выгрузить. Может быть использована и любая другая программа, отвечающая требованиям конкретной задачи, но в этой статье в качестве «жертвы» будет рассматриваться именно internat.exe.
Реализация этой идеи состоит из двух задач: 1) создать dll, которая будет способна выполняться в качестве «компоненты»; 2) заставить internat.exe против его желания стать «контейнером», т.е. загрузить вашу dll.

← →
paul_shmakov (2002-03-15 07:06) [25]

«Компонента»
Создание такой библиотеки ничуть не сложнее создания обычной dll или приложения с аналогичной функциональностью. Просто нужно придерживаться некоторых правил. Сразу предупрежу: я буду приводить примеры кода на С++, хотя для других языков код будет полностью аналогичным.
Выполнение вашего приложения должно начинаться с момента вызова функции DllMain с параметром dwReason равным DLL_PROCESS_ATTACH и заканчиваться в вызове той же функции с DLL_PROCESS_DETACH.
DLL_PROCESS_ATTACH
Код вашей библиотеки должен выполняться в отдельном собственном потоке. Поэтому в обработчике события DLL_PROCESS_ATTACH создаем новый поток функцией CreateThread. Кстати, как показывает практика здесь можно создать произвольное количество потоков, а не только один, как написано в некоторых источниках. Перед созданием потока следует вызвать DisableThreadLibraryCalls для того, чтобы предотвратить вызов DllMain при каждом создании и уничтожении потоков в процессе. Этот поток (или потоки) и будет выполнять главную функцию вашей библиотеки.
DLL_PROCESS_DETACH
При обработке этого события следует уведомить созданный поток(и) о завершении работы (например, установить объект-событие), дождаться их завершения и вернуть управление.

Функции потоков будут достаточно простыми. Единственное, что им нужно делать (помимо полезной работы) - это проверять объект-событие (а не пора ли завершиться).

Далее про внедрение в чужое адресное пространство.

← →
paul_shmakov (2002-03-15 07:08) [26]

2) внедрение dll в адресное пространство
чужого процесса: 2.1) внедрение динамически, 2.2) внедрение статически
(т.е. физический patch файла).

На второй вопрос, а особенно на 2.1, можно найти очень много
информации. _Кратко_ опишу основные методы (пусть Ваша dll называется
mydll.dll):
1. Динамическое внедрение, т.е. когда программа-жертва ужу запущена. В
этом случае требуется программа загрузчик (пусть loader.exe).

1.1. внедрение с помощью ловушек. Последовательность действий следующая:
а) loader.exe установливает глобальный хук. Функция обработчик хука
реализована в некой dll (пусть inject.dll).
б) основному окну программы-жертвы посылаеться любое сообщение.
в) для перехвата этого сообщения в программу-жертву автоматически
подгружаеться inject.dll, и вызывается функция-обработчик хука.
г) функция-обработчик хука загружает нашу библиотеку, т.е.
LoadLibrary("mydll.dll").
д) loader.exe снимает глобальный хук, чтобы inject.dll не грузилась
еще и во все остальные процессы.
е) из-за снятия хука inject.dll автоматически выгружается из
адресного пространства программы-жертвы, а вот mydll.dll
остается там работать! что и требовалось совершить.
Это универсальный способ, для всех версий виндов. Я считаю его
наиболее приемлемым из динамических.

1.2. Загрузка программы-жертвы в режиме отладки. Это более сложный и
менее универсальный способ, хотя тоже подходит для всех версий.
Главный недостаток в том, что loader.exe остаеться в памяти на все
время работы программы-жертвы, что не удовлетворяет условиям задачи
(никаких нащих процессов). Поэтому я не буду его здесь описывать.

1.3. внедрение с помощью удаленных потоков. Этот способ только для
WinNT, т.к. используется функции CreateRemoteThread.
а) loader.exe открывает процесс-жертву с помощью OpenProcess.
б) выделяется область памяти в адресном пространстве
процесса-жертвы с помощью pMyDllName = VirtualAllocEx.
в) копирование в эту область строки с названием нашей dll, т.е.
"mydll.dll" (WriteProcessMemory).
г) создание удаленного процесса.
CreateRemoteThread(hProcess, NULL, 0,
GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA"),
pMyDllName,
0, &tid).
Поток создаеться, выполняется, загружая нашу dll, и завершаеться.
Все!

← →
paul_shmakov (2002-03-15 07:09) [27]

1.4. Еще один способ, очень похожий на 1.2., но куда более
универсальный. Так же требует знаний ассемблера. Самому писать
лениво :), поэтому отсканирую Рихтера. Он, правда, очень примерные инструкции
дает. Но если заинтересует именно этот метод, то я могу подробно
описать (вроде даже я это в какой-то проге использовал).
--- cut ---
Внедрение кода через функцию CreateProcess
Если Ваш процесс порождает дочерний, в который надо внедрить
какой-то код, то задача значительно упрощается. Родительский
процесс может создать новый процесс и сразу же приостановить его.
Это позволит изменить состояние дочернего процесса до начала его
выполнения. В то же время родительский процесс получает описатель
первичного потока дочернего процесса. Зная его, Вы можете
модифицировать код, который будет выполняться этим потоком. Тем
самым Вы решите проблему, упомянутую в предыдущем разделе: в данном
случае нетрудно установить регистр указателя команд, принадлежащий
потоку, на код в проекции файла.
Вот один из способов-контроля за тем, какой код выполняется
первичным потоком дочернего процесса:
1. Создайте дочерний процесс в приостановленном состоянии.
2. Получите стартовый адрес его первичного потока, считав его из
заголовка исполняемого модуля.
3. Сохраните где-нибудь машинные команды, находящиеся по этому
адресу памяти.
4. Введите на их место свои команды. Этот код должен вызывать
LoadLibrary для загрузки DLL
5. Разрешите выполнение первичного потока дочернего процесса.
6. Восстановите ранее сохраненные команды по стартовому адресу
первичного потока.
7. Пусть процесс продолжает выполнение со стартового адреса так,
будто ничего и не было.
Этапы 6 и 7 довольно трудны, но реализовать их можно — такое уже делалось.
У этого метода масса преимуществ. Во-первых, мы получаем адресное
пространство до выполнения приложения. Во-вторых, данный метод
применим как в Windows 98, так и в Windows 2000. В третьих, ...
--- cut ---

← →
paul_shmakov (2002-03-15 07:10) [28]

2. Статическое внедрение. Именно этот способ я предпочитаю
использовать - лучше чтобы не было никаких loader-ов, а только
жертва и наша dll. Я уже притомился писать ;) и поэтому опишу
коротко.
2.1. Добавление в pe-файла нескольких инструкций:
call loadlib
db "МояЛюбимая.dll", 0
loadlib:
call LoadLibraryA
jmp OriginalEntryPoint
Этот код можно добавить либо в существующую секцию с кодом (обычно
.text) (если там есть свободное место, либо создать свою секцию.
После этого подправить несколько полей в pe-заголовке, в частности
EntryPoint, чтобы он указывал на новый код. Этот способ (который,
кстати я и использую) имеет свои достоинства и недостатки. Если в
предыдущем варианте требовалось, чтобы запускался loader.exe , что
дает пользователю возможность проследить по реестру и автозагрузке,
что какой-то loader.exe запускается, то в этом варианте запускается
только программа-жертва и все. Недостатки же чисто технические. Во
первых требуется, чтобы программа-жертва импортировала функцию
LoadLibraryA (или LoadLibraryW, или по ординалу). Если не
импортирует, то читай 2.2. Далее, способ не универсальный, т.е. в
случае с internat.exe придется делать версию под каждую версию
виндов. Хотя это не так сложно, если написать автоматический патчер.

← →
paul_shmakov (2002-03-15 07:11) [29]

2.2. Изменение таблицы импорта. Идея состоит в том, чтобы заставить
стандартный виндовый загрузчик подумать, что программа статически
использует вашу dll. Для этого необходимо, чтобы ваша dll
экспортировала хотя бы одну произвольную функцию (функция может быть
абсолютно любая, т.к. никто и никогда ее на самом деле вызывать не
будет). Добавляем в таблицу импорта pe-файла новую запись, имя вашей
dll, количество импортируемых функций равное 1, имя или ординал
импортируемой функции и поле для адреса этой функции. У этого
способа есть достоинства и, к сожалению, недостатки. Загружать вашу
dll будет уже не какой-то loader.exe, а стандартный виндусовый
загрузчик pe-файлов, что конечно очень хорошо. А недостатки, опять
же, технические: в секции импорта должно быть достаточно места для
вышеназванных данных, что не всегда так. Если я не ошибаюсь, то на
эту тему очень хорошо писал Крис Касперски.
2.3. Подмена стандартной dll. Берем какую-нить стандартную dll с
небольшим кол-вом экспортируемых функций, подменяем ее своей с
такими же функциями. А в наших функциях просто перенаправляем вызов
к оригинальным функциям.

Мне способы 2.1 и 2.2. кажутся наиболее удобными.
Во всех способах исользуются достаточно низкоуровневые возможности
windows. Рекомендую, прежде, чем начинать, почитать Джефри Рихтера
(обязательно), Мэта Питрека (хотя бы частично) и несколько статей по
pe-формату из интернета. Несколько, потому что есть различия в
описании формата как в статьях, так и в exe-шниках(!), получаемых от
линкеров различных производителей. Ну а для проверки знаний -
одназначно hiew.exe (особенно хороша самая последняя версия 6.76).

← →
paul_shmakov (2002-03-15 07:12) [30]

Ну и несколько исходников (в кладовке inject1.rar и inject2.rar). Они на с++. Первый файл содержит
простенький пример к пункту 1.1.; второй - к пункту 2.1.
Первый пример настроен на присоединение к Notepad. Поэтому перед
запуском loader.exe следует запустить Notepad.
Насчет второго: это очень ограниченная по функциональности версия
автоматического патчера - например, патчер сработает только если
программа импортирует функцию LoadLibrary, кроме того, в основном
патчит только майкрософтовские программы (скомпанованные ms линкером)
- про остальные говорит, что не может. Для ее тестирования рекомендую
использовать internat.exe.
В общем, это простая версия, призванная показать концепцию. Сейчас
работаю над куда более совершенной.

← →
paul_shmakov (2002-03-15 07:16) [31]

теперь несколько соображений по механизму прятания процесса программой back orifice 2000.

D> Если знаком и есть свободное время и желание то в архиве
D> исходники Back Orifica на С, который очень грамотно прячется
D> (насколько я понял перехватывает вызовы Process32First ... ) в
D> системе.
Ситуация следующая. bo2k очень специфичное приложение: оно по-своему
работает с памятью, по-своему с dll (у них свой загрузчик) и вообще
- загружает себя абсолютно нестандартно.

Т.е. те способы, которые реализованы в bo2k не слишком просто
подшить к любому приложению, тем более на delphi. Особенно это
касается кода, который отвечает за скрытие в NT (все та же функция в
файле process_hop).
Поясню.

Версия для NT.
bo2k поступает следующим образом: открывает некий работающий процесс
(какой именно указано в настройках), выделяет там под себя память,
копирует себя целиком(!) в эту память, с помощью функции
CreateRemoteThread запускает себя в чужом процессе. Не каждую
delphi-прогу можно просто так взять и целиком скопировать :)
Этот прием, в принципе, очень похож на мой - с dll, но мой имхо куда
лучше, т.к. не накладывает таких жестких ограничений на дизайн
приложения :)

← →
paul_shmakov (2002-03-15 07:18) [32]

Версия 9x.
Здесь несколько иначе, т.к. нет функции CreateRemoteThread. Для
начала вызывается все та же RegisterServiсeProcess. Далее, как ты
верно подметил, перехватываються вызовы всего семейства функций
Toolhelp API. Смысл у них у всех очень простой: вызывают
оригинальную функцию, сравнивают id процесса в возвращенной
структуре с id текущего процесса (т.е. того, который нужно
спрятать), если они равны, то эта запись пропускается.
То есть если мы перехватили вызов, например, Process32First, то уж
заставить его вернуть "правильное" значение легко. Но как
перехватить?
Для текущего процесса это сделать очень просто - достаточно
подправить несколько полей в таблице импорта так, чтобы они
указывали на наши функции.
Но проблема в том, что этот самый Process32First вызывает не наш
процесс, а чужой, который как раз и показывает пользователю наш
работающий процесс.
Тогда есть еще одно решение: править не таблицу импорта процессов, а
таблицу экспорта у загруженной kernel32.dll. Но таблица экспорта у
загруженной kernel32.dll read only. Здесь bo2k использует
недокументированный вызов VXDCall, чтобы сделать эту таблицу
writable.
Появляется еще одна проблема - как сделать доступным код наших
функций-перехватчиков Toolhelp API? Они ведь находяться в нашем
процессе. Для решения этой проблемы используется еще одна
особенность win9x - вся виртуальная память выше 2Гб является общей
для всех процессов в системе. bo2k выделяет там себе память,
копирует туда код функций-перехватчиков и меняет адреса адреса
функций Toolhelp в секции экспорта kernel32.dll так, чтобы они
указывали на наши функции-перехватчики. Все! Теперь все фильтруется

← →
paul_shmakov (2002-03-15 07:18) [33]

Итого: NT-вый способ вообще тяжело воссоздать в обычной программе,
9x - можно, но не очень красиво, но можно :)
Лучше реализовать способ 9х с помощью отдельной dll, которая с
помощью глобальных хуков будет грузиться в каждый(!) процесс, в нем
править секцию импорта и спокойно перехватывать вызовы к toolhelp
api.
Но это, подчеркиваю, вариант только для win9x. Если это устраивает,
то можно попробовать.

Именно из-за всех этих проблем я и реализовал свою программу как
dll, т.к. это наиболее нормальный (для моей задачи) вариант. И
надежный, т.к. никаких извращений с копированием тела процесса
куда-то в память нет.

← →
paul_shmakov (2002-03-15 07:24) [34]

ну и заключительное слово :)

все, что здесь описано - это не абстрактная теория. все это выстрадано, реализовано и уже очень давно и успешно работает, принося моим друзьям, в частности неограниченный доступ в инет на рабочем месте и в рабочее время :) пользуясь случаем, передаю им привет :)

вопросы, пожелания - welcome!

← →
paul_shmakov (2002-03-15 11:51) [35]

p.s. файлы в кладовке выложились под другими именами:
Загрузка dll в чужой процесс (к ветке)
Загрузка dll в чужой процесс (к ветке) №2

← →
limon (2002-03-15 14:40) [36]

← →
gluka (2002-03-19 02:19) [37]

Спасибо!!! Учень поучительно.
А можно ли по побробней про перехват функций и корректировку таблицы импорта(експорта), VxdCall и зделать таблицу writable.

Если конечно нетрудно...

← →
paul_shmakov (2002-03-19 03:31) [38]

про перехват api написано очень много статей, поэтому здесь писать об этом не стоит. лучше всего об этом почитать у рихтера.

кстати, если кто не знает:

автор: джеффри рихтер. его книга издавалась на русском в двух
изданиях:
1) Windows для профессионалов. Программирование в Win32 API для
Windows NT 3.5 и Windows 95. Издание второе. 1995. В оригинале
называется "Advanced Windows. The Developer"s Guide to the Win32
API for Windows NT 3.5 and Windows 95".
2) Windows. Создание эффективных Win32-приложений с учетом специфики
64-разрядной версии Windows. Издание четвертое. 2001. В оригинале
называется "Programming Applications for Microsoft Windows.
Fourth Edition".

несмотря на разные названия - это одна и таже книга, только 2),
конечно, намного новее и актуальнее. именно ее я и рекомендую.
единственный недостаток - высокая цена ~420р. поэтому можно и 1)
почитать, если найдете.
как она выглядит, можно посмотреть здесь:
http://bolero.ru/catalog/book/pages/pages-1319185.html

← →
paul_shmakov (2002-03-19 04:03) [39]

ну а про перехват (чтобы было понятно, куда и что искать): самый простой способ - это внедрение dll в чужое адресное пространство, после внедрения корректировка таблицы импорта всех подгруженных в это адресное пространство модулей.
корректировка таблицы импорта - это на самом деле очень простая вещь.
очень упрошенно говоря, таблица импорта представляет из себя следующее:

адрес имя dll имя функции
===== ====== ==========
XXXXX1 kernel32.dll CreateProcess
XXXXX2 kernel32.dll LoadLibrary
XXXXX3 kernel32.dll GetModuleHandle
.....
XXXXX7 shell32.dll MessageBoxA
.....

в этой таблице содержится список всех функций (подлинкованных статически), которые код модуля вызывает. таблица эта есть и в exe-шниках, и в dll - во всех файлах с форматом portable executable (pe). и, заметьте, в каждом своя.

во время запуска процесса виндузовый загрузчик создает новое адресное пространство для процесса и проецирует туда модуль.
далее перебирает все записи в таблице импорта. для каждой записи проверяет, а не загружена ли уже нужная dll. если нет, то загружает ее.
далее определяет адрес указанной функции (условно говоря, вызывает GetProcAddress) и записывает его в ячейку XXXXN.
и так для всех записей.
кроме того, для всех подгружаемых dll загрузчиком выполняется точно такая же работа, т.к. каждая из них тоже имеет свою таблицу импорта.

когда мы в исходном коде пишем CreateProcess(nil, "la-la-la", ....) компилятор генерирует код, который берет значение из ячейки XXXX1 и делает вызов по этому адресу. и точно также для всех остальных функций.

теперь понятно, как перехватить вызов к тому же CreateProcess: нужно всего лишь найти эту ячейку XXXX1 и заменить адрес в ней на адрес своей функции MyCreateProcess.
ну а функция MyCreateProcess сделает свое грязное дело и может, например, вызвать оригинальную CreateProcess. MyCreateProcess будет расположена все в той же dll, которую мы внедрили в адресное простанство чужого процесса.

единственное, что нужно помнить - это то, что у каждого модуля своя таблица импорта. т.е. заменить значение ячейки XXXX1 нужно не только в таблице импорта модуля процесса, но и в таблицах импорта всех загруженных в процесс dll.

вот упрощенная схема простейшего перехвата api. к сожалению, простейшая - она и самая слабая. перехватить 100% вызовов не получится.
на тему:
http://www.rsdn.ru/forum/message.asp?mid=21412#21412

← →
SDS (2002-03-19 21:52) [40]

Ну и чтоб закончить интересную лекцию г-на paul_shmakov
скажу что еще одна стоящая книга, где тоже неплохие примеры и на эту тему Свен Шрайбер "Недокументированные возможности Widows 2000", книга классная, и написана несколько "с другой" стороны, т.е. Рихтер использует методы "одобренные" MS, а в этой действительно недокументированные функции.
Посмотреть ее можно здесь
http://www.piter.com/book_about.phtml?id=978531800487

← →
Алексей Петров (2002-03-19 23:02) [41]

>
paul_shmakov © (19.03.02 03:31)
А мне приходилось пользоваться еще и третьим изданием и тоже на русском языке.
Там NT 4 и Win 95 за основу взяты, но от 2-го отличий мало.

А читать луше 4-е. Если денег жалко - на CD к книге есть электронный вариант, но на английском...

← →
paul_shmakov (2002-03-19 23:53) [42]

2 SDS:
спасибо за информацию. я к этой книге тоже приглядывался, но в руках пока не держал. а еще интересуют следующие две книги. может, кто-нибудь уже читал? буду благодарен за отзывы.

Внутреннее устройство Microsoft Windows 2000. Соломон Д., Руссинович М.
http://bolero.ru/catalog/book/pages/pages-1961633.html

Программирование серверных приложений для Microsoft Windows 2000. Рихтер Дж., Кларк Дж.Д.
http://bolero.ru/catalog/book/pages/pages-1851121.html

← →
cok (2002-03-26 18:12) [43]

А если попытаться поставить хук на Ctrl+Alt+del и на его обработку послать ShowWindow(h, SW_Hide), где h- хэндл кнопки, которая завершает процесс?

← →
NA (2002-04-04 01:56) [44]

cok © (26.03.02 18:12) А если попытаться поставить хук на Ctrl+Alt+del и на его обработку послать ShowWindow(h, SW_Hide), где h- хэндл кнопки, которая завершает процесс?

Ну сколько можно вам объяснять про "попытки хука на ctrlaltdel"? :(((

Не говоря уже о том, что масса народу (включая меня ;) элементарно _не_пользуется_ этой кнопкой - на это дело есть контекстные меню с возможностями побогаче этой кнопки.

← →
NA (2002-04-04 01:59) [45]

paul_shmakov:

0:-)

← →
vuk (2002-04-04 15:28) [46]

to paul_shmakov:
Про книги. Обе у меня есть.

>Внутреннее устройство Microsoft Windows 2000. Соломон Д.,
>Руссинович М.
С этим нужно "медитировать", необходимо достаточное время чтения и вникания в концепции, а его-то как раз и нет. :o(

>Программирование серверных приложений для Microsoft Windows
>2000. Рихтер Дж., Кларк Дж.Д.
Сейчас у меня на столе лежит, ковыряюсь в EventLog. Хороший справочник по программированию, как и любая книга к которой приложил руку Рихтер. В комплекте CD с примерами а также электронная версия на английском языке.

← →
paul_shmakov (2002-04-05 11:59) [47]

2 vuk:
спасибо за информацию, я дуиаю, нужно брать обе. а то все нет времени от работы оторваться и до магазина доехать, чтобы на них посмотреть в живую. а теперь можно и в инет-магазине заказать.
сорри за оффтопик.

← →
paul_shmakov (2002-06-04 13:57) [48]

продолжение или пояснение :)
http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1023020683&n=5

← →
Игорь Шевченко (2002-06-04 18:27) [49]

Руссиновича/Соломона точно стоит брать. Сорри за оффтопик :-))

← →
Вася666 (2002-06-16 11:53) [50]

Удалено модератором

TaskManeger Найти похожие ветки