BIOS protection by Holly

[kof888]

Can you tell me which address specific bios files?

[MetalliC]

(17.06.2014 17:46)kof888 писал(а):  Can you tell me which address specific bios files?

what you mean ?

I was asking about

Код:

mov.l @(h'EC,pc), r5 ; [8C0005F4] = h'A0008000
mov.w @(h'F0,pc), r4 ; [8C0005FA] = h'300
mov.w @(h'EC,pc), r0 ; [8C0005F8] = h'3400
bsr sub_8C00055E

I've debugged a bit random games, but not seen calling of sub_8C00055E with such arguments.
so I've asked - where you seen (mov.l @(h'EC,pc), r5 ; [8C0005F4] = h'A0008000) ?

[kof888]

Those are the bios file inside, 0xA0000000 address is bios

During that process is beginning to enter the bios do not call the game before the last

Simply copy the bios is to open the opportunity to start and run a number of bytes of memory (IP check front)

[MetalliC]

you are not native english, right ? and use Google-translate or something like that to translate texts from yours native language to English ?
bad news - those translated texts becomes total nonsense and impossible to understand, better write on your language, or better post both message variants - original and google-translated.

[kof888]

是的，我不会说英语，我是用google翻译的

我想说的是那段程序是在ip画面读取显示之前，是从bios复制过去的，我觉得和这关系不大（isoload是跳过这段的）

当年在rc1的时候我就测试过UNDER_DEFEAT，光盘引导可以看见游戏loading的画面，如果是刷写bios的话是到不了这里的，其中会到某个地址返回（如果​nop的话可以跳过这里，不过后面和光盘引导的一样停到loading画面）

http://www.dc-swat.ru/forum/thread-1370-...l#pid22812

最后我观察了一下，凡是dc游戏，读文件名是以mov.l @(h'3C,r14), r0 JMP @r0开头的游戏，部分可以支持sd hdd，如果是以mov.l @(h'40,r14), r0 JMP @r0读取文件名的程序的话，肯定都不支持

r14=CD001地址处-0x80







Yes, I do not speak English, I use google translation

I want to say is that part of the program is to read before the ip screen display is copied from the bios in the past, I think, and not this relationship (isoload are skipped during the)

Year in rc1 when I tested UNDER_DEFEAT, CD guide can see the game loading screen, if it is, then flashed bios is not here, where will be returned to an address (if you can skip if nop here, but behind and CD-ROM as the boot of

http://www.dc-swat.ru/forum/thread-1370-post-22812.html # pid22812

Finally, I observed a moment, all dc games, read the file name is mov.l @ (h'3C, r14), r0 JMP @r0 beginning of the game, and some can support sd hdd, if you are mov.l @ (h'40, r14), r0 JMP @r0 program reads the file name, then certainly do not support

r14 = CD001 address-0x80

[SWAT]

(17.06.2014 20:40)MetalliC писал(а):  better write on your language...

Ahahaha now better? ))
I'm little adapted himself for understanding him, but sometimes it's really hard and I have to ask again and again.

One tip for kof888, try to write on literary language and maximally competently compose sentences. It is much better for the translator.

[SWAT]

(17.06.2014 16:17)MetalliC писал(а):  получается, что железяка мониторит и суммирует данные читаемые с G1 с самого старта системы, а не только после записи 5F74E4
и когда выполняется весь тот код дизассемблинг которого я привел выше - это и есть чтение первых 256 байт
потом, уже после записи 5F74E4 код прокачки просто продолжает его читать дальше, с 100

тогда получается, что пока/когда девайс в "залоченном" соcтоянии (в т.ч. после сброса) он суммирует всё что читается через G1, а запись 5F74E4 просто устанавливает последний адрес, НО не сбрасывает текущую вычисленную контрольную сумму.

Хмм наверное поэтому временный swap биоса не работает должным образом.
Получается сначала нужно сбросить подсчет контрольной суммы, который запустился на старте. Может как раз просто записью в этот регистр значения 0x42fe это и сделать? Я кстати не думаю что это совсем "отфонтанная" цифра, ну точнее она просто заложена в holly, как в случае и с многими другими регистрами, допустим регистр holly reset, в него пишется 0x7611 для активации сброса и никакое другое значение этого не сделает. Просто Sega любит волшебные числа ))

P.S.
Кстати мы не правильно выражаемся, когда говорим что блокируется шина G1.
Сама шина никак не блокируется, ибо на ней находятся еще BiosROM и FlashROM.
Блокируется только IDE интерфейс для привода.

[MetalliC]

всё это можно (и стоит) проверить,
для начала убедиться, что предыдущее предположение вообще верно, и попробовать такой код инита, с чтением кусочка биоса до записи 74Е4

Код:

*react = 0x1fffff;

    for(p = 0; p < 0x200 / 4; p++) {
        (void)bios[p];
    }

    *react = 0x1fffff;

    for(p = 0; p < 0x200000 / 4; p++) {
        (void)bios[p];
    }

если инит гдрома после этого таки произойдет - значит запись 74E4 таки сбрасывает текущую сумму (а не сбрасывает только при "холодном старте" системы), что нас оч даже устраивает

если гдром будет залочен - значит мы угадали
и если так можно проверить гипотезу с "магической цифрой"

Код:

*react = 0x1fffff;

    for(p = 0; p < 0x200 / 4; p++) {
        (void)bios[p];
    }

    *react = 0x42fe;

    *react = 0x1fffff;

    for(p = 0; p < 0x200000 / 4; p++) {
        (void)bios[p];
    }

Цитата: Я кстати не думаю что это совсем "отфонтанная" цифра, ну точнее она просто заложена в holly, как в случае и с многими другими регистрами, допустим регистр holly reset, в него пишется 0x7611 для активации сброса и никакое другое значение этого не сделает.

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

Цитата:Кстати мы не правильно выражаемся, когда говорим что блокируется шина G1.
Блокируется только IDE интерфейс для привода.

я думаю всем присутствующим здесь это и так понятно

[cybdyn]

первые 0x100 как раз могут вычитыватьса при исполнении кода из биоса. далее копия куска кода в кэш. и прокачка (из кэша - это важно!) со "0х100" (или как там..).
так что вероятность есть, что данные прокачиваютса с самого начала, через некий "сумматор",
а запись 1fffff, возможно указывает в какой момент (или признак: количество, маг.число и т.д) - до остановки и сравнения результата.

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

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

[MetalliC]

уфф, если всё же оба варианта будут давать облом - нам надо искать сброс этой хренотени, без него брутфорс этого дела будет крайне гемороен.

можно предположить, что оно само сбрасывается, при чтении "конечного адреса", проверять типа так:

Код:

*react = 0x3ff;

     for(p = 0; p < 0x400 / 4; p++) {
         (void)bios[p];
     }

     *react = 0x1fffff;

     for(p = 0; p < 0x200000 / 4; p++) {
         (void)bios[p];
     }

[cybdyn]

а этот кусок откуда или где появляетса исполнение : react = 0x3ff; ? я где то видел... но не припомню точно

[MetalliC]

(18.06.2014 14:36)cybdyn писал(а):  первые 0x100 как раз могут вычитыватьса при исполнении кода из биоса. далее копия куска кода в кэш. и прокачка (из кэша - это важно!) со "0х100" (или как там..).
так что вероятность есть, что данные прокачиваютса с самого начала, через некий "сумматор",

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

(18.06.2014 14:36)cybdyn писал(а):  а запись 1fffff, возможно указывает в какой момент (или признак: количество, маг.число и т.д) - до остановки и сравнения результата.

судя по всему да.

(18.06.2014 14:36)cybdyn писал(а):  если допустить что сега делала это просто для защиты чексуммы, а не от левого биоса/пиратсва. то мож как вариант вписать 0 и прочитать 0))

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

---

(18.06.2014 14:39)cybdyn писал(а):  а этот кусок откуда или где появляетса исполнение : react = 0x3ff; ? я где то видел... но не припомню точно

это кусок кода инициализации гдрома в KOS, SWAT поймет )

[cybdyn]

может и защита, а может и нет)
из кэша могли для ускорения это сделать.
по чексумме, могли не написать, т.к не входит в понятие разработки иного биоса, тем более он в однократной пзу.
есть так же много пробелов по другим вопросам. тот же привод возвращает какойто набор кода по команде 0х71.

[MetalliC]

(18.06.2014 14:51)cybdyn писал(а):  из кэша могли для ускорения это сделать.

шо ? из какого такого кеша ?

(18.06.2014 14:51)cybdyn писал(а):  по чексумме, могли не написать, т.к не входит в понятие разработки иного биоса, тем более он в однократной пзу.

это в дриме в однократной, в Наоми в обычной УФ-стираемой ПЗУ в DIP корпусе, на панельке.

(18.06.2014 14:51)cybdyn писал(а):  есть так же много пробелов по другим вопросам. тот же привод возвращает какойто набор кода по команде 0х71.

пробелов "аж" три:
- контрольная сумма биоса
- SPI комманда 0x70
- SPI комманда 0x71
и всё

add: ну и защита GD-диска от копирования, но я лично думаю что там то же самое что и в Saturn - в области "кольца" дорожки не "ровные" а с радиальным биением, привод детектит сей факт.
и скорее всего по 0x71 и возвращает результат поверки на это дело

[SWAT]

(18.06.2014 13:17)MetalliC писал(а):  всё это можно (и стоит) проверить,
для начала убедиться, что предыдущее предположение вообще верно, и попробовать такой код инита, с чтением кусочка биоса до записи 74Е4

Код:

*react = 0x1fffff;

    for(p = 0; p < 0x200 / 4; p++) {
        (void)bios[p];
    }

    *react = 0x1fffff;

    for(p = 0; p < 0x200000 / 4; p++) {
        (void)bios[p];
    }

если инит гдрома после этого таки произойдет - значит запись 74E4 таки сбрасывает текущую сумму (а не сбрасывает только при "холодном старте" системы), что нас оч даже устраивает

Работает.

(18.06.2014 13:17)MetalliC писал(а):  если гдром будет залочен - значит мы угадали
и если так можно проверить гипотезу с "магической цифрой"

Код:

*react = 0x1fffff;

    for(p = 0; p < 0x200 / 4; p++) {
        (void)bios[p];
    }

    *react = 0x42fe;

    *react = 0x1fffff;

    for(p = 0; p < 0x200000 / 4; p++) {
        (void)bios[p];
    }

Работает.

(18.06.2014 14:37)MetalliC писал(а):  уфф, если всё же оба варианта будут давать облом - нам надо искать сброс этой хренотени, без него брутфорс этого дела будет крайне гемороен.

можно предположить, что оно само сбрасывается, при чтении "конечного адреса", проверять типа так:

Код:

*react = 0x3ff;

     for(p = 0; p < 0x400 / 4; p++) {
         (void)bios[p];
     }

     *react = 0x1fffff;

     for(p = 0; p < 0x200000 / 4; p++) {
         (void)bios[p];
     }

Не работает.

[cybdyn]

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

sw: как понять работает / не рабоатет,? уже нашёл формулу)))?

[SWAT]

(18.06.2014 17:22)cybdyn писал(а):  sw: как понять работает / не рабоатет,? уже нашёл формулу)))?

Если "работает", то значит проверка пройдена и IDE разблокирован.
А "не работает" значит что IDE не разблокировался.

[OzOnE]

Hi,

Here is my crappy GD / IDE test code for checking the Holly lockout...

https://mega.co.nz/#!654gUBiI!XkG0QLjgGI...GgvhqOuqc0

I haven't had chance to do much else yet, but I'm hoping it can be bypassed by forcing some specific Word values onto the G1 bus.

It easiest to just load the binary from Dreamshell, then press Y to switch to "ATA" mode.

Pressing X should switch between Hex and ASCII display, but it can be a bit messed up (code needs checking / fixing).

If you then press A, it will do the usual "g1_activation" check by reading the whole BIOS.
But, it only knows whether it has passed the check by reading back a specific WORD value from your HDD / CF.

It's easier to understand if you look in the code. eg...

if (*DMA_LOAD_ADDR == 0x49524952) // Check the first word of the buffer to make sure it matches MY HDD contents!!

Remember, when it displays the hex on screen, it's actually Byte-swapped too, so the value I see on screen is 0x5249.

I just used an arbitrary sector on the HDD for the test - you have to change the default FAD at the top of the code to suit your HDD. eg...

int dump_fad = 314;

(I just used the FAD address, even though I'm reading from HDD. )

So basically....

1. Run the GD.BIN.
2. Find any arbitrary Word value on your IDE device using the D-Pad, but keep the Offset to 0!
3. Note down the FAD address where your Word is.
4. Modify the default FAD value at the top of the code.
5. Modify the check code to match the Word at that address.

Hope that makes sense - it's just a quick-and-dirty way to test the lockout.

To force the HOLLY check to Fail, I simply switched the physical Flash BIOS switch on my DC DURING the check!
(I'm using sd_loader_with.bios, so it still passes the test in either switch setting).

So, probably best just to switch back to the stock Sega BIOS, then try some different code tests to see if you can get it to pass.

If it does get locked out, you CAN re-do the test and get it to unlock the G1 / IDE again (you don't need to reset the DC).

Don't try DMA in the code though, it wasn't fully working anyway (locks up when waiting for DMA flag, so had to add a delay instead.)
PIO works fine for checking the Holly lockout, so don't press B if the lockout fails!

Oh, and make sure that nothing in the code is writing back to your IDE device or you might corrupt something! :o

A lot of junk in the code is from me trying to get it to boot a game from IDE many months ago, so please ignore it.

The code also contains chunks of other people's code (like Bluecrab's PSO loader syscall routines), but it's all in the public domain anyway.
It does have some basic GD Syscall redirection though, so all the PIO / DMA reads are being redirected via cdfs_redir.s, and going back to the C routines.

As always, I'm probably over-complicating things.
If you read the bottom part of the code, it makes more sense. lol

OzOnE.

[MetalliC]

требуется проверить модифицированный биос на работоспособность на дриме.
кто-то с флеш-модом биоса сможет помочь ?

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

[cvgs]

да тут почти у всех есть, но лучше свату кидай.