Подскажите, как защитить свой процесс от нехороших приложений, которые выделяют память и затем исполняют свой код в моем приложении через АПЦ ? Без использования Ринг-0 кода.
А если все-таки нужно создавать alertable в KiUserApcDispatcher можно определить, что это не моя апц пришла ?
Такая вот идея, нигде не могу параметров найти которые передаются в KiUserApcDispatcher, там скорее всего адрес для запуска есть, если посмотреть к чему он принадлежит и если это 'ничейная' память пропускать АПЦ Zw/Nt/AllocateVirtualMemory выделяя память не указывают ведь на регион какой нить длл или ехе в АП которые могут ожидать АПЦ
Из юзермода мы не можем в полном обьёме манипулировать потоками и памятью(без доступа к памяти ядра). Также и выполнить надёжный перехват диспетчера апк. Стартупапк ведь тоже следует учитывать. Если диспетчер апк захвачен к примеру редиректом на обработчик непосредственно(джамп напр.), то не проблема обойти: Если имеется доступ к потоку, то манипуляции контекстом также следует учитывать, апк лишь одна из них. Наиболее устойчивый перехват получится при замене приватной памяти на проекцию секции, спроецированной только для чтения. В этом случае не получится из юзермода изменить код в этой проекции. Редирект на диспетчер исключений требует захвата его начала с помощью этой манипуляции. Например если перенаправить диспетчер апк на диспетчер исключений(напр. записью привилегированной инструкции) это не решит проблему с защитой диспетчера исключений(KiUserExceptionDispatcher()). Мы видим как решение перемап всей кодовой секции нтдлл. Второй проблемой является определение родителя апк, тоесть процесса который её поставил в очередь. Для этого следует получать сообщения при добавлении апк в очередь, что проблемно например в случае нэйтивных таймеров. Также как и манипуляции контекстом посредством апк, может быть выполнены манипуляции памятью и контекстом непосредственно. Тоесть NtProtectVirtualMemory и захват диспетчера ислючений, либо как частный случай подключение отладочного порта. Защитой от захвата контекста может стать описанное когдато создание потока-ловушки. При создании нового потока получаем слепок(системинфо) и первый поток текущего процесса в этом списке должен использоваться как ловушка. Делается не валидным стек, либо устанавливается хардварный останов в контексте его и тред выполняет бесконечный цикл обращения к ядру(ожидание в случае апк). Тогда при доставке апк в его контексте либо изменение Eip приведёт к неожтданному исключению(стек не созаёт никто отдельно). Вобще понятие защиты в юзермоде слишком мутное.
