Знатокам реверса - развилка в коде - как найти???

Всем привет!

Сам прикладник, пишу разное на С++. Реверс - не мой хлеб. Но вот жизнь забросила...

Есть утилита, которая на вход принимает правильныйФайл и мойФайл. С правильным все хорошо - отрабатывает как надо.
На моем - валится.

Утилита: scanpst.exe (идет в комплекте с Outlook)
правильныйФайл: пустой pst.-файл, созданный средствами Outlook.
мойФайл: пустой pst.-файл, созданный разрабатываемой мной библиотекой.

С прошлого года спецификация pst.-файла стала публично доступной. Все изложенное там я реализовал. Но то ли не совсем верно, то ли не все сказано, то ли Outlook знает лучше, как ему и с чем работать.

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

Использую IDA Pro. Слава богу исследуемая среда не враждебная, вроде ничего не криптовано и не защищается от отладчиков. По кр. мере так выглядит.

Нашел по коду то место, где выполняется проверка и после которой с правильным файлом все продолжается, с моим же - запись логов, бросание пользователю сообщения о какой-то ошибке (никакой конкретики - просто ошибка) и завершение работы утилиты.

Дальнейший разбор показал, что при работе с правильным файлом происходит проверка данных, взятых из исходного файла, который мы и анализируем. При работе же с моим файлом анализируются данные, взятые из какого-то созданного налету временного файла, равного по размеру входящему/анализируемому. Этот временный файл создается всегда. Но когда утилита обрабатывает мой файл, то из этого временного читается не то. То есть он (временный) сам по факту вместо реальных данных (из моего файла) содержит нули.

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

Так вот как найти это самое место - эту развилку - в коде всей утилиты???

Сам формат .pst-файла достаточно сложный. Утилита умеет его проверять, а также ремонтировать - значит ее функционал тоже далеко не самый простой.

Мне нужно знать, как вообще решается подобная задача? Какие техники, подходы? Может надо написать какой-то скрипт, который что-то где-то как-то будет дампить и потом сравнивать дампы правильный и мой??? И так найти место, с которого пути расходятся?

Но что где и как? Или это полный бред? С какой стороны заходить?

.pst-формат - полностью бинарный. Ему уже не один десяток лет со всеми вытекающими. По сути это трехслойный пирог. Каждый слой реализует свой уровень абстракции. На нижних уровнях (где и скрыта проблема) все построено в виде деревьев. Большая часть файла зашифрована. Это не мешает, а просто усложняет процесс. Все участки файла имеют свои метаданные, в кот. есть сигнатура и контрольная сумма блока. Меняем где-то бит/байт - надо найти нужное место и пересчитать сигнатуру и контрольную сумму (это в частности приводит к тому, что исследовать этот файл вручную - становится практ. невозможным - надо писать специальный патчер для любых манипуляций). Плюс используются GUIDы и уникальные счетчики, что приводит к тому, что логически одинаковые файлы физически могут быть дост. различны. Конечно, одинаковые физически одинаковы и логически.

Есть идеи?

Спасибо в любом случае!!!

 

Так сравните побайтно пустой правильный файл и файл, который создает Ваша библиотека. Увидите отличия и найдете в своем коде место, где данные формируются некорректно.

 

повторюсь - но побайтное сравнение по трудоемкости вполне сопоставимо с исследованием работы утилиты под отладчиком.

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

Найдя отличия я должен проанализировать каждый байт. Отличия каких-то байтов может быть понятным сходу. И даже логичным. Других же - непонятным и не очевидным. В любом случае я должен буду поменять каким-то образом очередной байт в своем файле на типа "правильный" байт. Вручную это делать дост. трудоемко. Надо делать инструментарий. Он отчасти готов - просто покрывает не все возможные байты - не все участки файла.
Далее поменяв очередной байт я должен посмотреть, как на это реагирует утилита. Она может завершаться одинаково при множестве разных ошибочных ситуаций внутри. И я так и не смогу понять роль очередного байта. Значит он что-то или нет.

И потом невозможно просто менять один байт! Этот один байт может быть частью восьмибайтной ссылки, указателя, сигнатуры, или контрольной суммы. и поменяв просто один байт я разрушу все остальное. И тогда утилита будет на эти побайтовые изменения генерить все новые и новые ошибочные сообщения, в которых я просто потону. Они все тоже требуют не самого простого анализа.

Поэтому смотреть на этот файл как просто на массив байт - бесперспективно. Его надо анализировать на логическом уровне - с учетом внутренней логики, структуры.

 

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

 

mrCyber
Это есть не такая сложная задача. Первое что вам придется сделать это понять буфер памяти. читает ли он весь файл? и так далее .
После того как вы узнаете устройства буфера, вы сможете его проинвалидировать (VirtualProtect) и собствено говоря увидить манипуляции .

 

возникла идея/вопрос:

как можно
1. запустить два экземпляра IDA Pro (видимо на одной машине)
2. в каждом экземпляре открыть исследуемую утилиту (но только ее бинарник может находиться только в одном месте системы, где она (эта утилита) установлена).
3. запустить утилиты под отладчиком - каждая со своим входным файлом ....... И!!!!
4. как-то автоматически отследить, когда произойдут неодинаковые переходы при одних и тех же проверках .....

КАК??? Такое вообще возможно???

Для гуру реверса это абсолютно плевый вопрос!!
Подскажите же, пожалуйста!!!

 

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

 

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

 

Насколько я помню формат pst (давно дело было) он представляет собой хранилище (storage). Для доступа к хранилищам есть специальные апи, а для pst рекомендую пользоваться библиотеками аутлука (mspst32.dll).

 

Да, нахождение развилки в коде вас 100% не спасет.

 

Тут вы недописали чуток - "API, которое является частью лицензируемого и порядочно стоящего софта". И в этом все дело.

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

Да! Тысячу раз. И если бы мне это можно было делать - я бы завершил эту задачу еще неск. месяцев назад. Но я как раз и разрабатываю библиотеку, которая позволит работать с .PST без указанных проприетарных библиотек. Такой уж заказ.

Не могли бы объяснить, почему все так плохо и категорично?

Одну проверку, с которой начинается "приземление" - я нашел и многое понял. Теперь мне надо найти еще один "поворот", после которого все идет не так. Если я его найду, то я скорее всего пойму проблему, или же буду вынужден найти следующую развилку. Но в конечном счете их не должно быть слишком много. И каждая из них отражает логику работы и требования, предъявляемые к структуре - а это само по себе ценно.

 

Да, если и сравнивать, то поструктурно. Ок. Но и это не решает задачу. Дело в том, что сравнение может лишь сказать, что где-то что-то отличается. А значимо это или нет - я смогу понять лишь после проверки. Кстати проверка может ничего и не показать.

(Скажем, в моем файле отличий на самом деле 10. Я нашел первое. "Исправил". Попробовал. Эффект нулевой. Потому что еще 9 все портят. Но я их еще не нашел и я о них ничего не знаю. Так что же делать с этим исправлением? Оставлять? Оно значимо или нет? А может оно что-то ломает?
Это все гадание без всякого понимания.)

И таких отличий как и проверок - может быть вагон. Их не сделать вручну. Под каждое очередное отличие я должен буду как-то править алгоритм работы своей библиотеки. При этом я не буду вообще понимать, зачем я это делаю. То есть в этом не будет логики - только лишь что, чтобы "байты мои стали как те, что якобы правильные". Но это бред. И что станет с кодом библиотеки после неск. таких модификаций - жутко представить. Формат достаточно сложный и даже сейчас там комментариев и пояснений чуть ли не больше, чем кода.....

Если же искать "ту самую проверку" в работе утилиты, то можно будет точно найти то самое место, где все решается. И не трогать ничего лишнего, не делать неосмысленных вещей.

 

Стандартное, идущее с виндою апи работает с хранилищами. Или вы пишете под другую ос?
API для pst действительно идет только вместе с Outlook (либо с Exchange). Есть mspst, входящий в стандартную поставку винды, но насколько я помню, он с новыми форматами не работает.

Однажды мне пришлось решать эту задачу в кратчайшие сроки путем жосткай операции над библиотекой с целью превратить ее в нечто малоузнаваемое. Вроде работало, вроде, с тех пор никто не жаловался )
Либо декомпилить и переписывать, увы.

Это сложный формат, недокументированный (ну вы же не поверили, что M$ вот так сразу и раскроет все карты), а алгоритмы не реверсятся нахождением пары развилок. Если все-таки нужно этим заниматься, то универсальных советов вам никто не даст, задавайте более дробные вопросы по ходу дела.
Pst в частности, если я правильно помню, мапится в память, потом дешифруется, и после этого с ним уже идет работа как с участком памяти.

 

Вот эту жуткую рутину хотелось бы макс. автоматизировать. Ведь в IDA Pro есть внутр. язык. Можно ли на нем написать нечто, что по шагам шло бы по коду и фиксировало все условные переходы - адрес перехода, выполнен переход или код выполняется дальше. Я думаю, что если отследить только условные переходы, то этого будет дост, чтобы найти, где обработка идет разными путями.
Едва ли в коде будут какие-то трюки, чтобы замаскировать от дизассемблера какой-то переход или вызов.

 

Да, если ваше ПО будет работать на машине с установленным аутлуком, то имхо никто вам не запрещает использовать его библиотеки.

 

Как говорит один мой друг - у меня такое неприятное чувство, что вы правы.....
Один тот факт, что в наст. время нет ни одной коммерческой библиотеки, решающей эту задачу - оч. сильно настораживает.

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

 

Кстати, в этой утилите я вижу, как этот файл все же не мапится (что странно - я сам у себя его именно так и цепляю - через маппинг), а по кускам вычитывается (брэйк на ReadFile).
Что касается шифрования, то это относится лишь к тем данным, что хранятся в блоках данных. Это, так сказать, уже за деревом BBT. Для непосвященных (то есть нормальных людей) это ни о чем не говорящие слова. А управляющие структуры и деревья NBT и BBT - они не зашифрованы. Слава богу!..... К тому же у меня все ломается где-то в самом начале, что тоже радует.

 

От библиотеки была отпилена инфа о производителе, и много еще лишнего... Изменена база образа и расположение секций... Ресурсы... Может, и еще что, не помню.
В общем, получилась как бы новая библиотека. Неузнаваемая без декомпиляции.

У меня есть наработки на эту тему, но бесплатно могу только давать советы на форуме, сами понимаете.
Или займитесь сами реверсом, работа долгая но интересная.

 

Я все прекрасно понимаю, без иллюзий.
То есть у вас некое альтернативное решение по созданию "своих" библиотек взамен существующих коммерческих - взять коммерческую и так ее изменить (на вид), что на оригинальную она снаружи не похожа, но при этом весь код, все мясо - остается и все работает. Так?

Может в каких-то случаях это и решение, но тоже не лишенное массы рисков и недостатков. Но где-то однозначно может сработать.
Надо подумать....

А по поводу "заняться реверсом"...... ) Хорошая шутка. Полагаю, что это не такая шуточная и мелкая тема, чтобы ей можно было так запросто между прочим совмещая со всем остальным взять так да и заняться Пока стоишь в пробке или едешь в метро Это целая жизнь.... если заниматься всерьез. Я непрафф?

 

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

Имхо, это сильно от способностей зависит. Бывают 14-тилетние детишки, которые щелкают закрытые форматы как орешки, и гениальные программисты, которые не в силах освоить ассемблер.