типа антиинжект чтоли, вообщем ясно что на маршруте RtlUserThreadStart -> LPTHREAD_START_ROUTINE гдето уходит в ExitThread, разбираться не стал, решается CreateThread(SUSPENDED)->SetThreadContext(Eip==Target)->ResumeThread - и вуаля. вопрос разумеется к профи этого дела, как можно противостоять таким инжектам? или например тому что я тупо фрейм перепишу возвратом на шеллкод - делая гейт для процедуры, сохраняя все регистры, - тут даже CFG вообще ниалё, а поток как играл так и играет, только ещё один заспавнил. товарищ Инде, поскольку вы теперь авер, расскажите как с этим бороться. в юзермоде разумеется.
sn0w, Не вполне понимаю вопрос. Достаточно обычного ав фильтра - ограничение по вайт спискам и прочие фильтры, инжект блокируется на сервисном уровне, те ставятся фильтры на нтапи. > тому что я тупо фрейм перепишу возвратом на шеллкод Вы немного запутались в формулировке задачи, выше вы говорите про штатный инжект(IPC), а теперь про OP-атаки. Определитесь для начала, это разные вещи и методы. Что бы что то обсудить нужно чёткое описание задачи и понимание её. А если вы сами не поняли что спрашиваете, то на это и ответить нельзя. "FF" мне эта абр. говорит только про триггер Flip-Flop, не о чём более, так что я хз о чём вы думаете.
sn0w, вагон и маленькая тележка Например SetProcessMitigationPolicy(ProcessDynamicCodePolicy + etc) + appcontainer и привет с твоими шеллкодами, ipc (тут конечно можно разрулить, но не тривиально). Возможны ропы конечно, но с ними много не навоююшь. Хотя заинжектиться ты сможешь (но тоже есть свои лулзы - в какой момент времени работы апп), но про сплайсы ты забудешь, а без этого и смысла нету лезть в фф =) Год два и все браузеры будут работать так (я про фф и хром). Когда они с джитом решат правда, там им надо испоняемую выделять.
