подскажите плз, можно ли определить, являются ли 2 хэндла дескрипторами одного и того же объекта. Вообще меня интересует именованный ивент. Через OpenEvent я получаю его хэндл. А в хуке SetEvent я хочу понять, это хэндл того же ивента или нет. На данный момент пользую api-функцайку NtQueryObject, через которую по хэндлу определяю имя и сравниваю. Но это как-то времязатратно.
Определить адрес обьекта в ядре, если не имеет значение именованный он или нет. NtQuerySystemInformation(SystemHandleInformation) но тоже долго, лучше сделать как ты.
Да, это наверное вариант. Дело в том, что интересующий меня ивент создается в другом процессе. И если к тому моменту, как я туда заинжектилась, ивент создан, то я его могу найти по тому же самому имени, перебрав все хэдлы процесса. И тогда в хуке SetEvent мне надо будет сравнить именно пришедший хэндл с найденным мною. Но, вот если я никого не найду, тады придется проверять имя пока не наткнусь на нужный мне.
LubaEls Ничего не понятно, из того что ты написал. Имена обьектов глобальны в системе. По нармальному обьясни что тебе надо сделать в перехвате.
В хуке SetEvent мне нужно понять, что это вызывается именно для ивента с именем "BaseNamedObjects\Name1"
Ради интереса проверил скорость исполнения. Аффинитет 11b, приоритет нормальный. Вызов в цикле NtQueryObject(ObjectNameInformation) для одного из евентов директории \BaseNamedObjects, число циклов - 800000h, затрачено - 13 секунд. Вызов в цикле NtQuerySystemInformation(SystemHandleInformation), число циклов - 2000h, затрачено - 18 секунд. Видно что один вызов NtQuerySystemInformation (в секунду примерно 455 раз) выполняется примерно за 2.2 миллисекунды, а один вызов NtQueryObject (в секунду примерно 645277) выполняется примерно за 1.55 микросекунды. Вызов NtQueryObject(ObjectNameInformation) выполняется быстрее чем вызов NtQuerySystemInformation(SystemHandleInformation) в 1400 раз.
С другой стороны, если Event ещё не создан, то можно перехватывать CreateEvent/OpenEvent в целевом процессе до тех пор, пока Event не будет создан. С третьей стороны, сравнение чисто по числовому значению хэндла в хуке SetEvent может иметь какой-то смысл только если целевой процесс гарантированно создаёт\открывает этот именованный Event лишь один раз (и ни разу не делает с ним DuplicateEvent). Ведь иначе неизвестно, с использованием какого из хэндлов одного и того же Event'а целевой процесс обратиться к SetEvent.
Это понятно. Но список хэндлов, указывающих на нужный мне ивент через NtQuerySystemInformation я получаю один раз при инжекте в процесс. Естественно, при условии, что в ивент уже создан. А NtQueryObject мне придется вызывать каждый раз в хуке SetEvent. Но сравнение хэнлов и правдо видать не валидно, т.к. его могут и закрыть, тогда еще надо добавить хук на CloseEvent, и дублировать... Поэтому и хотелось идти по схеме: OpenEvent ( нужного именованного ивента ) возвращает h1, запонимаю хук SetEvent дает h2 А теперь я хочу знать, дискрипторами одно и того же объекта они являются. При чем быстро
Если событие с автосбросом, то можно узнать, что SetEvent был вызван, и при этом с некоторой вероятностью предотвратить получение уведомления целевым процессом: В своём процессе создать\открыть нужное событие. Создать много-много потоков. В каждом созданном потоке вызвать WaitForSingleObject(hEvent); Пробуждение какого-либо из потоков говорит о том, что в целевом процессе была вызвана SetEvent. Но, конечно, это вероятностный подход - мы не можем знать, что сигнал получит какой-либо из наших потоков, а не целевой процесс. Для этого, собственно, и создаётся много потоков. (Кстати, есть какие-то способы повлиять на выбор потока для пробуждения? Приоритет должен влиять же, да?)
Clerk Просто мы сделали предположение, что в данном случае одной может быть достаточно отследить сигнализацию. При этом в случае события с автосбросом мы также получаем некоторую возможность контролировать ситуацию - можем убивать свои потоки и сигнализировать, можем не сигнализировать... Гм, да, "могу копать, могу не копать").
А мне не нужно вмешиваться в воркфлоу целевого процесса. Мне нужно тока подсматривать. И вероятностный подход тоже не катит
