O>Короче, надо ждать пока в тему заглянет x64 и даст какой-нибудь толковый совет.



Я здесь и готов помочь обездоленным!

O>ZwReadFile/ZwWriteFile, кстати, работают [далеко] не только с файлами.
O>Короче, надо ждать пока в тему заглянет x64 и даст какой-нибудь толковый совет.
я даже знаю какой это будет совет

CEM>А можно по-подробнее или линк?

А что тут рассказывать, всё уже обсуждалось много раз. В ntdll.dll есть переходники NtWriteFile(), NtReadFile() и т.д. Хватай их и вставляй свои задержки, как требуется.

Добрый день!

Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

Здравствуйте, CEMb, Вы писали:

CEM>Добрый день!

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

Например, хук на ZwReadFile/ZwWriteFile, в котором реализовать требуемые правила ограничения.

Здравствуйте, 5er, Вы писали:

CEM>>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

5er>Например, хук на ZwReadFile/ZwWriteFile, в котором реализовать требуемые правила ограничения.

Это всмысле, перехват вызова? ZwReadFile/ZwWriteFile — это низкоуровневые недокументированные функции?

Здравствуйте, CEMb, Вы писали:

CEM>Здравствуйте, 5er, Вы писали:

CEM>>>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

5er>>Например, хук на ZwReadFile/ZwWriteFile, в котором реализовать требуемые правила ограничения.

CEM>Это всмысле, перехват вызова? ZwReadFile/ZwWriteFile — это низкоуровневые недокументированные функции?

Да, перехват вызова.
Функции, на самом деле, давно уже документированы.

Здравствуйте, 5er, Вы писали:

CEM>>>>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

5er>>>Например, хук на ZwReadFile/ZwWriteFile, в котором реализовать требуемые правила ограничения.

CEM>>Это всмысле, перехват вызова? ZwReadFile/ZwWriteFile — это низкоуровневые недокументированные функции?

5er>Да, перехват вызова.

А есть хотя бы схематический примерчик с ключевыми функциями?

5er>Функции, на самом деле, давно уже документированы.

Здравствуйте, CEMb, Вы писали:

CEM>Добрый день!

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

ограничить байты в секунду или байты?

Здравствуйте, CEMb, Вы писали:

CEM>Добрый день!

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

Что значит "информация, записываемая процессом на диск" ?
С файлами все понятно. Хотя не очень — временные файлы учитывать ? А файловый кэш ?
А если приложение выделяет память, которая удовлетворяется из файла подкачки ?
С чтением вообще темный лес. В смысле — критерии "чтения" очень размыты.

ZwReadFile/ZwWriteFile, кстати, работают [далеко] не только с файлами.
Короче, надо ждать пока в тему заглянет x64 и даст какой-нибудь толковый совет.

Здравствуйте, CEMb, Вы писали:

5er>>Да, перехват вызова.

CEM>А есть хотя бы схематический примерчик с ключевыми функциями?

В инете есть примеры. Как-то хитро они ищутся, но есть ибо малварно-хакерская техника, особенно под винду старше чем XP.
На форуме, например, есть статья

Автор(ы): Тихомиров В.А.
Дата: 11.11.2002

.
Для ознакомления с принципом работы сойдет.

Вообще, м.б. стоит пересмотреть бизнес логику приложения. Если нужен мониторинг работы с диском, то писать/читать на диск нужно
через свой компонент, в котором реализован соответствующий манеджер.

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

Так что если не пишите свой FileMon, то в такие дебри лезть не стоит ради сомнительного функционала.

Здравствуйте, dcb-BanDos, Вы писали:

DB>ограничить байты в секунду или байты?

Байты в секунду. Ну или в минуту Короче, в единицу времени

Здравствуйте, ononim, Вы писали:

O>>ZwReadFile/ZwWriteFile, кстати, работают [далеко] не только с файлами.
O>>Короче, надо ждать пока в тему заглянет x64 и даст какой-нибудь толковый совет.
O>я даже знаю какой это будет совет
Я тоже, у меня его аська есть, уже как-то чё-то спрашивал
Я думаю, он посоветует написать драйвер, но что-то мне неохота писать драйвер, потому что под 7-ку его подписывать надо, а во-вторых, я не умею писать драйвера. Апишные перехваты я хоть делал немного

Здравствуйте, CEMb, Вы писали:

CEM>Добрый день!

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

Я что-то постановку задачи не пойму. Ограничимся простым примером — идет WriteFile в один файл.
Что ты хочешь — чтобы один вызов прошел, а второй дал отказ ? И что потом ?

ИМХО ограничивать надо просто задержками между записью в своей программе.

Здравствуйте, 5er, Вы писали:

CEM>>А есть хотя бы схематический примерчик с ключевыми функциями?

5er>В инете есть примеры. Как-то хитро они ищутся, но есть ибо малварно-хакерская техника, особенно под винду старше чем XP.
5er>На форуме, например, есть статья

Автор(ы): Тихомиров В.А.
Дата: 11.11.2002

.
5er>Для ознакомления с принципом работы сойдет.
Ага, читал, делал перехват через таблицу импорта.
Интересен был инжект в чужой процесс через LoadLibrary с последующим перехватом.

5er>Вообще, м.б. стоит пересмотреть бизнес логику приложения. Если нужен мониторинг работы с диском, то писать/читать на диск нужно
5er>через свой компонент, в котором реализован соответствующий манеджер.
Ага, я тоже так считаю Но фирма-автор сего "шедевра" настолько большая и опупенная, что меня просто нафиг пошлют с такими идеями
Не_пользоваться их софтом я не могу по ряду причин, в подробности вдаваться не буду

5er>Перехват api-вызовов хорош для тестирования, когда нужно зафейлить системный вызов в готовом приложении и посмотреть реакцию.
О, интересная идея. А насколько это актуально бывает? Ну и фэйл фэйлу — рознь. Да и зафэйлить можно без перехвата — стек сломать/забить

5er>Или залоггировать те же вызовы.

5er>Так что если не пишите свой FileMon, то в такие дебри лезть не стоит ради сомнительного функционала.
Между делом: API-Mon хочу написать, но это уже другая песня

Здравствуйте, CEMb.

Мне вот интересно — неужели для решения данной задачи нельзя обойтись встроенными
средствами безопасности Windows, дисковыми квотами NTFS, наконец ?..
Или хотя бы как-то извратиться, запуская программу из-под специально настроенной
учетной записи с такими квотами ?
Что, без тяжелой артиллерии вроде файловых драйверов никуда ?

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

Тебе надо именно квоту или регулирование пропускной способности?

Здравствуйте, x64, Вы писали:

O>>Короче, надо ждать пока в тему заглянет x64 и даст какой-нибудь толковый совет.

x64>

x64>Я здесь и готов помочь обездоленным!

Если что — я тут так, мимо проходил...

Здравствуйте, okman, Вы писали:

O>Мне вот интересно — неужели для решения данной задачи нельзя обойтись встроенными
O>средствами безопасности Windows, дисковыми квотами NTFS, наконец ?..
Это где настраивается? Если возможно, то, конечно, лучше такое решение.

O>Или хотя бы как-то извратиться, запуская программу из-под специально настроенной
O>учетной записи с такими квотами ?
Вот тут не получится... программа запускается службой, и нет доступа (и не будет).

O>Что, без тяжелой артиллерии вроде файловых драйверов никуда ?
Драйвера тоже не пойдут, потому что на 7-ке подпись нужна.

Здравствуйте, Pavel Dvorkin, Вы писали:

CEM>>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

PD>Я что-то постановку задачи не пойму. Ограничимся простым примером — идет WriteFile в один файл.
PD>Что ты хочешь — чтобы один вызов прошел, а второй дал отказ ? И что потом ?
Хочу делать паузы между обращениями к диску на чтение/запись.

PD>ИМХО ограничивать надо просто задержками между записью в своей программе.
Да не моя это программа. Есть программа, которая своим мамонтячьим обращением к диску вешает напрочь всю систему. Убить её нельзя, остановить тоже, хочется её притормозить именно на тему I/O

Здравствуйте, x64, Вы писали:

CEM>>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

x64>Тебе надо именно квоту или регулирование пропускной способности?

Вобщем, есть программа, которая читает пишет гигабайтами с места на место. Можно как-то сделать так, чтобы между обращениями к диску делать паузы? Я сейчас ProcMon открыл, посмотрел, там все программы пишут/читают по смещению и порциями. Вот если бы можно было бы для the программы после каждой записи делать Sleep(20) — было бы чудно (наверно/надеюсь)

Здравствуйте, CEMb, Вы писали:

CEM>Хочу делать паузы между обращениями к диску на чтение/запись.

Так ведь паузы должна сама программа делать, а не кто-то за нее.

Хотя...

Попробуй следующее. Есть такие функции из ntdll.dll — NTSuspendProcess и NTResumeProcess (XP и выше)

http://rsdn.ru/forum/winapi/746124.1.aspx

Автор: Pavel Dvorkin
Дата: 02.08.04

Вызывай их по таймеру . Может, что-то и получится.

PD>Есть такие функции из ntdll.dll — NTSuspendProcess и NTResumeProcess (XP и выше)

Регистр, блин! Сервисы тупо перечисляют все потоки под локом и делают с каждым запрошенное действие.

NTSTATUS
NtSuspendProcess (
    IN HANDLE ProcessHandle);

NTSTATUS
NtResumeProcess (
    IN HANDLE ProcessHandle);

PD>Вызывай их по таймеру...

В общем-то, не самая удачная идея, т.к. будет заморожено всё, включая UI, а не только дисковые операции, но как вариант, имеет право на существование.

CEM>Вот если бы можно было бы для the программы после каждой записи делать Sleep(20)...

Ну ты понел, да?
Ещё можно хуки на Nt-сервисы в процессе.
И называется это не квота, а регулирование пропускной способности.

Здравствуйте, x64, Вы писали:

CEM>>Вот если бы можно было бы для the программы после каждой записи делать Sleep(20)...

x64>Ну ты понел, да?
x64>Ещё можно хуки на Nt-сервисы в процессе.
А можно по-подробнее или линк?

x64>И называется это не квота, а регулирование пропускной способности.
Ясно.

Здравствуйте, CEMb, Вы писали:

5er>>Перехват api-вызовов хорош для тестирования, когда нужно зафейлить системный вызов в готовом приложении и посмотреть реакцию.
CEM>О, интересная идея. А насколько это актуально бывает? Ну и фэйл фэйлу — рознь. Да и зафэйлить можно без перехвата — стек сломать/забить

Актуально бывает редко, в целом. В основном для стресс-тестов кода 24*7*365, приближенного к системным вызовам.
Например, хуки можно использовать для эмуляции сетевых задержек или медленной работы с файловой системой (в хуке простой Sleep)
Довольно быстро обнаруживаются невоспроизводимые при штатной эксплуатации ошибки синхронизации в коде,
который 'думает', что, например, ReadFile всегда будет работать быстро.

Здравствуйте, x64, Вы писали:

PD>>Есть такие функции из ntdll.dll — NTSuspendProcess и NTResumeProcess (XP и выше)

x64>Регистр, блин!



>Сервисы тупо перечисляют все потоки под локом и делают с каждым запрошенное действие.

По крайней мере под локом.

x64>В общем-то, не самая удачная идея, т.к. будет заморожено всё, включая UI, а не только дисковые операции, но как вариант, имеет право на существование.

И на том спасибо

В твоей идее насчет хука NtReadFile и NtWriteFile будет та же заморозка, если ввод-вывод делается в GUI потоке.

PD>В твоей идее насчет хука NtReadFile и NtWriteFile будет та же заморозка, если ввод-вывод делается в GUI потоке.

Тащемта, да, разумеется, но во-первых, в грамотно спроектированном приложении такое недопустимо, во-вторых, всегда можно виртуализовать файловые операции, сделав их асинхронными принудительно, т.е. пришёл запрос на запись, пишем данные в свой внутренний кэш и сразу же возвращаем наверх результат "Успех", а реально данные пишем на диск в отдельном потоке с нужной нам задержкой. Тут только две проблемы: это, скажем так, слегка затратно по времени реализации, и виртуализацию конкретно чтения получится сделать только если файл был изначально открыт для асинхронного ввода/вывода, т.к. мы не сможем сразу вернуть данные с тома, они ведь станут доступны нам только после того, как отработает задержка.

Здравствуйте, CEMb, Вы писали:

CEM>Можно как-то чем-то ограничить объём читаемой-записываемой процессом информации на диск?

В висте/семёре появилось несколько ручек для управления приоритетом ввода-вывода. Может, подойдёт?
Вот здесь посмотрите.

Q>В висте/семёре появилось несколько ручек для управления приоритетом ввода-вывода. Может, подойдёт?

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

Здравствуйте, x64, Вы писали:

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

Да, но из описания задачи непонятно, для чего именно нужно ограничивать пропускную способность дискового I/O. Из моей практики, обычно это нужно, чтобы один процесс не забивал другие. Тут приоритизация должна помочь.

[OFF]Дорого бы я дал за такую функциональность для XP. Корпоративные сканеры 3 раза в день подрываются по своим стукаческим делам и отхватывают себе пол-ОЗУ и весь disk i/o. Полчаса можно читать книжку с КПК. [/OFF]

Здравствуйте, x64, Вы писали:

x64>Тащемта, да, разумеется, но во-первых, в грамотно спроектированном приложении такое недопустимо

Судя по всему, ТС досталось не очень грамотно спроектированое приложение

>во-вторых, всегда можно виртуализовать файловые операции, сделав их асинхронными принудительно, т.е. пришёл запрос на запись, пишем данные в свой внутренний кэш и сразу же возвращаем наверх результат "Успех",

Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

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

Тут еще одна проблема. Получив ответ "Успех" , приложение решит, что данные и впрямь записаны, после чего, чего доброго, иной поток (а может, и этот же) попробует их прочитать. Будешь контролировать полностью работу кэша и брать данные из него ? А если сюда еще доступ по mmf добавится, то накроется все это медным тазом, если только ты не реализуешь свой собственный кэш всерьез, то есть фактически реализуешь кэш-систему Windows на уровне одного процесса.
И не дай бог есть соседние процессы, котрые с ним синхронизированы по файловым операциям.

Здравствуйте, Pavel Dvorkin, Вы писали:

x64>>Тащемта, да, разумеется, но во-первых, в грамотно спроектированном приложении такое недопустимо

PD>Судя по всему, ТС досталось не очень грамотно спроектированое приложение

Ага. Это (широко известный) aнтивирус, насаждённый сетевой политикой. Причём, я смотрел, скоко он стоит, он у меня на лаптопе был триал-версия, предустановленный. Снёс. За такие деньги это чудо работает так:
— берёт следующий файл и копирует его к себе в папку
— проверяет
— удаляет
Из интересного:
— пофиг чё за файл, жрёт образы виртуалок несколько гиговые. Ну это ладно, хотя вот это дело винт и подсаживает. Представьте, 20 гигов копировать.
— не проверяет сколько свободного места на винте! То есть, копирует до тех пор, пока в ноль всё не съест. После этого, судя по внешним признакам, минут 5-10 пытается упорно копировать дальше. После бросает эту затею и идёт за следующим файлом. 300-400 баксов стоит простая годовая подписка!

>>во-вторых, всегда можно виртуализовать файловые операции, сделав их асинхронными принудительно, т.е. пришёл запрос на запись, пишем данные в свой внутренний кэш и сразу же возвращаем наверх результат "Успех",

PD>Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

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

PD>Тут еще одна проблема. Получив ответ "Успех" , приложение решит, что данные и впрямь записаны, после чего, чего доброго, иной поток (а может, и этот же) попробует их прочитать.

Да, я как раз рассказал, что за прога, потому что записав файл, чудо начнёт его тестить. Я думаю, правильно было бы при чтении ему сразу EOF сказать? Но всё=-таки хотелось бы, чтобы он свою функцию выполнял, т.е. проверял на вирусы. Но мееееедленоооо...

Здравствуйте, quodum, Вы писали:

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

Q>Да, но из описания задачи непонятно, для чего именно нужно ограничивать пропускную способность дискового I/O. Из моей практики, обычно это нужно, чтобы один процесс не забивал другие. Тут приоритизация должна помочь.

Не помогает, в том и дело Приоритет в нуль, афинити в один — нифига. Винт светит лампочкой бесперерывно. В критической ситуации делаю суспенд. Но это крайний случай, так как есть подозр, что на этот процесс завязаны другие, нужные мне, и не достучавшись до него тоже ступорятся/частично.

Q>[OFF]Дорого бы я дал за такую функциональность для XP. Корпоративные сканеры 3 раза в день подрываются по своим стукаческим делам и отхватывают себе пол-ОЗУ и весь disk i/o. Полчаса можно читать книжку с КПК. [/OFF]
Вот и мне для XP надо. Походу, надо скинуться и нанять x64() чтоб он накатал нам ту мегасофтину спасительную

PS: процесс без-GUI, окон там нету.

> Вот и мне для XP надо. Походу, надо скинуться и нанять x64() чтоб он
> накатал нам ту мегасофтину спасительную

Под хапе — вам напиши так вы ж потом фидбэком запарите
Под w2k3 sp1+ — уже проще, там FltMgr есть.

PD>Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

Я вроде уже написал об этом.
Ты, главное, успокойся, никто не говорил, что будет легко.

PD>Будешь контролировать полностью работу кэша и брать данные из него ?

Да, разумеется, любой файловый кэш так и работает вообще-то.

PD>А если сюда еще доступ по mmf добавится, то накроется все это медным тазом...

Да нет, MMF на уровне процесса тоже вполне возможно перехватить.

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

Драйвер-фильтр файловой системы, господа.
Ну и я предупреждал о трудоёмкости, чего теперь удивляться-то?

V>Под w2k3 sp1+ — уже проще, там FltMgr есть.

Ну под XP SP2 он тоже есть, если что.

Здравствуйте, x64, Вы писали:

PD>>Гм, а чтение как ? "Успех" без данных ? Я же в буфер тут же полезу, а что там ?

x64>Я вроде уже написал об этом.

Вот это ?

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

Если да, то это и есть признание того, что работать в общем случае не будет.

x64>Ты, главное, успокойся, никто не говорил, что будет легко.

Я и так спокоен.

PD>>Будешь контролировать полностью работу кэша и брать данные из него ?

x64>Да, разумеется, любой файловый кэш так и работает вообще-то.

Я и говорю — перепишешь менеджер кеша Windows применительно к одному процессу.

PD>>А если сюда еще доступ по mmf добавится, то накроется все это медным тазом...

x64>Да нет, MMF на уровне процесса тоже вполне возможно перехватить.

Именованные MMF всегда потенциально могут быть расшарены.

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

x64>Драйвер-фильтр файловой системы, господа.
x64>Ну и я предупреждал о трудоёмкости, чего теперь удивляться-то?

Да никто и не удивляется. То, что ты предложишь, было заранее известно

http://rsdn.ru/forum/winapi/4470834.1.aspx

Автор: ononim
Дата: 25.10.11

PD>То, что ты предложишь, было заранее известно

Предложи что-нибудь лучше, я ж не против, у тебя есть другие варианты?

Здравствуйте, x64, Вы писали:

PD>>То, что ты предложишь, было заранее известно

x64>Предложи что-нибудь лучше, я ж не против, у тебя есть другие варианты?

Э!э!э! Ну вы чего?
Я вам дал описало действий программы, будут уточнения по функционалу?

А>Я вам дал описало действий программы...

Ссылку?

А>...будут уточнения по функционалу?

Функционалу чего?

Здравствуйте, x64, Вы писали:

А>>Я вам дал описало действий программы...

x64>Ссылку?

Симантек Антивирус, ссылку не знаю, ибо никогда GUI его не видел, всё зашифровано и скрыто сетевой политикой.

А>>...будут уточнения по функционалу?

x64>Функционалу чего?

Ну, всмысле, по плану действий, как с the бороться.

Здравствуйте, x64, Вы писали:

PD>>То, что ты предложишь, было заранее известно

x64>Предложи что-нибудь лучше, я ж не против, у тебя есть другие варианты?

Так я же и предложил. С недостатками, верно, но работать скорее всего будет.

А>Симантек Антивирус...

Я имел в виду, ссылку на описание проблемы, но не важно, уж сам нашёл.

А>Ну, всмысле, по плану действий, как с the бороться.

Ну хуки ты туда вряд ли внедришь, самозащита не даст, там что пиши драйвер-фильтр и ограничивай/запрещай необходимые операции. Если файлы большие, значит, сделай так, чтобы этот AV думал, что файлы маленькие. Ну и так далее, дальше сам придумаешь.

PD>Так я же и предложил. С недостатками, верно, но работать скорее всего будет.

К сожалению, нет — антивирус не даст открыть свой процесс с правами на Suspend.

Здравствуйте, x64, Вы писали:

PD>>Так я же и предложил. С недостатками, верно, но работать скорее всего будет.

x64>К сожалению, нет — антивирус не даст открыть свой процесс с правами на Suspend.

А права доступа ему поменять нельзя ?

> x64>К сожалению, нет — антивирус не даст открыть свой процесс с правами
> на Suspend.
>
> А права доступа ему поменять нельзя ?

Ну, если с-под аккаунта с SE_DEBUG_PRIVLEGE, и он сам себя периодически
на такое не чекает — то в теории можно.

PD>А права доступа ему поменять нельзя ?

Антивирус не даст открыть свой процесс с правами Set Information.

Здравствуйте, x64, Вы писали:

x64>Антивирус не даст открыть свой процесс с правами Set Information.

Администратору ? Если можно, расскажи (или дай ссылку), как такое делается.

PD>Администратору?

Разумеется. Драйвер ядра всегда имеет больше привилегий, чем любой пользовательский процесс, запущенный от админа.

PD>Если можно, расскажи (или дай ссылку), как такое делается.

Здесь 1

Автор: x64
Дата: 23.06.10

Здесь 2

Автор: x64
Дата: 29.06.10

Здравствуйте, <Аноним>, Вы писали:

А>Симантек Антивирус, ссылку не знаю, ибо никогда GUI его не видел, всё зашифровано и скрыто сетевой политикой.
Симантек испортился видимо к ним пришли программисты от Касперского