BIOS Disassembling

[MetalliC]

я тут порылся в старых логах IRC и не только, почитал что умные люди разбиравшиеся с этим делом говорили, и похоже всё-таки контрольная сумма считается в процессе "прокачки", вот только я ошибся в том что именно мониторит данные с G1, и это не Holly а сам GD-ROM (в случае Naomi - Altera FLEX EPF8452(есть ее firmware если кому интересно), ну а в Atomiswave наверное чип "Romero" или вообще ничего)

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

cybdyn зачем реверс ? доки по SPI GD-ROM-а есть и в них всё верно описано, кроме пары недокументированных команд 0x70 и 0x71, эмуляторы на них возвращают фиксированные блоки данных.
грубо говоря если взять gdromv3.cpp из NullDC и реализовать в FPGA ну и отреверсить и реализовать протокол работы по шине G1 - это дело должно работать.

SWAT все занимавшиеся проблемой всё-таки склоняются к тому, что контрольная сумма считается только после записи регистра и только "прокачиваемых" данных, так что первые 256 байт можно менять.
ну а самая большая дырка в том, что они использовали слабо стойкий алгоритм, что методом тыка можно случайно получить данные проходящие проверку, в случае например CRC32 вероятность такого была бы очень очень мала, больше похоже что там 16-бит, а то и вообще 8бит алгоритм.
кста как в Dreamcast так и в Naomi, т.к. у D.Knute методом тыка получилось сделать рабочий модифицированный биос для нее.

[SWAT]

Ну некоторое время назад я тоже считал что проверку осуществляет сам GD-ROM, но после холиваров с cybdyn мы решили остановиться на том, что проверку делает holly. И как оно на самом деле я уже и не берусь утверждать наверняка.
Но есть тут еще один такой момент... Ну ладно, заблокировался gd-rom ну и хрен бы с ним вроде, если он не используется. Но не все так просто, katana игры при этом тоже перестают работать, даже если им подсовываешь другие сисколы, а они ведь с gd-rom общаются только через них. Эта блокировка влияет еще на что-то, но вот на что и как оно проверяется я не знаю.

[cybdyn]

к гдрому не подходит сигнал CS и адресная шина только 3 адреса. врятли гдром чтото увидит.

вообщем то а что даст разгадка алгоритма. задача загрузить код и исполнить. эта возмоность есть.

[SWAT]

И где эта возможность? Типа вот эти 256 байт? Я сомневаюсь что это прокатит...
А без проверки биоса, игры не работают. Знание алгоритма решило бы все проблемы.

[cybdyn]

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

[SWAT]

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

[MetalliC]

(02.08.2013 13:42)SWAT писал(а):  Но есть тут еще один такой момент... Ну ладно, заблокировался gd-rom ну и хрен бы с ним вроде, если он не используется. Но не все так просто, katana игры при этом тоже перестают работать, даже если им подсовываешь другие сисколы, а они ведь с gd-rom общаются только через них. Эта блокировка влияет еще на что-то, но вот на что и как оно проверяется я не знаю.

с этим действительно не понятно, вот лог доступа к области гд-рома и управляющих регистров при буте шенмы2 http://rghost.ru/47890388 (последняя цифра в логе - PC с которого был доступ, логировалось всё что попадало под if ( memMasked >= 0x7000 && memMasked < 0x7800)
) вроде весь доступ с области сисколов, хотя в либах катаны находятся указатели на A05F74xx, так что возможно что софт сам проверяет статусы дма G1.

SWAT ткни носом плз где можно почитать на тему этой проверки и не работы игр при запуске с SD

[cybdyn]

классный лог! в графе read только нехватает что именно прочитано. както монжо подправить?

под GD - я так понял область с базовым адресом: A05Fxxxx?

адрес на конце - это точка где перехват чт. записи был?

[MetalliC]

(04.08.2013 23:17)cybdyn писал(а):  под GD - я так понял область с базовым адресом: A05Fxxxx?

да, старшие 16 бит в лог не пишутся, и так ясно что это x05fxxxx

(04.08.2013 23:17)cybdyn писал(а):  адрес на конце - это точка где перехват чт. записи был?

да, это адрес опкода SH4 который читал/писал регистр попадающий в диапазон 5f7000 - 5f7800
собсно в этом и смысл, я хотел посмотреть лезут ли игры сами к гдрому и к GD-DMA Control Registers или делают это только через сисколлы

но, как я уже говорил, судя по тому что я видел в shinobi.lib из katana sdk могут и сами 5f74ххх читать/писать

[cybdyn]

либо может както переназначают указатели сисколов на свои.

но мне больше понравился лог, както увидеть что читается можно?

[MetalliC]

(05.08.2013 03:27)cybdyn писал(а):  либо может както переназначают указатели сисколов на свои.

возможно, я в логах IRC-канала NullDC что-то видел на эту тему.
типа в зависимости от результата недокументированной команды 0x71 (или 70?) код сисколов пишется разный.
хз так ли это, сам не проверял.

(05.08.2013 03:27)cybdyn писал(а):  но мне больше понравился лог, както увидеть что читается можно?

да, вот http://rghost.ru/47898930

[SWAT]

(04.08.2013 19:49)MetalliC писал(а):  SWAT ткни носом плз где можно почитать на тему этой проверки и не работы игр при запуске с SD

Об этом ты можешь почитать только здесь, что я написал Ведь никто кроме меня пока не делал софтварную эмуляцию GD-ROM, для запуска коммерческих игр с SD. А если ты и имел ввиду этот форум, то фактически в этой теме большая часть обсуждений и было.

[cybdyn]

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

[cybdyn]

Metalic - у тебя есть эти доки по SPI GD-ROM??? скинуть можешь или где скачать... твой лог очень занимательный))!!!

[MetalliC]

дока у меня та же что и у всех "cdif131e.doc", "Gdfm_k214e.doc", "Gdfm_s132e.doc".

[SWAT]

Ну в kamui и shinobi мало чего интересного, это уже библиотеки, в которых только API можно глянуть. А вот cdif это то что нужно и я тебе уже писал же про нее cybdyn, там весь SPI/ATA протокол описан.

[cybdyn]

повторение - мать наладки)) лучше линк

[SWAT]

https://dl.dropboxusercontent.com/u/40145/CDIF131E.pdf

[cybdyn]

теперь сопоставить этот док и лог...

может ещё лог от обычной(другой) игры сделаешь?

[MetalliC]

cybdyn тебя в гугле чтоли забанили ?
вбиваешь в поиске имена указанных файлов и качаешь по первой же ссылке.

(06.08.2013 13:17)cybdyn писал(а):  теперь сопоставить этот док и лог...

может ещё лог от обычной(другой) игры сделаешь?

уфф, если уж собрался разгребать всякие логи гдрома - скачай исходники NullDC, найди в nullDC\dc\gdrom\gdromv3.cpp строчку "#define printf_rm nilprintf" и замени на "#define printf_rm log", скомпилируй эмулятор, запусти игру и разбирай полученную кучу текста хоть до посинения
там же есть дефайны принта SPI и ATA команд, включаются аналогично заменой nilprintf на log

SWAT два последних дока это не камуи/шиноби, а описания формата гд-ромов, тоже полезно для понимания что там, где и как на диске лежит.