Обновить

Исходники Borland C++ 2.0 восстановили из бинарника: BCC.EXE пересобирается байт в байт

Время на прочтение12 мин
Охват и читатели10K
Всего голосов 11: ↑10 и ↓1+11
Комментарии22

Комментарии 22

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

Кстати нейросети похоже позволили воплотить одну мою старую идею: декомпилятор с обратной компиляцией в режиме патчинга. То есть декомпилируем по типу hexrays, меняем в этом декомпилированном исходном коде что-то по минимуму, или добавляем пару функций, и полученный измененный код компилируем обратно - причем неизмененные части можно брать оригинальные прямо из старого бинарника. Это потребовало бы особого софта, где декомпилятор и компилятор являются единым программным продуктом, а декомпилированный код и бинарник были бы связаны в единый формат хранения. Сейчас с нейросетями получилось честнее (хотя и менее оптимально) - полная декомпиляция и полная компиляция.

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

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

Мешают патенты, лицензия и права на интеллектуальную собственность.

Такой код просто будут удалять с крупных платформ (GitHub, GitLab, …), а разработчики не будут заинтересованы в развитии такого проекта.

Можно если делать методом чистой комнаты. Берёшь 1 агента и он по декомпиляции описывает как работать код. 2 агент по документации пишет новый код. На выходе программа с таким же функционалом но по факту совершенно новая и без чужого кода. Юристам не до чего докопаться

Если ваш софт неотличим от коммерческого софта, то как вы его сделали всем все равно. Суд, тюрьма и миллионы штрафа.

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

И при нехватке инфы, сгенерированной первым агентом, второй чего-нибудь там отреверсит сам...

А ещё бывают запатентованные алгоритмы. Как в MP3. Существовал кодек LAME под свободной лицензией, но его использование для сжатия звука всё равно требовало уплаты денег держателям патентов. Потому что платить надо было за сам факт реализации этих запатентованных алгоритмов. По этой же причине кодек в FFMpeg и всяких линуксах лежал в отдельном репозитории. Мол, дорогой пользователь, если ты это себе сознательно подключаешь, то ты тем самым подтверждаешь, что сам утрясёшь вопрос с держателями патентов и получишь от них разрешение.

Юристы видят прежде всего не код, а идентичный до пикселя GUI...)

Интересна легальность этого процесса, ведь если удалось сделать это с одним, то можно сделать и с другими.

Про то что это сделано с помощью ИИ информации мало, косвенно про скилы и claude в исходном репозитории

Как правило, декомпиляция запрещена.

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

одна команда декопмпилирует, объясняет функционал другой команде, которая реализует... серость в том что те что декомпилируют могут находиться в иной юрисдикции.

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

Какая разница. Кто декомпилирует, тот и нарушает.

Второй половине команды тоже может прилететь за соучастие в нарушении.

Липа это все.

Эх, такое бы для MSVC 6.0...

Именно для самого компилятора? Помню среда разработки была шустрая, но что там особенного в компиляторе?

А вообще такое бы для очень много какого софта надо:) Включая саму винду.

Да это по-моему был пик компиляторостроения :) По соотношению умности к bloat. Новый переписанный с нуля VS еще долго не мог его догнать по скорости, и я так и не узнал, догнал-таки или нет, потому что перестал им пользоваться...

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

бинарники растут от того, что в них питают новые библиотеки.

Вроде VC5 более компактный код генерил. Встречал такое мнение.

Кстати, про винду, надеюсь ReactOS не игнорируют достижения ИИ :)

OS/2 в открытой реинкарнации в виде osFree, как по мне, более интересная эволюционная ветка

Откуда такая ностальгия?) ice в нем было инициировать после прочтения Александреску было как два пальца об асфальт) уже от 2002й был гораздо стабильнее.

Для VS6 вышло 6 сервис паков. Даже сама МС долго с неё не слезала.

Вроде до сих пор в Виндовс от неё dll-ки живут, msvcrt.dll и mfc42

Ох уж эти повторяемые сборки! На что только не идут, чтобы их получить. /s

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации