BIOS protection by Holly

[megavolt85]

Цитата:11 11 11 11
11 10 11 12
11 10 12 11

00 00 00 00 00 00 00 00
00 00 00 01 00 00 FF FF
00 00 00 01 80 00 00 00

11 11 11 11 22 22 22 22 33 33 33 33 44 44 44 44
11 11 11 10 22 22 22 22 33 33 34 33 44 44 43 45

вывод: блоки 32-х битные

[MetalliC]

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

попробуй такое:
00 00 00 00 00 00 00 00
00 00 00 FF 00 00 00 FF
или
00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01 00 00 00 FE 00 00 00 FF
или что-то еще в таком репертуаре

[megavolt85]

Цитата:00 00 00 00 00 00 00 00
00 00 00 FF 00 00 00 FF

00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01 00 00 00 FE 00 00 00 FF

[MetalliC]

спасиб
мда, значит там не банальный xor ))

[megavolt85]

мда, явно не xor, а как похоже было

видимо операции подсчёта на уровне +- ,но регистр unsigned int

Цитата:offset 0x204 .................... offset 0x320
11 11 11 11 ..................... 00 00 00 00
11 11 11 10 ..................... 00 00 00 01

[alex]

(24.06.2016 19:30)SWAT писал(а):  Мне кажется тут все в итоге окажется банально просто, он не проверял толком homebrew
Что мы вообще гадаем, может кто-то себе прошить его да проверить? У меня просто привода нету на дриме щас.

Вот его видео с запуском хомбрю, правда это прошлая версия его биоса.

Запуск хомбрю смотрим с 0:55 секунды.

[SWAT]

А прошлая версия использовала этот 1кб кусок?
Наверное он для тестов использовал только его, а для релиза уже подобрал вручную сумму всего биоса.

[MetalliC]

(26.06.2016 03:20)megavolt85 писал(а):  видимо операции подсчёта на уровне +- ,но регистр unsigned int

Цитата:offset 0x204 .................... offset 0x320
11 11 11 11 ..................... 00 00 00 00
11 11 11 10 ..................... 00 00 00 01

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

но вот такое:
11 11 11 11 22 22 22 22 33 33 33 33
11 11 11 10 22 22 22 22 33 33 33 34
11->10 - сброшен бит 0
33->34 - сброшены биты 0 и 1, установлен бит 2
ожидаемо уже не прокатывает

а проходит лишь что-то вроде
11 11 11 10 22 22 22 22 33 33 34 33 44 44 43 45
10 и 45 - обменяли бит 0, в 11 сбросили в 44 взвели
34 и 43 - обменяли биты 0 - 2

[MetalliC]

еще результаты тестов:
в одном из предыдущих я пробовал менять конечный адрес на 3fe и 3fd и получал негативный результат, но похоже сам адрес на сумму таки не влияет

в сегодняшних тестах я ставил его на long с нулями, и читал последним после вычитки всего блока - сумма бьется, в том числе с любым значением 2х младших бит регистра конечного адреса типа 40f 40e 40d, проверка проходит ОК
так что циклических сдвигов текущей суммы после вычитки и суммирования байт там нет

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

но в общем и в целом всё выглядит будто оно действительно суммирует 32бит словами, думается в процессе вычитки сохраняет в регистрах/триггерах считанные с рома байты, и затем при вычитке 4го суммирует как одно целое.
а так же при достижении конечного адреса, что может объяснить некоторые непонятки с ним, типа почему не прокатило с 3fe и 3fd - не были считаны во внутренний регистр последние нули, и там остались ненулевые байты с предыдущего 32бит слова - сумма обломалась.

[megavolt85]

надо будет попробовать биосы с загрузчиком DS переделать, чтоб проходили проверку на весь размер

[MetalliC]

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

[megavolt85]

Занимательная математика

Код:

#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <ctype.h>

int main( int argc, char *argv[] )
{
    FILE *fp;
    int i,n=0,size;
    char *buf = malloc(2*1024*1024);
    uint64_t crc, tmp, tmp2, tmp3, sum=0, sum2=0;
    
    fp = fopen(argv[1],"rb");
    
    if(!fp)
    {
        printf("can't open %s\n",argv[1]);
        return 0;
    }
    
    fseek(fp, 0, SEEK_END);
    size = ftell(fp);
    fseek(fp, 0, SEEK_SET);
    
    fread(buf,size,1,fp);
    
    fclose(fp);
    
    for(i=0;i<size;i+=8)
    {
        memcpy(&tmp, &buf[i],4);
        memcpy(&tmp2, &buf[i+4],4);
        
        tmp3 = tmp-tmp2;
        
        if(crc + tmp3 >= 0xffffffff)
        {
            crc = ((crc + tmp3) >> 32);
            n++;
        }
        else
            crc += tmp3;
        
        if(sum + tmp >= 0xffffffff)
        {
            sum = ((sum + tmp) >> 32);
        }
        else
            sum += tmp;
        
        if(sum2 + tmp2 >= 0xffffffff)
        {
            sum2 = ((sum2 + tmp2) >> 32);
        }
        else
            sum2 += tmp2;
    }
    
    printf("KS =  %08X\n",(uint32_t)(crc&0xffffffff));
    printf("N = %d\t%08X\n",n,n);
    printf("SUM1 = %08X\n",(uint32_t)sum);
    printf("SUM2 = %08X\n",(uint32_t)sum2);
    
    return 0;
}

Код:

megavolt@megavolt-GA-790XTA-UD4:~/dreamcast/crc$ ./test 1_01d_01.bios
KS =  A49ED5DB
N = 88922    00015B5A
SUM1 = 796E35CD
SUM2 = 79694A7E
megavolt@megavolt-GA-790XTA-UD4:~/dreamcast/crc$ ./test 1_01d_02.bios
KS =  A49ED5DB
N = 88956    00015B7C
SUM1 = 796E35CD
SUM2 = 79694A7E
megavolt@megavolt-GA-790XTA-UD4:~/dreamcast/crc$ ./test 1_011_01.bios
KS =  71E0CBF9
N = 89624    00015E18
SUM1 = 185C35CD
SUM2 = 4B155460
megavolt@megavolt-GA-790XTA-UD4:~/dreamcast/crc$ ./test Link83_bios_1.0.bios
KS =  71E0CBF9
N = 89599    00015DFF
SUM1 = 185C35CD
SUM2 = 4B155460

[MetalliC]

занимательная, но она предполагает что биты байтов используются в обычном виде, хотя на самом деле могут быть перемешаны хрен знает как.
если предположить что тут используется обычное сложение, я бы попытался определить "вес" битов.
допустим берем и где-то взводим два бита, типа
00000000 00000000 => 00000001 00000001
и затем методом тыка сбрасываем где-то по соседству по очереди каждый из 32бит
идеальный случай если рядом есть FFFFFFFF - последовательно пробуем FFFFFFFD FFFFFFFB FFFFFFF7 FFFFFFEF и так далее
таким образом можно найти бит равный по весу двум битам номер 0, если таковой вообще существует в этом алгоритме )

[megavolt85]

как ни странно, но фокус с прибавлением и отниманием не работает на обычном биосе, только на килобайтном

[MetalliC]

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

честно говоря, я не очень понимаю чего ты уперся в арифметические операции - сложения-вычитания, они крайне крайне редко используются в таких вещах.
бинарные операции типа XOR/OR/AND, сдвиги, перестановка (пермутация) битов --- "наше всё" в электронике. глянь к примеру алгоритм CRC - там нет ни сложений ни вычитаний, потому что относительно сложнее реализуются на логических элементах, т.е. в чипах.
скорее всего и тут тот же случай.

так что и с этой перестановкой бит, которая тут работает а там нет, может быть имеется нечто в духе (все цифры от фонаря):
current_sum ^= (current_sum & 0x0248000) << 7;
и лишь пока в сумме не взведены биты 0248000 мы можем развлекаться и менять битики, впихивать в поток нули, и т.п.

[megavolt85]

думаешь всё же используется циклический сдвиг?

[MetalliC]

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

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

[megavolt85]

(21.06.2016 00:03)MetalliC писал(а):  нельзя, если оно оказалось в состоянии номер 2 - всё, выйти с него можно только по сбросу. это мы еще пару лет назад выяснили, как и вобщем-то само наличие трех состояний и как они переключаются или не переключаются.
ну а то что я вчера нашел этот регистрик - финальный пруф

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

Код:

r a05f74ec 1
Read REG: address = a05f74ec size = 1
REG A05F74EC = 0x00000003
w a05f74e4 4 001fffff
Write REG: address = a05f74e4 size = 4 value = 1fffff
return 1
r a05f74ec 1
Read REG: address = a05f74ec size = 1
REG A05F74EC = 0x00000000
r a01fffff 1
Read REG: address = a01fffff size = 1
REG A01FFFFF = 0x00000000
r a05f74ec 1
Read REG: address = a05f74ec size = 1
REG A05F74EC = 0x00000002
w a05f74e4 4 001fffff
Write REG: address = a05f74e4 size = 4 value = 1fffff
return 1
r a05f74ec 1
Read REG: address = a05f74ec size = 1
REG A05F74EC = 0x00000000

[cybdyn]

может там эти биты которые изменяют число, учитывают знак паритета?!?))

[MetalliC]

(26.09.2016 06:50)megavolt85 писал(а):  как ни странно ,но из состояния 2 в 0 дрим выходит.

на наоми тоже так, но в этом случае после чтения блока с правильной суммой он опять становится 2 а не 3.

(26.09.2016 06:50)megavolt85 писал(а):  кстати в a05f74e4 мы пишем не количество байт которые нужно прочитать, а адрес при чтении которого остановится проверка

верно, это давно было известо да и по самим записываемым значениям видно