Soft Дизассемблирование и декомпиляция программ(игр)

Всем здравствуйте. После чтения темы по установке Chasm The Rift у меня возникла мысль по декомпиляции или дизассемблировании. Хотелось бы знать насколько сложен этот процесс и что для этого нужно. Ну и примеры того, как это возможно сделать. Хотелось бы переделать для начала Chasm или Beasts & Bumpkins. Для Мастерской тема не сгодится. Знаю что одного только исходного кода недостаточно потому что нужны еще новые текстуры, которые смогут хорошо отображаться на широких экранах с высоким разрешением. Ну и звуки с музыкой тоже.

 

Mysyk, для этого надо технически:
1. IDA - дизассемблер такой умный.
2. До хрена прочей фигни на все случаи жизни - отладчики, компиляторы, анпакеры.
Ну и соответсвующее железо в ряде случаев.
3. Светлую голову и прямые (желательно ещё и чистые) руки.

А кроме всего прочего надо бы нехило знать железо, системы команд процессоров (на свете их больше чем 1), внутренности различных операционок и их API, в случае CHASM ещё и спецификацию DPMI. Ну и неплохо бы всё это изучить в течении недельки или двух максимум.

И это самый минимум. А музыка и художества - это уже совсем другая опера...

 

Bato-San, спасибо за план. У меня в планахмечтах собрать свое сообщество(команду). Возможно далеких.
На каком языке перепрограммировать? Delphi, C++ и какие там еще есть?
В моем случае не то что прямые, а скорее как безрукий.
Из ОС надо рассматривать от Win98 до WinXP, затем Vista, Seven и будущие ОС семейства Microsoft. И конечно же Unix-системы.
Есть ли возможность соединить декомпилированный код с Open-Source движков и других игр? Или это не ускорит процесс пересоздания и только усложнит?
Для Chasm я примерно представляю себе порт наподобие портов для Doom и Quake 1. Для Beasts and Bumpkins наподобии порта для Dune 2.

 

Это все надо, но проблема не в этом. Самая большая сложность не в коде, а в его количестве. Объемы настолько велики, что самая рутинная и простая работа рискует затянуться на годы.
Попутно, предлагаю задачку для пояснения того, с чем придется столкнуться:

Всего два десятка байтов, но что это?

 

Блин. Даже понятия не имею. Так. ROM скорее всего память. Но никак не Read Only Memory. Обращение к адресам памяти. Если что, то дай ссылку, где можно будет пополнить знания.

 

Судя по виду - какой-то бред видимо кусок защиты какой-то программы, в ртс выход. И это разве PC? Какой-то он восьмибитный.

 

Это MOS 6502. Стоял в Apple 1/2, Агат и многом другом, включая NES. Вобщем очень популярный был проц... да... В данном случае мы видим кусок некоего ROM фиг знает от какого устройства. Что хотя и не сводит к нуля понимание содержания куска, но сводит к нулю осмысленность вопроса "что это?".

Mysyk, Проблема начинается там, где новичок захлебнётся в информационном потоке. Это только кажется, что код надо всего то "декомпилировать", а потом "подправить, как надо" и "скомпилировать"... Всё не так просто. А что бы понять, насколько это не просто - надо много читать, изучать, писать код... Иногда в принципе можно вообще не заниматься декомпиляцией - к примеру тот же пакмен изготавливается чисто "по памяти", как и Арканоид и Тетрис. Но там и кода то... где то валяется коллекция игр этого типа размещённых в 256 - 1024 байтах памяти - для IBM.

Unix - вообще отдельная песня. А начинать в случае CHASM надо от MS-DOS.

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

Выбор компилятора дело вообще очень ответственное ибо "не всё одинаково полезно" в разных ОС, что бы там не говорили упёртые приверженцы MSVC и C# Чую, быть батхерту на пустом месте, после этой фразы. Но, гильотина, конечно же, тоже хорошее средство от "головы".

 

Па-а-адписываюсь на тему. =)

 

В том-то и подвох. Большинство дизассемблированных кусков именно так и выглядит. В данном случае все предельно просто - это генератор случайных чисел. Но для того, чтобы это понять, надо либо помнить наизусть тысячи парадигм ассемблерных алгоритмов (от распаковок-сортировок, до типовых оптимизаций разных компиляторов), либо разбираться в кусках, окружающих данный, чтобы понять, зачем и кто его использует. Однако, и на вызывающих кусках нигде не написано, зачем они нужны...
В данном случае обошлось малой кровью. Поняв, что логика этого куска от меня ускользает, я начал искать куски, с ним общающиеся. Достаточно быстро обнаружил, что в в BASIC-части программы по упоминаемым здесь адресам изначально грузится что-то подозрительно напоминающее значение таймера. Где таймер - там, обычно, и генератор случайных чисел. Полез во второй том Кнута - действительно, есть подобные, аддитивные, генераторы. Для очистки совести переписал на C и погонял (а вдруг распределение оказалось бы не равномерным). Ура! Осталось еще 1250 байт (библиотечка-то маленькая).

 

Ну я считай угадал А судить по мелкому куску кода (причем дизассемблированного) о полной программе вообще нереально. Вот этот что делает (учитывая что это вообще исходник, не дизассемблер):

Код:

	ld ix,0
	ld hl,t,de,gfx_bf
t1	ld a,(hl):and a:jp z,t_e
	inc ix
	push hl
	ld h,#40,b,fht
1	xor a:ld l,a
	dup 32
	ld (hl),a:inc l
	edup
	inc h:djnz 1b
	pop hl
	push de
	ld bc, 0
t2	ld a,(hl):inc hl:cp 13:jr z,t3
	push hl
	call prs
	pop hl
	jr t2

PS: Посмотрим, насколько задача анриал

 

Scorpion ZS 256, хе. приколол - тонко ! Назначение этого куска всё же абсолютно точно идентифицируется по паре чисел, одной метке и некому особому знанию (сорри за спойлер) !

gudleifr, то, о чём ты толкуешь - тривиально. И тут уж или ты быстро соображаешь в чём прикол или... не соображаешь. Объём играет роль, когда тебе надо всё это привести в "компилябельный" вид. Даже не в удобочитаемый.

А если вам так охота "трудностей жутких" - вспомню, про недокументированные команды процессоров и не менее недокументированные особенности оборудования, а ещё про оборудование, которое никто в глаза не видел, но коды обслуживания которого сидят в ПЗУ и, временами, весьма причудливо используются не по назначению или срабатывают при "плохой погоде".


Guyver, На обложке: "Сможете восстановить программу по исходному коду". Это перл !

 

1. Во-первых оно точно идентифицирует неумение/нежелание "обрезать" код под распознавание. Многовато неразрешенных ссылок. Конечно, здесь они имеют значение [шутливых] намеков, но...
2. Основная истина дизассемблирования: "ничто не может быть идентифицированно аболютно точно"! Если угодно, эта задача доказуемо неразрешима.

Именно.
3. Дизассемблирование - вещь тривиальная. Вопрос только в объеме.

Всегда.

4. Такие вещи встречаются настолько редко, что обычно, наоборот, облегчают дело, служа маяками.
5. И откуда взялась идея "судить по куску о всей программе"?

 

Scorpion ZS 256, заполняет нулями область памяти с 4000 по 401F; потом, если в fht была 1, вызывает какую-то функцию prs, пока не встретит 13 в памяти, начиная с адреса t; иначе прыгает на 1b. Ну и всякие мелочи делает, которые хрен знает зачем нужны, по этому куску не угадаешь. Короче, что делает вся программа, вряд ли можно узнать. И это не потому что на ассемблере написано) Из исходника на любом другом языке можно выдернуть кусок в 20 строк, по которым ничего нельзя судить о полной проге, даже если будет досконально понятно, что происходит в этом куске.

 

gudleifr, "объём" при таком утверждении - измеряет глубину лени и потребности в решении задачи. При такой постановке вопроса "всегда" звучит логично.

Всё, что может быть запущено - может быть сломано. B.R.H.

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

DI
HALT

Ибо спор не в ту сторону пошёл.

А если ещё кто то захочет покидаться кусками кода - сперва почитайте вот ЭТО.

 

Создатели защит смеются над этим.

Если говорить об алгоритмах дизассемблирования - может быть. Только код всегда один и тот же и он не меняется со временем.

Если знать и уметь.

Оправдание тех, кто занимается переводом приставочных игр на картдриджах.

Абсолютно все ли игры видел?

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

 

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

Что же касается книжек, то нужно понимать тоже только две вещи: читать надо. т.к. на пальцах всего не объяснишь, и никогда нельзя думать, что уже прочел столько, что хватит завершить даже текущий проект.
Для начала порекомендую букинистические: Брэдли (по ассемблеру), "Правец-16", Джордейн. Конечно, в них описаны компьютеры, которых уже давно не существует в природе, но "мурзилки", вроде указанной выше, дают только видимость знания. Прочтя перечисленные мною книги, Вы получите задел, который поможет выдирать из "мурзилок" крохи имеющейся там информации. (Как я до сих пор краю затертые до дыр ксерокопии трех страничек из описания Турбо-Асма с перечислением методов адресации).

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

---------- Сообщение добавлено в 15:28 ---------- Предыдущее сообщение размещено в 15:26 ----------

Я больше не по играм.

 

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

Ещё как существуют И даже работают. И их даже реанимируют в случае надобности и пишут эмуляторы.

Doctor - sanare se! Ибо аргументы ваши странны местами, а чужие посты вы не до конца понимаете, даже там, где с вами соглашаются

 

Offtop

Эх, жаль тут Дж.Фримена нет.

 

Не смешно. Когда я увольнялся, оставил ящик стола, забитый доверху CD-дисками с приходящими-исходящими. Я даже их все надписал...