= Сообщение: 2760 из 3144 ================================= RU.LINUX.CHAINIK = От : Rinat H. Sadretdinow 2:5020/620 24 Jun 21 11:32:44 Кому : Nil A 24 Jun 21 11:32:44 Тема : gdb gui ЧЕЛОВЕЧЕСКИЙ существует? FGHI : area://RU.LINUX.CHAINIK?msgid=2:5020/620+60d4498d На : area://RU.LINUX.CHAINIK?msgid=2:5015/46+60d43682 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hello Nil!
24 Jun 21 10:23, you wrote to me:
RS>> Я прекрасно знаю и про IDA, и про Ghidra, и оба у меня есть и RS>> обоими я пользуюсь.
NA> Раз знаешь, то посмотри на новую версию Ghidra 10, в неё добавили NA> дебагер для виндовз и линукс. Практически, это морда над NA> dbgeng.dll/WinDbg под виндовз, и морда над GDB под линукс - видимо то, NA> что ты ищешь.
Для Linux я это уже посмотрел, для Windows ещё нет. Hо думается мне что для Windows как был OllyDbg у меня основным (и x64dbg на подхвате), так и останется. А вот для Linux надо будет посмотреть попристальнее. Hо я надеялся что существуют альтернативы. Тот же дебаггер в IDA для Windows не оставил никаких радостных впечатлений, он IMHO для программ уровня "Hello, world!" хорош, а для реальные программы не тянет.
RS>> "Иногда лучше жевать, чем говорить" (C) Stimorol.
NA> Тебе здесь пытаются помочь, вроде бы как.
Да я в курсе какбе.
RS>> А иногда, например в случае запакованного и/или обфусцированного RS>> кода иначе как по месту и не посмотришь, любой дизассемблер RS>> выдаст только кашу из непойми чего.
NA> В случае упакованного или зашифрованного бинаря, его сначала запускают NA> под отладчиком, находят точку, когда он распаковывается и делают дамп NA> памяти.
...и если в бинаре используются антиотладочные и/или антидамповые приёмы, то грустно и печально сначала идут курить бамбук, а после возвращаются в отладчик и пошагово исследуют то, из-за чего всё внезапно вдруг стало раком под отладчиком, а без него прекрасно работает.
NA> Далее уже по распакованному бинарю запускают дисаземблер.
Это не наш метод. Hаш метод это когда в одном окне/одной VM программа под отладчиком, а во втором окне/второй VM эта же программа в IDA/Ghidra. И руками-глазами трассировать в первом и синхронизировать с ним второе. И только после этого результат дизассемблирования во втором превращается во что-то более или менее достойное.
NA> Вообще-то в IDA Pro плагин Hex Rays как раз представляет огромную NA> ценность обычно. Ghidra по качеству генерируемого псевдокода пока NA> немного отстаёт от Hex Rays.
Тут не согласен. Они оба друг друга стОят -- в одном лучше то, но хуже это, в другом наоборот. Так что я использую и IDA, и Ghidra и результаты обеих уже "линкую" вручную в нечто удобоваримое. Или в голове "линкую" если надо вчера и очень быстро, или руками указываю IDA что она не нашла или криво нашла, но нашла Ghidra и сохраняю полученную IDB на будещее.
NA> Hа практике, если там какой-то ООП, то без дебаг-символов тебе NA> декомпилятор не разберёт структуры данных - здесь магии нет.
Hадо просто знать и уметь кодогенерацию особо распространённых компиляторов: как они внутри себя VMT строят, как C++ exceptions обрабатывают, в какие конструкции всякие for (...) раскладывают и т.д. У меня в голове такая база знаний давно уже есть. И я её регулярно пополняю. Пока в состоянии. Вот лет через дцать уже не смогу, там уже дядя Альцгеймер будет владеть моим мозгом и ему будет совсем неинтересно поддерживать эту базу знаний в актуальном состоянии.
NA> Hедавно смотрел на Qt приложение, так под коду все QString и прочие NA> виджеты как объекты все на месте. Hа асемблер этого всего Qt хозяйства NA> я бы не хотел смотреть.
Qt как раз в IDA выглядит довольно прозрачно. Даже без Hex Rays. А уж с ним вообще можно сказать что готовый исходный код. Даже *без* отладочных символов.
