Комментарии 16
Раз уж делаете трансформации кода, и есть предложения по feature requests, не добавите code folding? Я пользуюсь Hexlight, конечно, но иногда так и тянет убрать большой блок, чтобы не маячил перед глазами. Впрочем, настаивать не буду.
Есть "Collapse/uncollapse item" (https://www.hex-rays.com/products/decompiler/manual/interactive.shtml). Не то ли это что вам нужно?
В любом случае, code folding, как мне кажется, это не трансформация кода. Дерево же при этом не меняется, просто скрываются отдельные его части при отображении.
Тут сразу напрашивается feature request. Иногда в коде встречается слишком много inline функций. Приходилось разбирать бинарник где чуть ли не в каждой десятой строчке был заинлайнен деструктор строк. Удобно было бы скрыть их все автоматически. В идеале их хорошо бы вообще вынести отдельно, но это уже более сложная задача.
А вот сокрытие произвольных областей по маске было бы интересно, не часто вижу обфусцированный код, но полагаю, там особенно актуально.
Перестройка дерева довольно мудрено сделана в IDA — там нужно унаследовать класс, у которого паттерн Visitor. Затем, в процессе обхода всего дерева, распознать то, что хотим изменять и там же или отдельным классом-наследником Visitor перестроить дерево. Можно у меня посмотреть как это делается с отрицательными смещениями и переворачиванием условий в конструкции if
. В общем, каждый такой случай, который хочется скрывать скорее всего придется программировать отдельно (впрочем можно этому научиться и, если потратив на это некоторое время, можно будет потом сэкономить гораздо больше, то это стоит того)
Насчет folding. Ида прячет сразу всё, но хотелось бы всё же условие у for
, while
и if
видеть и иметь возможность отдельно True и False ветки сворачивать.
Есть неочевидные вещи, например, IDA Pro будет падать, если не отключать Garbage Collector для объектов, добавленных с помощью idaapi в абстрактное синтаксическое дерево
Какое-то время назад при реверсинге прошивки под ARM столкнулся с тем, что Hex-Rays не распознает одну инструкцию и оставляет ее в asm {}. Она использовалась повсюду и это очень сильно портило код. Попытался написать плагин, который бы заменял эти блоки asm {}. Но как только я стал добавлять свои узлы в дерево — IDA сразу падала. Никогда бы не подумал что проблема может быть в Garbage Collector.
В итоге проблему решил, заменив везде инструкцию на аналогичную, с которой у Hex-Rays было все в порядке. Но тут можно сказать повезло, так как такой могло и не оказаться.
Можно было бы, используя стандартную опцию "map to another variable", избавиться от них. Но это не всегда удобно при отладке, может быть ошибочно и к тому же невозможно откатить не пересоздавая функцию заново.
Почему невозможно? Есть же "unmap variable": https://www.hex-rays.com/products/decompiler/manual/cmd_map_lvar.shtml
В блоге Hex-Rays многое можно почерпнуть. Вот например HelloWorld в мире плагинов Иды http://www.hexblog.com/?p=120#PLUGIN_KEEP
— «IDA Pro Book, 2nd Edition» https://www.nostarch.com/idapro2.htm
— «The Beginner's Guide to IDAPython» hooked-on-mnemonics.blogspot.ru/2015/04/the-beginners-guide-to-idapython.html
— «Gray Hat Python» https://www.nostarch.com/ghpython.htm
— Читать код чужих плагинов
HexRaysPyTools: декомпилируй с удовольствием