BIOS protection by Holly

[OzOnE]

Ok, some more thoughts (hope this is OK to post?)...

Код:

    /* initialize ROM checksum */
    *HW32(0xa05f74e4) = 0x001fffff;

    /* switch to double precision (for 64bit copying below) */
    reg[FPSCR] = 0x00140001;

    /* Copy various parts from ROM to RAM */
    /* This is done for two reasons:
     * First, code and data must be available to be executed from RAM
     * secondly, the data read from ROM are passed through some type
     * of "checksum". Unless a specific value is computed, a flag is
     * set to disable the GDROM drive. Sega must have put this in there
     * to "discourage" people from replacing the BootROM with their custom
     * versions!
     */
    src = (uint64_t *)0xa0000000;
    dst = (uint64_t *)0x8c000000;
    for (i = 0; i < 32; i++) {    /* skip the system variables */
        (void)*src++;        
        dst++;
    }
    for (i = 0; i < 2016; i++)     /* copy a0000100-a0004000 to 8c000100 */
        *dst++ = *src++;

    for (i = 0; i < 2048; i++) {    /* skip a0004000 to a0007fff */
        (void)*(src++);
        dst++;
    }
    for (i = 0; i < 258048; i++)     /* copy a0008000-a0200000 to 8c008000 */
        *(dst++) = *(src++);

    /* back to single precision */
    reg[FPSCR] = 0x00040001;

    boot2(reg[DBR]);

The above code was taken from the bottom of this page...
http://www.ludd.luth.se/~jlo/dc/

Could it simply be that the HOLLY chip is checking for something in the chunk of "License Screen" code in the BIOS, from 0x8000 to 0xB3FF?

This is the same chunk of code that it checks against the code in IP.BIN from 0x300 to 0x36FF...
http://mc.pp.se/dc/ip.bin.html

"Note that the code in this area can not be modified. The ROM checks every byte of it against a copy in the ROM, and will not boot the disk if there is a difference."

SWAT - have you tried just putting that chunk of code back in the ROM, then doing the GD activation check by copying only from 0x8000 to 0xB3FF?

I'll try some tests on that to see if it still passes the checksum.

OzOnE

[OzOnE]

I keep seeing this "interesting" Word value too (0x42FE, from the MESS source)...

Код:

    // The following is required to unlock the GD-ROM. The original Japanese BIOS doesn't need it
    case GD_UNLOCK:
        if (data==0 || data==0x001fffff || data==0x42fe)
        {
//          atapi_regs[ATAPI_REG_SAMTAG] = GDROM_PAUSE_STATE | 0x80;
            printf("Unlocking GD-ROM! %x\n", data);
        }
        break;
    }

Which seems to have been taken from "security_stuff.c".

Maybe 0x42fe is a seed value? Or probably just an arbitrary random number to request a GD Unlock syscall?

[SWAT]

0x42fe - this is a flag for disable GD drive. It's not a seed, just magic value for this reg.
A similar approach is used and in some other registers.
0x001fffff - this is a size of boot ROM (last byte offset), I think need all 2MB data for checking, otherwise it's not completed.

[OzOnE]

Ahh, thought so.

Looks like it's just a quick way to disable the drive by scrambling the checksum again then?

I'm wondering if the 0x001ffff can be reduced though?
It may just be to set the "size" of the final checksum and initialize it.

It might be possible to get a correct checksum using a much smaller part of the BIOS, but we'll still need to find the algo.

btw, I think the File Explorer corrupted my HDD slightly - I was trying to copy the OTOREI.CDI from SD to HDD, and it dumped a few junk folder names on the drive?
It didn't complete the copy either, it just took half a second to "copy" a 700MB file?

I was looking at trying OTOREI, as it's apparently the only title which used the DC MIDI interface?
The MIDI IN / OUT signal test pads are supposed to be at the back of the mobo (underside) near the G2 expansion port.
I thought it might be fun to connect a MIDI keyboard + synth to that soon.

Anyway, I'm still hoping to get time today to connect the FPGA board so I can try to brute-force the BIOS checksum.
It's just that the soldering is a bit daunting, 'cos I'll have to figure out the pins for the G1 IDE connection again. lol


OzOnE.

[kof888]

mov.l r14, @-r15
sts.l pr, @-r15
mov r4, r14
mova @(h'2B4,pc), r0 ; unk_8C0007B0
mov r0, r5
bsr sub_8C00055E
mov #h'10, r0
bf loc_8C000556
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
add r14, r4
bf loc_8C000556
mov.b @(h'72,gbr), r0
and #7, r0
mov r0, r6
mov #5, r1
shld r1, r0
add r0, r4
add r0, r5
bsr sub_8C00055E
mov #h'20, r0
bf loc_8C000556
add #h'30, r6
add r14, r6
mov.b @r6, r1
add #-h'18, r4
mov.b @r4, r0
cmp/eq r1, r0
bf loc_8C000556
mov r14, r0
add #h'60, r0
mov.l r0, @(h'9C,gbr)
mov r14, r4
bsr sub_8C000572
add #h'3E, r4
mov.b r0, @(h'24,gbr)
mov r14, r4
add #h'3D, r4
bsr sub_8C000574
mov #1, r2
mov r0, r1
add #-2, r1
mov.b @(h'26,gbr), r0
and r1, r0
mov.b r0, @(h'26,gbr)
bra loc_8C000558
mov #0, r0
; ---------------------------------------------------------------------------

loc_8C000556: ; CODE XREF: ROM:8C000502j
; ROM:8C00050Ej ...
mov #-1, r0

loc_8C000558: ; CODE XREF: ROM:8C000552j
lds.l @r15+, pr
rts
mov.l @r15+, r14











sub_8C00055E: ;
mov.b @r4, r2
mov.b @r5, r3
cmp/eq r3, r2
bf loc_8C00056E
dt r0
add #1, r4
bf/s sub_8C00055E
add #1, r5

loc_8C00056E: ;
rts
tst r0, r0

---

I think the issue here is not

[MetalliC]

(13.06.2014 09:27)kof888 писал(а):  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

а откуда это? я смотрел под отладчиком - да, в 8C00055E процедурка сравнения, но с такими аргументами она у меня не вызывалась.

Цитата:I'm wondering if the 0x001ffff can be reduced though?
It may just be to set the "size" of the final checksum and initialize it.

for sure.
for example Sammy Atomiswave have only 128Kb BIOS, so code writes 0xA677 to this register and then execute a read loop until this address.

from my current knowledge about "how it works" - 5F74E4 register is definitely "last address of checksum calculation".
then its written - device resets to "locked" state and (starts to )or(switch to state of) calculate checksum until that address.
after reading this "last address" calculated checksum compared with some hardcoded value, and if they match - G1 bus will be unlocked.

but how this is done totally unclear...
imo there is 2 options -
1. hardware reads data automatically, by itself, so "read loop" in bios code is just a delay, long enough until Holly reads BIOS and unlocks G1 bus.
2. hardware monitor data passed through G1 bus (i.e. bios readed by code) and summs them, and then readed address will match "last address" it compares calculated summ.

[SWAT]

Reducing the size will not help against the protection, since the required checksum we can't get from part of original BIOS, need all data...
At least it does not alleviate the problem, so it makes no sense.
I think it's the second option, since the first implies simultaneous reading of BIOS by processor and holly, and this obviously does not good, just may be a conflict. And it would work longer, then it was easier and safer to use a timer.
I have an idea ... Maybe instead of reading, try to write data onto the bus, maybe Holly does not understand the trick, because the data will be on the bus.
Although it would be too easy ...

[MetalliC]

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

есть добровольцы ?
требуется наличие дрима и CD-болванки

PS: почему я не исключаю первый вариант ?
в биосе Atomiswave 5f74e4 пишется когда код крутится еще в биосе, и сама процедурка прокачки крутится там, так что получается что "мониторилка" сначала увидит чтение в линейку кеша проца процедурки прокачки, а затем уже читаемых ей данных биоса (которые начинаются сразу после нее).
возможно конечно, что там оно акуратно рассчитано, что у кода процедуры+последующих данных получается как раз та что надо контрольная сумма.

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

[MetalliC]

(16.06.2014 07:17)SWAT писал(а):  I have an idea ... Maybe instead of reading, try to write data onto the bus, maybe Holly does not understand the trick, because the data will be on the bus.
Although it would be too easy ...

very good idea, if it true - it will be really superb
but needed someone who can check this assumption.

[SWAT]

Я просто изменил в KOS код прокачки, вместо чтения всего биоса, я читал в цикле только первые 4 байта. Результат ожидаемый, зависло на инициализации привода.
Трюк с записью вместо чтения тоже не прошел

[MetalliC]

(16.06.2014 14:16)SWAT писал(а):  Я просто изменил в KOS код прокачки, вместо чтения всего биоса, я читал в цикле только первые 4 байта. Результат ожидаемый, зависло на инициализации привода.

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

(16.06.2014 14:16)SWAT писал(а):  Трюк с записью вместо чтения тоже не прошел

жаль, а как пробовал ?
скопировал родной биос в RAM а затем после записи 5f74e4 читал его из рамы и писал в адреса от 0x100 до 0x1fffff ?

[SWAT]

(16.06.2014 15:02)MetalliC писал(а):  

(16.06.2014 14:16)SWAT писал(а):  Я просто изменил в KOS код прокачки, вместо чтения всего биоса, я читал в цикле только первые 4 байта. Результат ожидаемый, зависло на инициализации привода.

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

Я именно так и сделал, без инкремента читал просто всегда первое слово, но нужное количество раз.

(16.06.2014 15:02)MetalliC писал(а):  

(16.06.2014 14:16)SWAT писал(а):  Трюк с записью вместо чтения тоже не прошел

жаль, а как пробовал ?
скопировал родной биос в RAM а затем после записи 5f74e4 читал его из рамы и писал в адреса от 0x100 до 0x1fffff ?

Да, именно так. Без оптимизаций процессором этих данных, а так же из некэшируемой области. В общем учел все шероховатости, но это не помогло как не крути
Только писал я его с нулевого адреса, как он и проверяется в общем то в KOS, там все 2 МБ прокачиваются, я до сих пор не пойму откуда вообще этот оффсет взялся.
Из кода биоса понятно, что прокачивается он абсолютно весь:

PHP код:

    /* initialize ROM checksum */
    *HW32(0xa05f74e4) = 0x001fffff;

    /* switch to double precision (for 64bit copying below) */
    reg[FPSCR] = 0x00140001;

    src = (uint64_t *)0xa0000000;
    dst = (uint64_t *)0x8c000000;
    for (i = 0; i < 32; i++) {    /* skip the system variables */
        (void)*src++;        
        dst++;
    }
    for (i = 0; i < 2016; i++)     /* copy a0000100-a0004000 to 8c000100 */
        *dst++ = *src++;

    for (i = 0; i < 2048; i++) {
        (void)*(src++);
        dst++;
    }
    for (i = 0; i < 258048; i++)     /* copy a0008000-a0200000 to 8c008000 */
        *(dst++) = *(src++);

    /* back to single precision */
    reg[FPSCR] = 0x00040001; 


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

PHP код:

(void)*src++; 


Вот так выглядит прокачка в KOS:

PHP код:

uint32 p;
    volatile uint32 *react = (uint32*)0xa05f74e4,
                     *bios = (uint32*)0xa0000000;

    /* Reactivate drive: send the BIOS size and then read each
       word across the bus so the controller can verify it. */
    *react = 0x1fffff;

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


[cybdyn]

вроде не с нулевого. первые 0x100 это иниты всякие сис регов, и сам код прокачки.
но мож я и ошибаюсь. так как 0х100 может быть просто вектор после прокачки.
есть в нэте дисасм с коментами. оттуда эта инфа про сотню.

[SWAT]

(17.06.2014 11:25)cybdyn писал(а):  вроде не с нулевого. первые 0x100 это иниты всякие сис регов, и сам код прокачки.
но мож я и ошибаюсь. так как 0х100 может быть просто вектор после прокачки.
есть в нэте дисасм с коментами. оттуда эта инфа про сотню.

Я вот из этого дисасма и выдернул первый код. В котором видно что эта область хоть и не копируется, но прокачивается.
Первые 256 байт не копируются, потому что в биосе это инициализация железа (запись кучи регов), а в памяти это всякие параметры и вектора на системные вызовы. Все остальное содержимое биоса тупо зеркалируется в память, кроме данных 4000-8000, они опять же просто прокачиваются.
Вообще не важно в каком месте код прокачки, когда и откуда он запускается. Главное запустить его до обращения к G1 bus.

[MetalliC]

Цитата:Из кода биоса понятно, что прокачивается он абсолютно весь:

Цитата:Первые 256 байт просто не копируются в память, но они тоже прокачиваются через шину, об этом говорит вот эта строка:

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

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

[SWAT]

(17.06.2014 14:49)MetalliC писал(а):  

Цитата:Из кода биоса понятно, что прокачивается он абсолютно весь:

Цитата:Первые 256 байт просто не копируются в память, но они тоже прокачиваются через шину, об этом говорит вот эта строка:

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

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

Ок, а как тогда объяснить что это работает в KOS?
По твоей логике получается что биос проверяется не с того места, а значит и контрольная сумма не должна совпасть. Но этого не происходит!
А биос я дисасмил и сам, правда смотрел в большей степени на системные вызовы. И в общем то код совпадает с тем что выложен на том сайте. Конечно есть ошибки, но это ведь не полный и рабочий реверс, он больше теоретический, но по факту я не видел там особых отличий.

[SWAT]

В общем хочу тебя огорчить, я только что проверил, вот так это не работает:

PHP код:

uint32 p;
    volatile uint32 *react = (uint32*)0xa05f74e4,
                     *bios = (uint32*)0xa0000000;

    *react = 0x1fffff;

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


Работает только с полной прокачкой и никак иначе.

[MetalliC]

фиг его знает как оно работает вообще, и в KOS тоже
собсно выяснением того как оно работает вроде как и занимаемся

как работает bios:
http://pastebin.com/jQ67bCkE
в кратце -
- инитит пару регистров
- читает pref-ом в кеш 80000060
- прыгает в 80000080
то есть уже с включенным кешем
далее с 80000080 -
- инитит еще несколько регистров
- ждет пока регистр регенерации памяти не станет 0x10
- копирует процедурку прокачки в RAM
копирует не просто так, а складывая 16бит слова в обратном порядке
то есть:
читается 800000E0 пишется в 8c0000FE
читается 800000E2 пишется в 8c0000FC
читается 800000E4 пишется в 8c0000FA
и так далее до
читается 800000FE пишется в 8c0000E0
по концовке в RAM начиная с 8c0000E0 оказывается "процедура прокачки", уже в дескрембленном виде, куда и прыгает код

---

далее код самой процедурки прокачки
http://pastebin.com/DgxCTPun
на входе в нее
R0 = 80000100 - адрес откуда оно будет читать)
R3 = 8C000100 - адрес куда писать

вот так работает биос

[SWAT]

Вижу что прыгает, но не вижу причем тут оффсет 0x100. Покажи код самой прокачки пожалуйста.

[MetalliC]

(17.06.2014 15:13)SWAT писал(а):  В общем хочу тебя огорчить, я только что проверил, вот так это не работает:

Работает только с полной прокачкой и никак иначе.

почему огорчить, наоборот - кое-чего выяснилось

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

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

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

---

(17.06.2014 16:05)SWAT писал(а):  Вижу что прыгает, но не вижу причем тут оффсет 0x100. Покажи код самой прокачки пожалуйста.

внизу сообщения, вторая копипаста, то и есть код прокачки