VTIL (Virtual-machine Translation Intermediate Language)

OKOB

Посетитель
Победители турниров
Мудрец
Сообщения
34
Реакции
436
Относительно новый фреймворк для борьбы с виртуализацией и обфускацией - VTIL Project (Virtual-machine Translation Intermediate Language)
https://github.com/vtil-project/

Project is a set of tools that can be used for binary deobfuscation and devirtualization.

What is VTIL?
VTIL Project, standing for Virtual-machine Translation Intermediate Language, is a set of tools designed around an optimizing compiler to be used for binary de-obfuscation and de-virtualization.

The main difference between VTIL and other optimizing compilers such as LLVM is that it has an extremely versatile IL that makes it trivial to lift from any architecture including stack machines. Since it is built for translation, VTIL does not abstract away the native ISA and keeps the concept of the stack, physical registers, and the non-SSA architecture of a general-purpose CPU as is. Native instructions can be emitted in the middle of the IL stream and the physical registers can be addressed from VTIL instructions freely.

VTIL also makes it trivial to emit code back into the native format at any virtual address requested without being constrained to a specific file format.

Из примеров успешного применения от "банды" secret club (https://twitter.com/the_secret_club), есть anti-cheat BattlEye накрытый VMProtect.
https://secret.club/2020/07/06/bottleye.html
 

plutos

_Вечный_Студент_
Мудрец
Сообщения
37
Реакции
546

mak

Соломенные сандалии
Администратор
Сообщения
319
Реакции
108
Тема интересная, в прошлой теме меня отпугнул этот двиг, заявка, что этот IL лучше LLVM весьма спорна, а нового в этом двиге в целом ничего нет, обыкновенный гибридный псевдокод с сохранением ИСА, почти все декомпили пользователей подобного типа, потребуется ещё много дописывать, чтобы реально изучать ВМП. Смысл этого двига, поднять ВМ на хайлевел уровень, я долго изучал эту задачу ещё в 2010 году, но после разных экспериментов, понял, что лучше все эти этапы разделить. Этот проект мне напомнил забытый REIL − The Reverse Engineering Intermediate Language https://github.com/Cr4sh/openreil

About
REIL was initially developed by Zynamics as part of their BinNavi framework, proprietary code analysis software written in Java. To learn more about REIL read the following documents:

«REIL − The Reverse Engineering Intermediate Language» (link)

«The REIL language» (part 1, part 2, part 3, part 4)

«Applications of the Reverse Engineering Language REIL» (PDF)

«REIL: A platform-independent intermediate representation of disassembled code for static code analysis» (PDF)

However, after Zynamics was acquired by Google they abandoned BinNavi, so, I decided to develop my own implementation of REIL. I made it relatively small and portable in comparison with original, the translator itself is just a single library written in C++, it can be statically linked with any program for static or dynamic code analysis. The higher level API of OpenREIL is written in Python, so, it can be easily utilized in plugins and scripts for your favourite reverse engineering tool (almost all modern debuggers and disassemblers has Python bindings).

OpenREIL is not a 100% compatible with Zynamics REIL, it has the same ideology and basics, but there's some changes in IR instruction set and representation of the traget hardware platform features.

OpenREIL is based on my custom fork of libasmir − IR translation library from old versions of BAP framework. I removed some 3-rd party dependencies of libasmir (libbfd, libopcodes) and features that irrelevant to translation itself (binary files parsing, traces processing, etc.), than I did some minor refactoring/bugfixes, switched to Capstone for instruction length disassembling and implemented BAP IR → REIL translation logic on the top of libasmir.

Because libasmir uses VEX (production-quality library, part of Valgrind), full code translation sequence inside of OpenREIL is looks as binary → VEX IR → BAP IR → REIL. It's kinda ugly from engineering point of view, but it allows us to have a pretty robust and reliable support of all general instructions of x86. Current version of OpenREIL still has no support of other architectures, but I'm working on x86_64 and ARMv7.

UPDATE: Current version of OpenREIL already has much or less usable ARMv7 support with dynamic switching of translation context between ARM and Thumb execution modes. There is no proper documentation on ARM yet, but you can check some unit tests for this functionality as usage examples: 1, 2, 3

Please note, that currently OpenREIL is a far away from stable release, so, I don't recommend you to use it for any serious purposes.
Плюс подобный код я уже видел в не менее чем в трёх других движках. Ряд ограничений такой
1. Ошибки в парсинге из-за гибридного подхода
2. Ограниченная поддержка набора команд
3. Сложный набор апи с постоянными фиксами
4. Слабая портабельность
5. Шаблонизация ограничена синтаксисом
6. Поиск шаблонов лежит на плечах юзера (т.е. ничего не поменялось, а нормальный подход самостоятельно шаблоны раскидывает, у автора на это ушло 2 дня)

Позитивная сторона, подобных двигов нет в паблике, можно хоть как-то попробовать использовать готовое и не создавать своё, классная игрушка :roll:

Кто копает глубоко, проблематику можно понять из этого документа - http://www.ittc.ku.edu/~kulkarni/teachi ... ter5_6.pdf
 

plutos

_Вечный_Студент_
Мудрец
Сообщения
37
Реакции
546
Мой вопрос не о восстановлении исходного кода из bytecode'a, a наоборот о создании bytecode'a при защите программы с помощью виртуализации (VM Protect, Themida).
Если взять за основу классическое определение compiler'a:
"A compiler may formally be defined as a function, whose domain is a source language, and whose range is contained in an object or target language."
(Compilers and Compiler Generators © P.D. Terry, 2000)
или из книги by Alfred Aho ("The Dragon Book"):
"A compiler is a program that can read a program in one language - the source language - and translate it into an equivalent program in another language - the target language",
то по идее все копилляторы делают одну и ту же работу, но :
Как работа Virtualization Compiler'a, скажем VMProtect'a будет схожа и в чем будет отличаться от работы "обычного" компиллятора, того же gcc? Ведь если следовать классическим определениям, то и обычный компиллятор и Virtualization Compiler делают однo и тo же?
Я понимаю, что обычный компиллятор работает со pseudo-English text representation of HLL program, it needs lexer, parser, AST, etc.
Virtualization Compiler работает уже с assembly code и многие традиционные шаги уже не нужны. Казалось бы все должно быть проще, но на самом деле гораздо сложнее. Понятно, что VMProtect использует свои private algorithms и никто мне их не представит.
Но мне хотелось бы понять сам процесс создания такого протектора, саму логику и последовательность действий.
Скажем, создали мы много-много handlers, но как потом превращать защищаемый код в bytecode, который будет выполнятся этими handlers? Как работает vm с bytecode, более-менее ясно, по крайней мере в теории, а вот как генерируется сам bytecode?
Если уж совсем коротко, то как vm protector создает bytecode?

Вот, добавлю еще одну цитату: "Virtualization is the recompilation of instructions to a custom proprietary architecture, and the generation of handler routines to emulate said architecture".
Значит если я правильно понимаю, первый шаг в разработке vm протектора, это разработка соответсвующего ISA and its handlers?
Но все же RECOMPILATION phase остается загадкой! Прошу помощи!
Желательно подробно и с примерами, или со ссылками на них. :!:
 

mak

Соломенные сандалии
Администратор
Сообщения
319
Реакции
108
Мой вопрос не о восстановлении исходного кода из bytecode'a, a наоборот о создании bytecode'a при защите программы с помощью виртуализации (VM Protect, Themida).
Если взять за основу классическое определение compiler'a:
"A compiler may formally be defined as a function, whose domain is a source language, and whose range is contained in an object or target language."
(Compilers and Compiler Generators © P.D. Terry, 2000)
или из книги by Alfred Aho ("The Dragon Book"):
"A compiler is a program that can read a program in one language - the source language - and translate it into an equivalent program in another language - the target language",
то по идее все копилляторы делают одну и ту же работу, но :
Как работа Virtualization Compiler'a, скажем VMProtect'a будет схожа и в чем будет отличаться от работы "обычного" компиллятора, того же gcc? Ведь если следовать классическим определениям, то и обычный компиллятор и Virtualization Compiler делают однo и тo же?
Я понимаю, что обычный компиллятор работает со pseudo-English text representation of HLL program, it needs lexer, parser, AST, etc.
Virtualization Compiler работает уже с assembly code и многие традиционные шаги уже не нужны. Казалось бы все должно быть проще, но на самом деле гораздо сложнее. Понятно, что VMProtect использует свои private algorithms и никто мне их не представит.
Но мне хотелось бы понять сам процесс создания такого протектора, саму логику и последовательность действий.
Скажем, создали мы много-много handlers, но как потом превращать защищаемый код в bytecode, который будет выполнятся этими handlers? Как работает vm с bytecode, более-менее ясно, по крайней мере в теории, а вот как генерируется сам bytecode?
Если уж совсем коротко, то как vm protector создает bytecode?

Вот, добавлю еще одну цитату: "Virtualization is the recompilation of instructions to a custom proprietary architecture, and the generation of handler routines to emulate said architecture".
Значит если я правильно понимаю, первый шаг в разработке vm протектора, это разработка соответсвующего ISA and its handlers?
Но все же RECOMPILATION phase остается загадкой! Прошу помощи!
Желательно подробно и с примерами, или со ссылками на них. :!:
Привет,

ключевое слово "Уровень абстракции" и "полнота данных". Ассемблер на этом уровне - это мета язык, т.е. не чисто бинарный, если взять и представить, что асм это сишка, то ты увидишь парадигму Ассемблера. Эту парадигму и используют для удобства записи байткода. На этом уровне действуют все правила HLL программ, lexer, parser, AST, etc, т.е. ты можешь делать что хочешь. У тебя же есть примеры из rewolf-x86-virtualizer, есть примеры другого протектора с конвертацией кода, не помню название. Мне кажется, что текст вносит смуту, когда без примера обсуждают.

Для Bytecode нужен простой парсер, структура Bytecode-а, это твой мета ассемблер, для примера можно глянуть конвертацию в Xbyak 5.92 - JIT assembler for x86(IA32), x64(AMD64, x86-64) by C++ - https://github.com/herumi/xbyak Ты можешь закодировать инструкции своим кодом, главное, чтобы ВМ понимала и могла парсить твою структуру инструкций. Как уже сказано ранее, все эти примеры уже были в твоих проектах. Сама структура может быть любой.

Значит если я правильно понимаю, первый шаг в разработке vm протектора, это разработка соответсвующего ISA and its handlers?
Первый или нет, но да.
 

plutos

_Вечный_Студент_
Мудрец
Сообщения
37
Реакции
546
На этом уровне действуют все правила HLL программ, lexer, parser, AST, etc, т.е. ты можешь делать что хочешь. У тебя же есть примеры из rewolf-x86-virtualizer
Отлично! Спасибо Макс!
Вот это собственно и есть ответ на мой вопрос!
 

plutos

_Вечный_Студент_
Мудрец
Сообщения
37
Реакции
546
mak wrote:
"Ассемблер на этом уровне - это мета язык, т.е. не чисто бинарный, если взять и представить, что асм это сишка, то ты увидишь парадигму Ассемблера. Эту парадигму и используют для удобства записи байткода."


Посмотрел пока очень бегло на пример, который ты приводишь выше.
"Xbyak is a C++ header library that enables dynamically to assemble x86(IA32), x64(AMD64, x86-64) mnemonic."
Т.е., если я правильно понял, уровень mnemonics это в нашем случае мета язык?
 

plutos

_Вечный_Студент_
Мудрец
Сообщения
37
Реакции
546
Ассемблер на этом уровне - это мета язык, т.е. не чисто бинарный, если взять и представить, что асм это сишка, то ты увидишь парадигму Ассемблера. Эту парадигму и используют для удобства записи байткода.

это очень интересный момент. Не можешь немного по-подробнее об этой парадигме?
 

OKOB

Посетитель
Победители турниров
Мудрец
Сообщения
34
Реакции
436
Появились приложения к VMProtect
A static devirtualizer for VMProtect x64 3.x powered by VTIL
NoVmp

A full VMProtect static devirtualizer powered by VTIL
vmpattack
 
Последнее редактирование:

mak

Соломенные сандалии
Администратор
Сообщения
319
Реакции
108
Можно накрыть последним вмп сэмпл и посмотреть, как VTIL справится.

Здесь маленький код на асме, который после протекции занял 1 мб, протекции и антидебага нет, без упаковки, только вирт - https://www.upload.ee/files/12160844/VMP_Test_VTIL.7z.html
 

mak

Соломенные сандалии
Администратор
Сообщения
319
Реакции
108
:D понятно почему никто пример не тестировал ..

Крутит уже вторые сутки, стабильно один гиг памяти занимает и 16 процентов нагрузка на и7 4 ого поколения. Из минусов, нельзя один и тот же пример запустить, даже если он с другим именем. Первый баг описывают на страничке утилиты ..

Bash:
U:\VMPTest2>NoVmp XOR_20200817194428.vmp.exe
##############################################################################
# NoVmp  Copyright (C) 2020 Can Boluk                                        #
# This program comes with absolutely no warranty, and it is free software.   #
# You are welcome to redistribute it under certain conditions--for which you #
# can refer to the GNU General Public License v3.                            #
##############################################################################

[!] Warning: This image has relocations stripped, NoVmp is not 100% compatible with this switch yet.
Discovered vmenter at 0000000000401000
Lifting virtual-machine at 0000000000044A98...
Routine => optimizer::stack_pinning_pass                                               | Took 2.65    ms (N=17224).
Routine => optimizer::istack_ref_substitution_pass                                     | Took 3.85    ms (N=0).
Routine => optimizer::bblock_extension_pass                                            | Took 0.00    ms (N=0).
Routine => optimizer::local_pass<optimizer::stack_propagation_pass>                    | Took 6118.70 ms (N=4131).
Routine => optimizer::local_pass<optimizer::dead_code_elimination_pass>                | Took 8474.14 ms (N=10591).
Routine => optimizer::local_pass<optimizer::mov_propagation_pass>                      | Took 284.35  ms (N=1545).
Routine => optimizer::local_pass<optimizer::register_renaming_pass>                    | Took 251.41  ms (N=1280).
Routine => optimizer::local_pass<optimizer::dead_code_elimination_pass>                | Took 52.10   ms (N=1551).
Routine => optimizer::symbolic_rewrite_pass<1>                                         |
Второй тул выдал
Bash:
U:\VMPTest2>VMPAttack XOR.vmp.exe
** Loaded raw image buffer @ 0x000001DA9C335060 of size 0x104400
** Found 0 virtualized routines:

Press any key to continue . . .
 

mak

Соломенные сандалии
Администратор
Сообщения
319
Реакции
108
Верх Низ