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

УУУУУУУХХХХХХХХ!

счас только выплыло из памяти!
ведь ASM сам есть виртуал-машина! он ведь транслируеться процессором........

так что быстрее ASM-а может быть прямой процессорный код. Завтра

а виртуалиэация на ASM-е = 2x виртулизация

 

je_
вы чтото путаете, он не

а компилируеться, в самый что не наеться машиный нативный код

 

а трансляция это когда перевод, да? ... ~

 

Смотря что вы понимаете в логике , некоторые вещи в математике давно уже не совсем логичны. Ускорение получается за счет особого метода интерпритации кода , который был открыт и опробован совсем недавно. Поэтому ускорения даже на очень медленных участках будет , а скорость выполнения превышает скорость на обыкновенном процесоре.

К этому дело и идет , уже есть прототип такого компиллера , его показатели просто блестящие. Он может собирать кросплатформенные программы , которые пойдут на любой системе.

 

calidus

В поисках логики:
Кросплатформенный код эмуляции команды MOV EAX,EBX (именно само тело интерпритатора) выглядит завися от интерпритации типа:

push [VMM_REG_EBX]
pop [VMM_REG_EAX]

или

mov eax,[VMM_REG_EAX]
mov [VMM_REG_EBX],eax

push [ebp+Const_VMM_REG_EAX]
pop [ebp+Const_VMM_REG_EBX]

lea eax,[CPU_START_ADDR]
mov edx,[eax+numb_reg_EAX]
mov [eax+numb_reg_EBX],edx

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

 

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

так же существуют вм в которых практически нет ветвлений. и за счет этого так же достигается нехилое ускорение.

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

calidus
> Ускорение получается за счет особого метода интерпритации кода
> который был открыт и опробован совсем недавно.
да ладно тебе "недавно". черт знает когда открыт. на пальцах принцип - динамическая рекомпиляция с участием профилировщика. такой способ действительно позволяет добится существенного ускорения особенно на тупом коде. ну и плюс выбрасывание всего ненужного. вот конкретный пример работы одного виртуализатора.

вход:
test ebx, ebx
jz lr
test ecx, ecx
jz lr
mov eax, 1
ret

:lr
xor eax, eax
ret

а теперь выход:
or ecx, ebx
setz al

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

 

Эт вы чтото не в ту степь.

Вопервых
вход:
test ebx, ebx
jz lr
test ecx, ecx
jz lr
mov eax, 1
ret
:lr
xor eax, eax
ret

а теперь выход:
or ecx, ebx
setz al

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

Из приведеного вопервых откуда ВМ знала что что то равно нулю, не посмотрев какое значение лежит в регистре? Она что экстрасенс?
Во вторых код выхода для вм не есть верным вопервых (если мы имели ввиду виртуализацию)
Хотябы должно выглядеть на подобии т.к. мы имеем дело с виртуальным процессором как минимум.

Mov ecx,[VM_ECX]
MOV ebx,[VM_EBX]
pushfd

push [VM_EFL]
popfd

or ecx, ebx
setz al

pushfd
pop [VM_EFL]

popfd
mov [VM_AL],al

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

 

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

kaspersky да ты прав насчет такого метода , он давно известен , но в данном случае он используется лишь для оптимизации самой вм ...оптимизация выполнения кода уже выпоняется иначе. За это отвечает другой блок. Я поэтому и сказал что немного о разных вещах ...

 

Соглашусь с PaCHER. А насчет .NET, дык если покопать то все упреться в некорректные сравнения .NET компилятора(назовем его так), который генерит оптимальный код для платформы и компиляторов, код от которых на одном компе будет вычисляться быстрее чем на другом. Но взяв какой-нибудь последний IntelCompiler, да поковырявшись в настройках компиляции мы сможем генерить уже более эффективный код чем у .NET'a.

 

А насчет динамической рекомпиляции - она _медленнее_ по определению, чем нативный код.

 

"Особенностью системы .NET является использование оригинальной технологии интеграции кода, которая обеспечивает совместимость кода не на уровне исполняющего ядра (процессора, виртуальной машины .NET), а на уровне самой программной модели.
Существует два вида виртуальных машин — интерпретирующие и компилирующие.
Интерпретирующие машины исполняют код, полностью эмулируя его работу.
Фактически, они сами исполняют код вверенных им приложений. То есть на каждую инструкцию интерпретируемого байт-кода приходится N инструкций интерпретатора виртуальной машины. В итоге, происходит значительное снижение скорости выполнения программы. За что и не любят виртуальные машины такого типа. (вот собственно про что мы говорили)

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

Собственно у нас какбы тут уже и нету понятия виртуализации как таковой т.к. ничего не виртуализируется.

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

тоесть у нас не будет цикла обработчика байткода

например подобный код будет сгенерн

натив:
add eax,ebx
add eax,ecx
test eax,eax
jnz натив

нет:
mov eax,[vmm_eax]
add eax,[vmm_ecx]
add eax,[vmm_ecx]
test eax,eax
jnz нет:

Цикла обработчика каждой команды нету просто код уже сгенерен так последовательно как ему нужно и опятьже заслуга скорости нета изза толкового компановщика.

 

TSS

+10

Если человек бежит по салону летящего самолёта , то получается он быстрее бежит , чем летит самолёт.
Ересь господин kaspersky , ересь.

 

жжешь =) ... если расмотреть пределы этого самолета , то при беге в летящем самолете человек будет двигаться быстрее чем самолет , и это верно ))))))) тыб хотябы пример подобрал чтоли

 

Я придерживаюсь мнения что если сравнить тривиальный кусок кода собраный нетовским компоновщиком с кодом написаным на АСМЕ натив асма полюбому будет работать быстрее того что соберет нет отсюда и такие сомнения. Заслуга же идет восновном в маштабных процедурах или проектах где нативный компилятор посравнению с нетовским компоновщиком (т.к. нетовский код не будет иметь вида виртуальной машини с обработчиком и в памяти будет исполнятся уже сгенерированый тотже натив) генерирует более толковый код.

 

h__p://msdot.ru/dotnet/199953/
Вот кстати по теме, там конечно нету примеров кодов и обработчиков но я вроде попытался показать напримере уже готового асма.

 

и если присмотрется к картинке
h__p://msdot.ru/imgs/Microsoft%20.NET-2.jpg
мы видем что написано "машинный код родной для данной платформы" то тут какбы становится понятно что проц исполняет тотже НАТИВ и виртуализации как таковой именно исполнимого кода нету.

 

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

 

calidus

Чем тебя пример не устраивает ? Есть нативный код , есть виртуальный , но выполняется всё на
физическом процессоре...
Никто ведь не спорит , что можно написать тормозной код ?
Но в итоге то что виртуальный , что нативный код выполняется на "нативном" процессоре ....

 

Просто 2 описаные машины я видел в живую и сгенеренный код нета тоже. Поэтому я и говорю что заслуга скорости ВМ 2ого типа по сравнению с нативом зависит от толкового интерпритарора высокоуровневого кода в низкоуровневый. Поэтому и привел пример с сравнением обычного АСМ натива например самого тривиального Return(a+b) нетовский код проиграет хотябы изза скорости загрузки приложения, но более сложный код написаный на нете может выиграть у кода написаного на vc++ именно изза того что в нете более толковый интерпритатор кода.

 

calidus

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