Предыстория: в ремонт пришла приставка CUH-1003A, с симптомом – не включается. Диагностика показала отсутствие поступления напряжений ядра и графики на APU приставки. После снятия дампа и анализа с помощью BwE NOR Validator стало понятно, что с дампом не все так здорово и придется испытывать судьбу по ее восстановлению. Ситуацию осложняло то, что версия прошивки приставки была 1.62, в то время как уже повсеместно была доступна 9.03.

Анализ исходной ситуации.
В исходном состоянии было 2 критические ошибки (Danger), 8 предупреждений (Warning) и 1 несовпадение контрольной суммы в блоке с файловой системой с неопределенным содержимым (Unlisted). Что же проблема со стартом налицо, будем пробовать восстанавливать. Для перехода к дальнейшим шагам вам потребуется дамп такой же версии, но с рабочей приставки. Если дампа той же версии нет, то шансы резко падают, хоть и остаются ненулевыми.
В моем случае ситуацию осложняло то, что найти редкий и древний дамп версии 1.62 мне так и не удалось. Единственное, что было найдено более-менее близким, была версия 1.61Е. На основе работы с этими двумя дампами и будет строиться данный гайд.
NB! Следует запомнить, что наличие несколько Warning без непосредственно ошибок, вполне себе допустимо и не влияет на работоспособность консоли. Большинство проанализированных мной дампов прошивок имели по 2-3 предупреждения и прекрасно работали.

Перед разбором дампа, следует снять дамп несколько раз и проверить на различие по MD5, если различия есть, нужно снять так, чтобы различий не было (проверить контакты и прочее)

Понимание того, как устроена прошивка

Прежде чем идти дальше, рекомендую ознакомиться с главным источником информации о том, как устроено содержимое прошивки. Для этого лучше всего подойдет англоязычный ресурс www.psdevwiki.com и статься на нем Flash-Main (https://www.psdevwiki.com/ps4/Flash-Main). Для тех, кому не нужны подробности я опишу основные виды блоков в прошивке (согласно BwE NOR Validator):
- Static Section. Статическое содержимое, повторяющееся на всех консолях и их прошивках
- Dynamic Section. Изменяемое содержимое, в зависимости от версии прошивки, но не привязанное к конкретному экземпляру консоли
- Dynamic Section (Per console). Изменяемое содержимое, в зависимости от версии прошивки, и привязанное к конкретному экземпляру консоли. Иногда может повторяться в разных консолях, но с вероятностью 1 к 100, а то и меньше. Одна из самых паршивых ситуаций, если у вашей прошивки поврежден именно этот блок.
- SKU Ident. Идентификатор серии консоли (например, CUH-1xxx).
- Filler. Просто серия повторяющихся байтов, служащая заполнителем текущего блока до начала следующего. Как правило забито 0xFF.
- Прочие… их мы особо не рассматриваем, поскольку интерес они представляют в меньшей степени.

Также обратите внимание, что перед типом блока указывается его класс:
- SCE (SONY Computer Entertainment)
- SLB (область загрузчика)
- CID (область Сonsole ID, специфичная для каждой приставки и крайне критическая, тут же находится микрокод для различных устройств, того же BT или WiFi)
- UNK (область пока неизвестного назначения)
- VTRM (Virtual Table Rights Management). Этот блок отвечает за работу с защищенным контентом и за шифрование. Содержит счетчик активаций консоли. Тоже крайне критическая область.
- CoreOS (ядро системы). Уязвимая часть, содержит в себе уникальные для определённой версии прошивки блоки, поддается восстановлению, в т.ч. автоматическому через программу BwE NOR Validator.

Как несложно догадаться из описания выше, статические блоки, просто динамические а так же уникальные для конкретной версии прошивки можно брать с прошивок-образцов практически безболезненно. Филлеры можно просто самому заполнить значением 0xFF, а вот все, что связано с уникальными блоками на уровне экземпляра консоли, блока прав и шифрования вызовет у вас легкий зуд в районе пятой точки.

Первым в логе валидатора нам попадается блок со статусом [Unlisted]. Конкретно не сходится контрольная сумма по MD5 файла C0018001.bin:
C0010001.bin MD5: 6FCA0436441A1BCBFF497DC306EE8ADD [UNLISTED]

Поскольку он пока не сильно информативен и не понятна степень влияния на запуск, решено было пропустить данный блок и заняться остальными.
Следующим на пути у нас появляется рассадник, состоящий из критической ошибки и тройки предупреждений.

Повреждены блоки SKU Ident, CID Dynamic Filler, CID Filler, а также CID Dynamic Section. Самое время открыть Hex-редактор и приступить к сравнению обоих дампов. Используем для этого режим Tools – File Comparison – Compare Files…, после чего выбираем оригинальный битый дамп с приставки и дамп-образец. Дальше ставим синхронизацию окон и вертикальное разбиение:


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

Копируем из лога первый сбойный фрагмент: (B9290007FF070007FF0700030C040000000450DE) и ищем его в нашем битом дампе:

Поиск привел нас к первому сбойному блоку, а HEX-редактор сразу подсвечивает разницу в содержимом дампов, делая процесс наглядным:

Тут же откроем лог обоих дампов чтобы понимать, какое содержимое должно было быть на месте ошибок и предупреждений (слева наш многострадальный дамп, справа – образец).

1. Обращаем внимание на то, что в нашем битом дампе повторяются циклично значения
50 de 2c bb, а первым вхождением данного мусора является блок
CID SKU Ident 25: B9290007FF070007FF0700030C040000000450DE [WARNING]
В первоисточнике же видно, что должно стоять 00 00 на конце SKU Ident 25, а потом должен идти Dynamic Filler 3.
Воспользуемся копированием и приведем блоки в идентичное состояние, поскольку они не являются уникальными.

2. Дальше идет динамическая секция с пометкой уникальности для конкретной консоли, но раз у нас блок поврежден и взять его неоткуда, то просто копируем с первоисточника (вдруг повезет?) и заодно «добиваем» очередной филлер с помощью 0xFF.

Если на этом этапе все сохранить и сделать повторную валидацию битого дампа, то можно будет увидеть, что у нас ушел 1 Danger и Warning’и, а значит пока движемся в правильном направлении.

3. Следующим у нас идет битый блок CID Dynamic section 6. К сожалению, у нас он забит 0xFF и что туда писать – не понятно.

Но тут нам на помощь приходит смекалка и можно попробовать найти такой же блок в дампе-образце, вдруг где-то есть повтор.

Ищем по данной сигнатуре в дампе-образце возможное второе вхождение и натыкаемся на еще один такой же блок по адресу 0x001ce220 (первый был по 0x001c5220).
Бинго!

Копируем указанный блок, начинающийся с 04 00 из этой секции в верхнюю по адресу 0x001c5220 и сохраняем. Еще один блок восстановлен!

Смотрим в дамп-образец, а там всё забито 0xFF-ками. Недолго думая, делаем привычное дело – копируем блок.

5. И вот мы добрались до финальной ошибки и пары предупреждений.


Снова повреждена динамическая секция, филлеры и еще одна динамическая секция. Но нам это уже чем-то знакомо. Точно! Нечто подобное было при восстановлении SKU из п.1! Меняем тут последние 2 байта с 50 DE на 00 00, копируем секцию, начинающуюся с 6b 00 и забиваем остатки филлером по образцу.

6. Делаем финальную валидацию, и смотрим на результат….

Отлично, пробуем прошиться! После прошивки нашего восстановленного дампа консоль ожила, дала старт и картинку.
Надеюсь, мой опыт будет кому-то полезен. Всем удачных ремонтов!