Aiks, Это очевидные вещи, разрабы ядра не так глупы, половину ядра 10-ки занимают механизмы безопасности и прочие навороты. Оно глючило потому что намеренно был введён рандом в запрос по описателям, в связи с тем что это лишь малварке нужно, реверси ядро; даже если на текущем сеансе будет стабильность, то на другом будет анстаб. Я бы это не юзал. Кстате зачем тебе описатели ?
Indy_, детект процессов которые получили дескриптор для чтения/модификации памяти моего процесса + детект некоторых программ.
Aiks, Античит значит пилишь. Так вот описатели нужны для получения их обьекта обычно(кернел адрес его), можно тупо ссылки на обьект посчитать, что не наше значит чит, через счётчики ссылок на обекты выполнялись атаки на ядерные фильтры ав
Но в таком случае я смогу только детектить. Будет много false detections. Ибо даже легальные программы могут открывать мой процесс. А мне еще нужно иметь возможность закрыть этот дескриптор у другого процесса. С моим методом это возможно.
Aiks, Что же за метод, если он основан на палевном механизме слепков, в который ради защиты введён рандом и ты про это ничего не знаешь. А как быть с правами, толку то от описателя, если тебя защита заблочит при попытке доступа. Эти слепки нужны были для иной цели, морозился второй поток во время ядерной обработки. Счётчик ссылок или эти слепки позволяли узнать что тред встал в ядре в безопасном для атаки месте.
Indy_, речь идет про ZwDuplicateObject + DUPLICATE_CLOSE_SOURCE и CloseHandle. Все зависит от уровня знаний человека, который решил обойти защиту. Против большинства работает.
Можно попробовать перечислять хэндлы для каждого процесса по-очереди. Логика примерно такая: 1. NtQuerySystemInformation(SystemProcessInformation) 2. NtOpenProcess(SystemProcessInformation->UniqueProcessId) 3. NtQueryInformationProcess(ProcessHandleInformation, sizeof(ProcessHandleInformation) * SystemProcessInformation->HandleCount)) 4. NtQueryObject(ProcessHandleInformation->HandleValue)
