Привет всем!
Хочу поделиться опытом и результатом своего исследования безопасности программы Mobilize.Net Visual Basic Upgrade Companion. Эта программа помогает перевести проект, написанный на VB6 в современный VB.NET. Программа специфическая, и вряд ли у неё есть много фанатов. Но мало ли, может кому будет интересно и полезно.
О своих результатах я направил письмо в компанию, выпускающую данный софт, они меня поблагодарили, но в следующей вышедшей версии ничего не изменилось. Что ж, зря они так.
Итак, по порядку. Программу можно запросить, а затем бесплатно скачать с сайта разработчиков. Присылают демо-версию, естественно. В ней стоит ограничение на число строк кода, которое можно преобразовать. Но нам-то хочется всего и сразу, правда?
Значит, при превышении заданного объёма, программа упирается рогом и выводит сообщение об отсутствии лицензии. Ага, значит, лицензия. Запускаю API monitor от rohitab и пытаюсь найти хоть какие-то вызовы, которые содержат хоть что-то, что связано с поиском файла лицензии. Безуспешно. Всё запутано и не отслеживается.
Ок, не отчаиваюсь, ради прикола ищу в директории программы все файлы, содержащие слово LICENSE. Опа, тут начинается интересное! Выскакивают сразу несколько dll-ок. Просматриваю их содержимое, и больше всего меня цепляет файл VBUpgrade.Engine.dll.
Пытаюсь открыть его с помощью IDA - безуспешно. Прогоняю его через разные программы для исследования EXE файлов.. Оказывается, наша DLL-ка написана на .NET!
Идём в Reflector. Хм, ничего не обфусцировано, библиотечка превосходно декомпилируется, и весь код оказывается как на ладони. Изучаю его... Названия функций и классов говорят сами за себя. Что ж, чутьё не подвело, это именно то, что мы ищем!
В классе LicenseValidator обрабатываются все зашифрованные (!!!) с помощью RSA файлы лицензий и выдаётся вердикт: лицензия годная (LicenseErrors.LicenseOk) или нет (все остальные варианты).
Дальше действуем таким образом. Декомпилированный код переносим в новый проект Visual Studio. Все методы, которые возвращают булевы значения, заставляем возвращать True, а везде, где проверяется состояние лицензии и возвращается тип LicenseErrors, возвращаем LicenseErrors.LicenseOk. Компилируем DLL-ку, заменяем в папке программы, запускаем её... И вуаля, она радостно позволяет нам открывать проекты любого размера!
Если кому-то нужны подробности, пишите.

56d1_11.11.2018_EXELAB.rU.tgz - inf.png

| Сообщение посчитали полезным:

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

-----
2 оттенка серого

| Сообщение посчитали полезным: TryAga1n

f13nd пишет:
Пункт с перекомпилированием дллки по-моему излишество, есть способы попроще.
А не уточните, какие именно?

| Сообщение посчитали полезным:

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

А есчо могут быть косяки в самом трансляторе. Даже если исходный код не уязвим, уязвимость создаст транслятор/интерпретатор, так как сам кривой.

-----
vx

| Сообщение посчитали полезным:

aave пишет:
А не уточните, какие именно?
Байткод дотнетовый пропатчить. Условный переход на pop-nop заменить или что-то в этом роде. В иде удобно очень через patch program>change bytes, patch program>apply changes, не воюя с днспай и тем более компилером.

Добавлено спустя 16 минут
difexacaw пишет:
Именно виртуализация делает апп уязвимым. Если обычный, нэйтивный" код довольно просто изучается, то код с обфускацией, виртуализацией и тп. напрямую даже не читаем. А есчо там тонны мусора, поэтому поиск ошибок по этим причинам в нём затруднён.
О чём это вообще было?) Виртуализация делает апп уязвимым, потому что обфусцированный код напрямую не читаем и поиск ошибок в нем затруднен? А кто эти ошибки в обфусцированном коде станет искать? Разработчик? Там иногда такие калеки попадаются, что примитивную виртуальную машинку из десятка команд на своем сишарпе переписать не могут, сбрасывают значения функции y=f(x) в файл, пакуют в зип под паролем и готово. Пока сворачивал это файло обратно до алгоритма всего ему нажелал.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd пишет:
Байткод дотнетовый пропатчить.
Не уверен, что это проще. Там много мест, в которых проверки осуществляются. Имхо, проще разобраться с высокоуровневым кодом, чем погрязать в дебрях байт-кода. Ну, во всяком случае, для меня.

| Сообщение посчитали полезным:

aave пишет:
Имхо, проще разобраться с высокоуровневым кодом
А это не мешает разбираться с декомпилированным кодом. Это касается только внесения в него исправлений исходя из принципа минимального вмешательства.

-----
2 оттенка серого

| Сообщение посчитали полезным: