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

Собственно M$ давно вынашивала идею разорвать секретную договорённость с Intel (M$ специально делает тормозные программы, требующие мощных процессоров, стимулируя их продажи). Появление виртуальных машин нового поколения, позволяющих создавать программы которые по занимаемому размеру и скорости работы на 2-3 порядка превосходят тщательно оптимизированные программы на обычном ассемблере сделало возможной реализацию этой мечты M$. Собственно идея такой ВМ далеко не нова - например в ZX Spectrum подобная ВМ занимала всего 16кб, размещалась в ПЗУ и была замаскирована под бейсик. Это позволяло полноценному векторному графическому редактору ArtStudio уместиться в 48кб ОЗУ и быстро отрисовывать графические объекты на процессоре с частотой 3,5МГц. Современные версии AutoCad, CorelDraw и т.п. едва управляются с этими задачами используя ххГГц процессоры, поскольку не имеют подобных виртуальных машин. Но реализовать такую ВМ на Intel платформе у M$ долго не получалось - процесс сдвинулся с мёртвой точки только после привлечения свежих сил из Индии.
Но M$ прекрасно понимала, что подобный ход может вызвать ответную реакцию со стороны производителей процессоров вплоть до полного саботажа в их производстве. Поэтому разработка ВМ была строго засекречена: для отвода глаз ключевая идея ВМ - байт-код была тщательно опошлена выпуском NET платформы. Также для прикрытия от имени программистов из Индии (ключевых исполнителей идеи ВМ) массово выпускался код, написанный американскими студентами первого курса. Параллельно M$ в обстановке строжайшей секретности скупала (не брезгуя и пунктами сбора мусора) морально устаревшие компьютеры - ведь для программ, рассчитанных на такую ВМ глубоко фиолетово на чём исполняться на 386 или на Core 2. Наконец нужное количество компьютеров (чтобы не зависеть от их производителей) накоплено и главное - завершена работа над Бейсиком, полностью основанном на новой ВМ. Поэтому и слухи о новом поколении ВМ начали просачиваться за стены секретных лабораторий. Теперь на этом бейсике будет легко и быстро написана новая ось - windows 13, которая заменит win 7 и в 2013 году будет представлена почтенной публике.

 

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

 

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

 

SPA
> Обьясните мне на пальцах как ВМ может работать быстрее нативного кода.
> Ведь она его всеравно переводит в нативный.
это понятно, что код все равно будет нативным. вопрос в том будет ли он __КОДОМ__ и сколько там того кода будет, а сколько все-таки __ДАННЫХ__

не нужно путать ВМ с эмуляций PowerPC на x86.

таблицы переходов, которые строят компиляторы и табличные вычисления - это как бы микро-ВМ. и они, кстати, не зависят от проца на котором выполняются. С++ вообще использует кучу идей виртуализации

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

с другой стороны многие проекты содержат микро-вм, написанные для удобства портирования программы под другие платформы. и чем они не вм? тем что интегрированы в код, а не поставляются отдельно?

мы просто о разных вещах спорим. ну хорошо, ну вот вы же не будете спорить, что большую часть времени программа проводит в циклах? и если нам надо написать цикл который одинакого хорошо исполняется на разных процах, то его нужно планировать так, чтобы он отвечат требованиям оптимизации всех процов. чтобы хватало регистров там. чтобы скажем если один проц генерит исключение при переполнении, а другие нет, то это исключение не использовалось в программе, так же если один проц поддеживает данные аж до 128 бит, а другой только 8, то писать нужно так, чтобы этот самый виртуальный код можно было легко заменить одной инструкцией 128-битного проца или оптимизированной последовательностью быстрого сложния на 8 битах, которая автоматически выбирается на основе текущего значения аргумента. если аргумент умещается в 8 бит, то у нас всего одна инструкция. так же если еще и знака нет, то вобще можно выполнить беззнаковое сложение. а вот если у нас аргумент умещается в 10 бит, то можно использовать одну 8 битную инструкцию сложения + небольшую табличку.

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

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

 

kaspersky

А кто вам запрещает такие места (сложение 128-ми бит например) делать через некую inline функцию, которая уже будет сама выбирать оптимальный алгоритм сложения? Во всех остальных случаях (типа нам тут и 8-ми битов для сложения хватит) "затраты" на выяснение разрядности аргументов и результатов у вас будут на порядок больше чем количество тактов у ADD EAX,XXXX и ADD AL,XX.

Да да - Basic рулит )

 

dermatolog
> А кто вам запрещает такие места
> (сложение 128-ми бит например) делать через некую inline функцию,
статически такую функцию не сделать.
если делать функцию для знакового сложения 128 чисел, но как ее оптимизировать?! один из вариантов (есть, конечно, и другие) это использовать сам аргумент в качестве указателя на таблицу методов сложения. тогда если аргумент влезает в 8 бит - вызывается один метод, ну а если не влезает, то соотвественно другой.

ну и чем _такая_ реализация отличается от вм? мы же реализуем примитивную выборку. и она ускоряет программу.

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

кстати, когда сложный вычислительный код пишется на чистом си, то проблем с его портированием возникает больше, нежели, когда он пишется на примитивной виртуальной машине, сооруженой на том же си. особенно если мы не просто переносим программу между борландом и майкрософтом, а гоняем ее по всем процессорам от маленьких до больших. огромное кол-во умолчаний в си (для оптимизации) вынуждает (на чистом си) использовать приемы приводящие к тормозам в общем случае или риску, что на каком-то компиляторе программа выдаст неверный результат. вот только один пример. если нам достаточно char'а, мы все равно используем int, потому как при этом снимаются вопросы будет у нас знак или не будет и в общем случае компилятор обращается с int'ом более оптимизированно. на том же x86 char будет только тормозить (больше инструкций), а в памяти займет все равно столько же сколько и int (оптимизация). но это x86. а на другом ЦП может оказаться, что использование char'а дает существенную выгоду. и по любому мы приходим к тому, что на си писать программы... гм... конечно, можно и даже нужно, но вм так же имеют право на жизнь.

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

кстати, вопрос не в тему. кто видел упаковщики/протекторы под Win CE? или программы упакованные/запротекченные ими. коммерческие или фришные - без разницы.

 

kaspersky

Что-то я не понял - что значит как оптимизировать? Использовать команды из SSE наборов если процессор их поддерживает (на этапе инициализации программы смотрим на инфу из CPUID и пишем куда-нить что проц имеет SSE) - в принципе тоже самое будет делать и мегасупер пупер ВМ )

Да что ты так привязался к этим 8-ми битам то? У нас 32-х битные регистры и копаться в этом мусоре только ради того чтобы вместо ADD EAX.. получилось ADD AL... - выигрыша не будет никакого.

 

dermatolog
> Что-то я не понял - что значит как оптимизировать? Использовать
> команды из SSE наборов если процессор их поддерживает
а если не поддерживает? а тебе нужно быстро сложить два числа, которые программист поместил в ячейки памяти по 128 бит. а у тебя есть только 32х разряные нативные команды сложения. и если на входе стоят скажем числа 16 и 69, то достаточно только одной 32х команды. но ведь после сложения двух 32х чисел нельзя проверять флаг и делать ветвление - ибо это еще больший тормоз. поэтому лучше иметь разные реализации команды 128-сложения, которая в зависимости от значения аргументов прыгает на ту или иную последовательность команд. самый быстрый способ. быстрее пока не придумали. или я о нем не знаю.

> Да что ты так привязался к этим 8-ми битам то? У нас 32-х битные регистры
> и копаться в этом мусоре только ради того чтобы вместо ADD EAX.. получилось ADD AL...
какой такой AL? ты о чем? мы же не только про x86 говорим... а если еще вспомнить про тупо и остроконечников, то половина сишных програм ляжет сразу, т.к. использует нецензурный кастинг, а если писать по уму, то выборку двойного слова по char* указателю можно делать только если знать - нужно ли в данном конкретном случае соблюдать порядок байт или или нет. если данные гоняются внутри программы - то зачем его соблюдать? то на то и выйдет. а если программа считывает двоичный файл, то тут опа - типа вот к чему приводит кастинг а ВМ страхуют нас от подобных штучек.

 

Если нативный код выполняется медленнее функционально эквивалентного байт-кода, значит он не оптимизирован. Оптимизация, в частности, может привести к тому, что нативный код начнёт выглядеть как некая виртуальная машина, выполняющая некий байт-код. С этой точки зрения, когда вы пишете нативный код, вы делаете _специальную_ ВМ, выполняющую _специальный_ байт-код. Поэтому такой код всегда можно сделать быстрее "стандартного" байт-кода, который пишется для "стандартной" ВМ.

 

Хм - по моим наблюдениям как раз низкоуровневая оптимизация стирает всякое подобие ВМ, даже если оно сначала там было ) Другое дело то о чём пишет kaspersky - получить кросплатформенную оптимизацию (если таковая необходима) на ВМ действительно проще чем без неё, тем более что низкоуровневая оптимизация даже в рамках одной платформы от машины сильно зависит. И иногда действительно может получиться что ВМ за счёт кросплатформенной гибкости будет работать лучше.
"- Можно ли хреном перешибить дуб?
- Конечно можно, если хрен дубовый, а дуб хреновый."
© Армянское радио.

 

kaspersky
Вашу мысль понял, у вас ключевое слово написанных на си Ну даладно для себя я чтото отложил.

 

Y_Mur

Понятие ВМ весьма расплывчато. Вот kaspersky усматривает признаки ВМ в обычных косвенных вызовах, если я правильно понял.

Это да. Нативный код, в зависимости от степени "чужеродности" платформы, может изрядно тормозить вплоть 0, т.е. полной невозможности выполнения.
Понятие нативности вообще относительно. x86-код можно рассматривать как байт-код, переводимый в микрокод CPU VM.

 

Обсуждение плюсов ВМ и кроссплатформенности конечно интересное, но как-то вы слегка ушли в сторону от начальной темы.

 

почему?

 

dermatolog
для тех, кто не в теме
огласите цену и метод распространения subj'а.

P.S. интересный топик

 

green
> Если нативный код выполняется медленнее функционально эквивалентного байт-кода,
> значит он не оптимизирован.
это верно, с той лишь оговоркой, что данные выполняются быстрее кода и умный перенос части кода в данные очень сильно помогает, но программа (внешне) становится похожа на вм. но что (применительно к ИТ) значит "похожа"? значит она и есть вм

> Оптимизация, в частности, может привести к тому,
> что нативный код начнёт выглядеть как некая виртуальная машина,
ну вы меня поняли

SPA
> Вашу мысль понял, у вас ключевое слово написанных на си
для асма это еще более актуально. давайте оставим теорию и попробуем найти програму на асме (размер > 10, 000 строк иначе это не программа, а учебное пособие) которая действительно заоптимизирована. там такой ужас повсюду, какой себе даже компиляторы не позволяют... даже микрозадачи типа вернуть 0 если истина и 1 если ложь асматики ухитряются сделать с ветвлениями, когда даже mc vc 6 его оптимизит.

kioresk
ок. давайте к ней вернемся. поговорим о методах анализа черных ящиков. т.е. считаем, что vmprot - идеально защищает от "белого" анализа.

 

t00x
> для тех, кто не в теме
> огласите цену и метод распространения subj'а.
а интернет у вас отключили за неоплату?

http://www.vmprotect.ru/buy.php

VMProtect Lite (99 $)
VMProtect Professional - Personal license (159 $)
VMProtect Professional - Company license (319 $)
VMProtect SenseLock Edition (399 $)
Yearly subscription plan (49 $)

из способов оплаты:
* Bank Wire Transfer
* Western Union
* Plimus

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

 

kaspersky

Вообще-то принимаются - Plimus.

 

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

эээ.... а нельзя ли это написать как для програмеров? с смысле про Plimus. ну вот у меня есть виза и мастер кард. допустим, я хочу купить VMProtect Professional для персонального использования. мои действия? заходил на плимус - ничего не понял.

 

задетектит он вас и видоизменённый ююю