![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TaskManeger [D5, D6, NT4, Win2k]
TOLTEC © (2002-03-01 17:17:00)Как отловить событие отрубание моей программы TaskMeneger - ом
Вася666 (2002-06-16 11:53:00) [1]Удалено модератором
Игорь Шевченко (2002-06-04 18:27:00) [2]Руссиновича/Соломона точно стоит брать. Сорри за оффтопик :-))
paul_shmakov (2002-06-04 13:57:00) [3]продолжение или пояснение :)
http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1023020683&n=5
paul_shmakov (2002-04-05 11:59:00) [4]2 vuk:
спасибо за информацию, я дуиаю, нужно брать обе. а то все нет времени от работы оторваться и до магазина доехать, чтобы на них посмотреть в живую. а теперь можно и в инет-магазине заказать.
сорри за оффтопик.
vuk (2002-04-04 15:28:00) [5]to paul_shmakov:
Про книги. Обе у меня есть.
>Внутреннее устройство Microsoft Windows 2000. Соломон Д.,
>Руссинович М.
С этим нужно "медитировать", необходимо достаточное время чтения и вникания в концепции, а его-то как раз и нет. :o(
>Программирование серверных приложений для Microsoft Windows
>2000. Рихтер Дж., Кларк Дж.Д.
Сейчас у меня на столе лежит, ковыряюсь в EventLog. Хороший справочник по программированию, как и любая книга к которой приложил руку Рихтер. В комплекте CD с примерами а также электронная версия на английском языке.
NA (2002-04-04 01:59:00) [6]paul_shmakov:
0:-)
NA (2002-04-04 01:56:00) [7]
cok © (26.03.02 18:12)
А если попытаться поставить хук на Ctrl+Alt+del и на его обработку послать ShowWindow(h, SW_Hide), где h- хэндл кнопки, которая завершает процесс?
Ну сколько можно вам объяснять про "попытки хука на ctrlaltdel"? :(((
Не говоря уже о том, что масса народу (включая меня ;) элементарно _не_пользуется_ этой кнопкой - на это дело есть контекстные меню с возможностями побогаче этой кнопки.
cok (2002-03-26 18:12:00) [8]А если попытаться поставить хук на Ctrl+Alt+del и на его обработку послать ShowWindow(h, SW_Hide), где h- хэндл кнопки, которая завершает процесс?
paul_shmakov (2002-03-19 23:53:00) [9]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
Алексей Петров (2002-03-19 23:02:00) [10]>
paul_shmakov © (19.03.02 03:31)
А мне приходилось пользоваться еще и третьим изданием и тоже на русском языке.
Там NT 4 и Win 95 за основу взяты, но от 2-го отличий мало.
А читать луше 4-е. Если денег жалко - на CD к книге есть электронный вариант, но на английском...
SDS (2002-03-19 21:52:00) [11]Ну и чтоб закончить интересную лекцию г-на paul_shmakov
скажу что еще одна стоящая книга, где тоже неплохие примеры и на эту тему Свен Шрайбер "Недокументированные возможности Widows 2000", книга классная, и написана несколько "с другой" стороны, т.е. Рихтер использует методы "одобренные" MS, а в этой действительно недокументированные функции.
Посмотреть ее можно здесь
http://www.piter.com/book_about.phtml?id=978531800487
paul_shmakov (2002-03-19 04:03:00) [12]ну а про перехват (чтобы было понятно, куда и что искать): самый простой способ - это внедрение 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
paul_shmakov (2002-03-19 03:31:00) [13]про перехват 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
gluka (2002-03-19 02:19:00) [14]Спасибо!!! Учень поучительно.
А можно ли по побробней про перехват функций и корректировку таблицы импорта(експорта), VxdCall и зделать таблицу writable.
Если конечно нетрудно...
limon (2002-03-15 14:40:00) [15]> paul_shmakov ©
!!!!!!!!!!!!!!!!!!
paul_shmakov (2002-03-15 11:51:00) [16]p.s. файлы в кладовке выложились под другими именами:
Загрузка dll в чужой процесс (к ветке)
Загрузка dll в чужой процесс (к ветке) №2
paul_shmakov (2002-03-15 07:24:00) [17]ну и заключительное слово :)
все, что здесь описано - это не абстрактная теория. все это выстрадано, реализовано и уже очень давно и успешно работает, принося моим друзьям, в частности неограниченный доступ в инет на рабочем месте и в рабочее время :) пользуясь случаем, передаю им привет :)
вопросы, пожелания - welcome!
paul_shmakov (2002-03-15 07:18:00) [18]Итого: NT-вый способ вообще тяжело воссоздать в обычной программе,
9x - можно, но не очень красиво, но можно :)
Лучше реализовать способ 9х с помощью отдельной dll, которая с
помощью глобальных хуков будет грузиться в каждый(!) процесс, в нем
править секцию импорта и спокойно перехватывать вызовы к toolhelp
api.
Но это, подчеркиваю, вариант только для win9x. Если это устраивает,
то можно попробовать.
Именно из-за всех этих проблем я и реализовал свою программу как
dll, т.к. это наиболее нормальный (для моей задачи) вариант. И
надежный, т.к. никаких извращений с копированием тела процесса
куда-то в память нет.
paul_shmakov (2002-03-15 07:18:00) [19]Версия 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:16:00) [20]теперь несколько соображений по механизму прятания процесса программой back orifice 2000.
D> Если знаком и есть свободное время и желание то в архиве
D> исходники Back Orifica на С, который очень грамотно прячется
D> (насколько я понял перехватывает вызовы Process32First ... ) в
D> системе.
Ситуация следующая. bo2k очень специфичное приложение: оно по-своему
работает с памятью, по-своему с dll (у них свой загрузчик) и вообще
- загружает себя абсолютно нестандартно.
Т.е. те способы, которые реализованы в bo2k не слишком просто
подшить к любому приложению, тем более на delphi. Особенно это
касается кода, который отвечает за скрытие в NT (все та же функция в
файле process_hop).
Поясню.
Версия для NT.
bo2k поступает следующим образом: открывает некий работающий процесс
(какой именно указано в настройках), выделяет там под себя память,
копирует себя целиком(!) в эту память, с помощью функции
CreateRemoteThread запускает себя в чужом процессе. Не каждую
delphi-прогу можно просто так взять и целиком скопировать :)
Этот прием, в принципе, очень похож на мой - с dll, но мой имхо куда
лучше, т.к. не накладывает таких жестких ограничений на дизайн
приложения :)