Работа с описателями

[gaidar]

Подойдет. Если не сложно, то вышли, пожалуйста, на gaidar.magdanurov@gmail.com все, что у тебя к публикации готово. Иначе я просто забываю опубликовать на сайте когда время появляется.

[tyomitch]

Утроенный по объёму вариант -- в аттаче. Продублировать на мыло?

[gaidar]

Продублируй, если не сложно.

[ANDLL]

Интересно узнать у автора статьи, почему он использует VirtualAlloc а не HeapAlloc? Ведь первая выделяет память по несколько килобайт срау.

[tyomitch]

А автор и выделяет как раз по несколько килобайт сразу...

[ANDLL]

Ааа. Ну тогда это... Что бы не вводить меня в заблуждение. 1 страница(4 Кб) это 4096 байт, а не 4000...[/code]

[tyomitch]

ANDLL, предлагаешь сэкономить 96 байт?

[ANDLL]

Нет, просто я плохо сосчитал нули, и мне сначала показалось, что там 400... Если бы там было написано все как у людей(то есть 4096) я бы не ошибся и не пришлось бы писать сообщение.

[GM]

Все же в статье есть некоторые ошибки в оглашении структур, а именно:

Код: Выделить всё

  Reserved1(4) As Long
...
Reserved2(4) As Long


Видимо когда автор переводил из Си, где в оглашении написано

Код: Выделить всё

ULONG Reserved1[4];
...
ULONG Reserved[4];


забыл что в VB по умолчанию(Option Base 0), Reserved1(4) означает Reserved(0 to 4), а не Reserved[0..3] как в Си.
Мелочь но все же

[Twister]

Интересно узнать у автора статьи, почему он использует VirtualAlloc а не HeapAlloc? Ведь первая выделяет память по несколько килобайт срау.

Привычка такая. Для больших объемов (больше 4кб) я ее обычно использую. Тем более, что для HeapAlloc необходимо еще и кучу найти, а это лишние телодвижения.

1 страница(4 Кб) это 4096 байт, а не 4000...

Но выделится-то все равно страница размером 4096 байт. Впрочем Темыч уже ответил...

GM
Тебе спасибо, я и правда не взял в расчет OptionBase...

Эй, народ! А что по поводу второй статьи? Ее что, ни кто не осилил?

[tyomitch]

Став писать аналогичную прогу, обнаружил более тонкие баги.

>"SYSTEM_HANDLE_INFORMATION = 2"
разве не 16? в моём справочнике 2=SystemPerformanceInformation.

>"но мы не будем использовать этот параметр"
а зря, при нехватке места туда положат требуемый размер -- и не нужен перебор

>"Открываем процесс-владелец описателя с доступом PROCESS_DUP_HANDLE и копируем описатель к себе"
мне для этого потребовалось включить SeDebugPrivilege, иначе не давало

[tyomitch]

И ещё один вопрос вдогонку: как по хэндлу дочернего объекта узнать родительский? (В моём случае, по хэндлу файла -- том.)

[tyomitch]

(Уже и не надеясь завладеть вниманием автора)

> "запрашивая информацию о хэндле ... (ZwQueryObject или ZwQueryInformationFile, не важно) ... вызывающий поток ... «умирает». Самое ужасное что такой «мертвый» поток уже невозможно никак закрыть, а процесс, имеющий такие потоки выгружается из памяти только по ресету"

Мои эксперименты с Win2000 показали, что поток, замерший в ZwQueryInformationFile, отлично убивается. Замерший в ZwQueryObject -- действительно, бессмертный.

[Twister]

(Уже и не надеясь завладеть вниманием автора)

Да, меня сейчас в сети практически не бывает. Много работы - времени посидеть и почитать форумы катастрофически не хватает. Ну а если находится время посидеть за компом "для себя", то посвещяю его написанию вируса, который уже почти готов... Так что извеняюсь за то, что вопросы ко мне оставались долгое время без ответа. Итак...

SYSTEM_HANDLE_INFORMATION = 2

Угу. Очепятка. Конечно 16.

при нехватке места туда положат требуемый размер -- и не нужен перебор

Это, конечно, было мне известно. Но я брал в расчет тот факт, что между двумя вызовами функции информация о хэндлах может поменяться (и не редко делает это!), а перебор гарантирует, что мы получим самую "свежую" инфу.

мне для этого потребовалось включить SeDebugPrivilege, иначе не давало

Да. А разве в исходниках я не включал эту привилегию?

как по хэндлу дочернего объекта узнать родительский? (В моём случае, по хэндлу файла -- том.)

Ну, вообще если бы не комментарий в скобках, то я б и не понял что ты имеешь ввиду. Хотя то, что без скобок и то, что в скобках - абсолютно разные вещи. Хэндл, как известно, просто индекс ячейки в трехуровневой таблице (два первых бита - уровень таблицы). Ячейка же указывает на сам объект ядра. Так вот, к чему я это - понятие "родительский объект" есть не у всех объектов. Вот у объекта "процесс" есть запись об ID родительского процесса (EPROCESS->InheritedFromUniqueProcessId), поэтому нет проблем узнать процесс-родитель. А у объекта "файл", как не сложно догадаться, нет "ссылки" на том. Зато есть ссылка на имя файла. Имя, если я не ошибаюсь, в Native'ном формате - "\Device\HardiskVolume3\WINNT". Отмечу, что из имени в нативном формате нельзя однозначно получить имя в Win32-формате (из "\Device\HardiskVolume3\WINNT" получить "K:\WINNT"), а вот наоборот можно. Как писалось в одной статье: "преобразование явно может не быть однозначным даже в случае компьютера без службы сервера, ибо существует программа subst." Т.е. единственный способ - это отсечь от имени начало - "\Device\HardiskVolume3", перебрать каталог объектов "\Global??" и найти симлинк, указывающий на то, что обозначено в "отсеченной части". Имя симлинка и будет буквой тома ("C:", "D:").

Надеюсь, что столь запоздалый ответ все же будет полезен...

[tyomitch]

мне для этого потребовалось включить SeDebugPrivilege, иначе не давало

Да. А разве в исходниках я не включал эту привилегию?

Включал, но я-то читал статью, а не исходники


(Про родительский объект я действительно спорол чушь, но когда это осознал, править свой пост не мог.)

Надеюсь, что столь запоздалый ответ все же будет полезен...

Увы, нет: уже самостоятельно наступил на все грабли, и дописал-таки ту прогу.