Русский / Russian English / Английский

Сейчас на форуме: Dart Raiden (+7 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS ·

 eXeL@B —› Крэки, обсуждения —› LLVM, Clang для реверсинга
. 1 . 2 . >>
Посл.ответ Сообщение

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 9 декабря 2019 14:54 New!
Цитата · Личное сообщение · #1

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


Ранг: 85.7 (постоянный)
Статус: Участник

Создано: 10 декабря 2019 15:29 New!
Цитата · Личное сообщение · #2

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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 11 декабря 2019 20:07 New!
Цитата · Личное сообщение · #3

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


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 13 декабря 2019 20:33 New!
Цитата · Личное сообщение · #4

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

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

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



Ранг: 330.5 (мудрец)
Статус: Участник

Создано: 14 декабря 2019 23:18 · Поправил: difexacaw New!
Цитата · Личное сообщение · #5

mak

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


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 16 декабря 2019 12:57 New!
Цитата · Личное сообщение · #6

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 мне больше нравится, т.к. решение компактнее и добавить здесь больше нечего.

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



Ранг: 330.5 (мудрец)
Статус: Участник

Создано: 16 декабря 2019 20:20 · Поправил: difexacaw New!
Цитата · Личное сообщение · #7

mak

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

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

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

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

Ранг: 586.6 (!)
Статус: Модератор

Создано: 17 декабря 2019 22:37 New!
Цитата · Личное сообщение · #8

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

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



Ранг: 330.5 (мудрец)
Статус: Участник

Создано: 18 декабря 2019 19:54 New!
Цитата · Личное сообщение · #9

r_e

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

RE".

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

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

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

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

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

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

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



Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 19 декабря 2019 15:05 New!
Цитата · Личное сообщение · #10

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


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

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

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

capstone2llvmir - --> Link <--

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



Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 23 декабря 2019 02:44 New!
Цитата · Личное сообщение · #11

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 <--

После компиляции тайминги этого исходника -
Code:
  1. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  2. Insert Kernel ran in: 50.529282 ms
  3. Find   Kernel ran in: 0.005120 ms
  4.  
  5. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  6. Insert Kernel ran in: 53.239807 ms
  7. Find   Kernel ran in: 0.005120 ms
  8.  
  9. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  10. Insert Kernel ran in: 49.198078 ms
  11. Find   Kernel ran in: 0.005120 ms
  12.  
  13. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  14. Insert Kernel ran in: 49.577984 ms
  15. Find   Kernel ran in: 0.005120 ms
  16.  
  17. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  18. Insert Kernel ran in: 51.966976 ms
  19. Find   Kernel ran in: 0.006112 ms
  20.  
  21. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  22. Insert Kernel ran in: 53.110783 ms
  23. Find   Kernel ran in: 0.006144 ms
  24.  
  25. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  26. Insert Kernel ran in: 50.780159 ms
  27. Find   Kernel ran in: 0.005120 ms
  28.  
  29. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  30. Insert Kernel ran in: 49.320992 ms
  31. Find   Kernel ran in: 0.006144 ms
  32.  
  33. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  34. Insert Kernel ran in: 49.470463 ms
  35. Find   Kernel ran in: 0.005120 ms
  36.  
  37. X:\CudaAVLTree\CudaAVLTree\x64\Release>CudaAVLTree
  38. Insert Kernel ran in: 52.481026 ms
  39. Find   Kernel ran in: 0.005120 ms
  40.  
  41. X:\CudaAVLTree\CudaAVLTree\x64\Release>


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


Ранг: 330.5 (мудрец)
Статус: Участник

Создано: 23 декабря 2019 21:05 New!
Цитата · Личное сообщение · #12

mak

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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 15 января 2020 10:57 New!
Цитата · Личное сообщение · #13

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

Ранг: 246.6 (наставник)
Статус: Участник

Создано: 15 января 2020 19:05 · Поправил: cppasm New!
Цитата · Личное сообщение · #14

Там же AT&T синтаксис. Или нет?
Code:
  1. movl     (%ebx,%edi),%eax  -> eax=[ebx+edi]
  2. movl     buffer, %eax  -> eax=offset buffer
  3. movl     (buffer),%eax  -> eax=[buffer]


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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 15 января 2020 19:50 New!
Цитата · Личное сообщение · #15

cppasm пишет:
var - адрес, [var] - значение.

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

Понятно, что как вариант:
Code:
  1. mov rax, offset somebody

менять на
Code:
  1. lea rax, [rip+somebody]

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

Ранг: 246.6 (наставник)
Статус: Участник

Создано: 15 января 2020 20:05 New!
Цитата · Личное сообщение · #16

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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 16 января 2020 18:03 New!
Цитата · Личное сообщение · #17

cppasm пишет:
$var - адрес переменной

Не работает. Дерьмо


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 17 января 2020 15:05 New!
Цитата · Личное сообщение · #18

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


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

Code:
  1.  
  2.     mov rax, [data]
  3.  


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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 17 января 2020 20:55 New!
Цитата · Личное сообщение · #19

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

Он ругается на 'offset'
без offset компилируется неправильно - как обращение по адресу
Code:
  1. mov rax, [label1]

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


Ранг: 2011.1 (!!!!)
Статус: Модератор
retired

Создано: 17 января 2020 21:15 New!
Цитата · Личное сообщение · #20

Сделай lea.

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 17 января 2020 22:40 New!
Цитата · Личное сообщение · #21

Archer пишет:
lea

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


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 17 января 2020 22:58 New!
Цитата · Личное сообщение · #22

Здесь обсуждают идентичную тему ...
[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 <--

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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 17 января 2020 23:49 New!
Цитата · Личное сообщение · #23

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


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 21 января 2020 16:11 New!
Цитата · Личное сообщение · #24

ELF_7719116

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


--> Link <--

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

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



Ранг: 582.3 (!)
Статус: Участник
_Вечный_Студент_

Создано: 29 января 2020 02:58 · Поправил: plutos New!
Цитата · Личное сообщение · #25

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

Ранг: 409.8 (мудрец)
Статус: Участник
"Тибериумный реверсинг"

Создано: 30 января 2020 22:11 New!
Цитата · Личное сообщение · #26

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

Да

mak пишет:
обещают поправить

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

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


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 31 января 2020 00:41 · Поправил: mak New!
Цитата · Личное сообщение · #27

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 <--, остальное в перемешку , только через тест можно понять ..

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



Ранг: 582.3 (!)
Статус: Участник
_Вечный_Студент_

Создано: 31 января 2020 01:34 · Поправил: plutos New!
Цитата · Личное сообщение · #28

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

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


Ранг: 667.3 (! !)
Статус: Участник
CyberMonk

Создано: 31 января 2020 02:05 · Поправил: mak New!
Цитата · Личное сообщение · #29

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


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

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



Ранг: 582.3 (!)
Статус: Участник
_Вечный_Студент_

Создано: 31 января 2020 03:06 · Поправил: plutos New!
Цитата · Личное сообщение · #30

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


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

хотя в свете приведенного ниже фрагмента, я вижу, что и тот и другой термин вполне уместен и зависит от ситуации.
Code:
  1. At its heart, LLVM is a library for programmatically creating machine-native code.
  2. A developer uses the API to generate instructions in a format called an intermediate representation, or IR.
  3. LLVM can then compile the IR into a standalone binary, or perform a JIT (just-in-time) compilation 
  4. on the code to run in the context of another program, 
  5. such as an interpreter for the language.
. 1 . 2 . >>
 eXeL@B —› Крэки, обсуждения —› LLVM, Clang для реверсинга

Видеокурс ВЗЛОМ