Добрый день! Есть программа, работающая под windows (r3), исходников её у меня нет. Мне нужно научиться узнавать, что в неё пытается совершить инжект другая программа, тоже работающая под r3. Она может делать это затем, чтобы узнать, какие winapi вызывает первая программа и с какими параметрами. Мне важно узнать, что такая попытка была. Собственно, нужен код (желательно делфи, но в принципе любой язык можно, если оно соберётся в .dll), который мог бы детектить любые такие попытки перехвата вызываемых api.
вnagva27, Можно реализовать механизмы, которые позволят обнаружить локальный инжект - изменения в памяти етц. Но оно обычно делается удалённо, из другого процесса. Поэтому никакой нотификации не будет, кроме штатных методов - запуска потоков. Память может быть изменена из другого процесса, тоесть через ядро. Может даже быть захвачен и изменён контекст потока. Что бы такое обнаружить можно использовать два способа - при изменении памяти по таймеру выполнять проверку целостности, а эта весьма сложная задача, так как захватить код можно без изменения статик памяти(кода), проверку переменных выполнить невозможно, либо визоры. Обнаружить изменение контекста - так же сложная задача. Можно создать поток - ловушку и проверять его. Но если инжектор реализован грамотно вы ничего не обнаружите. Так как методы детекта учитываются при имплементации инжекта, вы же не думаете что это пилят совсем глупые и не знают возможных методов детекта ? По факту вы хотите универсальное решение, которое невозможно, да есчо и в юм. Эта задача не решаема в принципе. Но можно создать костыль - фильтр, который будет мониторить потоки, в самом сложном случае это подтверждать локальную выборку данных(нужен визор) и по таймеру проверять целостность образов. Смысла в этом нет, это обходится после прочтения этой темы или отладки такой защиты за минуты.
если программа которая делает инжект работает в r3, можно делаеть детект вызова функок: *OpenProcess, без этих фунок инжекта не может быть, если не учитовать dll hijacking.
nagva27, а начиная с какой версии Windows требуется совместимость? Например на Windows 8.1 и выше можно запретить выделять исполняемую память (посредством SetProcessMitigationPolicy).
jupman, Хорошая фича, да. Вот только можно спроецировать файловую секцию, так и происходит системная загрузка после запрета на аллокацию E памяти. Прямо заинжектить модуль с диска. Иначе бы подгрузка либ была бы невозможна
vx1d, это очень интересно! Indy_, можете согласиться с тем, что любой инжект в r3, кроме dll hijacking, подразумевает вызов openProcess?
nagva27, Но открытие процесса не означает что будет выполнен инжект. В таком случае нужно как то обнаружить событие открытия в чужом процессе.
Indy_, имеете в виду, что мой процесс может "открыть" кто-то с помощью openProcess, чтобы просто посмотреть, как там дела? Ну наверное такое бывает, но очень редко и можно считать, что не бывает такого.
nagva27, Инжектиться во все процессы не получится, далее это вредоносная активность, а не защита. Ну и нет гарантий что получится отследить открытие процесса.
Видос для другой темы, но думаю для этой тоже годится, что бы показать бесперспективность попыток какого либо детекта. Никаких изменений памяти нет. Модуля даже не исполняются в данном случае https://yadi.sk/i/jaRS5EFT3KF38d
Примерная модель защиты. Приложение взято под визор. Всё АП не исполняемо, за исключением кодовой секции нтдлл(из за Ki-ядерных векторов). В таком случае инжект принципиально невозможен - удалённая аллокация памяти и исполнение в ней или же сетконтекст при первом вызове любой апи или вообще любого кода приведёт к фолту и запуску визора, таким образом инжектированный код так же будет взят под монитор(визор). Может быть локальная уязвимость - выполнение кода через внутренние вызовы визора, примеру вызов нтапи может привести к передаче управления на произвольный код. Для блокировки этого необходима блокировка секции нтдлл от записи. Тогда возможен безопасный вызов нтапи. Прочий ртл должен вызываться через рекурсивны запуск визора, так как АП не исполняемо. Через подобный механизм может быть реализована универсальная защита от OP(ROP/COP - это тоже инжект). Защита от ROP сводится к связыванию Call-ret(CET) и проверке на RET валидного адреса возврата(который формируется при каждом call'е под визором). Для COP валидация возможна только по целостности потока данных(DFG), это можно расширить и на ROP. В этих двух случаях будет получено управление при инжекте и сам факт инжекта, в первом случае - передача управления(срабатывание ловушки - запуск визора) без предшествующего вызова, во втором случае - нарушение DFG, но тут сложность с его валидацией.. В конечном итоге всё упирается в профайл визора. При пакетном исполнении(по блочно) профайл падает в три раза, но это при не оптимальной раскодировке инструкций.
nagva27, Indy_, мож в коллбэках ловить новые потоки (имхо просто перехват апи без шекодов и потоков вряд ли производится)? я писал 100 лет назад еще на руткитсах выкладывал (свой -чужой поток как отследить). А сам факт инжекта - да, отдельный дебаг процесс для "чтобы узнать, какие winapi вызывает первая программа и с какими параметрами". Сорри с экранной клавы фигово писать, сделайте в итоге свой отлаживающий процесс, никто к отлаживаемому не сможет прицепиться.
0xC3, Модель описанная выше весьма продуманна. Остальные же способы - элементарно обходятся. Так если всё АП не исполняемо, то аллокация памяти удалённо и передача на неё управления любым способом - захват контекста рабочего потока например(setcontext) приведёт к передаче управления на NX память, либо на впрыснутый регион памяти, откуда ничего не возможно вызвать без запуска визора(так как АП не исполняемо). Что далее приведёт в первом случае к прямому срабатыванию ловушки, во втором случае код отработает некоторое время и обратиться к апи, что так же приведёт к срабатыванию ловушки. Более того, в старших версиях системы можно отключить аллокацию исполняемой памяти(ислючая образы).
Indy_, Согласен про стэк, не пойму фразу: "Более того, в старших версиях системы можно отключить аллокацию исполняемой памяти(ислючая образы)."
neutronion_old_school, ТЗ не соотвествует имеющимся технологиям(нет механизмов защиты для решения задачи тс), поэтому нужна разработка совершенно новых техник и про код тут речи не идёт.
