On Mon, 16 Oct 2006 15:52:31 +0300, Alexey Popov wrote:
1. Нужно прорваться через загрузчик.
А зачем? Аттачимся с процессу уже в работе. Вариант
с драйверами пока не рассмативаем.
Даже если вариант с драйвером не рассматривать.
Аттач к процессу во время работы даст еще меньше, так как
нужные куски создания кода VM будут уже зашифрованы, а
прорываться через полученные в результате мутирующие VM еще
сложнее.
2. Определить, где же находиться код DLL. Поиск по сигнатурам скорее
всего ничего не даст...
Поиск по сигнатурам - это только один из методов. Не верю что он
может не работать. Например, dll всегда использует какие до константные
данные, строки и прочее.
Тот же поиск, но по сигнатурам данных.
Данные лежат в сегменте данных...
Протектор мало того, что приводит их в нечитабельный вид,
так его загрузчик еще и размазывает все это добро по памяти.
В результате возвращаемся к п.1
Проблема в том, что код не просто замусоривается, но еще и
крадется...
Красть байты реально очень трудно ибо надо быть уверенным
что прога будет работать корректно. Обычно из ОЕП крадут.
В других случаях надо мощно анализировать код, чтобы быть
уверенным что прога не слетит.
Реально они крадутся. Например в исходном было так:
FF1518D35500 call DWORD PTR DS:[EDI] ; kernel32.getstdhandle
83C8FF or EAX, FFFFFFFF
E95C0F0000 jmp 00F905000
83C0F5 add EAX, F0
в расшифрованном дампе:
E8F346D000 call 00568451 ; А это вызов kernel32.getstdhandle
посредством VM
10A574DF0D11 adc BYTE PRT SS:[EBP+74DF0D11]
33EF xor EBP,EDI
CC int 3
83C0F5 add EDX, F0
Как видишь, байт-длинна команд совпадает.
Но реально командны другие...
А все потому, что or EAX, FFFFFFFF и JMP
протектор выполнил где-то в недрах функции 00568451. А недра у
нее мутируют. К тому же RET из нее вышел на десяток байт позже.
Причём без потерь в производительности.
Такое конечно возможно в принципе, но для
этого минимум нужна перелинковка всего приложения.
Ну и в крайнем случае степень полиморфизма
замусоривания крайне низкая.
Вот эту мысль я не понял вообще...
Мысль в том, что без цепочки:
декомпиция->защита->компиляция->линковка
замылить код большой и жирной функции нереально.
Вполне реально. Взлом на оборот...
Особенно если протектор заточен под определенный компилятор :-)
А они заточены :-)
Хм. А как еще можно исследовать защиту? Сразу на реальном
приложении - так это сильно много времени уйдет...
Метод взлома использует не снятие защиты а уязвимые места
конкретного хорошо известного приложения.
Попасть в эти уязвимые места трудно. Проще снять защиту.
--
WBR, Jerry
