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

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

 eXeL@B —› Оффтоп —› LLVM, Clang для реверсинга
Посл.ответ Сообщение

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

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

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

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

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

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

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

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

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


Ранг: 664.6 (! !)
Статус: Участник
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



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

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

mak

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


Ранг: 664.6 (! !)
Статус: Участник
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 мне больше нравится, т.к. решение компактнее и добавить здесь больше нечего.


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

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

mak

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

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

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

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

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

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

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


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

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

r_e

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

RE".

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

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

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

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

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

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

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



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

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

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


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

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

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

capstone2llvmir - --> Link <--

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



Ранг: 664.6 (! !)
Статус: Участник
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>


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


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

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

mak

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

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

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

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

Ранг: 243.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] - значение.

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

Создано: 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]

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

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

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

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

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

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

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

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


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

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

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


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

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


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

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

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

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

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

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


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

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

Сделай lea.

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

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

Archer пишет:
lea

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


Ранг: 664.6 (! !)
Статус: Участник
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 <--

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

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

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

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


Ранг: 664.6 (! !)
Статус: Участник
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

 eXeL@B —› Оффтоп —› LLVM, Clang для реверсинга

У вас должно быть 20 пунктов ранга, чтобы оставлять сообщения в этом подфоруме, но у вас только 0


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