NtQuerySystemInformation & others
P.S. Native API тоже можно... )
нужно узнать список всех процессов... но какие еще функции есть, кроме NtQuerySystemInformation и CreateToolhelp32Snapshot? очень важно знать, ведь мне придется их отловить и "модифицировать" результаты, которые эти функции пользователю выдадут.. )
P.S. Native API тоже можно... )
Я знаю следующее:
1. Tool Help Functions - ф-ции CreateToolhelp32Snapshot/Process32First/Process32Next
2. Process Status Helper Functions (Process status API (PSAPI)) - ф-ция EnumProcesses
3. NT kernel functions - NtQuerySystemInformation
Я знаю следующее:
1. Tool Help Functions - ф-ции CreateToolhelp32Snapshot/Process32First/Process32Next
2. Process Status Helper Functions (Process status API (PSAPI)) - ф-ция EnumProcesses
3. NT kernel functions - NtQuerySystemInformation
Абсолютно все эти функции обращаются к единственной базовой - ZwQuerySystemInformation(). А вообще, на мой взгляд, проще не поцессы скрывать, а dll'ки в чужие процессы внедрять, так, например, можно запросто брандмауэры обходить (практически ни в одном из них не осуществляется контроль подключений на уровне библиотек)
Абсолютно все эти функции обращаются к единственной базовой - ZwQuerySystemInformation().
Просмотрел я все описание этой функции, она точь-в-точь NtQuerySystemInformation. Параметры - те же самые... Но вот вопрос: есть вызов какой-либо проги к NtQuerySystemInformation, эта NtQuerySystemInformation в свою очередь ВНУТРИ модуля ntdll.dll обратится к ZwQuerySystemInformation, то как бы я не старался, как-бы не пытался модифицировать таблицу импорта, никакого перехвата не получится... или может, я не прав? может, и вправду проще отслеживать все обращения к
1) NtQuerySystemInformation
2) ZwQuerySystemInformation
3) EnumProcesses
4) CreateToolhelp32Snapshot
?
Кстати, вопрос по ходу моего мозгового штурма - может, где-нибудь есть пример модификации результата Process32First Process32Next? :)
P.S. Я использую модификацию таблицы импорта, а не "дописывание" первых инструкций функции на jmp...
P.P.S. хе-хе... тема скользкая, мало ли чего может показаться... если знаешь, но тут писать не охота, please, моя почта [email]despair_daemon@mail.ru[/email]
Просмотрел я все описание этой функции, она точь-в-точь NtQuerySystemInformation. Параметры - те же самые...
Модифицирование таблицы импорта уже устарело. Хуки рулят. Можешь качнуть пример сокрытия процесса winlogon на паскале
Модифицирование таблицы импорта уже устарело. Хуки рулят. Можешь качнуть пример сокрытия процесса winlogon на паскале
Спасибо за примерчик, но там именно перезапись самого кода, вернее, как я понял первых байт ZwQuerySystemInforamtion. (Паскаль я знаю не особенно сильно)
Эх-эх... я от этого давно отказался, пусть уж по старинке, через таблицу импорта - проторенная дорожка, да и сигнатура самого PE врядли изменится когда-нибудь...)))
Спасибо за примерчик, но там именно перезапись самого кода, вернее, как я понял первых байт ZwQuerySystemInforamtion. (Паскаль я знаю не особенно сильно)
Эх-эх... я от этого давно отказался, пусть уж по старинке, через таблицу импорта - проторенная дорожка, да и сигнатура самого PE врядли изменится когда-нибудь...)))
Ну, тогда желаю удачи с перезаписью адресов пары десятков функций...
Ну, тогда желаю удачи с перезаписью адресов пары десятков функций...
Ну не пары десятков, всего лишь 4! :-)
Гдк-то я прочел нечто, что меня крайне смутило насчет перезаписи начальных байт... по-моему, что-то Рихтер не очень жаловал это... хотя, - это просто соломинка для утопающего, попробую, если ничего не получится.... еще раз спасибо за пример :-)
P.S. кстати, объясни plz, как происходит вызов ZwQuerySystemInformation? вот допустим чья-то прога вызывает NtQuerySystemInformation, далее происходит ЧТО? как-то ведь переходит на ZwQuerySystemInformation, вот только КАК? через таблицу импорта-экспорта DLL, или по адресам в самом модуле как-то прыгает?
P.P.S. блин, похоже, что я тебя загрузил (((
хотя бы где про это прочесть можно? я в сети не нашел ничего, может, плохо искал? :-)))
Я вот что хотел уточнить... внутримодульные вызовы ведь никак не перехватываются, кроме как перезаписать первые байты вызываемой функции?
P.S. кстати, объясни plz, как происходит вызов ZwQuerySystemInformation? вот допустим чья-то прога вызывает NtQuerySystemInformation, далее происходит ЧТО? как-то ведь переходит на ZwQuerySystemInformation, вот только КАК? через таблицу импорта-экспорта DLL, или по адресам в самом модуле как-то прыгает?
P.P.S. блин, похоже, что я тебя загрузил (((
хотя бы где про это прочесть можно? я в сети не нашел ничего, может, плохо искал? :-)))
Почитать можно на сайтах, посвящённых ассемблеру (механизмы работы функций наподобие Proccess32First() выясняются путём дизассемблирования системных библиотек), линки тебе подсказать не смогу, но google рулит...
ZwQuerySystemInformation находится в той же ntdll.dll, что и NtQuerySystemInformation (которой, кстати, нет в windows9x), просто вторая из них вызывает первую, так что вызов идёт внутримодульный. В явном виде kernel32.dll не импортирует ZwQuerySystemInformation, это внутрисистемная функция и в Platform SDK она не докумментирована, равно как и заголовка в windows.h к ней нет и ни в каких таблицах импорта она не фигурирует. Как ты правильно понял, подобные внутримодульные функции можно перехватить только сплайсингом (подменой первых пяти байт), тем более, что в этом нет абсолютно ничего сложного и даже ассемблер для этого знать не надо...
по мере понимания у меня возникли проблемы, ответ на которые я не нашел в сети...
В общем, можно внедрять код с помощью хуков, можно - инжектированием. Я решил попробовать и так и так...
С помощью хуков - все прошло "на ура!", но вот беда, у хуков есть один недостаток - если в приложении нет цикла обработки сообщений, то и хук к такой проге не воткнуть (((. Инжектированием можно внедрить в любой процесс...
Но не в этом суть! Есть такая программка простенькая - Starter. Так вот, если инжектировать в эту прогу, то ничего не выйдет! DLL грузится, код в DllMain выполняется, но не более того! Хоть я загружал библиотеку в адресное пространство процесса, после загрузки она оттуда "исчезает"... Перехвата API соответственно не происходит(((. В общем, сможешь объяснить феномен этого явления?
Я все это написал лишь потому, что хотел остановиться на инжектировании, а не на хуках. Хочется полностью контролировать систему, а не часть оконных приложений.
P.S. Код, инжектирующий в чужой процесс был просто взят у Рихтера, точь-в-точь.. :-)
С помощью хуков - все прошло "на ура!", но вот беда, у хуков есть один недостаток - если в приложении нет цикла обработки сообщений, то и хук к такой проге не воткнуть (((. Инжектированием можно внедрить в любой процесс...
Но не в этом суть! Есть такая программка простенькая - Starter. Так вот, если инжектировать в эту прогу, то ничего не выйдет! DLL грузится, код в DllMain выполняется, но не более того! Хоть я загружал библиотеку в адресное пространство процесса, после загрузки она оттуда "исчезает"... Перехвата API соответственно не происходит(((. В общем, сможешь объяснить феномен этого явления?
SetWindowsHookEx() в перехвате API используется для глобализации, поскольку автоматически загружает библиотеку во все процессы, имеющие потоки с циклом обработки сообщений. Для сокрытия процесса этого вполне достаточно.
А что значит библиотека "исчезает"? То есть не вызывается подмененная функция? Или библиотека выгружается?
А что значит библиотека "исчезает"? То есть не вызывается подмененная функция? Или библиотека выгружается?
Для наглядности я зписал в DLLMain вызов MessageBox ;-) Окошко появилось при загрузке DLL в процесс, однако библиотека была выгружена после этого непредсказуемым образом (((
Для наглядности я зписал в DLLMain вызов MessageBox ;-) Окошко появилось при загрузке DLL в процесс, однако библиотека была выгружена после этого непредсказуемым образом (((
Хм... не знаю... Расставь трасеры в обработчиках DLL_PROCESS_DETACH и ZwQuerySystemInformation() и глянь, что там происходит.
Придется смотреть, что и как происходит под отладчиком.
Но все равно спасибо за ценные советы! :-)
похоже, что проблема неразрешима до установки SoftICE.
Придется смотреть, что и как происходит под отладчиком.
Но все равно спасибо за ценные советы! :-)
Кстати, начсёт того, что Рихтер не жаловал сплайсинг. В последнем из примеров, посвящённых перехвату API функций (это там, где перехватывается MessageBox), он использует именно сплайсинг (и, кстати, не очень удачным образом с точки зрения надёжности)
Кстати, начсёт того, что Рихтер не жаловал сплайсинг. В последнем из примеров, посвящённых перехвату API функций (это там, где перехватывается MessageBox), он использует именно сплайсинг (и, кстати, не очень удачным образом с точки зрения надёжности)
Как я понял, он использует считывание нескольких байт для определения истинного адреса функции, ты этот кусок имел в виду? (в конструкторе CAPIHook):-)
//--------------------------------------------
m_pszCalleeModName = pszCalleeModName;
m_pszFuncName = pszFuncName;
m_pfnHook = pfnHook;
m_fExcludeAPIHookMod = fExcludeAPIHookMod;
m_pfnOrig = GetProcAddressRaw(
GetModuleHandleA(pszCalleeModName), m_pszFuncName);
chASSERT(m_pfnOrig != NULL); // Function doesn't exist
if (m_pfnOrig > sm_pvMaxAppAddr) {
// The address is in a shared DLL; the address needs fixing up
PBYTE pb = (PBYTE) m_pfnOrig;
if (pb[0] == cPushOpCode) {
// Skip over the PUSH op code and grab the real address
PVOID pv = * (PVOID*) &pb[1];
m_pfnOrig = (PROC) pv;
}
}
// Hook this function in all currently loaded modules
ReplaceIATEntryInAllMods(m_pszCalleeModName, m_pfnOrig, m_pfnHook,
m_fExcludeAPIHookMod);
//-----------------------------------------------
вот как это объясняет сам Рихтер.(мне это особенно понравилось ))))
When an application runs on Windows 98 under a debugger, the debugger makes the module's import section point to a stub that calls the desired function. To account for this, the code in this module must do some crazy stuff. These variables are needed to help with the crazy stuff.
Крэйзи стафф :-))))))))
Как я понял, он использует считывание нескольких байт для определения истинного адреса функции, ты этот кусок имел в виду? (в конструкторе CAPIHook):-)
//--------------------------------------------
m_pszCalleeModName = pszCalleeModName;
m_pszFuncName = pszFuncName;
m_pfnHook = pfnHook;
m_fExcludeAPIHookMod = fExcludeAPIHookMod;
m_pfnOrig = GetProcAddressRaw(
GetModuleHandleA(pszCalleeModName), m_pszFuncName);
chASSERT(m_pfnOrig != NULL); // Function doesn't exist
if (m_pfnOrig > sm_pvMaxAppAddr) {
// The address is in a shared DLL; the address needs fixing up
PBYTE pb = (PBYTE) m_pfnOrig;
if (pb[0] == cPushOpCode) {
// Skip over the PUSH op code and grab the real address
PVOID pv = * (PVOID*) &pb[1];
m_pfnOrig = (PROC) pv;
}
}
// Hook this function in all currently loaded modules
ReplaceIATEntryInAllMods(m_pszCalleeModName, m_pfnOrig, m_pfnHook,
m_fExcludeAPIHookMod);
//-----------------------------------------------
вот как это объясняет сам Рихтер.(мне это особенно понравилось ))))
When an application runs on Windows 98 under a debugger, the debugger makes the module's import section point to a stub that calls the desired function. To account for this, the code in this module must do some crazy stuff. These variables are needed to help with the crazy stuff.
Крэйзи стафф :-))))))))
Ууууууууууууупсссссссс! Каюсь-каюсь, затупил! Просто на днях изучал PE секции с целью написания кода, способного дописать в некоторый исполняемый модуль код из другого исполняемого модуля (в частности, dll) с последующей подменой точки входа. Вспомнил, что в этом примере Рихтер пользуется ImageHelp функциями, и наткнулся на
WriteProcessMemory(), следующий за проверкой операции и перезаписывающий функцию (я почему-то подумал, что он перезаписывает её вместе с кодом операции). Поскольку искал я совершенно другое (и к тому времени уже нащёл то, что искал), то не стал детально разбираться, что там происходит, а просто подметил для себя.
Ууууууууууууупсссссссс!
Бывает, бывает :-)))))))
кстати, насчет вылетающего модуля я так и не разобрался :'( DLL_PROCCESS_DETACH не вызывается, ужОс!!! Кстати, вопрос насчет SoftICE. Я пользовался им в 98-ой и был счастлив, но ведь тут не прокатит! слил по такому случаю Driver Studio (4.31 версия) там удобный Wizard для написания драйверов, но ведь там и есть софт айс для ХР.... только проблемы - он работает(по крайней мере, по Ctrl+D вылетает его окошко и проги всякие ругаются на некий таинственный дебагер), но брЯкпойнты на функции системные не ставятся ((( что делать, каГ быть???
Кстати, вопрос насчет SoftICE. Я пользовался им в 98-ой и был счастлив, но ведь тут не прокатит! слил по такому случаю Driver Studio (4.31 версия) там удобный Wizard для написания драйверов, но ведь там и есть софт айс для ХР.... только проблемы - он работает(по крайней мере, по Ctrl+D вылетает его окошко и проги всякие ругаются на некий таинственный дебагер), но брЯкпойнты на функции системные не ставятся ((( что делать, каГ быть???
Автор, если проблему ещё не решил, то держи вакцину от бациллы :) Такая же возникла ситуация, когда вчера DriverStudio поставил (до этого был SoftICE, но он был "выдернут" из основного пакета). Только вот у меня он зависал при активации бряка.
ZwQuerySystemInformation находится в той же ntdll.dll, что и NtQuerySystemInformation (которой, кстати, нет в windows9x), просто вторая из них вызывает первую, так что вызов идёт внутримодульный. [/QUOTE]
Это не совсем верно. Zw-функции и Nt-функции - это одно и тоже в юзер моде.