
Восстановление мертвого USB-протокола: секреты портативного устройства, раскрытые горячим ножом, междисциплинарное путешествие по возрождению забытого USB-интерфейса
В 2024 году bjiru загрузил видео о ручном устройстве ME2 — игрушке, выпущенной около 2008 года, которая позволяла использовать USB для синхронизации очков и самоцветов между устройством и онлайн-миром. Игра была крайне нишевой, поэтому никакого программного обеспечения, драйверов или ресурсов не сохранилось, по крайней мере, пока bjiru не объявился с клиентом онлайн-игры.
Я — лидер Miuchiz Reborn, проекта, начатого в 2015 году с целью сохранения, обратной разработки, эмуляции и поддержки доступности игры, похожей на эту, с онлайн-частью и ручным устройством, соединённым через USB. Из-за схожего возраста и типа игры ME2 уже привлёк моё внимание сообществом Miuchiz в 2018 году, так как они (ошибочно) считали, что эти устройства могут иметь схожую архитектуру. Несмотря на то что я знал о существовании устройства годами, видео bjiru наконец подтолкнуло меня к началу исследования.
Мои первые усилия были сосредоточены исключительно на воссоздании сервера, необходимого для восстановления работоспособности копии компьютерной игры bjiru, но по ходу дела моё внимание неизбежно переключилось на ручное устройство. Воссоздание онлайн-игры, безусловно, не могло быть полным без механизма синхронизации очков с устройством и обратно. Ведь эта связь между компьютером и устройством ME2 была главной «фишкой» игры. Я решил, что мой предыдущий опыт работы с ручными устройствами Miuchiz поможет мне быстро разобраться в их протоколе связи... при условии, что я смогу достать какой-нибудь код для обратной разработки.
Любопытство требовало жертвоприношения ME2. eBay требовал жертвоприношения фиатных денег. Вскоре передо мной лежали эти экземпляры.

Это маленькие блоки всего с несколькими кнопками и разъёмом mini-USB type female. В комплекте есть кабель, но нет диска с ПО и драйверами. Этот USB-порт должен был использоваться для синхронизации очков между компьютером и ручным устройством, но когда я проделывал тот же путь для ручного устройства Miuchiz, я получил полный доступ к его флеш-памяти, обратно разработав работу сопутствующего ПО для Windows. Поскольку для ME2 такого ПО не существует, нечего и обратно разрабатывать, чтобы понять, как общаться с устройством. Даже после проверки Wayback Machine и bjiru, по-видимому, не сохранилось ни одной копии того ПО, которое использовалось для связи с этими штуками. Кажется, оно называлось ME2 Desktop Buddy, но это приложение было отдельным от игрового клиента, который восстановил bjiru. Ручное устройство представляется как съёмный носитель, но его содержимое просто направляет вас в интернет для загрузки игры ME2, которая уже недоступна.
Путь вперёд ясен, поскольку остаётся только один вариант: вскрыть аппаратуру.

Основная прошивка ME2 хранится на SST39VF3201 — флеш-чипе ёмкостью 2 мегаслова (4 мегабайта, 16-битные адресуемые единицы). Главный микроконтроллер... находится под твёрдой эпоксидной каплей. Это называется «чип на плате» (CoB) и обычно является мерой экономии, но побочным эффектом является сокрытие любой идентифицирующей информации об интегральной схеме внутри. Обычный чип в корпусе обычно имеет маркировку, идентифицирующую его, как у флеш-чипа. Поскольку микроконтроллеры, используемые в таких устройствах, часто содержат внутреннюю ПЗУ, возможно, что часть или весь USB-код, который я хотел обратно разработать, находился в этой ПЗУ. Наличие кода в ПЗУ даёт преимущество восстановления «кирпичного» устройства или, если производитель решит так сделать, прошивки устройства после сборки. Эта ПЗУ существовала бы внутри чипа, который я никак не мог идентифицировать.
Извлечение данных из флеш-чипа — это простой и хорошо документированный процесс: выпаять чип, поместить в стандартный программатор флеш-памяти, например от XGecu, и использовать его для дампа содержимого. Если мне также нужна информация из ПЗУ микроконтроллера, это менее прямолинейно, но всё же выполнимо для такого устройства, где защита маловероятна. В прошлом я добавлял код в SPI-флеш на Tamagotchi Pix, который копировал его загрузочную ПЗУ в свободное место на флеш-чипе, а затем эту ПЗУ можно было прочитать тем же программатором, который я использовал для внедрения кода. Однако в том случае микроконтроллер был в обычном корпусе и имел маркировку с информацией о модели, так что я мог найти его даташит, чтобы узнать систему команд и расположение ПЗУ в адресном пространстве. На тот момент у меня не было никакой этой информации о загадочном чипе на плате ME2.
Несмотря на неопределённость, единственный очевидный путь отсюда — выпаять флеш-чип. Я также купил несколько панелек для флеш-чипа в надежде припаять одну из них к плате ручного устройства. Это позволило бы мне перепрограммировать ME2 и быстро итерировать, если бы мне понадобилось написать код для дампа внутренней ПЗУ микроконтроллера.
К сожалению, мне не удалось снять флеш-чип паяльником, не повредив его. Чтобы решить эту проблему после нескольких неудачных попыток, я приобрёл паяльную станцию (по сути, тепловой пистолет, который якобы может достигать 500 °C) и удалил чип, расплавив припой горячим воздухом. Это позволило мне без проблем снять дамп флеш-памяти, но стало ясно, что фактическое использование купленных панелек будет выше моих возможностей. Мне пришлось бы не только припаять все 48 крошечных выводов к плате, но и сделать это достаточно быстро, чтобы не расплавить пластик панелек. У меня не было ни инструментов, ни навыков для этого, поэтому, если бы мне понадобилась ПЗУ, пришлось бы придумать другую стратегию.
Однако дамп выглядел хорошо, и с помощью инструмента, который я уже создал специально для поиска несжатых растровых изображений в дампах прошивок, я смог найти изображения, которые обычно отображаются на устройстве:

Я получил дамп прошивки из флеш-чипа, но прежде чем можно будет приступить к серьёзной обратной разработке, мне хотя бы нужно знать, какую систему команд использует устройство. На самом оборудовании не было маркировки, поэтому пришлось гадать. Я попробовал проанализировать код в Ghidra — дизассемблере, декомпиляторе и кривом кошмаре с открытым исходным кодом, который меня кормит — с почти каждым типом процессорной спецификации, который в нём был. Какая-нибудь разновидность ARM? Потомок 6502? MIPS? Буквально что-нибудь ещё, поддерживаемое Ghidra? Всё — решительное «нет».
Я перепробовал всё, и ничто не могло дизассемблировать этот код. Я знал, что это код, потому что мог найти даже части того кода, который искал!
