IDA Pro: каким не должен быть SDK +31




Приветствую,



Эта статья будет о том, как не нужно делать, когда разрабатываешь SDK для своего продукта. А примером, можно даже сказать, самым ярким, будет IDA Pro. Те, кто хоть раз что-то разрабатывал под неё и старался поддерживать, при чтении этих строк, наверняка, сейчас вздрогнули и покрылись холодным потом. Здесь я собрал опыт сопровождения проектов, начиная с IDA v6.5, и заканчивая последней на момент написания статьи версии — v7.5. В общем, погнали.


Краткое описание


SDK для IDA Pro позволяет вам разрабатывать следующие типы приложений:


  • Загрузчики различных форматов
  • Процессорные модули
  • Плагины, расширяющие функционал (процессорных модулей, интерфейса и т.п.)
  • IDC-скрипты (свой внутренний язык) и Python-скрипты (используют стороннюю разработку IDAPython, которая стала неотъемлемой частью IDA)

По информации с сайта Hex-Rays, стоимость плана поддержки SDK — 10000 USD. На практике же — если у вас есть лицензия, вам даётся код доступа к Support-зоне, в которой вы его скачиваете и работаете с ним. Стоимость же указана на тот случай, если у вас будут появляться вопросы и вы захотите задать их разработчикам: без плана поддержки вам скажут, мол, напишите это сами; с поддержкой же, как я понимаю, отказать вам не могут. К сожалению, я не знаю ни одного человека (фирмы), который купил данный план.


Немного подробнее


С того момента, как у вас появляется желание написать что-то под IDA, и вы скачиваете SDK, вы ступаете на достаточно скользкую дорожку, на которой, к тому же, очень легко сойти с ума. И вот почему:


1) В современной разработке вы, скорее всего, уже привыкли к тому, что у любого более-менее серьёзного проекта есть либо doxygen-сгенерированная справка по API, либо вручную написанная хорошая справка, которая вам говорит что куда передаётся, что нужно заполнять, чтобы работало, и т.п., с кучей примеров.


В IDA практически в большинстве доступных пользователю API указаны лишь имена параметров и их типы, а что туда передавать — можно отгадывать лишь по именам аргументов. В последнее время, конечно, со справкой у IDA стало получше, но не то что бы значительно.


2) Во многих заполняемых структурах требуется задавать callback-функции, при этом некоторые указаны как необязательные, мол, не укажешь (передашь NULL) — и ладно. В действительности — крэши приложения при попытке запуска вашего плагина. И, т.к. колбэков много (пример — плагин-отладчик), ты начинаешь поочерёдно задавать все, которые "можно не задавать". В итоге это очень сильно утомляет, ты открываешь x64dbg/ollyDbg, в нём — idaq.exe/ida.exe, грузишь плагин, ставишь точки остановки, и пытаешься словить момент, когда управление передаётся в 0x00000000.


Эх, помню те времена, когда так много папок с проектами были забиты 200MB dmp-файлами, которые создавались при крэше IDA… Но мне они ничем не помогали.


3) Самая болезненная тема для IDA Pro — обратная совместимость. В принципе, это достаточно тяжёлая для любого разработчика задача — наперёд продумывать интерфейсы, структуры, модульность и т.п. Поэтому здесь и возникает два пути:


  • Хранить обратную совместимость со всеми старыми версиями
  • Не заниматься обратной совместимостью

В первом случае очень быстро накапливается legacy-код, от которого потом становится невозможно избавиться. Вычистить его редко кому удаётся. Потому как, фактически, нужно бросать все силы не на разработку нового функционала, а на выпиливание/перенос старого.


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


Что же в случае Hex-Rays? Вы удивитесь, но они пошли двумя путями одновременно! Известно, что проект развивается с очень и очень бородатых времён, когда основной целевой платформой был лишь MS-DOS (и, следовательно, реверс-инжиниринг написанных под него приложений). Нужно было поддерживать сегментные регистры, селекторы, параграфы и другую подобную атрибутику. Шло время, в IDA начали появляться другие платформы, процессорные модули и загрузчики, где модель памяти уже была плоской (flat), но пережиток в виде перечисленных мной MS-DOS "фич" сохраняется до сих пор! Весь интерфейс IDA пронизан этим. При разработке процессорных модулей, в который только flat, вам всё равно придётся указывать сегментные регистры (правда уже виртуальные).


А вот с SDK ни о какой обратной совместимости речи идти не может вовсе. В каждой новой версии (даже внутри минорных билдов 6.x и 7.x) что-то да ломается: у колбэков появляются новые аргументы, у старых структур переименовываются и теряются поля, функции API, которые раньше делали одну задачу, теперь делают другую. И таких примеров много.


И ладно бы это всё хоть как-то сопровождалось разработчиком, мол, в этой версии поменялось то и это, теперь нужно так и так. Так нет же! Гайд есть, да: IDA 7.0 SDK: Porting from IDA 4.9-6.x API to IDA 7.0 API, но это всё. Более того, по нему вам не удастся перевести свой проект на новую версию, т.к. он не включает очень многих, но мелких, изменений, о которых, конечно же, вам никто не сообщит. К тому же, это последний гайд для C/C++ разработчика, а с тех пор вышло ещё где-то 5-6 версий SDK.


По итогу получается, что внутри фирмы поддержка обратной совместимости есть, а для внешних пользователей, которые заплатили деньги — нет.


Реальный пример


Когда-то я взял на себя смелость попытаться разработать свой первый плагин-отладчик Motorola 68000 под IDA. В поставляемом SDK был пример отладчика (который, фактически, используется в IDA Pro и сейчас в качестве локального и удалённого), но он был выполнен настолько плохо, что пытаться по нему сделать свой было невозможно. Тогда я полез в интернет и нашёл единственный плагин-отладчик — для PS3, который, что забавно, был выполнен на базе того самого кода из SDK.


Чтобы вы понимали, почему код из SDK я так и не решился использовать, вот вам скриншот участка кода, на котором я уже тогда понял, что будет несладко:



Видите cpp-файлы, которые включены через #include? И так по всему исходнику. Тем не менее, тщательно изучив исходный код отладчика PS3, мне удалось вычленить из него что-то рабочее и сделать свой — для Sega Mega Drive.


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



Для этого пришлось снова отлаживать IDA, процессорный модуль m68k, и делать исправления для последнего (об этом я писал в "Модернизация IDA Pro. Исправляем косяки процессорных модулей").


Несмотря на все трудности, мне удалось написать хороший отладчик! К сожалению, вышла новая версия SDK… В ней изменилась структура debugger_t, отвечающая за отладчик и его колбэки, и всё, что я пытался сделать, приводило к крэшам самой IDA. Спустя время я и с этим справился.


Но вышла новая версия SDK… x64, без совместимости с x86! А эмулятор Gens, на базе которого я делал отладчик, не умел в x64, и проект заглох на много лет. Когда же я нашёл эмулятор, который был способен работать в x64, вышло так много версий SDK, что снова пытаться понять, почему мой плагин не работает, я не решился.


Выводы


Проблемы SDK для IDA Pro в отсутствии нормальной документации об изменениях в каждой из версий; в том, что изменения выходят скопом — их много, они кардинальные, и за ними очень тяжело угнаться.


Если уж ваша фирма/команда выкладывает какой-то публичный SDK, и у него есть пользователи, которые платят деньги — будьте добры, думайте и о них тоже! Их разработки могут помочь вашему продукту стать лучше и популярнее, как это произошло с IDAPython. Понятно, что хранить обратную совместимость очень сложно, но, если уж решились не поддерживать старые версии, постарайтесь документировать все изменения, которые вы делаете.


Я видел на Github большое количество полезных проектов, которые так и остались непортированными на IDA v7.x. Можно подумать, что их функционал стал ненужным в новых версиях? Может и так, но, как по мне, это усталость и нежелание бороться с постоянно меняющимся API в совокупности с хоббийностью проекта.


IDA Pro Book


Ещё хотелось бы вспомнить об одной бесценной книге, которая мне когда-то очень помогла, но которая сейчас абсолютно бесполезна для разработчика плагинов к IDA — IDA Pro Book от Chris Eagle. Всё описанное в ней относится к версии 6.x (ориентировочно v6.5-v6.8). С тех пор изменилось практически всё.


Спасибо.




Комментарии (11):

  1. gecube
    /#21812664 / +10

    А все почему? Потому что на рынке инструментальных средств этого класса по сути нет конкуренции. Вы с этим согласны? А раз так, то можно брать с клиента любой ценник и особо не париться по поводу качества своего продукта. Я ни в коем раз не говорю, что ИДА плохая. Это превосходный инструмент с кучей функционала. Но… Она могла бы быть и лучше! Что настоящая статья прекрасно иллюстрирует.

    • DrMefistO
      /#21812676

      Абсолютно верно! Опять же, будь разработчики IDA её же пользователями — было бы куда лучше. Комьюнити жаловаться не привыкло, потому что зачастую сидит на пиратке, а разработчики не слушают пиратов.

      • extempl
        /#21813682 / -1

        Комьюнити жаловаться не привыкло, потому что зачастую сидит на пиратке, а разработчики не слушают пиратов.

        Не совсем понятно, что мешает писать фидбеки тем, кто купил. "Меня всё-равно не будут слушать", или пишете, но не слушают, потому что… думают что вы пират (нельзя проверить, что-ли)?

        • HardWrMan
          /#21813770 / +4

          Нене, там всё интереснее. Я помню баталии 10ти летней давности. Когда юзеры купившие обращались на официальном форуме с просьбами исправить ошибки и Ильфак их игнорировал а иногда даже банил. А потом выкатывал в новой версии такие плюшки, которые у него никто не просил, но они обсуждались между пиратами IDA на других форумах.

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

          В то же время я помню сильно начала развиваться Олька, да вот только, похоже, всё заглохло окончательно…

          • sergegers
            /#21821232

            Да не, OllyDbg была вроде карамельки (котроую суёт тебе в рот порочный Дед Мороз), а IDA — адово мощнейшая штука, но, чтобы задействовать её возможности, нужно писать адски сложные плагины.

  2. JackKatch
    /#21814048 / +1

    Не качественное ПО это бич нашего времени. И ситуацсия будет только ухудшатся. Я бы взглянул на это с другой стороны. Вот если кто то купит просроченный кефир, то как минимум может его вернуть. А если травонулся, может и отсудить что то у производителя. Почему производитель ПО может впарить нам любую дичь (сейчас не про IDA) и не нести за это ни какой ответственности?!!! (Риторический вопрос)

    • sandroDan
      /#21814098

      люто плюсую! (не могу, молод да зелен)
      Почему 99.99% софта имеют магическую надпись «как есть»?! почему только в Австралии Суд встал на сторону покупателей (в том случае это была глючная игра, может кто добавит ссылку, я быстро найти не смог).
      Причем, у меня пяток лицензионных программ, и везде «как есть». Да, есть форумы поддержки, да помогают советами. Но обычно медленно и (всё чаще) никак :(

    • Ingulf
      /#21815784 / +4

      потому что на заре всего появилась строчка «как есть» в лицензии, причем в открытых проектах, в принципе, по-моему с этим можно считаться, потому что можно попытаться самому допилить и послать мердж, а вот почему в платных лицензиях вообще это допускают, видимо опять из-за того, что первоначально не было ничего, а теперь кто возьмется менять эти кучи непонятных лицензий, разве что новые добавить — но тогда как заставить разработчиков выбрать именно эти новые исправленные варианты?

  3. VelocidadAbsurda
    /#21815666 / +5

    Постепенно пришел к такому: в качестве документации открываю в отдельном VSCode корень IDA SDK вместе с его примерами, нахожу объявление нужной функции, читаю там комментарии, затем делаю поиск использований и смотрю «а как оно на самом деле» (и удивляюсь).
    Плюс в какой-то момент сказал себе «доколе?!» и выделил время на дизассемблирование самой IDA и процессорного модуля ARM — многое стало понятнее, ну и «грязные хаки» стали возможны — вызвать внутреннюю функцию, отсчитав её смещение от экспортированной, «похитить» таблицу виртуальных методов внутреннего объекта и установить hook туда, куда API не позволяет итд, что ещё усиливает привязку к конкретной версии. Вот такой печальный SDK.

    • DrMefistO
      /#21816964 / +1

      Я где-то так же и делал) у меня номера регистров и внутренних ивентов были, которые я чекал у себя в плагине, и на нужный вешался.