Всех приветствую. Меня терзает один вопрос, связанный с тем, что антивирусы не ловят выделение+исполнение исполняемой памяти. По логике это узкое горлышко бутылки для вредоноса. Без выделения памяти замаскировать файл намного сложнее (речь идёт о пакере), т.к. придётся резервировать место под образ в одной из секций выходного файла пакера (иначе как ещё загрузить образ-начинку?). Противодействие запуску writeable-памяти (или записи в executable-память, вопрос терминологии) было бы сильным средством борьбы с малварью. В iOS так давно уже сделано, а в винде - как можно было выделять и запускать шеллкод, так и сейчас можно (в целом), и антивирусы на это не ругаются. Какую гипотезу я строю из рассуждений выше? Вероятно, слишком много легального софта выделяет исполняемую память (сложилось исторически). Настолько много, что подобные детекты давали бы неприемлемо много false-алертов. Как я мог бы это проверить? Например, написать драйвер, перехватывающий выделение исполняемой памяти и собирающий человекопонятную статистику. Но при детальном рассмотрении оказывается, что задача нетривиальна: может быть много вариантов - к примеру, сначала выделение writeable, запись, потом NtVirtualProtect чтобы сделать executable; или в другом порядке (т.е. нужно вставать с дивана) Поэтому я решил спросить совета у гуру перед тем, как что-то песать Как часто легальный софт использует выделение исполняемой памяти и зачем? К примеру, в голову приходит JIT-компилятор, а ещё?
Для оптимизации многопоточки пид может использовать свое пространство (всякие экзотические нити) и им требуются свои стеки, в том числе исполняемые. Сперва стоит посмотреть в эту сторону, что бы понять нежелание аверов. Ведь аверы и так слушают сетевые сокеты и сисколы.
COM, MFC, ATL во всю используют выделение исполняемой памяти для прокси-интерфейсов и обработчиков оконных сообщений. А детектов на них нет, потому что они подписаны.
Я поищу сам, но если скинешь наводку где искать - буду благодарен Так всё таки может не потому, что подписаны, а потому, что выделение исполняемой памяти на винде антивирусами не детектится (из-за слишком большой распространенности этой операции среди легальных программ) ?
как можно перехватывать в ядре выделение исполняемой памяти у user mode процессов? да и вообще перехватывать в ядре выделение исполняемой памяти в ядре тоже невозможно. иначе будет зацикливание. для любого перехвата надо выделить память для "мостика" которая должна быть execute и read. --- Сообщение объединено, 25 апр 2023 --- представь что ты перехватил выделение памяти для исполнения. что у тебя будет при перехвате?: - запрашиваемый размер; - id текущего процесса; - id текущего фреда; все. даже заполненой памяти не будет. она будет в нулях например. и что? надо перехватить RtlCopyMemory что бы понять что там зальется? а если память скопируется своей какойто другой функцией mycopymemory? и т.п. вопросов слишком много что бы както автоматизировать защиту с этим связяанную.
Снять флаг PAGE_EXECUTE и выловить исключение, которое возникнет при попытке передать туда управление. В этот момент в памяти все что надо уже будет.
H0: предположить, что программ с(без) rwx больше\меньше чем без(с) rwx. Продумать опровержение, задав размер ошибок ложноположительных и ложноотрицательных. Т.е. говоришь примерно так: если в пяти случаев из ста в программах взятых из топ100 по популярности встречаются софтины без(с) rwx, значит .... после этого взять набор софта и открыть в ghidra, далее memory map , посмотреть процент, посчитать, сверить с ранее высказанным, профит. но вообще просто дело в скорости софта. каждое падение флага и последующий анализ выборки - это слишком большой оверхед. Причем этот анализ еще придумать сперва надо, что б он осмысленный был.
ну, вот сам посуди - пашет виртуалка и на каждом шаге ловить выделение исполняемой памяти + для работы песочниц тоже нужна такая же фича + анти-дебаг.
флуд, конешно, но без костылей памяти тут было бы ниасилить, но, второе но (тоесть уже третье!) - ссылка на бешенного фаната перл и товарища могущего с лулзоме опейсать чо там в Diff to binary trace показовает для нубов типо трещгена - утеряна. возможно там ща всё не по русзке, а такое мы не читаем!
С чего вы решили, что аверы не реагируют на RWX память? как раз таки это триггер для них. просто тестить надо на реальных кейсах, а не выделил память и раз не спалило, то аверы тупые.. и в винде без аверов много чего будет, например ACG
Не реагировали 10 лет назад, не реагируют сейчас, это подтверждается тем фактом, что малварь как грузила payload-образ через VirtualAlloc так и грузит сейчас. Триггером это может быть только в том смысле, что добавит "баллов" для детекта Да, это оно самое. Штатный механизм винды для блокировки доступа к исполняемой памяти SetProcessMitigationPolicy(ProcessDynamicCodePolicy) но этот механизм направлен не на противодействие запуску запакованных ЕХЕ, а противодействию работе шеллкодов в процессе браузера и против неизвестных бинарников, насколько я понимаю, не применяется Соответственно, интересно, реально ли для винды, имея ввиду всё её наследие (софт и кодовая база) когда-нибудь запретить выделять исполняемую память по умолчанию?
x0rum, а сендбоксы по вашему для чего нужны? оставьте "всё ее наследие (софт и кодовая база)" коллекционерам. сериализация горячих плагинов, вот вам и запаковка, вот вам и исполняемый код.
Твоя защита не работает (один из частых вызовов шелкода): PVOID pShellcode = LocalAlloc(LPTR, 100); //выделили память if (pShellcode) { MyZeroMemory(pShellcode,100); Sleep(10 * rndms); MyFillRndMemory(pShellcode,100); Sleep(10 * rndms); DWORD oldp=0; if (VirtualProtect(pShellcode,100,PAGE_EXECUTE_READWRITE,oldp)) //подправили { Sleep(10 * rndms); //поспали MyCopyMemory(pShellcode,100,pShellcodebytes); INT (WINAPI*pfunc)() = pShellcode; INT ret = pfunc(); //вызвали получили ответ MyFillRndMemory(pShellcode,100); //перемешали VirtualProtect(pShellcode,100,oldp,PAGE_READ_WRITE); //востановили LocalFree(pShellcode).//и забыли } } --- Сообщение объединено, 27 апр 2023 --- не сработает* на такой код (один из оригинальных вызовов шелкода):
Если антивирус делали дебилы, то может и не сработать при таких очевидных уловках. Если перехватывать любые изменения флагов доступа к памяти и корректно их обрабатывать, то сработает. Любая проактивка еще со времен царя гороха как минимум на подмене обработчиков в SDT работала и все эти юзермодные штучки хоронила. --- Сообщение объединено, 27 апр 2023 --- ЗЫ: банальщина, но может я непонятно написал. Можно снимать PAGE_EXECUTE и не давать его установить, запоминая например попытки этот флаг выставить. В обработчике исключения при попытке передать туда управление сканировать память и если содержимое законно, устанавливать PAGE_EXECUTE, снимать PAGE_READWRITE и ловить уже попытки изменения, а там снова снимать PAGE_EXECUTE. По производительности это жонглирование флагами не должно сильно ударить.
Спасибо за ответы! Не совсем понятно что за механизм имеется ввиду в этом утверждении. Я ещё механизма не предлагал. Думаю,для начала можно отлавливать NtAllocateVirtualMemory с флагами PAGE_EXECUTE_*** И ЕЩЁ NtProtectVirtualMemory, с аналогичными флагами (если память выделели НЕ как исполняемую, а делее сделали исполняемой). Вы, кажется, уже имеете ввиду механизм, который отлавливает именно запуск Отлавливать конкретно запуск исполняемой памяти - сомнительная вещь, как мне кажется. Вобщем, ребят, вы решили, что обязательно нужно делать отлавливание непосредственно исполнения. А я только предлагал выделение И смена флагов доступа (NtProtectVirtualMemory) Ловить исполнение - это специфическая задача и она, кажется, выходит рамки этого небольшого исследования. Начиная отсюда ничего не понял, выражайтесь яснее. Память можно выделить заранее, и использовать её в дальнейшем. Так что вы сейчас из-за собственного незнания сделали далекоидущие выводы и высказали их в дерзкой форме. Догадываюсь, что вы ещё очень юный) Спасибо за ответ. Но тут как-то не складывается. Следуя вашей схеме: предполагаем, что программ, выделяющих исполняемую память меньше (их на самом деле меньше, т.к. исполняемая память - это либо грязный хак, либо специфический механизм типа jit-компилятора). Предположили. Придумываем опровержение: нет, выделяющих исполняемую память программ больше. Это очевидный абсурд. Я всю жизнь смотрю программы и из них 0.01% выделяет исполняемую память. Что-то не клеится. TrashGen Как я уже сказал выше, ловить именно исполнение памяти я не предлагал. Это было у меня только где-то в перспективе как вариант. Это вероятно сложно и не нужно. К сожалению не понял что ты имеешь ввиду. Какая виртуалка...? Спасибо за совет!) Сделал две вин10 вм, заразил лоадером и ещё какой-то хренью. Где смотреть результаты, которые меня удивят?
на компе может работать куча виртуалок и каждая выделяет исполняемую память. virustotal, к примеру. у тебя собс-но какие претензии к защитам? ещё, стоит отметить, что вм-ки не из самых лучших тестовых площадок в твоём случае. Пч вынь сечёт вм-ку и работает в пониженном режиме защиты.
