Это значит, что такой антивирус будет никак не изменить. В том числе и не обновить. Да? А если его не обновить (базы) то зачем он вообще?
Ересь какаято особенно: и собственно апогей Тоесть что получается, что есть отдельный модуль который будет изменять в динамике не вреданосный модуль чтоб тот стал вреданосным (собственно этот код и будет нужно детектить и накких проблем в этом не наблюдется). Дальше, изменив или подменив стек, мы не сможем добится нужного функционала когда нужные команды находятся в серединах процедур подопытной программы из которой будет выход после того как исполнытся еще 20 процедур, тоесть вообще не понятно как подменив стек можна заставить калькулятор (в котором не имеется вообще функционала работы с файлами реестром) завтавить выполнять какойто нужный мне функционал. Имхо стотья просто или не полная, или через задницу переведенная и лешенная смысла, но описаную технологию (с тем описанием что предоставлен в статье) какнибудь понять суть работы нереально.
Возвратно-ориентированное программирование подразумевает под собой наличие большой "ленты" в стэке с адресами возврата и различными параметрами. Я вижу целесообразность применения этой концепции разве что с переполнением буфера, где можно с перезаписью ret-адреса записать еще много полезной инфы(вот как раз эту "ленту"), да и Шахэм видимо тоже подразумевал именно такое использование. Вообще, главной идеей было обойтись без выполнения кода в стэке (обойти W^X). Почему это назвали "новой технологией написания вирусов", я не понимаю. Можно конечно применить эту технику и в вирусах с целью обмана антивируса, но тогда придётся таскать с собой код, который ищет эти последовательности в системных библиотеках и создаёт стэковую "ленту", что уже само по себе палевно.
статья на securitylab действительно тупая. а сама технология более чем понятна, если почитать английские доки от её авторов. но моё мнение, практически это применять никто не будет. хотя кто знает... по крайней мере это выглядит более реально, чем bluepill
Или это я буксую или хз но допустим -> есть у меня засуспендженый код в калькуляторе на какойто промежуточной внутренней процедуре к примеру вот дальше идущий код Код (Text): 00401769 POP ECX 0040176A OR DWORD PTR DS:[4031BC],FFFFFFFF 00401771 OR DWORD PTR DS:[4031C0],FFFFFFFF 00401778 CALL DWORD PTR DS:[<&MSVCRT.__p__fmode>] ; msvcrt.__p__fmode 0040177E MOV ECX,DWORD PTR DS:[4031B0] 00401784 MOV DWORD PTR DS:[EAX],ECX 00401786 CALL DWORD PTR DS:[<&MSVCRT.__p__commode>; msvcrt.__p__commode 0040178C MOV ECX,DWORD PTR DS:[4031AC] 00401792 MOV DWORD PTR DS:[EAX],ECX 00401794 MOV EAX,DWORD PTR DS:[<&MSVCRT._adjust_f> 00401799 MOV EAX,DWORD PTR DS:[EAX] 0040179B MOV DWORD PTR DS:[4031B8],EAX 004017A0 CALL Copy_of_.004018BB 004017A5 CMP DWORD PTR DS:[4030D0],EBX 004017AB JNZ SHORT Copy_of_.004017B9 Ну могу я перезатереть дальше идущий стек и мне надо выполныть допустим команды по адресам 00401769 POP ECX 0040176A OR DWORD PTR DS:[4031BC],FFFFFFFF слудующие не нужны, как простой подменой стека я могу добится нужного мне полного функционала. притом даже если заменить весь стек и поместить туда нужные аргументы для дальнейших выполнений чисто системных функций, тоесть разместить нужные аргументы и адреса возвратов, всеравно нельзя получить функционал не анализируя результаты выполнения функций, а этого простым подменой стека не добится.
PaCHER В общих словах, речь идет о том, что программа уже содержит в себе необходимый функционал, а вредный код его подругому ипользует, вызывая уже имеющиеся функции со своими параметрами. Вредный код получается заточенным на определенный продукт. Защита от него, создание внутреннего кода, проверяющего целостность и корректность программы изнутри.
Ну тогда идея бредовая, т.к. каждая софтина которая делает какието опирации с инетом с почтой и.т.д. может иметь свои прототипы функций. И всеравно идея "заражения" это уже не заражение, т.к. у насть есть отдельный модуль который должен подменять стек, нахрена подменять стек когда он может из себя исполнить нужный функционал.
Это наверно для сплоитов. Для обхода защиты от исполнения кода в стеке. Типа переписать адрес возврата на UrlDownloadToFile, следующий на WinExec...
угу, всебы хороще, но вот только чтоб узнать адреса функций их нужно найти, а искать их должен код который будет исполнятся и под полную концепцию отсутствия вредоносного кода опять не подходит.
Freeman Нифига себе симбиоз. Чистейший паразитизм. K10 В условиях отсутствия рандомизации можно попробовать ещё предсказать адреса на основе предположений о версиях библиотек, но вот выполнить что-то типа UrlDownloadToFile или WinExec не получится, т.к. нужно знать адреса-параметры строк, например. Судя по заявлению а-ля "всё в стэке" предсказать адреса строк (если их класть в стэк из эксплоита) нереально. Всё равно понадобится исполнение своего кода в том или ином виде. Эти эксплоиты рассчитаны на исполнение их кода в стэке.
Еще дос вспомни статья то 2008 года а не 2000. Получится очередной генератор крешей со статическими адресами, а несколько статических адресов по условию задачи быть не может, чобствено так и останется очередное голой идеей с 15% вероятностью работоспособности.
Техника баян. Тут однажды была тема о подобном, предлагалось для поиска использовать сигнатуры, наподобии того как это делает ида. Я посмеялся, может быть зря.
