Деконструкция сбоев покемонов?

(Прошу прощения, если это не то место, чтобы задать этот вопрос. Я думаю, что это определенно связано с программированием, хотя если это принадлежит другому сайту, пожалуйста, дайте мне знать)

Я вырос, играя в Pokémon Red and Blue, игры, которые были очень увлекательными, но несколько печально известны наличием множества уязвимых мест (например, см. этот нелепый спидран из игра , которая использует повреждение памяти, чтобы превратить экран элемента в шестнадцатеричный редактор).

Недавно я обнаружил интересную скорость прохождения игры, в которой используется сбой, называемый «сбой ZZAZZ», чтобы повредить важные области памяти и разрешить игрок почти сразу же выиграет игру. Согласно авторскому описанию спидрана , сбой ZZAZZ работает следующим образом:

Чтобы начать битву тренеров, игре необходимо загрузить много данных, таких как [...] деньги он уступит, если проиграет. Когда он загружает деньги, все может стать действительно уродливым. По причинам, не зависящим от меня, деньги хранятся совершенно по-другому, в игре используется структура данных из трех байтов, и вместо преобразования значения в двоичное, она хранит ее в «человеческом» представлении. Например, $ 123456 будет сохранено как 0x123456 вместо 0x01E240, правильное преобразование.

[Некоторые недопустимые записи в таблице трейнера] указывают на местоположение с недопустимыми данными о деньгах. Когда игра пытается выполнить арифметические действия с этими данными в указанной структуре, она сходит с ума и начинает перезаписывать огромные части ОЗУ. В частности, для каждого блока из трех байтов два из них будут содержать 0x9999 (максимальная сумма денег, которую может дать тренер). Этот шаблон многократно повторяется через ОЗУ. Чтобы лучше понять это, я рекомендую приостановить видео на эмуляторе после того, как столкнется с тренером ZZAZZ, и установите для средства просмотра памяти VBA значение 0xD070.

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

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

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