кто-нибудь ломал VMProtect

kaspersky также как и ТСС , я сказал про одно , а вы выдрали куски и рассказываете о своем ... но это ваше дело. Меня удивляет другое .. ну да вообщем то ладно...

 

je_

Давайте только не будем в теме "кто-нибудь ломал VMProtect" заботиться о наших кастомерах )

 

Vam

Думаю ты прекрасно понимаешь, что по-хорошему весь разбор виртуализованного кода должен происходить в статике (т.е. задал пару ключевых адресов и вперед и без трейса в отладчике), хотя и ежу понятно, что это сложнее написать.

_je
Что-то тебя в сторону немного повело.

 

Почему в статике? Чем динамика не нравится? Ветвление кода выполняется только через условные операторы, и если условный оператор пропускает этот код, то можно сохранить состояние BM, выполнить "пропущенный" код, восстановить состояние ВМ и продолжить анализ далее.

Сложнее в чём? Реальные значения в регистрах помогают человеку осмыслить виртуализацию, для декомпилятора они никакой роли не играют.

 

kioresk, вы правы!
с авторами-продавцами не стоит спорить о правде

есть вопросы!?

 

Vam

Ну хотябы потому что, условия для ветвлений могут зависеть от фазы луны например. В динамике вы восстановите ветку только для определенного состояния программы и не факт что при следующем запуске программы состояние фаз луны сойдется с тем, что вы восстановили.

 

dermatolog
Можно сделать трейсер/эмулятор с откатом состояний, и потом обходить граф выполнения полностью.

 

TSS
Дык ветка при "левом" состоянии будет просто неработоспособна и дальше первого эксепшена эмулятор навряд-ли пройдет.

 

Да какая разница от чего зависят условия ветвления, после ветвления есть только два пути, линейное продолжение или переход, любой переход в динамике игнорируется и продолжается прямой путь. Условный переход может быть трех типов:
1. Обратный (цикл), на уже проэмулированный код, неинтересен, ничего дополнительно делать не надо. 2. Прямой с выходом на него линейного продолжения (if). Состояние ВМ можно сохранить, а при достижение адреса перехода восстановить, а можно ничего не делать в зависимости от того по какому пути идет эмуляция.
3. Прямой с обходом его линейным продолжением (if...else). Состояние ВМ на точке if сохраняется, а на точке else восстанавливается.
Конечно, возможны и частные случаи - окончание работы ВМ на любой ветке, здесь помогает сохранение/восстановление состояния и продолжение работы ВМ.
Следуя этим принципам любые, даже самые запутанные ветвления, эмулируются правильно.
Теперь ответ, почему динамика, а не статика. Для декомпиляции asm кода требуется эмуляция стека для правильного распознавания вызова функций и их аргументов, а для ВМ машины тем более, т.к. они большей частью стековые. Здесь главную роль играют операции со стеком, а не само числовое значение каких-либо регистров или ячеек памяти. Таким образом динамическая эмуляция за один проход приведет к желаемому результату.

 

Исключение в эмуляторе - это что-то новенькое, на то он и эмулятор, чтобы управлять исключениями. Но если в нем есть ошибка, то да, будет и исключение.

 

dermatolog твой декомпилятор как построен ? особенности ?

 

dermatolog
Дык будет стек состояний, и после эксепшена эмулятор просто вернется на начало ветки, восстановив констекст на тот момент времени.

 

контекст*

 

TSS
А кто сказал что состояния будут устанавливаться/меняться в контексте ВМ? Это могут быть глобальные переменные, инициализированные самой программой и использующие эти предикаты в своих алгоритмах.

 

Ну это щит и меч, защита может быть какой угодно, зависит от фантазии разработчика, так же и со стороны взломщика, можно использовать комплексный подход, динамический и статический, смотреть частоту вызовов блоков, можно вобще перевести весь защищенный код в псевдокод и затем прогнать через оптимизирующий компилятор, думаю стековые ВМ после такого будут несколько быстрее поддаваться анализу ^^

 

TSS
> Я спорю. Не может виртуализированный код работать
> быстрее чем нативный, ну никак.
почему не может? аргументы в студию. если у VM средняя длина команд значительно меньше, чем у натива, то мы _уже_ имеем шансы выиграть в скорости за счет "сжатия" кода. дальше продолжать? вы никогда не писали на ассемблере программ, представляющих собой последовательность адресов микро-функций? таблицы переходов это уже не машинный код, хотя выборка из них, конечно, осуществляется не святым духом. а всякие машины состояний опять-таки представляют собой смесь команд и данных, причем данных там больше чем команд а нативного кода ну очень мало.

calidus
> я сказал про одно , а вы выдрали куски и рассказываете о своем...
> но это ваше дело. Меня удивляет другое ..
если честно, я не понял, о чем вы рассказали.... потому и удивился не меньше вашего

 

крис, а причем тут это? Ну допустим на каждую инструкцию нативкода приходится на 1 байт меньше, чем в обычном коде. При этом каждый обработчик каждой инструкции содержит десятки, если не сотни операций. КАК такой код будет быстрее??? за счет чего???

 

kaspersky

Мы имеем шансы лишь увидеть более компактный байт код, чем нативный аналог, но байткод ктото должен еще перевести в инструкции понятные процессору, и этот ктото обычно обработчик ВМ, который сам занимает более чем 1 инструкцию, именно поэтому "быстрее" никак не получиться.

Ну предположим заменили мы 1 и более инструкции на адрес в коде где они содержаться, и так для всего файла.
Т.е. буквально у нас получилось некое подобие команды switch:

Код (Text):

1. mov     cl, byte_xxxxxxxx[reg]
2. jmp     off_yyyyyyyy[ecx*4]
3. ...
4. xxxxxxxx     db      0,     1,     2,     1
5. ...
6. yyyyyyy     VM_block1, VM_block2, VM_block3
7. ....

В итоге, этот наш цикл выборки будет жрать времени выполнения больше, чем нативный аналог.

Поэтому Крис, вы меня не убедили

 

канешн!

если бы так, то ведь сами процессорры/компилеры стали бы виртуализовать.. ый

 

MSoft
TSS
+1
Сам хотел написать, но решил сначала поискт ьв гугле ,может и правда где есть чудо ВМ. Но по логике вещей такой быть не может. А самое главное нету её реализации, давно уже пора в вопросах скорости перестать смотреть на теорию.