Вопрос - как получить список хэндлов другого процесса ( win98 ) насчет winnt - вроде все понятно - покопаться во внутренностях handleex от Руссиновича. А вот в 98 Руссинович не хочет их показывать :(.
Вопрос 2 - как закрыть хэндл в другом процессе? DuplicateHandle + CloseHandle?
И последний вопрос - нужно принудительно закрыть ресурс открытый прогой - а именно COM1 к примеру открытый по CreateFile + SHARE_MODE_NONE. Т.е. открыть его из другого процесса и сказать модему +++ATH\n к примеру не получиться :(

Ну уж раз Руссинович их не показывает, то наверное не потому, что не хочет, а потому, что не может. Осмелюсь сделать такое предположение. Хотя теоретически это конечно можно сделать. Видимо очень сложно.

DuplicateHandle + CloseHandle? Нет. Такое работать не будет. Вернее, ты закроешь дубликат хендла в своем процессе, а в удаленном все останется как было. А если под NT, смотри как Руссинович это делает.

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

Если тебе не общее решение нужно, то можно попробовать внедрить свой код в интересующий тебя процесс, и уже изнутри как-то найти нужный хендл и закрыть его. Для внедрения кода можно заюзать ApiHooks by EliCZ http://www.anticracking.sk/EliCZ/ раздел Export.

По поводу "не может Руссинович" - похоже он анализирует какую-то "правильную " область памяти где находятся хэндлы. в 98-й такое тоже есть - у Петрека это описано - только что нашел. Нужно будет покопаться дальше.
По поводу инжектирования кода в другой процесс - в NT у меня с этим проблем нет. А вот в 9х - что-то не вериться ( нет там CreateRemoteThread ). Хотя там наверное тоже все будет работать - покопаю ApiHooks.

ЭЭх блин. все хорошо в ApiHooks, да я там к тому же нашел ещё кое-что интересное - CreateRemoteThread для win9x.. но у автора есть ужасная привычка - не давать сорцы. А у меня проект специфичный - там практически нет никаких импортов. И никакого C рантайма. А так же размер минимальный должен быть. Скорее всего придется копать его либины в IDA да писать самому код.

[ rst: Скорее всего придется копать его либины в IDA ]

Бог в помощь, но по моему опыту копания в его либах - дело это не простое, ибо парень фанат оптимизации. Там так все заколбашено, что ой-ёй-ёй. Как он сам в своих сорцах разбирается хз ;-)

В аттаче сорцы для v2.2b - это, вроде, последние открытые.
В следующем аттаче еще кое-что необходимое. Надеюсь, попроще те будет.


1374910935__AH22b.zip

1360985664__EliAsm.rar

Не хочу показаться тем, кто все слишком упрощает, но по-моему лучше будет не "анализировать какую-то "правильную " область памяти где находятся хэндлы", а просто перебирать от 0 до 65536, ибо совместимость будет больше, а инжектировать можно с помощью локального хука, причем я как-то сделал так, что обошолся без библиотек. Но так как я делал это на другом языке, нежели асм, то исходники показать не могу. Но если заинтересует, то я могу переписать.

хм... по-моему 65536 немного не вяжется. т.к.
#typedef HANDLE long это раз
sizeof (long) = 4 bytes
4 bytes=32 bits
2^32 далеко не 65536 а больше. следовательно 4 миллиарда вариантов перебирать - не самое приятное занятие.

rst
А разве Хендл это не структура?
Как например hWnd

The total number of open handles in the operating system is limited only by the amount of memory available to the operating system. However, a single process may have no more than 16,384 open GDI object handles. The per-process limit on kernel handles is 2^30. There is no per-process limit on user handles, but there is a systemwide limit of 65,536.
WinSDK(c)

2Edmond:
Хэндл - это смещение в таблице указателей на структуры хэндлов.

[ rst: ...следовательно 4 миллиарда вариантов перебирать - не самое приятное занятие. ]

Набери в айсе proc -o <имя процесса/пид/указатель на процесс>.
Даже для самого громоздкого процесса ты увидишь всего ~100 хендлов. Причем они практически подряд идут. Если умно организовать перебор, то найдешь очень быстро. Имеется ввиду NT. Что там под 9х - хз.


[ WinSDK: The per-process limit on kernel handles is 2^30. ]

Что-то многовато. Под NT, по райней мере начиная с 2000, теоритический предел зависит от структуры таблицы хендлов и составляет 256*256*256. Подробнее можно у Соломона почитать.

Я отвечу так:
потом посмотрите какое i выведет cout; а при работе смотрите в TaskManager на предмет кол-ва открытых хэндлов процессом. ( кстати - написал прогу. у меня кол-во хэндлов превысило 500 000 , не говоря уже о 65535 ) так что мои сооброжения относительно обоснованы. в любом случае не 65535 а намного больше.

#include "windows.h"
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
	int i=0;
	while (INVALID_HANDLE_VALUE!=CreateFile("c:\\boot.ini", GENERIC_READ,
             FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL))
	{
		i++;
	}
	cout << i << endl;
	return 0;
}

[ rst: кстати - написал прогу. у меня кол-во хэндлов превысило 500 000 , не говоря уже о 65535 ]

65535 имелось ввиду для user-объектов. А ты меряешь kernel-object хендлы, а их как написано в умной книге максимум 256*256*256. Точнее это максимальный размер таблицы хендлов процесса.

Но, таким способом ты не измеришь таблицу хендлов. Существует такая штука как квота. Каждому процессу выдается квота на объекты ядра. При создании объекта от квоты откусывается кусочек. Когда квота кончится случится облом. И произойдет это значительно раньше чем исчерпается место в таблице хендлов.

В любом случае, это имеет чисто спортивный интерес. Тебе ведь нужно закрыть реальный хендл в реальном процессе, а где ты видел процессы с 500 000 открытыми хендлами ?!

У системных процессов таких как Winlogon или Csrss ~200-300 открытых хендлов объектов ядра. А у обычного процесса не более 50, ну ~100 на крайний случай. Так что, если ты ограничишь поиск 1000 хендлов, то этого за глаза и за уши хватит.

Хм.. не буду голословным, но мне кажется, что
hFile=CreateFile()...
будет hFile=1;
CloseHandle(hFile);
hFile=CreateFile()..
hFile=2;
т.е. при каждом последующем открытии объекта кол-во хэндлов увеличивается.
т.е. если было 1000 открытий объектов и их закрытий, то даже если у процесса 20 хэндлов, то их номера будут от 1000 начинаться.
это мое ИМХО