запрет в приложенни remotethread, openprocess

Не плохой метод. Правда мне он не подходит, я использую много сторонних библиотек - для этого мне придется мониторить выделение удаление обращение к памяти - а это почти не реально.

Нужно подумать что это дает в итоге и что можно сделать...

 

это именно особенность... вспоминаем csrss.exe - он и удаленные потоки создает и пишет в чужую виртуальную память, насколько я помню... (поправьте, если я ошибаюсь)

какой же? приведите пример, а я вам скажу, как его обойти))

 

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

 

Можно!
Перехватываем LoadLibraryExW (ну если не достаточно LdrLoadDll) - и загрузка dll в ваш процесс у вас в кармане. Только не нужно набрасываться с наивными (я могу снять твой перехват, я могу задебагить твой процесс - от такого многих атак такого рода не сложно придумать защиту. т.е. получается защита для защиты - тем не менее работает).

Лоадер - да конечно этот метод не спасет от лоадера - но ведь на сколько я помню для этого нужно записать к нам в память WriteProcessMemory - собсно от этого то и хочу защититься на протяжении всего топика

Ну тада моя программа уже сама будет работать не корректно\сбоить. А может сразу в WinMain поставить такой код?

Код (Text):

1. VOID p = NULL;
2. delete p;

Блин а это идея - сразу защита от всего! )

 

Блин язык уже заплетается... гыыы

 

Выше написал, спасибо не нада - сам знаю лучше скажите как от этого защититься!

 

мдэ, ринг0, а вы пишете про ринг3 функцию не хорошо...

это аргументы? или очередной бред

 

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

 

от последнего защищаться только в ядре, и я если честно сам не знаю как)))

 

зачем инжект, ведь вирус может просто пропатчить ехе на диске. на ep поставит jmp на свой код
и таким способом подгрузить свою длл, еще до вызова winmain)

 

по сути все то что сказал Rel

 

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

 

или же в IAT добавить свою длл)

 

У меня две мысли прочитав фразу выше:
1) Это какая то кодировка...
2) Разговор опять зашел о Ring0?
Извините, spa,но смысла я не нашел, потрудитесь объяснить подробнее.

В общем то это было предположение с моей стороны - а вы думаете по другому?
Мне просто интерестно как так получается - памяти я не вижу, но в тоже время я ее использую.
Я бы выразился вашей фразой:

Вот здесь - полностью согласен!

 

Для этого существует подпись exe.
ну можно еще что нить придумать чтобы гарантировать целостность файла

 

Вот вот... можно подробнее.
По моему опять - WriteProcessMemory (внедряется базонезависимый шелл-код).

 

все равно,я думаю если целевой ехе попадет в руки вирмейкеру для анализа.
"вся защита" потеряет свою актуальность.имхо

 

Да и еще как вы заставите мой процесс сделать то о чем вы говорите - это оч. важно!

 

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

да... подписи, контрольные суммы, хеши... многое можно придумать, чтобы это обойти...

 

Я с этим не спорю. Эта проблема щита и меча. Выходит если у меня слабый щит - значит он не нужен вовсе?
Просто усиливая качество защиты вы повышаете стоимость взлома!