Как наиболее корректно получить число дескрипторов открытой .DLL?

Всем привет.

Кто может помочь в решении задачи наиболее корректного получения количества хендлов у открытой DLL? Пути перебора снимка через HelpTool или использования ntQueiryObjectInformation или как-то похоже мне не кажутся очень уж корректными, хотелось бы наиболее корректного решения с использованием официального API если возможно конечно. Весь Гугл уже перерыл, но либо плохо ключевые слова задаю, либо никому это не было интересно. Устроит просто направление поиска, скажем название функции без примеров использования или ссылка на соответствующий материал в инете, язык может быть русский или английский.

 

CreativeFighter
Что понимать под "хэндлом длл" ?

 

Значение возвращаемое при вызове LoadLibrary очевидно. Более точно задача стоит в том, чтобы точно знать сколько раз конкретная DLL отражена в адресных пространствах процессов, подозреваю, что статический импорт DLL также где-то там внтрях создаёт хендл на неё, как и использование LoadLibrary, если я не прав, то задачу я уточнил.

 

CreativeFighter

почему toolhelp нельзя назвать официальным и корректным путем?

 

CreativeFighter
Значение возвращаемое LoadLibrary() это адрес проекции модуля. С моей точки зрения модуль это файловая секция и мапиться может многократно в разные процессы, соответственно счётчик - число ссылок на обьекты(реверенс). Нормального решения в юзермоде не вижу, разве что открывать и получать инфу. Для секций - перечислять все процессы.

 

CreativeFighter

ИМХО задача всё ещё слишком расплывчато поставлена.
Если речь идёт о хэндле, возвращаемом LoadLibrary, то это всего лишь адрес загрузки dll в АП процесса. Поэтому в таком смысле о количестве хэндлов в системе говорить вообще некорректно.
Если речь идёт об отображении в АП процессов, то непонятно, считать ли маппинги не IMAGE типа или IMAGE, но не связанные с исполнением кода dll (т.е. открытие PE-редактором, например), считать ли целиком считанные образы в память с помощью простого ReadFile. А может считать просто файловые хэндлы, возвращённые при CreateFile?

 

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

 

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

Неужели нет официального раппера для соответствующей функции ntdll.dll?

 

Боюсь, что это будет ещё тормознее нежели использование ToolHelp, поскольку она именно этим и занимается ннасколько я могу судить.

 

Это не ошибка. Он делаеш снапшот. А снапшот по определению делается на момент времени.

 

CreativeFighter
Вы попутали всё, какие есчо дескрипторы. Ругаться техническим матом не достаточно, нужно есчо по смыслу связывать. Правильная постановка задачи половину проблемы решает. Я так и не понял что вам нужно. Вобще полноценно такую инфу из юзермода сервисами не извлечь.

 

Помедитировав над постом l_inc и на всё вышесказанное пришёл к выводу что вам наверно нужно найти число ссылок на файл(причём тут длл так и не понятно) таких как проекции и описатели, тогда так:
1. Ищем описатель файла.
o Перечисляем хэндлы всех файлов.
o Для описателя файла получаем его имя посредством ObjectNameInformation.
2. Ищем проекцию файловой секции.
o Перечисляем все регионы памяти.
o Для проекции извлекаем имя файла посредством MemoryMappedFilenameInformation.
3. Ищем описатель секции. Так как секция обьект, то имя её это имя обьекта, а не имя файла связанного с секцией. В связи с этим:
o Перечисляем хэндлы всех секций.
o Каждую мапим и извлекаем имя файла посредством MemoryMappedFilenameInformation(как в #2).
Глючить будет полюбэ, тысячи описателей и регионов во всех процессах отпарсить нужно ведь, очень не тру.

 

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

 

Как тогда Вы предлагаете мне называть то, что возвращает LoadLibrary? И при чём тут технический мат - я не понял? Есть определённая терминология, которую я использую равно как и все. Если Вы не поняли что мне надо, то как тогда изволите отвечать что это в юзер-моде получить невозможно?

Я собственно путь нашёл получения того, что мне надо в юзер моде, но он не является абсолютно корректным, поскольку использует недокументированный вызов и не один из ntdll.dll. Мне надо получить корректный способ если он есть через отдукументированные рапперы окошек.

 

Поскольку несколько человек не поняли задачу, возможно я не могу корректно её сформулировать. Дубль два того, что мне нужно:
1. Имеем дескриптор динамической библиотеки полученный при помощи LoadLibrary в моём собственном процессе, где можем с ним оперировать как мне надо ну и соответственно если необходимо, то имеем и имя библиотеки.
2. Необходимо получить количество ссылок на эту библиотеку во всей системе, то есть во всех процессах в системе, причём таких когда она открыта на исполнение, а не открыта скажем в блокноте взбесившимся пользователем. Иными словами, если она открыта при помощи LoadLibrary, если она загружена при помощи статического импорта в модуль работающий в одном из процессов или если она насильно открыта при помощи волшебного ключика в реестре и не успела к этому моменту времени закрыться. Наиболее простой путь был бы использовать DLLMain и подсчитывать число открытий библиотеки в случае DLL_PROCESS_ATTACH, беда только в том, что библиотека написана не мной и исходник получить невозможно.

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

Ну не знаю я как ещё объяснить задачу понятнее и точнее, ну неужели я так непонятно объясняю что мне надо получить в результате?

 

вот меня кстати, как и Клерка, раздражает, когда HMODULE называют хендлом, но ничего уж не поделать тут...

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

 

Clerk

ZwQueryObject (ObjectBasicInformation)
BasicInfo->ReferenceCount, BasicInfo->HandleCount

 

Great и Clerk, а как вы предлагаете от HMODULE перейти к дескриптору? всмысле когда "длл отобразилась" на адрессное пространство остается висеть открытый дескриптор файла? просто мне чет всегда казалось, что длл можно удалить не зависимо от того загружена она в вп процесса/процессов, а если бы оставался дескриптор, то этого сделать было бы нельзя... я может путую что-то с чем-то?)))

 

Great
Счётчики не соответствуют числу секций и числу проекций. Оешение в #12.
Rel
Проекция связана с вайлом через обьект секция, вот отсюда и извлекается имя. Но число LoadLibrary() != число проекций.
CreativeFighter

Указатель это. Темболее хэндл это не дескриптор, это описатель. А LoadLibrary() возвращает псевдохэндл.

 

*решение