Перескладання дампа Playstation 4

Якщо при перевірці дампа височіло, що багато блоків [DANGER] або [WARNING], то ось гайд по правці дампа

1. Лічений дамп
2. Дамп такої ж версії, але з робочої приставки. Якщо дампа тієї ж версії немає, шанси різко падають
3. BwE NOR Validator
4. Hex-редактор. Я віддаю перевагу Hex Editor Neo або Hex Editor HxD

Скачать “BwE_PS4_NOR_Validator.zip”

BwE_PS4_NOR_Validator.zip – Загружено 7 раз – 7,22 МБ

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

Аналіз вихідної ситуації.
У вихідному стані було 2 критичні помилки (Danger), 8 попереджень (Warning) та 1 розбіжність контрольної суми в блоці з файловою системою з невизначеним вмістом (Unlisted). Що ж проблема зі стартом очевидна, намагатимемося відновлювати. Для переходу до подальших кроків вам знадобиться дамп такої ж версії, але з робочої приставки. Якщо дампа тієї ж версії немає, то шанси різко падають, хоч і залишаються ненульовими.
У моєму випадку ситуацію ускладнювало те, що знайти рідкісний та давній дамп версії 1.62 мені так і не вдалося. Єдине, що було знайдено більш-менш близьким, була версія 1.61. На основі роботи з цими двома дампами і будуватиметься цей гайд.

Слід запам’ятати, що наявність кілька Warning без помилок, цілком собі припустимо і не впливає на працездатність консолі. Більшість проаналізованих мною дамп прошивок мали по 2-3 попередження і чудово працювали.

Перед розбором дампа слід зняти дамп кілька разів і перевірити на відмінність по MD5, якщо відмінності є, потрібно зняти так, щоб відмінностей не було (перевірити контакти та інше)

Розуміння того, як влаштовано прошивку

Перед тим, як йти далі, рекомендую ознайомитися з головним джерелом інформації про те, як влаштовано вміст прошивки. Для цього найкраще підійде англомовний ресурс www.psdevwiki.com та стати на ньому Flash-Main . Для тих, кому не потрібні подробиці я опишу основні види блоків у прошивці (відповідно до BwE NOR Validator):
Static Section. Статичний вміст, що повторюється на всіх консолях та їх прошивках
Dynamic Section. Змінний вміст, залежно від версії прошивки, але не прив’язаний до конкретного екземпляра консолі
Dynamic Section (Per console). Змінний вміст, залежно від версії прошивки, та прив’язаний до конкретного екземпляра консолі. Іноді може повторюватися в різних консолях, але з ймовірністю 1 до 100, або навіть менше. Одна з найбільших паршивих ситуацій, якщо у вашої прошивки пошкоджено саме цей блок.
SKU ID. Ідентифікатор серії консолі (наприклад, 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]

dump

Оскільки він поки не дуже інформативний і не зрозумілий ступінь впливу на запуск, вирішено було пропустити цей блок і зайнятися рештою.
Наступним на шляху з’являється розсадник, що складається з критичної помилки і трійки попереджень.

dump

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

dump

dump

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

dump

Копіюємо з лога перший збійний фрагмент: (B9290007FF070007FF0700030C040000000450DE) і шукаємо його в нашій битій дампі:

dump

Пошук привів нас до першого збійного блоку, а HEX-редактор відразу підсвічує різницю у вмісті дампів, роблячи процес наочним

dump

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

dump

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

dump

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

dump

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

dump

Наступним у нас йде битий блок CID Dynamic section 6. На жаль, у нас він забитий 0xFF і що писати туди – не зрозуміло.

dump

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

dump

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

dump

Копіюємо зазначений блок, що починається з 04 00 з цієї секції у верхню за адресою 0x001c5220 та зберігаємо. Ще один блок відновлено!

dump

Дивимось у дамп-зразок, а там все забито 0xFF-ками. Недовго думаючи, робимо звичну справу — копіюємо блок.

dump

І ось ми дісталися фінальної помилки та пари попереджень.

dump

Знову пошкоджено динамічну секцію, філери та ще одну динамічну секцію. Але нам це вже чимось знайоме. Точно! Щось подібне було за відновлення SKU з п.1! Змінюємо тут останні 2 байти з 50 DE на 00 00, копіюємо секцію, що починається з 6b 00 і забиваємо залишки філером на зразок. Робимо фінальну валідацію, і дивимося на результат.

dump

Чудово, пробуємо прошитися! Після прошивки нашого відновленого дампа консоль ожила, дала старт та картинку.
Всім вдалих ремонтів!

 

Okas43

Ремонт консолей, продаж Ігор та підписок

View all posts

Okas43

Ремонт консолей, продаж Ігор та підписок

Останні відео