Доступ к памяти чужого процесса

set
уверен?

З.Ы. в Висте по крайне мере это разницу для 7 Каспера имеет.

 

slow
почитал описание функции. То есть это то же самое что и УдаленныйПроцесс только вызоветься когда тот процесс перейдёт в состояния покоя\сна? Больше ничем не отличаеться? Если так, то почему эту функцию Каспер не перехватывает?

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

 

NtQueueApcThread(hThread,LoadLibraryExW,pvRemoteMemory,0,0)
в 2000й винде надо делать GetContext после создания потока, в ХП можно сразу вставлять

в x64 я не нашел способа вставить APC из 32б в 64б а вот наоборот можно, NtQueueApcWow64Thread, так что лучше если приложение 64б будет

Причем имя можно не писать, если отмапить свою длл вместо стандартной и указатель в knowndlls прописать кхм... Только сначала надо ее из Permanent object в Temrorary object сделать... хз, стоит попробывать, это был бы лучший инжектор во все процессы

Еще можно загрузить как шим (если процесс еще не запущен) в sysmain.sdb есть записи насчет загрузки shimeng.dll (я не ковырял как именно это поменять, кури ф-ю QueryExecuteOptions вроде так), ее можно прописать в knowndlls без запар со сменой типа объекта.

 

dead_body
получается что createremotethread не надо вызывать) а потом фильтровать ntqueueuserapc сложно так как она активно используется системой)
только еще надо как-нить запротектить память как EXECUTE)

 

Я обновил свой пост...

П.С. Разгребание очереди APC происходит не всегда и не часто, поэтому лучше создать поток на NtTestAlert

 

Не понял на счет NtTestAlert. Просветите технологию...

 

Ф-я разгребает очередь APC

 

она же локальная?