Чего их искать. dll в памяти будет одним куском. Когда IP туда
попадёт, то вот и оно.
Оно то оно. Но в случае влинковки DLL в
приложение, оно будет достаточно
виртуализировано, что бы двумя
проходами попасть в нужный кусок кода.
Да и сам код будет несколько "другим"...
Виртуализирован только небольшой процент
всего кода и возможно точки входа в длл.
Идея атаки состоит в использовании знании
о внутренних функциях dll, не подверженных
по объективным причинам защитой виртуализации.
Говорю по опыту: это дает достаточно мало.
Потому что:
1. Нужно прорваться через загрузчик.
2. Определить, где же находиться код DLL. Поиск по сигнатурам скорее
всего ничего не даст...
3. Таки найти нужную функцию. Это уже попроще, если найдешь, из какой VM
она вызвана...
4. Добиться реального выполнения кода под точкой останова...
Решить все эти задачи достаточно трудоемко. Проще поэтапно снять защиту,
и только потом отлавливать PDB.
Речь была не про виртуализацию, а про
замусоривание невиртуализоваронного кода.
Проблема в том, что код не просто замусоривается, но еще и крадется...
И местами мутирует...
Причём без потерь в производительности.
Такое конечно возможно в принципе, но для
этого минимум нужна перелинковка всего приложения.
Ну и в крайнем случае степень полиморфизма
замусоривания крайне низкая.
Вот эту мысль я не понял вообще...
Есть желание - скомпили какой-нить
"hello word" и защити триальным ASP или
фемидой. Начать рекомендую с ASP - у него
немного проще загрузчик.
Это совсем другое. У нас на столе dll почти 2мега
кода и многмегабайтное приложение на дельфи набитое
очевидными сигнатурами в коде и данных.
Хм. А как еще можно исследовать защиту? Сразу на реальном
приложении - так это сильно много времени уйдет...
Про injection code почитать можно много
где...
Если надо найти тело жирной функции, то это
сильно не помешает.
Опять не понял...
Короче, код не под ВМ элементарно уязвим.
Такого кода очень мало...
Такого кода 95%, как признавался оппонент.
Это Олег погорячился :-)
--
--
WBR, Jerry
