Grease — утилита для поиска ошибок в бинарных файлах

плагином к системе обратного инжениринга Ghidra

Насколько помню эту гидру АНБ сделала. Ой не к добру это...

Насколько помню эту гидру АНБ сделала.

АНБ много что сделали. Гидра имеет открытый код, можешь сам проверить его.

Первый раз вижу Haskell в контексте какой-то полезной проги (да ещё и сразу такой высококвалифицированной) а не эзотерического программирования.

Первый раз вижу Haskell в контексте какой-то полезной проги (да ещё и сразу такой высококвалифицированной) а не эзотерического программирования.

Это потому что ты не в теме. Те же Galois пачку тулинга на нём опубликовали уже. Другой пример от них же:

https://github.com/GaloisInc/reopt

Reopt is a general purpose decompilation and recompilation tool for repurposing application logic. It does this by analyzing machine code to recover a more flexible program representation – specifically the LLVM assembly language. Once in this format, one can then apply optimization tools to optimize the LLVM, recompile the application into optimized or security hardened object code, and use Reopt to merge the recompiled code back into the original executable.

АНБ много что сделали.

Не нужно думать что они что то просто так делают. Я уверен что этот grease как раз они и будут использовать, а сообщество будет его развивать и поддерживать.

Гидра имеет открытый код, можешь сам проверить его.

А ты сам когда нибудь пытался проверить открытый проект?

Первый раз вижу Haskell в контексте какой-то полезной проги

xmonad же! А если более серьёзно, то на Haskell-е много чего полезного сделано.

АНБ много что сделали.

Не нужно думать что они что то просто так делают.

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

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

А ты сам когда нибудь пытался проверить открытый проект?

Да.

на Haskell-е много чего полезного сделано

Конечно! pandoc, например.
Как можно о нём не знать, непонятно.

Не думаю, что тут у них есть прямо какой-то мегаплан.

Мегаплан вряд ли, а вот оптимизация расходов...

Да.

И как успехи?

Да.

И как успехи?

Нашёл несколько дыр, заслал патчи :)

Это единственные две программы которые написаны на хаскеле о которых я знаю.

Гидру, вроде, да. И не сделала, а проспонсировала. А этот проект вот

This material is based upon work supported by the Defense Advanced Research Projects Agency under Contract No. W31P4Q-22-C-0017 and W31P4Q-23-C-0020.

Опаньки! Интересная штука. Надо на скомпилированный код на Расте это дело натравить :)

Опаньки! Интересная штука. Надо на скомпилированный код на Расте это дело натравить :)

https://galoisinc.github.io/grease/rust-programs.html

ты неправедлив. На хаскеле еще мегаполезный для разработчиков микросхем klayout написан.

ты неправедлив. На хаскеле еще мегаполезный для разработчиков микросхем klayout написан.

Это он ещё просто про clash не знает.

Это только растаманы существующее переписывают. А на Хаскеле пишут то, чего не было :) Единственное, переписанное на хаскеле, из того, что я знаю, — это Matterhorn, TUI-клиент для матермоста.

Вердикт. Ниасилил, сукасложно! :)

как раз они и будут использовать, а сообщество будет его развивать и поддерживать

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

есть shellcheck на haskell… ах ты же программируешь в блокноте…

ну, тут он не уникален. Навскидку еще из той же оперы Chisel (Scala), MyHDL (Python). Все равно чистый SystemVerilog лучше.

Chisel (Scala)

Я почитал про него и… пытаться натянуть ООП на описание железа – это просто жесть.

Как можно о нём не знать, непонятно.

Элементарно. Как можно не понимать, непонятно.

pandoc?

arm поддерживается интересно?

grease supports analysis of ELF executables or shared objects containing ARMv7l, PowerPC, or x86_64 code. grease can also analyze LLVM bitcode.

dataman добавь плз это в текст новости.

GREASE supports analysis of AArch32, PPC32, PPC64, and x86_64 Linux ELF binaries, as well as LLVM bitcode.

Ага, спасибо, тоже нашёл.

Жаль arm64 пока не поддерживается.

Проверил гидру гидрой, сказала всё чётко на раёне. Я спокоен.

Есть же как минимум pandoc.

За компанию к AES (который Rijndael) и SELinux-у? :)

shellcheck еще, тоже очень полезная штука для проверки шелловых портянок.

Посмотрим...

...открыли гидру потому что на неё зарезали финансирование из-за бюрократии...

Откуда дровишки?

Совершенно непонятно, нафига нужна именно эта прога. У них есть другая, с тем же алгоритмом, но только без всякой декомпиляции: https://github.com/GaloisInc/crucible/tree/master/uc-crux-llvm

Работает, как я понял, с LLVM-IR, сгенерённым с помощью clang. Ну и это круто, а вот делать то же самое через декомпиляцию - по-моему, «эталонное ненужно».

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

«Эталонное ненужно» это тот бред, который ты пишешь. Если у тебя есть llvm ir то у тебя скорее всего есть и исходник, и ты можешь пользоваться обычным анализатором для исходника. А эта прога совсем для другого, и поддержка llvm ir в неё скорее всего добавлена просто потому что это было несложно.

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

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

В общем, позадавайте себе этот вопрос в разных вариациях. :)

И вот ещё вопрос: чего в добьётесь, найдя потенциальную ошибку в проге без исходников? Править-то как?

Если у тебя есть llvm ir то у тебя скорее всего есть и исходник, и ты можешь пользоваться обычным анализатором для исходника.

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

Вердикт. Ниасилил, сукасложно! :)

much of the standard library will be included in a typical Rust program

Т.е. для больших программ на C/C++ тоже не подойдет, это для анализа Hello world’ов?

Это анализатор для скомпилированного кода, когда ты просто достал/украл откуда-то неизвестный бинарник и хочешь по-быстрому найти список возможных векторов атаки на него для дальнейшего анализа, не тратя на эту подготовку ручную работу. А вовсе не для анализа собственного софта к которому у тебя есть все материалы - для этого есть традиционные средства. Так что твоё «давайте просто возьмём вывод компилятора» это чушь, свидетельствующая о полном непонимании темы.

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

Я вообще не занимаюсь анализом under-constrained execution программ. Значит ли это, что ни сабж, ни твой анализатор не нужны?

Теперь три)))

Так ошибок или уязвимостей?

Это анализатор для скомпилированного кода, когда ты просто достал/украл откуда-то неизвестный бинарник

Так вы виндузятник чтоль? У нас-то все исходники есть, и ничего красть не нужно.

Я вообще не занимаюсь анализом under-constrained execution программ.

under-constrained execution - это техника, которую они используют для анализа. Грубо говоря, это означает, что они накладывают «слабые» ограничения по контрактам на исполнение различных блоков данной программы. А значит, детектят не всё. Есть ещё over-constrained execution - это когда ограничения накладываются сильные, и с ними можно попробовать доказать полную валидность программы.

Я это понимаю, в моем сообщении стоило написать «under-constrained execution анализом программ».

…открыли гидру потому что на неё зарезали финансирование из-за бюрократии…

Откуда дровишки?

Читал где-то как раз когда её открыли.

Я это понимаю

Тогда должно быть понятно и то, что анализ «украденного бинарника», а не нормальной программы - это лишь частный, никому (кроме firkax) не нужный случай. Техника применима и при анализе через исходники.

Какой же ты тупой... Отпишись от тега reverse engineering, ничего кроме позора ты в нём не напишешь.

Похоже, вам по мозгам не только переход на uefi бьёт (про который вы в соседнем топике высказывались), но и вообще, СПО и открытые экосистемы, типа ARM. Нет уж, батенька, «воруйте» и реверсьте х86 бинарники 30летней давности сами, а у нас и других дел хватает. :) Например, анализировать открытый софт тулзами этой же конторы.