Сейчас на форуме: r0lka, johnniewalker, vsv1, NIKOLA (+4 невидимых) |
eXeL@B —› Крэки, обсуждения —› LLVM, Clang для реверсинга |
<< . 1 . 2 . |
Посл.ответ | Сообщение |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 09 декабря 2019 14:54 · Личное сообщение · #1 |
Ранг: 419.0 (мудрец), 647thx Активность: 0.46↗0.51 Статус: Участник "Тибериумный реверсинг" |
Создано: 31 января 2020 09:56 · Личное сообщение · #2 mak пишет: получить информацию, специфичную для текущего состояния. Как профит - внести корректировку в данную инфу и отправить далее на следующий шаг исправленный вариант. Но это для всяких протекторов годится по идее. Или в случаях, когда вижу, что компмлятор не смог самостоятельно родить оптимизированный код - не использовал регистры в цикле, который работает 100500 раз или когда хочется экзотики в виде использования регистра ESP/RSP, как общего назначения, а EAX/RAX вместо него. Но llvm только предоставляет эту инфу, а инструменты ее корректировки - через тест можно понять .. |
|
Создано: 31 января 2020 10:38 · Поправил: plutos · Личное сообщение · #3 может кому-то будет интересно: Почти без "воды", конкретные примеры (10,000 lines of source code!), даже я начинаю понимать! Book example code: The example code lbdex.tar.gz is available in: ну и Корифеи наверное это уже и так знают, но если кто только вступает "в тему", то в самый раз! ----- Give me a HANDLE and I will move the Earth. | Сообщение посчитали полезным: mak, sefkrd, Hugo Chaves, bartolomeo, ELF_7719116 |
|
Создано: 07 февраля 2020 13:38 · Поправил: mak · Личное сообщение · #4 SATURN -- Software Deobfuscation Framework Based on LLVM The strength of obfuscated software has increased over the recent years. Compiler based obfuscation has become the de facto standard in the industry and recent papers also show that injection of obfuscation techniques is done at the compiler level. In this paper we discuss a generic approach for deobfuscation and recompilation of obfuscated code based on the compiler framework LLVM. We show how binary code can be lifted back into the compiler intermediate language LLVM-IR and explain how we recover the control flow graph of an obfuscated binary function with an iterative control flow graph construction algorithm based on compiler optimizations and SMT solving. Our approach does not make any assumptions about the obfuscated code, but instead uses strong compiler optimizations available in LLVM and Souper Optimizer to simplify away the obfuscation. Our experimental results show that this approach can be effective to weaken or even remove the applied obfuscation techniques like constant unfolding, certain arithmetic-based opaque expressions, dead code insertions, bogus control flow or integer encoding found in public and commercial obfuscators. The recovered LLVM-IR can be further processed by custom deobfuscation passes that are now applied at the same level as the injected obfuscation techniques or recompiled with one of the available LLVM backends. The presented work is implemented in a deobfuscation tool called SATURN. Comments: reverse engineering, llvm, code lifting, obfuscation, deobfuscation, static software analysis, binary recompilation, binary rewriting Subjects: Cryptography and Security (cs.CR); Symbolic Computation (cs.SC) Journal reference: 3rd International Workshop on Software PROtection, Nov 2019, London, United Kingdom Info Tests ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube | Сообщение посчитали полезным: plutos, v00doo |
|
Создано: 08 февраля 2020 02:43 · Личное сообщение · #5 |
|
Создано: 19 апреля 2020 09:06 · Личное сообщение · #6 Еще один tutorial по теме LLVM and Binary Obfuscation. Build your first Мне было интересно, поэтому решил поделиться, но, как всегда: НИКАКОЙ ГАРАНТИИ ЗА КАЧЕСТВО! ----- Give me a HANDLE and I will move the Earth. |
|
Создано: 19 апреля 2020 13:33 · Личное сообщение · #7 |
|
Создано: 19 апреля 2020 14:41 · Личное сообщение · #8 |
|
Создано: 19 апреля 2020 16:08 · Личное сообщение · #9 |
|
Создано: 21 апреля 2020 01:01 · Поправил: Illuzion · Личное сообщение · #10 Попробовал, вообще вроде как неплохо сворачивает. Небольшой пример из реального протектора: Code:
Получаем такое: Code:
После компиляции "gcc -O3" с парой Warning получаем такое: Code:
Прямо как-то вообще же красиво ? Всё посчитал и свернул как надо. Второй пример попробовал из этого топика Code:
cppasm, а Вы предлагаете вот прямо из такой каши (см. ниже) делать оптимизацию и сразу в асм сворачивать? Ну.. Конечно для простых примеров и пары mov/push это вроде не сложно реализовать, а для более сложного страшновато выглядит. Или готовые полу-/средства есть? Code:
|
|
Создано: 21 апреля 2020 02:52 · Поправил: plutos · Личное сообщение · #11 plutos пишет: может кому-то будет интересно: --> Tutorial <--: Creating an LLVM Backend for the Cpu0 Architecture, Release 3.9.1 кто-нибудь пытался по этому туториалу собрать Cpu0 example code? Appendix A: Getting Started: Installing LLVM and the Cpu0 example code Все собирается нормально, но после всех шагов в ~/llvm/test/src/lib/Target/Cpu0/ExampleCode/lbdex/InputFiles эти самые ExampleCode/lbdex/InputFiles отсутствуют. Т.е. ~/llvm/test/src/lib/Target/Cpu0 есть, а дальше нет. Использовал Cpu0 example code, lbdex отсюда: http://jonathan2251.github.io/lbd/lbdex.tar.gz. ----- Give me a HANDLE and I will move the Earth. |
|
Создано: 21 апреля 2020 03:32 · Поправил: Bronco · Личное сообщение · #12 общие схемы оптимизации работают только на примитивном морфе, под каждую задачу свой рашпиль, и всё, от общих схем начинаешь уходить, и упираешься в шаблоны. ибо раскручивать многое довольно сложно, сейчас как правило оно многослойное, и с матрицей перестановок. но самое главное, что перед рашпилем, надо хорошо повозиться с исходником ручками и глазками. хз есть ли смысл тратить время на изучение такого огромного проекта как ллвм. ибо памяти и дисковой и оперативной требует то же не мало. ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 21 апреля 2020 11:27 · Личное сообщение · #13 Illuzion пишет: cppasm, а Вы предлагаете вот прямо из такой каши (см. ниже) делать оптимизацию и сразу в асм сворачивать? Ну.. Конечно для простых примеров и пары mov/push это вроде не сложно реализовать, а для более сложного страшновато выглядит. Или готовые полу-/средства есть? Это не надо реализовывать. В LLVM есть оптимизатор (opt), который оптимизирует код после компиляции, и он работает с LLVM IR. Надо из нативного кода получить LLVM IR и на него натравить opt. Ну насколько сильно то что он наоптимизирует соответствует тому что ты хочешь это вопрос, но по идее будет то же самое что при компиляции C кода получается. Как по мне, поднимать LLVM IR по Си кода это сложная задача, и излишняя в данном случае. Ну и вот такое ещё есть, но я не юзал: https://github.com/google/souper | Сообщение посчитали полезным: Illuzion |
|
Создано: 21 апреля 2020 15:35 · Личное сообщение · #14 Bronco пишет: общие схемы оптимизации работают только на примитивном морфе, под каждую задачу свой рашпиль, и всё, от общих схем начинаешь уходить, и упираешься в шаблоны. ибо раскручивать многое довольно сложно, особенно когда код смешанный и с перестановками. но самое главное, что перед рашпилем, надо хорошо повозиться с исходником ручками и глазками. хз есть ли смысл тратить время на изучение такого огромного проекта как ллвм. ибо памяти и дисковой и оперативной требует то же не мало. Общие схемы нормально работают на любом коде, т.к. есть абстракция в LLVM-IR, но перед этим конечно нужно развернуть код в линейный, а это большая тема, много техник есть и каждая подходит в своём конкретном месте, но есть и универсальные, у тебя они есть, т.к. ты уникорн используешь. А шаблоны там реализуются очень удобно, можно гибко настраивать оптимизацию под каждый случай (редкий случай). Я ожидал, что Ида Про будет развивать это "линейное" направление, но они тупо слились со своим питоном и системой плагинов. cppasm пишет: Ну и вот такое ещё есть, но я не юзал: https://github.com/google/souper Линейный фронтенд нужен в любом случае, но проект классный. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
Создано: 21 апреля 2020 23:24 · Личное сообщение · #15 mak пишет: Общие схемы нормально работают на любом коде, никто не спорит, только оппоненты не дебилы, и то же юзают эти же тулзы, и на них шлифуют свои гавнокодища. так что ожидать чуда от такой оптимизации не стоит, а время на адаптацию оно заберёт. тем более, не ведая чего ты хочешь получить на выходе, а опираясь только на промежуточный результ, можно довольно долго ковырять эти портянки,и не факт что выхлоп будет правильный, или без ошибок. ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 22 апреля 2020 01:13 · Поправил: plutos · Личное сообщение · #16 plutos пишет: кто-нибудь пытался по этому туториалу собрать Cpu0 example code? Если кто-нибудь столкнется с подобной проблемой - решение очень простое: используйте Другие, старые версии, очень похожи на настоящиe, но не работают! ----- Give me a HANDLE and I will move the Earth. |
|
Создано: 23 апреля 2020 01:53 · Поправил: Illuzion · Личное сообщение · #17 Попробовал много разных связанных с LLVM проектов, но так до конца и не понял про оптимизацию. Вроде "оно" и оптимизирует код, но его совсем потом не узнать - получается вообще другой код. Точнее, может он и делает то же самое (не уверен я), но выглядит как совсем две разные программы. Вот, например длинная портянка обфускации (просто видно что большая): Code:
По-человечески, получается, всего лишь: Code:
А после оптимизации opt или retdec: Code:
Оптимизация вообще неверно сделана. Перед последним вызовом 0x03df2d4 там в стек летят непонятные числа. Откуда они взялись, как он оптимизировал - мрак И ещё вопрос. При работе с шаблонами мы руководствуемся именно шаблонами инструкций? Что, собственно, просто. Т.е. : Code:
Сворачиваем в: Code:
Или же мы Taint Analysis всей трассы делаем? Т.е. упрощаем код не по инструкциям, а по изменениям, которые этот код производит. Собираем все изменения и в один прекрасный момент машина/наш код понимает, что изменить data по адресу 0х1 и 0х4 с числа семь на число восемь можно было всего лишь одной инструкцией X, а остальные 20 инструкций были ненужны - и оп, чудо, удаляем их? |
|
Создано: 23 апреля 2020 04:37 · Личное сообщение · #18 Illuzion пишет: Вот, например длинная портянка обфускации абстракция не глубокая, ваще почти нет, всё как на ладошке. многое читаемо, под морфом только дисплейшен и имидиата. перестановок нет, pushad&popad нет, радуйся что за контекстом следить не надо. если с промежуточным кодом тебе комфортней и есть преимущества, сам дели на блоки и скармливай оптимайзеру&решателю. Illuzion пишет: Оптимизация вообще неверно сделана. шо и требовалось доказать, улыбнуло. ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 23 апреля 2020 10:36 · Личное сообщение · #19 Illuzion Знакомая вм Ну ты пока в самом начале пути. Рано или поздно ты придешь к этому Сам интерпретатор выполняет байткод который тоже разбавлен мусором. На чём собственно, я и слился Оригинальный код ты всё равно уже никогда не достанешь. Illuzion пишет: И ещё вопрос. При работе с шаблонами мы руководствуемся именно шаблонами инструкций? Да, но там их практически никак не применить Добавлено спустя 50 минут Bronco Извини, но ты не мог бы по-русски писать, хоть немного? Я, наверное, не совсем нуб в "сленге", но реально иногда вообще не понимаю о чем ты пишешь, как впрочем и автор х64dbg. Что такое "абстракция не глубокая" и "дисплейшен"? Там есть и перестановки регистров, и pushad&popad, и за контекстом следить надо... а это чуть меньше чем 256 rvm регистров, Речь про RISC подобную машину с примитивными операциями("load","store" и простыми мат. операциями "+", "-", "*", "/", "not", "and") | Сообщение посчитали полезным: Illuzion |
|
Создано: 23 апреля 2020 11:30 · Поправил: Illuzion · Личное сообщение · #20 SReg пишет: Illuzion Знакомая вм Ну ты пока в самом начале пути. Не совсем так =) Квест "сделать что-надо" я прошёл достаточно просто. Решаю квест "как оно работает", мне кажется, он на порядок сложнее. Но главное, чтобы было интересно SReg пишет: Сам интерпретатор выполняет байткод который тоже разбавлен мусором. Там часто в критических местах RET из ВМ на абсолютно чистую функцию ведёт, где проверки имя/код и т.п. SReg, а вообще, теоритически реально ли по изменениям какой-либо информации в регистрах/памяти сгенерировать код, который бы изменения такие же делал? Т.е. не упростить данное, а именно отследить все изменения и сделать новый код? |
|
Создано: 23 апреля 2020 11:44 · Личное сообщение · #21 Illuzion пишет: Самое главное, что часто в критических местах RET из ВМ на абсолютно чистую функцию ведёт. Там что-то авторы не доделали. Ну, не будь слишком самоуверенным, в той другой твоей теме, я просто поленился тот бред комментировать Ты про какой ret, приведи пример? Всё там сделано как надо. ret там только в конце хендлера 'vm_exit' после восстановления контекста (vm_ctx->real_ctx) |
|
Создано: 23 апреля 2020 11:59 · Поправил: Illuzion · Личное сообщение · #22 SReg пишет: в той другой твоей теме, я просто поленился тот бред комментировать В чём был бред там? Конкретней, пожалуйста. SReg пишет: Ты про какой ret, приведи пример? Пример: Code:
И, собственно, он ведёт много куда, но вот, например, сюда: Code:
|
|
Создано: 23 апреля 2020 12:50 · Личное сообщение · #23 Illuzion пишет: Попробовал много разных связанных с LLVM проектов, но так до конца и не понял про оптимизацию. Это бред .. зачем это делать? Проекты ради примеров хороши, но все проекты, что я видел сделаны через ж, т.к. автор слабо понимает, что он делает, 80 процентов кода можно выкинуть из проекта. Зачем брать ретдек ?!?! А потом сравнивать с другим выхлопом ?! Что за .... Illuzion пишет: Точнее, может он и делает то же самое (не уверен я), но выглядит как совсем две разные программы. Две причины на то, первая, ты НЕ развернул код на линейный, вторая причина - после ИР обработки формируются новые шаблоны, но код должен быть узнаваем и это НОРМАЛЬНО. Illuzion пишет: Оптимизация вообще неверно сделана. Всё там нормально сделано Ты хочешь наскоком получить сразу результат, что ты ожидаешь? Алгоритм такой: Линеаризация кода (Деление на блоки, построение графа полиморфа(позволяет разобрать любой уровень мутации на автоматике), построение и инициализация Датафлоу(можно через эмулятор - на ВМП работает на ура, а можно через отладчик, а можно с дамми в комбинациях, это требуется только для первичной инициализации, своего рода интерфейс для блоков, т.е. весь граф датафлоу не нужен)), далее оптимизация и сборка, здесь работает ещё один аддон, который парсит редкие стейтменты. Первый и третий пункт, ты должен сам закодить, этого нет нигде. Что делаешь ты, ты взял код без фронтенда, перегнал его через оптимизацию(средставми которые заточены под другие цели :s2, потом взял повторил это шаг другим инструментом и сравнил код .. WTF ?! Illuzion пишет: И ещё вопрос. При работе с шаблонами мы руководствуемся именно шаблонами инструкций? Что, собственно, просто. Т.е. : Illuzion пишет: Или же мы Taint Analysis всей трассы делаем? И то и то ... сорсы открыты, ты можешь всё посмотреть .. Это как раз из первого поста ELF_7719116 пишет: это как прочитать всю "Война и мир" Толстого и попытаться осознать всю глубину сюжета. Архитектуру нужно изучать, а потом уже судить Bronco "шо и требовалось доказать" Добавлено спустя 8 минут mak пишет: но все проекты, что я видел сделаны через ж, т.к. автор слабо понимает, что он делает Имеется ввиду проекты оптимизаторы, не декомпили .. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube | Сообщение посчитали полезным: ELF_7719116, plutos |
|
Создано: 23 апреля 2020 13:00 · Личное сообщение · #24 Illuzion пишет: В чём был бред там? Конкретней, пожалуйста. да так во многом, если не во всём ты бы лучше прислушивался, а не обижался Ок. Например в Применим блочный RC5 Это которого там в помине никогда не было, есть RC4. Далее вшитый в программу 256-битный ключ ты просто не увидел RC4Init в XML файле проекта это <HardwareConstant>, а принял развернутый ключ как за "вшитый" Далее, Используем шаблон "ABCDEF1234567890" тут я вообще в осадок выпал, т.к. это называется Base16ToBase256 Далее, контрольная сумма это младшие 16 бит от СRC32 (где данные это длина base256 hw без первого word) Далее, есть паблик скрипты. Сейчас этого не сделать, т.к. по-сути там нет цельного понятия хвид, он только для пользователся в таком виде представлен тут ты даже не понял, почему скрипты внезапно не работает. Ок, подскажу: потому что vcl функции теперь под ВМ, такие как LStrLen, LStrFromPChar, и т.д. по второму: Illuzion пишет: Пример: Ну и? В чем вопрос-то, что некоторые инструкции не транслируются (fpu reg, cpuid)? И это кстати тоже vm_exit и переход на реальный код, а ты выше спрашивал про совершенно другую вм, и оттуда приводил куски. Добавлено спустя 6 минут Illuzion пишет: SReg, а вообще, теоритически реально ли по изменениям какой-либо информации в регистрах/памяти сгенерировать код, который бы изменения такие же делал? Т.е. не упростить данное, а именно отследить все изменения и сделать новый код? Я, наверное, не понял тебя. Буду угадывать. Тебе за первый (первые) проходы необходимо сгенерить "свой" пром. код, чтобы у тебя было представление что он вообще делает. Потом как-то (я не знаю как, т.к. на этом и застрял в своё время) нужно выкинуть мусор из этого пром кода. А потом его попробовать компилировать. т.к. определить что мусор а что нет можно только на глаз втыкая в этот пром код, автоматику я не знаю как применить, а шаблонов там нет. По идее, это бы положить на плечи оптимизатора З.Ы. Естественно я щас пишу про RISC, а та вм что ты говоришь она для новичков, и лично мне совершенно не интересна... Добавлено спустя 15 минут mak пишет: после ИР обработки формируются новые шаблоны в той вм, про которую он говорил, там на ИР не применить шаблоны, так как она не шаблонная з.ы. А, вру. Разве что только на циклах. | Сообщение посчитали полезным: v00doo |
|
Создано: 23 апреля 2020 13:21 · Личное сообщение · #25 SReg согласен, спасибо. SReg пишет: Ну и? В чем вопрос-то, что некоторые инструкции не транслируются (fpu reg, cpuid)? И это кстати тоже vm_exit и переход на реальный код, а ты выше спрашивал про совершенно другую вм, и оттуда приводил куски. Странно, тут видимо 2 ВМ? Это все один файл. Просто они не транслируют не только инструкции, а целые функции самого протектора, результаты которых мы можем менять. |
|
Создано: 23 апреля 2020 13:28 · Поправил: mak · Личное сообщение · #26 SReg пишет: в той вм, про которую он говорил, там на ИР не применить шаблоны, так как она не шаблонная з.ы. А, вру. Разве что только на циклах. Топик про ЛЛВМ, а не про разбор ВМ-ок, я имел ввиду шаблоны оптимизации для ЛЛВМ, чтобы разбирать ВМ на ЛЛВМ нужно сделать дополнительные движения в первом и третьем пункте, что я считаю слишком кучным, поэтому нужно выносить АПИ на внешний компонент и делать фреймворк, а не лепить всё в один пакет. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube | Сообщение посчитали полезным: SReg |
|
Создано: 23 апреля 2020 13:43 · Личное сообщение · #27 mak пишет: Топик про ЛЛВМ, а не про разбор ВМ-ок Вот тут да, согласен. Сливаюсь. Если бы еще на практике так было всё просто как в теории... Эх-х Illuzion пишет: Странно, тут видимо 2 ВМ? Это все один файл. Просто они не транслируют не только инструкции, а целые функции самого протектора, результаты которых мы можем менять. Да, две. И совершенно разные. Начни с простого, концепции ВМ например, многое станет понятно и вопросы отпадут. Транслятор это то, что транслирует например асм86 код в байткод, под другой процессор. А у тебя в файле интерпретатор, который и исполняет "транслированный" байт-код |
|
Создано: 23 апреля 2020 21:11 · Поправил: Bronco · Личное сообщение · #28 SReg пишет: Извини, но ты не мог бы по-русски писать, хоть немного? сорян, но что на уме то и на языке, иногда зайду поправлю. SReg пишет: Что такое "абстракция не глубокая" и "дисплейшен"? 1. в той портянке что выложили, и скармливали оптимайзеру, код читабельный без трассировки, поэтому и не глубоко. 2.disp ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
|
Создано: 23 апреля 2020 23:32 · Личное сообщение · #29 Illuzion пишет: Откуда они взялись, как он оптимизировал - мрак Это потому что у llvm оптимизации заточены под другое, они содержат и общие оптимизации в том числе, но для деобфускации подходят лишь косвенно. Взять проект который с горем пополам транслирует x86 в llvm ir, применяет стандартные проходы, и затем компилирует как C обратно в x86, и при этом надеятся получить чистый код очень опрометчиво. Больше толка будет если вы напишете анализатор примитивов, далее статическую трассировку этих примитивов в llvm-ir, и уже тогда прокрутите оптимизацию. Bronco пишет: оптимайзеру дисплейшен результ имидиата Ю вери лайк ту транскрипт инглиш вордс ин рашн, плиз стап зис шит. ----- В облачке многоточия | Сообщение посчитали полезным: Illuzion |
|
Создано: 23 апреля 2020 23:55 · Поправил: ClockMan · Личное сообщение · #30 |
|
Создано: 24 апреля 2020 00:23 · Личное сообщение · #31 |
<< . 1 . 2 . |
eXeL@B —› Крэки, обсуждения —› LLVM, Clang для реверсинга |