ConsoleFiX
Администратор
- Регистрация
- 7 Июн 2021
- Сообщения
- 304
- Реакции
- 26
Этот способ позволит узнать на каком этапе загрузки зависла приставка в BLOD.
Здесь также будем обсуждать ошибки загрузки и их решения.
Примерная инструкция, кто шарит быстро поймет.
Всё делается на свой страх и риск!
Требования:
1) Отладочная плата Teensy++ 2.0 или берите другой считыватель например CH341A Programmer
2) каретка под QFN8
3) Программа
BwE PS4 NOR Validator для активации UART
4) Терминал типа HyperTerminal или Arduino IDE
1) Отладочная плата Teensy++ 2.0 или берите другой считыватель например CH341A Programmer
2) каретка под QFN8
3) Программа
BwE PS4 NOR Validator для активации UART4) Терминал типа HyperTerminal или Arduino IDE
1. Отпаиваем SPI flash и подключаем к своему сокету. Подключаем это чудо к Teensy++ 2.0 или CH341, как обычную флешку
2. Считываем дамп прошивки 2 раза!
в програме HxD сверяем дампы на идентичность и сохраняем в надежное место!
3. в программе BwE проверяем дамп с помощью Validate. если присутствуют сектора WARNING, не продолжаем, криво считалось.
пример нормального дампа
4. Активируем Uart. Enable\Disabled UART or IDU Mode > Enable\Disable UART > Enable\1
5. Дамп с активированым uart "uart_disabled.bin" зашиваем во флешку с проверкой
6. Возвращаем SPI память обратно в приставку и подключаемся к UART
(два провода RX и GND).
TX – режим передатчика
RX – режим приемника
GND — Земля, минус.
На каждых рисунках по разному рисуют RX/TX.
Вот пример для СЛИМ.
Здесь надо подключить к RX вашему USB-UART
Вот пример для ФАТ.
а здесь нарисован TX0 к вашему RX (приставка передает — TX, а преобразователь принимает — RX)
Именно по этой линии будут идти информационные сообщения загрузки secure loader-a.
9. Настройки терминала:
Скорость: 115200, Биты 8, Без четности, Стоповые 1, Без управления потока
Включаем приставку, и видим сообщение на котором встал BLOD,
если у вас сразу тухнет приставка и нет сообщений, значит надо :
1)проверить процессор на короткое замыкание
для фат ~16ом
для слим ~1.2ом
для про ~0.7ом
2)подключаться к Mediacon-у у него другая линия (обычно рядом), смотреть через JaiBrute2 командами errlog 0 , errlog 1 и т.д. но расшифровки этих цифр нет нигде, только у меня несколько экспериментальных , например проблема с питанием 80810011
https://cloud.mail.ru/public/TAcs/Q2vFCwEa8
Примеры ошибок
secure loader build: Mar 19 2019 05:31:18 (r9884:release_branches/release_06.510) [711MHz]
AGESA: KG&CN.BDK W8C24
ERROR: DCT[0] is disabled
ERROR: DCT[1] is disabled
ERROR: DCT[2] is disabled
ERROR: DCT[3] is disabled
ERROR: DCT[4] is disabled
ERROR: DCT[5] is disabled
ERROR: DCT[6] is disabled
ERROR: DCT[7] is disabled
1) при отвале проца по линиям озу, решается реболом проца
2) При физическом отвале оперативной памяти
Моё мнение: Память работает парами, чтобы узнать какая именно отвалилась, можно попробовать ее прогреть до 150с, или сразу снять пару. сразу скажу SAMSUNG то еще говно, отваливается и сдыхает очень часто, а вот Micron намного лучше. Обычно, меняют сразу все банки. т.к. из за разности времени обновления HC-28 или HC-25 и тем более фирм могут быть проблемы с загрузкой системы (выхода из BLOD).
Запуск фатки до прогрева
[ERROR]: AmdInitSecure 0x5 и сразу отрубается или повисает в BLOD при замыкании информационной линии от Mediacon до APU.
также само ,ребол проца
А после прогрева
ERROR: main.c:ecdsaVeriP224(1509) EcDsaVeri -1 -
ERROR: main.c:main(3196) Invalid idpsCert
или ошибка как выше
то нужно менять память
ERROR: getManufacturingMode(1627) sceSblSnvsRecvSector -36
ERROR: main(3724) getManufacturingMode -36
Здесь очень просто, чужой SYSCON
ERROR: sceSblSlLoadSelfWithVerifiedHeader(171) sceSblCfVeriLoadSegment -36
ERROR: loadBios(2174) sceSblSlLoadSelf -8
ERROR: main(4065) loadBios -8 (здесь 4065 меняется в зависимости от версии ПО)
1) такая ошибка появилась при сгоревшем южном мосте ,а его смерти был виноват Panasonic, что был в коротком замыкании
2)Очень страшная ошибка говорящая скорее всего о повреждении раздела CoreOS, (приставку вырубили во время записи или обновления) если у вас нет рабочего дампа, скорее всего труп. Пока сам решаю данную проблему.
Даже перенос связки на другую плату НЕ ПОМОЖЕТ. Проблема именно в связке.
надо проверить SPI флешку с помощью BwE_PS4_NOR_Validator, может что покажет.
3)После считывания SYSCON-а через SYSGLITCH (Teensy++ 2.0)
выяснил следующее:
Прошивка SYSCON-а расположена по адресам 0x00000 - 0x5ffff для разных ревизий своя прошивка.
Уникальные данные расположены по адресам 0x60000 - 0x7ffff
Сравнивая рабочую SAE-004 и дохлую SAF-003 данной ошибкой.
адреса 0x00000 - 0x5ffff - идентичны
0x60000 - 0x7ffff - расхождения
на SAE-004 много уникальной информации, а на дохлой SAF-003 почти всё забито FF
есть информация для анализа.
GET_HDMI_STATE FAILED
нет связи гнезда с Panasonic. при этом будет белый огонь.
Еслим меняли панасоник - непропай
Или обрыв дросселей, или нет 5V hdmi на предохранителе
или обломан порт
2. Считываем дамп прошивки 2 раза!
в програме HxD сверяем дампы на идентичность и сохраняем в надежное место!
3. в программе BwE проверяем дамп с помощью Validate. если присутствуют сектора WARNING, не продолжаем, криво считалось.
пример нормального дампа
4. Активируем Uart. Enable\Disabled UART or IDU Mode > Enable\Disable UART > Enable\1
5. Дамп с активированым uart "uart_disabled.bin" зашиваем во флешку с проверкой
6. Возвращаем SPI память обратно в приставку и подключаемся к UART
(два провода RX и GND).
TX – режим передатчика
RX – режим приемника
GND — Земля, минус.
На каждых рисунках по разному рисуют RX/TX.
Вот пример для СЛИМ.
Здесь надо подключить к RX вашему USB-UART
Вот пример для ФАТ.
а здесь нарисован TX0 к вашему RX (приставка передает — TX, а преобразователь принимает — RX)
Именно по этой линии будут идти информационные сообщения загрузки secure loader-a.
9. Настройки терминала:
Скорость: 115200, Биты 8, Без четности, Стоповые 1, Без управления потока
Включаем приставку, и видим сообщение на котором встал BLOD,
если у вас сразу тухнет приставка и нет сообщений, значит надо :
1)проверить процессор на короткое замыкание
для фат ~16ом
для слим ~1.2ом
для про ~0.7ом
2)подключаться к Mediacon-у у него другая линия (обычно рядом), смотреть через JaiBrute2 командами errlog 0 , errlog 1 и т.д. но расшифровки этих цифр нет нигде, только у меня несколько экспериментальных , например проблема с питанием 80810011
https://cloud.mail.ru/public/TAcs/Q2vFCwEa8
Примеры ошибок
secure loader build: Mar 19 2019 05:31:18 (r9884:release_branches/release_06.510) [711MHz]
AGESA: KG&CN.BDK W8C24
ERROR: DCT[0] is disabled
ERROR: DCT[1] is disabled
ERROR: DCT[2] is disabled
ERROR: DCT[3] is disabled
ERROR: DCT[4] is disabled
ERROR: DCT[5] is disabled
ERROR: DCT[6] is disabled
ERROR: DCT[7] is disabled
1) при отвале проца по линиям озу, решается реболом проца
2) При физическом отвале оперативной памяти
Моё мнение: Память работает парами, чтобы узнать какая именно отвалилась, можно попробовать ее прогреть до 150с, или сразу снять пару. сразу скажу SAMSUNG то еще говно, отваливается и сдыхает очень часто, а вот Micron намного лучше. Обычно, меняют сразу все банки. т.к. из за разности времени обновления HC-28 или HC-25 и тем более фирм могут быть проблемы с загрузкой системы (выхода из BLOD).
Запуск фатки до прогрева
[ERROR]: AmdInitSecure 0x5 и сразу отрубается или повисает в BLOD при замыкании информационной линии от Mediacon до APU.
также само ,ребол проца
А после прогрева
ERROR: main.c:ecdsaVeriP224(1509) EcDsaVeri -1 -
ERROR: main.c:main(3196) Invalid idpsCert
или ошибка как выше
то нужно менять память
ERROR: getManufacturingMode(1627) sceSblSnvsRecvSector -36
ERROR: main(3724) getManufacturingMode -36
Здесь очень просто, чужой SYSCON
ERROR: sceSblSlLoadSelfWithVerifiedHeader(171) sceSblCfVeriLoadSegment -36
ERROR: loadBios(2174) sceSblSlLoadSelf -8
ERROR: main(4065) loadBios -8 (здесь 4065 меняется в зависимости от версии ПО)
1) такая ошибка появилась при сгоревшем южном мосте ,а его смерти был виноват Panasonic, что был в коротком замыкании
2)Очень страшная ошибка говорящая скорее всего о повреждении раздела CoreOS, (приставку вырубили во время записи или обновления) если у вас нет рабочего дампа, скорее всего труп. Пока сам решаю данную проблему.
Даже перенос связки на другую плату НЕ ПОМОЖЕТ. Проблема именно в связке.
надо проверить SPI флешку с помощью BwE_PS4_NOR_Validator, может что покажет.
3)После считывания SYSCON-а через SYSGLITCH (Teensy++ 2.0)
выяснил следующее:
Прошивка SYSCON-а расположена по адресам 0x00000 - 0x5ffff для разных ревизий своя прошивка.
Уникальные данные расположены по адресам 0x60000 - 0x7ffff
Сравнивая рабочую SAE-004 и дохлую SAF-003 данной ошибкой.
адреса 0x00000 - 0x5ffff - идентичны
0x60000 - 0x7ffff - расхождения
на SAE-004 много уникальной информации, а на дохлой SAF-003 почти всё забито FF
есть информация для анализа.
GET_HDMI_STATE FAILED
нет связи гнезда с Panasonic. при этом будет белый огонь.
Еслим меняли панасоник - непропай
Или обрыв дросселей, или нет 5V hdmi на предохранителе
или обломан порт
Okas43
Недавно была пс4 про в ремонте после предыдущего сервиса. Изначальный симптом включалась на пару секунд и выключалось. оказалось ,что грели процессор и на нем полное короткое замыкание. Отреболил процессор, после стала уже по логам проходить инициализацию ,но стопорилось наERROR: sceSblSlLoadSelfWithVerifiedHeader(171) sceSblCfVeriLoadSegment -36
ERROR: loadBios(2174) sceSblSlLoadSelf -8
ERROR: main(4065) loadBios -8
диагностировав дальше ,оказалось что панасоник в полном коротком замыкании, прозванивая конденсаторы под ним. сняв панасоник ,ситуация не изменилась. эта ошибка ушла после замены южного моста. панасоник тоже заменил. в итоге, консоль стопорилась по логу GET_HDMI_STATE FAILED. решилось заменой предохранителя 5в возле панасоника, пропайки дросселей между портом и чипом и замены HDMI гнезда
Если при проверке дампа высянилось,что много блоков [DANGER] или [WARNING], то вот гайд по правке дампа:
1) Считанный дамп
2) Дамп такой же версии, но с рабочей приставки. Если дампа той же версии нет, то шансы резко падают
3) BwE NOR Validator
4) Hex-редактор. Я предпочитаюHex Editor Neo или Hex Editor HxD
Предыстория: в ремонт пришла приставка 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. Делаем финальную валидацию, и смотрим на результат….
Отлично, пробуем прошиться! После прошивки нашего восстановленного дампа консоль ожила, дала старт и картинку.
Надеюсь, мой опыт будет кому-то полезен. Всем удачных ремонтов!
1) Считанный дамп
2) Дамп такой же версии, но с рабочей приставки. Если дампа той же версии нет, то шансы резко падают
3)
BwE NOR Validator4) Hex-редактор. Я предпочитаю
Hex Editor Neo или Hex Editor HxDПредыстория: в ремонт пришла приставка 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. Делаем финальную валидацию, и смотрим на результат….
Отлично, пробуем прошиться! После прошивки нашего восстановленного дампа консоль ожила, дала старт и картинку.
Надеюсь, мой опыт будет кому-то полезен. Всем удачных ремонтов!
Автор инструкции: Alexey Bogdanov, оформил: Okas43
Сайт проекта:
https://www.betterwayelectronics.com.au/Github проекта:
https://github.com/BetterWayElectronics/ps4-nor-validatorОписание:
Программа для проверки каждого байта NOR (а это более 2100 конкретных областей) - позволяя вам увидеть, где он поврежден. Наиболее распространенной областью повреждения, вызывающей BLOD, является CID. Он в основном заполнен данными о консоли и, следовательно, не может быть восстановлен. НО! Эта программа покажет вам области, которые заполнены и области, которые являются статическими (которые неизменны в разных консолях). Вам может повезти!
Скачать:
* BwE PS4 NOR Validator v1.8.8 Password: BwE
Последнее редактирование:
