Bindiff 6 отображает некорректный результат

[varwar]

В этой теме хотелось бы затронуть вопрос корректности работы Bindiff/Binexport с IDA Pro 7.5 (Oscar Agreda). А именно, связана ли версия SDK с выводом программы? А также, как можно решить эту проблему? (спойлер: временно перешел на Diaphora).

Исходные данные:
Bindiff 6 устанавливался штатно с официального сайта. Хотелось бы отметить, что в мануале написано, что он использует SDK 7.4.
Версия Windows: 20h2



Базы иды для анализа импортировались штатно Binexport'ом с последующим запуском в GUI Bindiff'а (в GUI IDA результаты аналогичные). Ниже представлены результаты сравнения вывода Bindiff и Diaphora (2.02) соответственно.


Если верить Bindiff, то функция win32kfull!xxxCreateWindowEx не патчилась вовсе (а это не так). Более того, количество базовых блоков по сравнению с выводом Diaphora сильно меньше. Это связано с тем, что Bindiff явно режет нормальные функции на части, из-за чего в выводе можно встретить большое количество неопознанных имен функций (см. скриншоты выше).


Это уже не первый раз, когда я столкнулся с таким поведением программы. Вопрос к форумчанам, сталкивался ли кто с подобным на SDK 7.4? Для сравнения корректности результатов могу скинуть бинари win32kfull.sys (UBR 746 и 804). Если никто не откликнется, то попробую решить проблему, пересобрав Binexport 11 на SDK 7.5 и перепроверить результаты.

Также есть хорошая новость, что к выходу IDA Pro 7.6 готовится выход Bindiff 7, который не использует функциональность SDK 7.6, а значит должен работать корректно на SDK 7.5 (если проблема вообще в этом).

 

[varwar]

Проблема была действительно в BinExport, который собран на IDA SDK 7.4. Видимо, все-таки есть отличия в парсере/формате баз иды из-за чего был этот неприятный баг.
После фикса, Bindiff стал корректно отображать имена функций.



На скриншотах ниже сравнение все тех же результатов win32kfull.sys на SDK 7.4 и SDK 7.5.


Все было настолько плохо, что по статистике функций Bindiff'ом распознавалось в два раза больше (false positives), что ломало граф и весь анализ сводило по сути на нет.

 

[varwar]

Чтобы окончательно поставить точку в вопросе (а может и нет), я решил сравнить две одинаковые базы иды, экспортируемые дефолтным и пересобранным BinExport'ом.

В качестве примера я взял ntoskrnl.exe версии 20H2 19042.572.
Еще раз поясню, я сравниваю бинарный файл одного и того же билда и UBR, чтобы указать на неточности вывода программы.

Чтобы не полагаться целиком на глаз и интуицию, я дополню умозаключения простой проверкой - посчитаю количество базовых блоков для одной из функций в нормальном (по моим предположениям) выводе BinDiff и сравню с выводом IDA Pro. В качестве инструмента здесь я буду использовать глаза и IDA Python.



Итак, мы сразу можем обратить внимание на разное количество функций. Старый BinExport "дорисовывал" псевдофункции, которые являлись просто отдельными базовыми блоками других функций. Это плохо, т.к. искажает картину происходящего в программе.

Теперь давайте посмотрим на функцию MiZeroLargePageThread, т.к. в ней присутствует больше всего "изменений".



На скриншоте ниже мы можем видеть существенные отличия в рамках одной функции. Теперь же нам необходимо сверить количество базовых блоков в выводе BinDiff (в данном случае 95) с выводом IDA Pro.



Даже не производя никаких рассчетов на глаз уже можно сказать, что старый вывод BinDiff'а был неверным, т.к. граф намного больше. Глазами такое считать лень, поэтому воспользуемся IDA Python.



Я нашел в сети ряд скриптов и взял в качестве базы один.

def get_bb_ends(address):
    """
    Get end addresses of all bbs in function containing address.
    :param address: address in function
    :return: list of bb end addresses
    """
    function = idaapi.get_func(address)
    flowchart = idaapi.FlowChart(function)
    return [hex(idc.prev_head(bb.end_ea)) for bb in flowchart]

MiZeroLargePageThread = 0x1403B08E0

print(get_bb_ends(MiZeroLargePageThread))
print(len(get_bb_ends(MiZeroLargePageThread))) # output 95

Функция get_bb_ends возвращает адрес последней инструкции каждого базового блока функции (ее указатель мы передаем в качестве параметра). Мы же должны просто посчитать количество этих адресов в массиве - это и будет нужное нам значение.



Скрипт вернул массив адресов и цифру 95 (длина массива), что и было нашим искомым значением. Оно совпадает с выводом BinDiff'а, чего я и пытался достичь по итогу. Казалось бы, мы привыкли доверять инструментам, а инструменты нас таким подлым образом подводят.

 

[varwar]

В связи с вышедшей бета-версией (скачать) Bindiff 7 и BinExport 12 решил сравнить его работу из коробки на IDA Pro 7.5. Установку производил предварительно удалив старую версию Bindiff 6 и BinExport из папки плагинов для иды соответственно.

Сравнивал по-прежнему win32kfull.sys (UBR 746 и 804).



Вывод: пользователи IDA Pro 7.5 должны использовать либо Bindiff 6 c BinExport 11, скомпилированным на базе IDA SDK 7.5, либо ставить бету Bindiff 7, которая работает нормально из коробки.