Такая вот идея - система обратного проектирования

Зародилась некая забавная идея, как из закрытых коммерческих программ и библиотек делать своеобразный open-source
Допустим, есть какая-то exe, dll или иная программа в двиочном виде, которая что-то делает. Исходников нет, сама программа содержит защиту и стоит денег. Что обычно делают? Крякают. С помощью отладчика и/или дисассемблера типа IDA Pro находят встроенную защиту, деактивируют ее, или выпускают кряк, и распространяют.

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

Итак, представьте - некий профессиональный хакер скачивает интересную коммерческую софтину, декомпилирует ее, снимает защиты классическими инструментами, а затем с помощью нашего гипотетического декомпилятора получает классический "проект" (xml-файл проекта, например *.idcproj, текстовый (!) файл с исходным кодом, ресурсы в отдельной папочке...). Тут же из полученных файлов компилируется exe/dll и проверяется, что функционал не нарушен.

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

Тут же можно сделать ветку, в которой вносить в файлы изменения и компилировать тем же инструментом обратно в двоичный код, ГАРАНТИРОВАННО получая почти такую-же софтину, как оригинальная. Т.е. к разработке на этом этапе подключаются уже не крэкеры, а программисты.

Что получается в итоге? А получается инструмент не только для лечения программ от жадности, но и для СВОБОДНОГО внесения в эти программы ПРАКТИЧЕСКИ ЛЮБЫХ изменений Не на ассемблере, а на простом и понятном си-подобном языке. При наличии такого инструмента можно будет делать все что угодно, включая пересборку Винды и создание гибридных осей, совмещающих код Windows и Linux

 

xcode
154564564894562341569851231385489749846564656546545645648974654651 идея которая никогда не станет реальностью

тему прибить ,имхо флуд.

 

забавно. я проблем с законодательством не будет?

 

Я не говорю что эта идея обязательно станет реальностью
Просто ничего подобного до сих пор не было и вроде не предлагалось. И почему сразу флуд?
P.S. простой пример. У меня есть одна простенькая десктопная игрушка, которая мне очень нравится. Защиты там никакой, я внес несколько мелких изменений - средствами IDA Pro+HexRays нашел код, а затем в hex-редакторе подправил байты.
Со временем у меня возникла идея кое-что улучшить в правилах игры Подправлять байты уже не прокатит А если бы была такая система, запросто бы переписал.
В общем, интересует конструктивное мнение сообщества.

 

xcode
самая удачаня попытка hex-rays,можете круче?тогда вперед.

 

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

 

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

 

maksim_

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

 

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

 

но коечто вытащить можно,этим впринципе и занимается hex-rays

 

может еще ц++ -сные классы покажет? плюс еще вирт. таблицу разберет?и все это в красивом деревце где будет видна иерархия классов?

 

от какого оригинала? от этого?

Код (Text):

1. void main() {MessageBox(0, L"", L"Hello world", MB_OK); }

 

а вообще, если говорить о качестве докомпиляции - тут конечный критерий один: компилябильны ли декомпиленные файлы?

для анализа кода согласен. очень хорошо справляется, очень удобно.

 

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

 

кто хекс-рейсом чтонибудь декомпилил, тот знает что он может,
а кто хекс-рейсом ничего не делал - тому и не надо

 

Ключевая идея в том, что система должна работать в обе стороны - и декомпилировать, и компилировать. hex-rays этого не может, как и ни одна из существующих систем.
Чтобы было понятнее, можно рассмотреть возможные "уровни сложности" такой системы.

0. линейный hex-конвертер. Простая программа, преобразующая любой бинарник в текстовый hex-файл и обратно. Даром никому не нужна, придумал этот уровень только для демонстрации идеи.
1. структурный hex-конвертер. У исполняемых файлов (допустим, PE-executable) есть четкая структура. Есть секции кода, данных, ресурсов. При декомпиляции формируется "файл проекта" (например xml), в котором содержится общая информация, извлеченная из PE-заголовка, и ссылки на текстовые файлы с hex-кодом и на файлы ресурсов. Файлы ресурсов (bmp, ico, cur, rc) можно при извлечении сохранять не в hex'е, а в их родных форматах. На этом этапе должен быть компилятор ресурсов, конвертер из hex в bin и специальный линкер, умеющий работать с файлами проектов xml.
Такая утилита уже может использоваться, скажем, как консольная программа для извлечения ресурсов из файлов.
2. структурный дизассемблер. Все то же, что и на уровне 1, но файлы с кодом дизассемблируются в ассемблерные мнемоники. Система должна содержать также ассемблер для сборки бинарников из этих мнемоник. Синтаксис ассемблера вовсе не обязательно делать 100%-совместимым с каким-либо классическим синтаксисом, здесь главное - обеспечить возможность обратного преобразования.
На этом этапе уже желательна, хотя и не обязательна, среда интерактивной разработки с простейшими функциями рефакторинга - разбивкой на файлы, переименованием меток, расстановкой комментариев и т.д.
Это уже инструмент, с помощью которого можно многое сделать!
3. структурный декомпилятор. На этом уровне код формируется уже не совсем на ассемблере. В специальные конструкции выделяются функции, их аргументы, вводятся типы данных. Пользователь может выделять стековые аргументы и локальные переменные, восстанавливать классы и структуры и т.д. Здесь можно подключить библиотеки сигнатур, из которых извлекать имена функций и имена аргументов (а значит, и имена переменных, передаваемых в эти функции). Здесь уже обязательна IDE с мощной поддержкой рефакторинга.
Система этого уровня, естественно, должна, кроме всего прочего, содержать компилятор с используемого языка программирования.

 

У меня однажды была идея. Не простого дизассемблера, а графического.
Программа дизассемблируется в специальное внутреннее представление и отображается в 2D-/3D-сцене.
Суть простая: Разобрать структуру программы и отобразить.
Циклы - окружностью/цилиндром, switch/case секции с множеством cmp/jcc - шестерёнкой. Процедуры, вызываемые только определённой частью кода - конус части кода и его процедуры на нём (еж/ёлка).
Связь между процедурами - жгутики. Чем больше передаваемых данных при вызове, тем шире жгут/лента.
И т.д.

Т.е. чисто эстетическая визуализация. В идеале - работающей программы с анимированием всех процессов внутри неё...

 

Это был дизассемблер в чистом виде, управлять процессом дизассемблирования можно было рутем задания специальных команд.

 

пишите лучше сами а не разивайте рот на произведения других

 

вы сами понимаете что пишете ????
маленькое но принципиальное архитектурное изменение может обернуться настоящим гемороем даже в случае когда вы обладаете исходниками