то что вы предлагаете помоему абсолютно не реально писать плагин к IDA, который будет хешить каждую функцию и потом сравнивать два хеш отчета? невижу результата в этом нужно же выявить возможные watermakes? а не сравнить насколько один билд похож на другой!
проще тогда уже реверсить по малому ida.wll/ida64.wll SDK для ранних версий доступно, возможно можно добыть и к 6.1 комплекту там почти все что нужно и сделать свобоный аналог ida.wll
Вы не до конца поняли идею. Как раз изначальная задача сравнить насколько один билд похож на другой. Тем самым и выявляются разночтения в коде и сопутствующих (окружающих) данных. Это и позволяет выявить watermarks, а в дальнейшем - избавиться от них. Напоминаю, сравниваться будут одни и те же версии, просто от разных поставщиков.
watermark может сидеть в не в секции кода, а вообще где то черт знает где
ваш метод может только сравнить насколько один билд отличается от другого билда по функциям, не более тоесть помощь в выявлении watermark это не принесет
Потому что если функции отличаться не будут вообще (например, идеальный вариант), то значит, что внекодовое пространство ненужно вообще. И его можно создать пустым.
Далее, если речь идет о watermark в данных, то опять же: пересортировав данные, можно втупую дальше сравнивать по fc /b. И видеть результат.
Просто представьте себе некое множество блоков. У вас их изначально два одинаковых. Потом приходит некто и переставляет внутри эти блоки по-разному. А потом еще маленькие блочки (единичные -- их будем считать за watermarks) меняет на "специальные", отличающиеся друг от друга.
Вопрос: сможете ли вы найти watermarks, переставив блоки в любом одинаковом порядке в этих множествах?
я не совсем понимаю что вы хотите сравнивать ок, берем простой пример
функция A в билде A находится по .text:00201000 и функция A в билде Б находится по .text:00304100
и теперь представляем что в функциях присутвует обращение к сеции .data данные одни и теже но компилер в разных местах разметил эти данные в секции .data соответсвенно и по хешам функии A в разных билдах будут различатся а если еще в функциях есть и call/jmp которые можут прыгать на одинаковые функции в разных билдах, но эти функции физически размещенны в разных местах то смещения по jmp/call буду тоже разные вот и все сравнение.. сравнивать получается и несчем
Обращение к данным -- в этих инструкциях присутствуют relocations. Эти данные, как относительные, анализироваться не будут. Насчет call поясню на примере:
.100013A0: 8B442404 mov eax,[esp][4] .100013A4: 50 push eax .100013A5: 68[801A1510] push 010151A80 ; ссылка на данные .100013AA: E8{51FD0A00} call _areacb_t_get_next_area ; call на функцию (некий код) .100013AF: 50 push eax .100013B0: 68[801A1510] push 010151A80 ; ссылка на данные .100013B5: E8{16000B00} call _areacb_t_getn_area ; call на функцию (некий код) .100013BA: C3 retn
[] - не анализируется (пропускается или заменяется на одинаковый набор символов) {} - не анализируется или (лучше) заменяется на связку - переход на функцию под определенным идентификатором (на нее в дальнейшем так же хэш насчитывается), соответственно, можно выстроить граф переходов по этим связкам
ок, теперь понял только учтите что есть разные билды которые скомпилированы к примеру с защитой стека _chkesp, или без него
она присутсует всегда до вызова retn и ее прийдется тоже выявлять и анализировать да и сам стек sub esp, ??? тоже может различатся по разному в разных билдах вообщем как бы не оказалось что в итоге и сравнивать будет нечего :))
Билды собираются с одними и теми же опциями. Это все-таки не наколенный продукт (хотя во многом по качеству некоторых мест на него похоже). :)
Вся разница в них - это просто порядок функций/данных. (По сути, команда линкеру располагать функции/obj в определенном, заданном, порядке). Все остальные опции те же. На тысячи клиентов различными опциями не напасешься, да и не нужно этого :)
написать скрипт idc который получает адресс функции и далее читай по одной комманде из функции и начинает ее хешить и результат в виде addrfn len md5hash не проблема а вот как потом сравнивать эти два результата ну допустим можно будет отсортировать сначала по длинне фукнции а потом по хешу а вот как и чем сравнивать два таких результата это будет поиск каждой комбинации с одного файла, в другом.. сложноватый поиск...
Смотрите предыдущий пост про watermarks. Потому что ida.wll, ida64.wll у каждого клиента разные (суть кода одна и та же). В них переставлены функции и данные. Это уже достоверно доказанный факт (по анализу v5.7 и практико-гипотезе v6.1).
писать плагин к IDA, который будет хешить каждую функцию
и потом сравнивать два хеш отчета?
невижу результата в этом
нужно же выявить возможные watermakes? а не сравнить насколько один билд похож на другой!
проще тогда уже реверсить по малому ida.wll/ida64.wll
SDK для ранних версий доступно, возможно можно добыть и к 6.1 комплекту
там почти все что нужно
и сделать свобоный аналог ida.wll
Reply
Reply
ваш метод может только сравнить насколько один билд отличается от другого билда по функциям, не более
тоесть помощь в выявлении watermark это не принесет
Reply
Потому что если функции отличаться не будут вообще (например, идеальный вариант), то значит, что внекодовое пространство ненужно вообще. И его можно создать пустым.
Далее, если речь идет о watermark в данных, то опять же: пересортировав данные, можно втупую дальше сравнивать по fc /b. И видеть результат.
Так что в этом смысле все хорошо.
Reply
Потом приходит некто и переставляет внутри эти блоки по-разному.
А потом еще маленькие блочки (единичные -- их будем считать за watermarks) меняет на "специальные", отличающиеся друг от друга.
Вопрос: сможете ли вы найти watermarks, переставив блоки в любом одинаковом порядке в этих множествах?
Ну это грубо так, но для простого понимания.
Reply
Reply
ок, берем простой пример
функция A в билде A находится по .text:00201000
и
функция A в билде Б находится по .text:00304100
и теперь представляем
что в функциях присутвует обращение к сеции .data
данные одни и теже
но компилер в разных местах разметил эти данные в секции .data
соответсвенно и по хешам функии A в разных билдах будут различатся
а если еще в функциях есть и call/jmp
которые можут прыгать на одинаковые функции в разных билдах, но эти функции физически размещенны в разных местах
то смещения по jmp/call буду тоже разные
вот и все сравнение.. сравнивать получается и несчем
Reply
.100013A0: 8B442404 mov eax,[esp][4]
.100013A4: 50 push eax
.100013A5: 68[801A1510] push 010151A80 ; ссылка на данные
.100013AA: E8{51FD0A00} call _areacb_t_get_next_area ; call на функцию (некий код)
.100013AF: 50 push eax
.100013B0: 68[801A1510] push 010151A80 ; ссылка на данные
.100013B5: E8{16000B00} call _areacb_t_getn_area ; call на функцию (некий код)
.100013BA: C3 retn
[] - не анализируется (пропускается или заменяется на одинаковый набор символов)
{} - не анализируется или (лучше) заменяется на связку - переход на функцию под определенным идентификатором (на нее в дальнейшем так же хэш насчитывается), соответственно, можно выстроить граф переходов по этим связкам
Reply
Забыл тэг pre сделать :(
Reply
только учтите что есть разные билды которые скомпилированы к примеру с защитой стека _chkesp, или без него
она присутсует всегда до вызова retn
и ее прийдется тоже выявлять и анализировать
да и сам стек sub esp, ???
тоже может различатся по разному в разных билдах
вообщем как бы не оказалось что в итоге и сравнивать будет нечего :))
Reply
Вся разница в них - это просто порядок функций/данных. (По сути, команда линкеру располагать функции/obj в определенном, заданном, порядке).
Все остальные опции те же.
На тысячи клиентов различными опциями не напасешься, да и не нужно этого :)
Reply
Просто может быть большое число коллизий. Нужно смотреть по конкретному коду.
Reply
который получает адресс функции и далее читай по одной комманде из функции и начинает ее хешить и результат в виде
addrfn len md5hash
не проблема
а вот как потом сравнивать эти два результата
ну допустим можно будет отсортировать сначала по длинне фукнции
а потом по хешу
а вот как и чем сравнивать два таких результата
это будет поиск каждой комбинации с одного файла, в другом..
сложноватый поиск...
Reply
уже готовый плагин для сравнения
Reply
И от каких разных? Контора вроде одна )
Reply
Reply
Leave a comment