Собственно, в чем профит, кроме построения синтаксич деревьев?

| Сообщение посчитали полезным:

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

-----
В облачке многоточия

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

The LLDB Debugger - интересный проект - --> Link <--, для вин вроде пока нет нормального Гуи - --> Link <--, но можно уже отлаживать в Visual Studio Debugging programs with LLDB under Visual Studio - --> Link <--

Ещё две темы интересные, это трансляция кода и динамическая оптимизация через эмуляцию, обе техники требуют ELF_7719116 пишет: прочитать всю "Война и мир" Толстого , просто нужно поменять мышление и подход к решению, у меня были большие сложности воспринимать этот код после мира ассемблера. Но если подниматься на уровень выше, то здесь уже больше модульная парадигма, каждый модуль центрирован на себе и имеет входные и выходные данные.

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: difexacaw, plutos

mak

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

-----
vx

| Сообщение посчитали полезным:

mak пишет:
динамическая оптимизация через эмуляцию

Вот пример второй темы - HQEMU is a retargetable and multi-threaded dynamic binary translator on multicores. It integrates QEMU and LLVM as its building blocks. The translator in the enhanced QEMU acts as a fast translator with low translation overhead. The optimization-intensive LLVM optimizer running on separate threads dynamically improves code for higher performance. With the hybrid QEMU+LLVM approach, HQEMU can achieve low translation overhead and good translated code quality.

HQEMU supports process-level emulation and full-system virtualization. It provides translation modes of running the QEMU translator and LLVM optimizer in one process, or running the LLVM optimizer as a stand-alone optimization server (version 0.13.0).

Сорсы на 30 метров --> Link <--

И дока к этим сорсам на 111 страниц ..

Efficient and Retargetable Dynamic Binary Translation
Ding-Yong Hong
April 2013
Computer Science
National Tsing Hua University

--> Link <--

Еслиб эту тему соединили с Unicorn Emulator, было бы очень здорово ..

difexacaw пишет:
mak

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

Как я вижу этот вопрос, требуется некий Hardware Accelerator, который позволит интерактивно подхватывать приложения заточенные под это, следовательно свой сдк нужен. Даже на примере выше, что можно перенести на технический уровень, чтобы подобный QEMU мод был шустрее.

И вот тут ребята уже экспериментировали - --> Link <--
Hardware-Accelerated Dynamic Binary Translation --> Link <--

Скорее всего пока такого ожидать не стоит, остаётся использовать только программные решения. А метод трансляции кода в LLVM мне больше нравится, т.к. решение компактнее и добавить здесь больше нечего.

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: bartolomeo

mak

> Скорее всего пока такого ожидать не стоит, остаётся использовать только программные решения.

Я и имел ввиду софт решение, те алгоритмическое. По этой теме я провёл довольно не малую работу, даже тут есть несколько тем. Не ясно как транслировать указатели, AVL не может вытянуть профайл.

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

ps: хотя впрочем ничего не измерено, никто тут и близко не смог к этой теме подойти.)

-----
vx

| Сообщение посчитали полезным:

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

-----
старый пень

| Сообщение посчитали полезным: plutos

r_e

> Но что это дает для РЕ?

RE".

Ничего это не даёт и вообще ниочём.

Реальная задача в повышении профайла автоматики, из за этого невозможен анализ тяжёлых апп.

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

Попытка это обойти приводит к большим сложностям. Так например из транслированного кода будут адресации на переменную с указателем на код(те indirect-addr). Когда она изменится это повлияет на все ссылки на ней в коде. Что бы это обойти можно создать своего рода кэш указателей. Тогда при дереференсе ссылки все они пойдут в описатель, который будет ссылаться на один адрес. Но при добавлении записи в этот список опять же придётся использовать авл. Как и при поиске в этом списке. Как это решить хз.

Если частично отказаться от использования указателей, те трансляции их на описатель, тогда будут повторения и потечёт память.

Есть подозрение что это и вовсе решить нельзя, хотя кто его знает.

-----
vx

| Сообщение посчитали полезным: mak, ELF_7719116

r_e пишет:
mak
Для тех кто не так глубоко в теме может напишешь пару слов зачем оно надо или чем может быть полезно в реверсе?
Судя по докам и описанию, то это попытки ускорения обычных полных эмуляторов других архитектур, когда вместо эмуляции используется трансляция в целевую архитектуру и исполнения на существующем железе.
Но что это дает для РЕ?

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

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

Плюс уже уточнялось ..
mak пишет:
А метод трансляции кода в LLVM мне больше нравится, т.к. решение компактнее и добавить здесь больше нечего.
capstone2llvmir - --> Link <--

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: ELF_7719116, r_e, plutos

difexacaw пишет:
Реальная задача в повышении профайла автоматики, из за этого невозможен анализ тяжёлых апп.

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

Попытка это обойти приводит к большим сложностям. Так например из транслированного кода будут адресации на переменную с указателем на код(те indirect-addr). Когда она изменится это повлияет на все ссылки на ней в коде. Что бы это обойти можно создать своего рода кэш указателей. Тогда при дереференсе ссылки все они пойдут в описатель, который будет ссылаться на один адрес. Но при добавлении записи в этот список опять же придётся использовать авл. Как и при поиске в этом списке. Как это решить хз.

Если частично отказаться от использования указателей, те трансляции их на описатель, тогда будут повторения и потечёт память.

Есть подозрение что это и вовсе решить нельзя, хотя кто его знает.

Было бы классно замерить тайминги отношений, связи размера кода и задержки, у тебя в теме я уже давал линк на интересный проект - dynamic-bt (A solution to accelerate dynamic binary translation for fixed size instructions using CUDA.) - --> Link <--, дока к этому проекту - Accelerating Dynamic Binary Translation with GPUs - --> Link <--

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

По таймингам в доке Accelerating Dynamic Binary Translation with GPUs есть подобное сравнение:



По теме AVL Tree есть проект - Implementation of BST, AVL and B-Trees on GPGPU (CUDA) - --> Link <--

После компиляции тайминги этого исходника -


Остальной функционал нужно тестировать

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

mak

Кэш для кэша ?
Нужно подумать.

-----
vx

| Сообщение посчитали полезным:

Оказывается сабж не подерживает директиву offset для asm инструкций
Как это работает? Разработчики clang вообще дубу дали??????

| Сообщение посчитали полезным:

Там же AT&T синтаксис. Или нет?


Offset можно и в Интеловском синтаксисе не юзать.
var - адрес, [var] - значение.

| Сообщение посчитали полезным:

cppasm пишет:
var - адрес, [var] - значение.
AT%T и intel. В последнем не работает не фига, в т.ч. самое смешное:
var == [var]

Понятно, что как вариант:

менять на

, но с какого первый вариант не рабочий? и что делать, когда требуется в стек запхнуть указатель?

| Сообщение посчитали полезным:

Хз что они там намутили.
В GAS offset работает вроде.
Попробуй $ как в AT&T:
var или [var] - значение
$var - адрес переменной

| Сообщение посчитали полезным:

cppasm пишет:
$var - адрес переменной
Не работает. Дерьмо

| Сообщение посчитали полезным:

ELF_7719116 пишет:
Не работает. Дерьмо

Сделал бы сэмпл для тестирования, ты инлайн асм делаешь в си коде? Или чисто ассемблерный код хочешь собрать?



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

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

mak
Hi! Тема такая: из .s собрать .exe
Банально вписываю инструкцию:

Он ругается на 'offset'
без offset компилируется неправильно - как обращение по адресу

Последняя версия clang

| Сообщение посчитали полезным:

Сделай lea.

| Сообщение посчитали полезным:

Archer пишет:
lea
Арчи, в #15 посте сделал. Но, это не отвечает на главный вопрос - почему в 2020 году clang не понимает директивы offset и что курят его разработчики

| Сообщение посчитали полезным:

Здесь обсуждают идентичную тему ...
[x86asm intel syntax] `mov` with a symbol from a .set directive not handled c... --> Link <--
Why does this simple assembly program work in AT&T syntax but not Intel syntax? --> Link <--
[llvm-bugs] [Bug 32530] New: inline assembly incompatibility between gcc and clang - mov with offset in intel dialect --> Link <--
[X86][AsmParser] re-introduce 'offset' operator --> Link <--

Если не лень, создай тему на гитхабе с этим вопросом

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

mak
Видел, но из всего этого нихрена не понятно совсем - добавили они offset или нет
clang, Intel syntax, offset... offset, Карл!!!!!!! это даже хуже, чем зоопарк из костылей и багов clang в Android Studio ndk

| Сообщение посчитали полезным:

ELF_7719116

ELF_7719116 пишет:
Видел, но из всего этого нихрена не понятно совсем - добавили они offset или нет
clang, Intel syntax, offset... offset, Карл!!!!!!! это даже хуже, чем зоопарк из костылей и багов clang в Android Studio ndk

--> Link <--

Можно искать баги которые попались или написать свою исузу с тестом --> Link <--, offset обещают поправить --> Link <--

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: ELF_7719116

Тема активная, интересная.
Нельзя ли ее перенести куда-нибудь по-ближе к "Основному форуму"? А то я так было и прошел мимо... (DisAster! :s10
А теперь нужно помнить всякий раз чтобы уведеть обновления?
Может я не один такой и меня поддержат?

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

plutos пишет:
меня поддержат?
Да

mak пишет:
обещают поправить
Ради интереса включил таймер. Так понимаю у них AT&T за стандарт принят, остальные по остаточному принципу поддерживаются.

Бит-код из llvm ir раскладывается в читабельный вид только через analyser module. Читаемый весьма условно - понять смысл не представляется возможным без дальней конвертации. А конвертировать штатными средствами допускается в одном направлении. Из ir бит-кода обратно сорцы в первозданном виде не восстановить?

| Сообщение посчитали полезным:

ELF_7719116 пишет:
Из ir бит-кода обратно сорцы в первозданном виде не восстановить?

[llvm-dev] LLVM IR to C++ --> Link <--
llvm ir back to human-readable source language? --> Link <--
[llvm-dev] llvm IR to C/C++ conversion --> Link <--

ELF_7719116 пишет:
Так понимаю у них AT&T за стандарт принят, остальные по остаточному принципу поддерживаются.

Часть инструкций, которые вроде как работают, я не делал тесты, но как хелпер можно использовать - the GNU Assembler, for GAS version 2.30 --> Link <--, остальное в перемешку , только через тест можно понять ..

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: ELF_7719116

Древнекитайская мудрость гласит: "Чтобы правильно понять, нужно правильно назвать".
Название LLVM вроде бы говорит о многом, и вместе с тем вроде как и ни о чем.
Я читал пару книг по этому предмету, но там в основном говориться о деталях установки, а дальше человек тонет в океане деталей и за деревьями не видно лесу. Есть ОЧЕНЬ подробная документация, но и там таже проблема. Технические детали я одолею сам, операясь на ту же документацию, но я не понимаю главной мысли: что вызвало к жизни LLVM, что это такое в двух словах?

Так вот, не мог бы кто-нибудь из корифеев обьяснить, не прибегая к таким терминам как "конгруэнтность локальной парадигмы", объяснить СУТЬ?
Типа: в низкоуровневом программировании создалась такая-то ситуация, назрел кризис, возникла неотложная необходимость создания, которая и вызвала к жизни LLVM, цель которой - решить такие-то и такие-то задачи и она это делает так-то и так-то.
Если я пойму ЗАЧЕМ, то будет проще понять ЧТО ЭТО ТАКОЕ.
Заранее спасибо!

-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

plutos пишет:
Если я пойму ЗАЧЕМ, то будет проще понять ЧТО ЭТО ТАКОЕ.

Если отбросить все теории и полезности, то всё можно свести к одной простой мысли - Управляемый код, эта парадигма отражается здесь - --> Link <--, но в LLVM расширенная парадигма, парадигма - Управляемый компилятор. Если взять пример с линка выше, то выйдет так - "Слово «управляемый» (англ. managed) здесь относится к методу обмена информацией между программой и компиляторной средой. Оно означает, что в любой точке исполнения управляющая среда(компилятор) может приостановить исполнение и получить информацию, специфичную для текущего состояния. Необходимая для этого информация представлена в управляемом коде на языке Intermediate Language и в связанных с этим кодом метаданных." В будущем все компиляторы будут такого типа, область применения безгранична. Этот термин был введён уже давно, просто сейчас забыт, в старых книгах по компиляторам можно найти подобное описание.

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: plutos

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

Если здесь прослеживается такая аналогия с .net framework, то может быть более уместным будет слово interpreter? (as opposed to compiler)

хотя в свете приведенного ниже фрагмента, я вижу, что и тот и другой термин вполне уместен и зависит от ситуации.


-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным: