VMU Hack

[SWAT]

Решил я найти уязвимости в других местах
Пролистал документацию на VMU и был приятно удивлен, этот девайс проработан не хуже консоли. Но суть темы не в этом конечно.
В общем у VMU есть свой ROM (помимо 128 Кб flash) размером 64 Кб, в котором находится следующее:

16384 байт: Основная программа (меню, часы и т.п.)
4096 байт: Системная программа (BIOS)
45056 байт: Пустое место

И главное в этом списке не пустое место Хотя оно конечно тоже кстати. BIOS, вот что меня интересует.
Дело в том, что у VMU есть 2 режима работы, standalone и dedicated.
В автономном режиме на ней можно выполнять некоторые программы, которые в том числе могут использовать некоторые сисколы из биоса. Но вот как только она подключена к DC или переключен режим кнопкой mode, то работать начинает bios.
В этом биосе есть код для работы с Maple Bus, т.е. этот биос складывает фрейм от maple в RAM (и кстати затирает все что там было, если пользовательская программа не убрала за собой) и в общем выполняет функции maple устройства, чтение/запись flash, часы и LCD экран.
Так вот если бы поменять этот биос на свой (а проверок я думаю там уж нет на его валидность), вероятно можно было бы это использовать для взлома и самого дрима. Как я пока конечно не знаю, но как минимум можно его заставить сделать ребут или вывалиться в ошибку, ну а дальше как пойдет.
Конечно не обязательно было бы для этого использовать VMU, можно просто сделать свой девайс, но прелесть здесь вся в том, что VMU есть у большинства владельцев DC, а кастомные устройства это уже куда сложнее.
А теперь главный вопрос - как прошить ROM VMU? Неужели опять только на программаторе? Неужели и здесь Sega решила остаться без обновлений? Ведь в доке написано явно, что bios служит для облегчения жизни разработчикам, так как в нем будут типа нужные функции. Но в данный момент там всего 3 сискола и куча свободного места в ROM. Неужели его обновляли бы только с выходом новых девайсов? Хотя это логично, если уж основной bios dc таким сделали...

[cybdyn]

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

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

вроде слышал есть какойто микрокод который можно в него грузить.

даже если доступ появиться... кто будет им пользоваться, я смотрю по ходу вообще глухо, никто ничего не програмит, не разрабатывает)))) (кроме всё Тех же Самых))) )

у меня идея гд эмуль, пощупать г2 шину , и интересно модифицировать sd мод, сделать его более шустрым.

[SWAT]

(05.08.2013 17:20)cybdyn писал(а):  если учесть что обычный биос тупо грузиться даже пусть с адреса 0х100 и до конца в память, то смысл его делать прошиваемым?, вставил диск и запустил новое меню,
ведь меню появляется если нет диска. (я понимаю про удобство флэш биоса) но разработчикам это незачем

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

(05.08.2013 17:20)cybdyn писал(а):  про VMU - ни держал в руках, ни разбирал. что там за желез не вкурсе. если только кто выложит фотки - хотя сеговцы как всегда всё зашифруют своими микрухами с кодом "315-xxxx" , и поди разбери что там )))

Там кастомный чип Sanyo LC868700, он обратно совместим по инструкциям с LC86000, ну и так еще по мелочи. Вообще это как маленькая консоль Там даже есть два serial интерфейса для подключения двух VMU друг к другу. Теоретически можно сделать даже мультиплеер
В общем всю инфу можно глянуть в офф доках, как всегда
http://www.megadrive.org/~elbarto/VMU.pdf

(05.08.2013 17:20)cybdyn писал(а):  вроде слышал есть какойто микрокод который можно в него грузить.

Ну там пользовательские приложения можно запускать, но они не имеют доступа в ROM как таковой, только к некоторым сисколам.
Они запускаются из основной flash памяти.

(05.08.2013 17:20)cybdyn писал(а):  даже если доступ появиться... кто будет им пользоваться, я смотрю по ходу вообще глухо, никто ничего не програмит, не разрабатывает)))) (кроме всё Тех же Самых))) )

у меня идея гд эмуль, пощупать г2 шину , и интересно модифицировать sd мод, сделать его более шустрым.

Если вдруг с помощью нее найдется лазейка для загрузки кода в дрим, то это фактически заменит bios mod самого дрима, что я думаю не мало важно и пользоваться этим будут все. А самое главное для этого не потребуется ничего ковырять и паять. Если конечно есть возможность прошить VMU без хардварного вмешательства.

[cybdyn]

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

вообщемто вопрос кто будет это исследовать... если бы теория работала я железо собрал бы.

у меня вот мысль улучшить sd мод поставив контроллер который будет всё делать на уровне файловой системы и работы с картой. а уровень обмена по сериалу упростить и ускорить, можно по двум фронтам как вариант. отдельно доработать звуковой канал - в контроллерах даже есть такой интерфейс (по типу PCM).

[SWAT]

Ну то что код можно отправить в DC это 100%, а вот с запуском нужно думать. Либо думать над тем, как этот код поместить в нужное место, после чего сгенерить исключение, которое спровоцирует soft reset, а вот уже во время этого сброса, запустился бы код. Так что есть как минимум два пути, либо научиться запускать, либо научиться размещать в нужное место.
В том то и дело, что хотелось бы обойтись тем что уже у всех есть, а не лепить новую железку.
Если уж железо делать, то больше вероятности найти дырку через G2 Bus, так как туда подключается девайс для отладки. Да и без него можно перехватить данные от AICA, я по крайне мере больше всего надежд возлагаю именно на нее, тут есть где развернуться. Я уверен на 99% что можно заменить код программы для ARM при его загрузке через шину, данные там никак не защищены. А уже дальше нужно найти уязвимость в драйвере что на стороне SH4 находится.
Не исключено конечно что никаких дыр ни в maple ни в g2 нету Но попытаться стоит же

[alex]

Для начала неплохо бы научиться дампить биос VMU, а то вменяемой инфы на эту тему в нэте нету

[SWAT]

Биосы есть в KATANA SDK, да и не дампить старый надо, а прошить новый. Дампить там нечего особо, все что там есть, можно смело выкинуть и написать свое. Или как вариант хакнуть стандартный, поставив где-то джамп в другое место, а свой код разместить рядом, благо свободного места там достаточно, его явно делали с запасом, а значит планировали же как то его обновлять. Иначе как то нецелесообразно использовать столько памяти впустую.
Хотя возможно что изначально планировали там больше функционала, но потом выпустили то, что было на тот момент...
Я видел что пишут спец код (для самой VMU, как игры) для дампа биоса, сам код не видел к сожалению (и не смог найти), но значит там есть доступ к биосу на чтение как минимум. Да и я вроде видел в доке, что можно переключать банк памяти, но думал что при этом происходит выход из игры, но видимо нет.
В биосе есть сисколы для чтения/записи/проверки памяти, видимо при переключении банка можно то же самое делать и с памятью биоса, по крайне мере читать. Но биос сам себя переписать не сможет, нужно реализовать эти сисколы в другом месте, тут уже реверс нужен... Но что-то сдается мне здесь не все так просто, этим бы уже кто-то воспользовался мне кажется.

[SI{AY]

Так вот вроде софт позволяет писать в любую область памяти, через LPT правда. http://web.archive.org/web/2010042504181...m/vmu.html

Цитата:I'll use the unrestricted writeFlash (called writeFlashOS), which allows writes to any area in FLASH memory (including the game file, the FAT, the directory, and other files), as an example. It's probably the only function here of use to a VMU developer.

http://web.archive.org/web/2010092803223.../bios.html (если я правильно понял)
увы, сам сайт не работает, и судя по вебархиву уже давно. Но все файлы есть в вебархиве

[MetalliC]

(13.08.2013 15:25)SWAT писал(а):  Биосы есть в KATANA SDK, да и не дампить старый надо, а прошить новый.

боюсь что прошить не выйдет - в доке везде пишется что биос Mask-ROM, а масочные ПЗУ не перезаписываются по определению.

2alex по-человечески сдампить его нельзя, только извраты с троянами где-то вот такие http://dknute.livejournal.com/18959.html

[SWAT]

SI{AY речь там о flash памяти, где сейвы лежат, а не о биосе.
А вот про то что напомнил про этот сайт спасибо, я про него совсем забыл.
Там есть немного информации о недокументированных регистрах, которыми манипулирует биос. Интересно можно ли ими пользоваться в режиме игры. Вот здесь описание: http://web.archive.org/web/2010042618114...otato.html
Регистры находящиеся в 0x160-0x162 то что нужно для хака дрима.
А здесь написано про дамп биоса - http://web.archive.org/web/2010092803223.../bios.html

Цитата:The BIOS isn't directly readable by a VMU program, but if you are crafty, you can use Marcus's program to read a copy from your ROM. Also, you if you have the official VMU developer's kit, you can easily translate the provided ".SBF" BIOS files into binary image files (".BIN") by simply dropping the first 4 bytes and xor'ing the rest of the bytes with the one byte key. It's too simple to be considered encrypted - the key and the algorithm are easily guessed by knowing that most unused EPROM data is $FF.

Никто не находил код этой программы от Маркуса для дампа? Кнут вроде описал процесс, но готового кода так и не выложил. Да и сдается мне он об этом узнал от Маркуса (возможно из того же кода).

[SI{AY]

http://gamesource.groups.yahoo.com/group...r=1&tidx=1
есть небольшое подозрение, что "игра" для карточки делающая дамп биоса находится в файлах этой группы. Но в нее никак попасть не получилось у меня. вроде сделал акк, сделал профиль, а при попытке вступить - предлагает опять сделать профиль %) я в ступоре. может кому повезет больше. но карточки подходят похоже только японские.
Некст - уже не обязательно, так как с Вашего адаптера можно потом на флэшку вытащить дамп будет.
но вот кода нигде нету

[SWAT]

Да где то там может и есть, в аттачи зайти можно только авторизованным.
Карточки не только японские подходят, просто под японские написан код, там что-то поменять нужно на сколько я понял.

[SI{AY]

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

Цитата:Members Only:
Post
Files
Photos
Links
Members
Calendar

мне кажется что там может быть.
Да, смогли добиться ток для яп подходящего значения. А крмое Маркуса и Джима (maushammer) похоже больше никто особо не копал.

[MetalliC]

дурной вопрос: а что и как вы собрались хакать через maple ?
данные от устройства DMA читает только по запросу от дрима, по указанному после команды адресу, и не более килобайта.
надеяться на ошибку в парсере ответа если подсунуть бредовые данные я бы не стал в случае дрима, тут один запрос - один ответ и структура ответа статична.
в случае наоми да, там пакет ответа прилетает на кучку комманд и шаблон ответа плавающий, и в их разбиралке есть недочеты, но толку тоже мало - в лучшем случае код циклится, в худшем - улетает куда-попало и/или выпадает по ексепшену.

[SWAT]

Данные там летают по DMA - 16 Кб буфер для всех maple устройств одним разом. Причем они летают постоянно, если сама шина инициализированна, а не по запросу CPU. Сам CPU уже просто смотрит этот буфер на наличие изменений. Т.е. фактически VMU может послать что угодно в память дрима, а сам дрим уже только потом сделает вывод что это хрень какая то.
К примеру при старте дрима, биос сканирует VMU на наличие допустим текстуры для бэкграунда в меню, возможно еще для чего-то. Если текстура загружается, значит она лежит где-то в RAM, прежде чем улетит в VRAM. Из за ограниченной памяти VMU, текстура там может быть размером максимум 256х256, а если VMU будет хакнута, можно отправить файл любого размера (по крайне мере сэмулировать этот процесс), проверок там на размер скорее всего нет, так как даже в стандартном меню биоса для управления VMU, если у нее задействованы экстра блоки, будут глюки в графическом представлении.
Ну это так, на тему как отправить больше данных, это в общем не проблема. На самом деле хватит и 512 байт для взлома, там надо то несколько строчек на ASM запустить. Самая главная проблема - как разместить эти данные в нужном месте или запустить их там, где они лежат.

[MetalliC]

(15.08.2013 07:51)SWAT писал(а):  Данные там летают по DMA - 16 Кб буфер для всех maple устройств одним разом. Причем они летают постоянно, если сама шина инициализированна, а не по запросу CPU. Сам CPU уже просто смотрит этот буфер на наличие изменений.

0_o вообще-то по запросу процессора, само там ничего не летает.
Maple этож простенький командный процессор + дма.
работает оно так: процессор составляет список комманд и данных, пишет указатель на них в SB_MDSTAR и стартует ДМА (еще есть режим авто-старта по vblank, но он используется только в WinCE)

формат передаваемых данных такой - 4 байта самой команды, в которой указывается номер порта, и объем передаваемых в него данных, затем 4байта указатель на буфер куда писать ответ от устройства (в смысле у каждой команды свой буферок), затем передаваемые в устройство данные (минимум 4байта), и так несколько раз, в последней команде взводится битик, чтоб мапле понимал что она последняя и дальше выполнять/передавать не нужно.
команды выполняются последовательно, т.е. считывается команда, отправляются данные в устройство, затем ДМА ждёт данные, если они приходят - пишет их начиная с адреса указанного в указателе после команды но не более 1Кб, если данные в течение таймаута не пришли - пишет туда FFFFFFFF.

теоретически в обработчике ответа могут быть глюки/дырки, но имхо это маловероятно.

[SWAT]

При инициализации шины, сначала выделяется общий для всех устройств буфер (16 кб), потом инициализируется maple dma, устанавливаются хэндлеры на прерывание maple dma и производится запуск шины. После этого шина работает сама по себе, когда срабатывает прерывание (пришли данные), CPU только парсит (делит на как ты выразился "буферки" ) и дергает коллбэки. DMA не работает отдельно для каждого устройства, все фреймы для всех устройств, пересылаются одним буфером разом, как в сторону шины, так и обратно! А "в последней команде взводится битик" - это метка для шины, чтобы она дальше не парсила все присланные 16 кб, если это не требуется.
Есть еще хэндлер на vblank, на нем висит мониторинг на случай появления новых устройств или удаления старых, а так же здесь происходит проверка данных нуждающихся для отправки и если таковые имеются, то инициируется передача по DMA.
Если уж совсем придраться к словам, то да, ты прав, отправку инициирует CPU как не крути. Но отправка нас не интересует в этой теме вообще, а вот прием данных происходит автоматически по прерыванию со стороны шины. И это главное, ибо это означает что можно отправить данные в заведомо определенный участок RAM (его можно узнать) без каких либо проблем.
А вот дальше уже начинаются проблемы Здесь нужна удача и много тестов. Есть шанс что при переполнении какого то буфера (к примеру той же текстуры), он залезет на ссылку до функции (такое легко может быть, если они в одной структуре), в которой получится подменить адрес на функцию в нашем фрейме и вуаля, мы вызовем свой код.

[alex]

Deunan (автор макарона) вроде тоже пытался задампить биос с европейских и американских VMU
http://dknute.livejournal.com/19465.html

[MetalliC]

(15.08.2013 14:04)SWAT писал(а):  После этого шина работает сама по себе, когда срабатывает прерывание (пришли данные), CPU только парсит (делит на как ты выразился "буферки" ) и дергает коллбэки. DMA не работает отдельно для каждого устройства, все фреймы для всех устройств, пересылаются одним буфером разом, как в сторону шины, так и обратно!

ты в корне ошибаешься, работает оно так как я выше описал (а я на maple "немножко" собаку съел ), не веришь - почитай доки, благо по мапле их более чем дофига.

alex ага, только европейские VMU он так и ниасилил - не смог методом тыка вычислить где в биосе есть последовательность типа "читаем в аккумулятор байт/слово из адреса указанного в регистре и потом RET", а без такой процедурки биос увы не считаешь.

хех, мне всё это напомнило спектрум и его TR-DOS лет 20 назад , там точно таким же образом извращались для прямого доступа к регистрам чипа контролера FDD

[SWAT]

MetalliC, возможно мы оба правы, ты описываешь одну реализацию, а я другую, или ты путаешь хардварную с софтварной. Я приводил пример на основе KOS. Я и не думал что кому-то в голову придет дергать DMA для 1 Кб, это грубая ошибка, в которую я до сих пор не могу поверить, так как все дримовские DMA работают оптимальней с пакетом из 16 Кб данных как не странно. И эта особенность используется там повсеместно.
Я читал все доступные доки, смотрел код, схемы шины и говорили о ней немного в другой теме, и в этом сообщении я более развернуто описал процесс обмена по DMA, я даже немного ошибся здесь пока писал, там правильней написано.
И чтобы не быть голословным, привожу выдержку из кода:

PHP код:

/** \brief  Maple DMA buffer size.

    Increase if you do a _LOT_ of maple stuff on every periodic interrupt.
*/
#define MAPLE_DMA_SIZE 16384

/* Global state info */
maple_state_t   maple_state;

//...

/* Allocate the DMA send buffer */
maple_state.dma_buffer = memalign(32, MAPLE_DMA_SIZE);

//...

/* Send all queued frames */
void maple_queue_flush() {
    int     cnt, amt;
    uint32      *out, *last;
    maple_frame_t   *i;

    cnt = amt = 0;
    out = (uint32 *)maple_state.dma_buffer;
    last = NULL;

    /* Go through and process each frame... */
    TAILQ_FOREACH(i, &maple_state.frame_queue, frameq) {
        /* Are we running out of space? */
        if((i->length * 4 + amt) > MAPLE_DMA_SIZE)
            break;

        /* Is this frame stale? */
        if(i->state != MAPLE_FRAME_UNSENT)
            continue;

        i->state = MAPLE_FRAME_SENT;

        /* Save the last descriptor head for the "last" flag */
        last = out;

        /* First word: message length and destination port */
        *out++ = i->length | (i->dst_port << 16);

        /* Second word: receive buffer physical address */
        *out++ = ((uint32)i->recv_buf) & 0x1fffffff;

        /* Third word: command, addressing, packet length */
        *out++ = (i->cmd & 0xff) | (maple_addr(i->dst_port, i->dst_unit) << 8)
                 | ((i->dst_port << 6) << 16)
                 | ((i->length & 0xff) << 24);

        /* Finally, parameter words, if any */
        if(i->length > 0) {
            assert(i->send_buf != NULL);
            memcpy(out, i->send_buf, i->length * 4);
            out += i->length;
        }

        cnt++;
        amt += i->length * 4;
    }

    /* Did we actually do anything...? */
    if(cnt > 0) {
        /* Tack on the "last" bit to the last one */
        assert(last != NULL);
        *last |= 0x80000000;

        /* Start a DMA transfer */
        maple_dma_addr(maple_state.dma_buffer);
        maple_dma_start();
        maple_state.dma_in_progress = 1;
    }
} 


Кстати с какой целью ел корейскую кухню изучал Maple и по каким исходникам/докам?