scetool & ps3tools - утилиты де/криптовки файлов PS3 - Страница 4

**YAGAMI55** · 04.05.2017, 21:31

ErikPshat, я менял ContentID у демо .sprx на дисковый
да все сделал и знаю как делается
там что то ещё есть,чего то не хватает

ErikPshat · 04.05.2017, 22:04

YAGAMI55, скорее всего эта секция NPD участвует в формировании ключа декриптовки самого тела. Если подменить там данные, тогда изменится хеш и не подойдёт ключ для декриптовки тела. Я так думаю. И возможно в SPRX проверяется ECDSA подпись в конце файла - это 0x28 байт, не считая последних 8 байт.

Короче нужно собирать весь файл один к одному. А для этого нужно править исходники scetool. Но это большая головная боль. Когда я начинаю сильно думать, то у меня начинает голова болеть

так что я уже стар для этого.

**YAGAMI55** · 04.05.2017, 22:48

Сообщение от ErikPshat

YAGAMI55, скорее всего эта секция NPD участвует в формировании ключа декриптовки самого тела. Если подменить там данные, тогда изменится хеш и не подойдёт ключ для декриптовки тела. Я так думаю. И возможно в SPRX проверяется ECDSA подпись в конце файла - это 0x28 байт, не считая последних 8 байт.

Короче нужно собирать весь файл один к одному. А для этого нужно править исходники scetool. Но это большая головная боль. Когда я начинаю сильно думать, то у меня начинает голова болеть

так что я уже стар для этого.

совершенно верно,мои мысли прочёл
я подозреваю что конечные суммы это суммы NPD секции,секции control info,секции prx и самого файла целиком(что уже известно)

**E2E41** · 06.08.2017, 23:50

Сообщение от ErikPshat

ECDSA подпись в конце файла - это 0x28 байт, не считая последних 8 байт.

или эти 0x28 байт вторая половина контрольной суммы, а есть ли возможность подогнать(забить нулями)
файл под контрольную сумму?

ErikPshat · 07.08.2017, 12:05

Сообщение от E2E41

или эти 0x28 байт вторая половина контрольной суммы

Нет, в исходниках всё видно. Эти 0х28 байт состоят из двух половинок по 0х14 байт, так называемые "R" и "S". А из чего они генерируются, пока не известно.

Сообщение от E2E41

а есть ли возможность подогнать(забить нулями)
файл под контрольную сумму?

То есть, подменить в файле какие-то неважные данные, чтобы в конечном счёте сошлось с имеющейся ECDSA? Теоретически это возможно, но это как перебирать 0x28-значный пароль к архиву

in1975 · 06.05.2017, 06:07

А может можно связаться с автором scetool ? Копаться в чужом коде - так себе занятие

**riku.kh3** · 06.05.2017, 08:33

NPDRM SELF'ы генерируются с фейковой подписью, они только на CFW будут работать.

**SergeSm** · 18.08.2017, 22:45

Я, наверное, жутко нубские вещи скажу... но попробую)))
Предпоследние 0х28 байт можно забить любой фигней - запустится и на CFW и на OFW (если взять изначально рабочий файл), причем без пересчета контрольной суммы (что логично). Если тронуть те самые хеши после NPD - то файл работать перестает (генерировал пустышку по инструкции, заменял байты, контрольную сумму в последних восьми байтах пересчитывал, да). Либо ECDSA находится в теле файла, как на картинке с
http://www.psdevwiki.com/ps3/SELF_Fi...and_Decryption
и как-то связана с этой NPD-секцией, либо (там же написано странное):
uint8_t digest[16]; // sha-1 hash of debug self/sprx created with make_fself_npdrm
это не просто соль, а какая-то контрольная сумма? и, по идее, у плойки должна быть возможность получить эту сумму из данного файла же... (ну, например, посчитать при декриптовании) - тогда и сейчас ее можно же получить из того же файла?

Я точно где-то чего-то не понимаю, мб кто-то знающий попробует? Еще раз сори за нубство

P.S.: я скорее всего сделал что-нить не так - ну не понимаю я в этом, поэтому лучше перепроверить все мои действия...

ErikPshat · 19.08.2017, 01:17

Сообщение от SergeSm

Предпоследние 0х28 байт можно забить любой фигней - запустится и на CFW и на OFW (если взять изначально рабочий файл), причем без пересчета контрольной суммы (что логично).

А ты точно проверял на рабочем EBOOT.BIN от игры? Я раньше уже говорил, что вполне возможно, что эта ECDSA даже не проверяется, как у EDAT/SDAT, так что вполне может быть, что проблема даже не в ней, а в неправильной сборке секций при создании SELF NPDRM. По крайней мере, не правильно собирается количество ключей.

Насчёт предпоследних 0x28 байт ECDSA, то в EDAT это точно они. Я сравнивал эту область с EBOOT, PKG, SPRX, и как будто эта подпись кругом находится именно там, т.к. расположение её в конце, перед последними 8 байт хеша всего файла, кругом схожа.

**SergeSm** · 19.08.2017, 09:55

я для проверки в обоих eboot (и в bles и в npeb) забил эти байты нулями и ff (случайно тыкал 0 и f) - после переноса заработало

еще, если длина "encapsulated data" кратна не 16 а 8 (=0хXXXXXX8), то появляется выравнивание 8 байт перед последними 0х30 байт - его тоже можно забить чем-нибудь, но уже с пересчетом контрольной суммы в последних 0х08 байтах - также будет работать. ощущение, что после конца файла остается какой-то мусор от промежуточных вычислений... но почему-то не обрезается под корень

и вот я не разобрался с офсетами чего-то... но если я правильно понял, то "metadata offset"=0x04A0 указывает как раз на последний хеш в секции npdrm. поэтому, видимо, и перестает работать файл, если заменить три контрольных суммы сгенерированными из пустышки через make_npdata? или там как-то хитро смещение вычисляется?

ErikPshat · 19.08.2017, 17:47

SergeSm, интересное наблюдение, это всё меняет. Хотя, если смотреть на спецификацию на вики, то ECDSA выходит находится не в конце файла, а в секции Metadata Header. Либо я там что-то не понял по английски, может она вычисляется от начала файла 0x0 до длины этой секции. Там как-то неопределённо написано. Хотя, как я вижу в разных типах self-файлов, то это должна быть она, эта ECDSA именно на предпоследних 0x28 байтах и она состоит из двух половинок S и R.

Сообщение от SergeSm

если заменить три контрольных суммы сгенерированными из пустышки через make_npdata?

Именно про это я и производил эксперимент где-то недавно, ах да, вот на этой странице сверху.
Файл после этого переставал работать, видимо есть ещё где-то проверка, либо тестер мог допустить ошибку.

E2E41, согласен, нужно для начала подогнать код так, чтобы добиться 100% совпадения. Хотя бы выстроить все секции аналогично, выставить правильное количество ключей, оно должно быть в NPDRM 0x33 штуки, тогда как утилиты конвертирования в NPDRM выдают там количество, как у дисковых EBOOT.

Собственно можно вручную собирать секции по частям, но надо вычислить все точки с контрольными суммами и последовательность их вычислений.
А вы там понимаете в спецификации все смещения и понятия uint64/32/16/8 или расписать спецификацию?
Думаю лучше, для начала, расписать спецификацию и разложить по полочкам, чтобы потом использовать в качестве библиотеки, а то там на вики как-то не чётко выстроены указатели.

Сообщение от E2E41

предлагаю переподписать один eboot от дисковой версии [BLUS30767] в NPDRM

Думаю проще взять лицензионный NPDRM-файл, декриптовать его и подписывать до 100% совпадения с оригиналом.

**riku.kh3** · 19.08.2017, 21:35

Сообщение от SergeSm

я для проверки в обоих eboot (и в bles и в npeb) забил эти байты нулями и ff (случайно тыкал 0 и f) - после переноса заработало

Какой версии были файлы? Насколько помню, на OFW некоторые части NPDRM SELF'ов сверяются только когда они подписаны ключами <=3.55.

**SergeSm** · 20.08.2017, 06:25

Сообщение от riku.kh3

Какой версии были файлы? Насколько помню, на OFW некоторые части NPDRM SELF'ов сверяются только когда они подписаны ключами <=3.55.

по версиям не подскажу, а так, в последний раз использовались:
- Farming Simulator 15 [BLES02108] с патчем - заменялись предпоследние 0х28 байт в обоих EBOOT.BIN;
- Super Stardust HD [NPEA00014] скачанная отсюда - заменялись предпоследние 0х28 байт и перед ними 0х08 байт с пересчетом контрольной суммы.
Если нужно какие-то еще протестить - то особых сложностей нету, лишь бы игра была с возможностью запуска на OFW через УПД... или такую сложно найти для версии ниже 3.55? (в смысле, патч будет для более старшей версии)

Сообщение от ErikPshat

Насчёт sha-1 hash - это вообще нужно проверить. Взять EBOOT от любого обновления (NPDRM), декриптовать его, затем зашифровать его как дебаг с помощью make_fself_npdrm, посчитать SHA-1 и сверится с этой строкой в оригинале. Дебаг - это скорее подписанный файл, но не с DRM шифрованием. Эмм, не всё сразу, нужно бы мысли собрать, а для начала нужно бы дорожную карту сообразить и нарисовать библиотеку для справки и сверки.

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

ну, это просто мои предположения, возможно проблема вовсе не в этом, тут надо бы, чтобы разобрались разбирающиеся в вопросе люди)))

P.S.: начиналось все с того, что есть игрушка After Hours Athletes [BCES01335] - в ней кроме EBOOT.BIN есть три .self файла (для каждой игры) и один из них содержится в оф.патче и работает на OFW (то есть, можно сравнить? правда она без мува не запускается). А еще есть же бесплатный singstar, правда не знаю, поможет ли он чем-нибудь. если надо - могу скачать и выложить куда-нибудь...

ErikPshat · 20.08.2017, 15:08

Сообщение от SergeSm

по версиям не подскажу

Ну это видно в ScetoolGui в строке FW Version.
А ты случайно не спутал, в игре есть 2 папки, папка NPEB выступает как загрузочная Bootable и оттуда происходит запуск EBOOT.BIN, а папка BLES как данные игры, поэтому, лежащий в ней EBOOT.BIN просто так лежит мёртвым грузом. Ну и конечно в обоих папках лежит один и тот же EBOOT.BIN от обновления из PSN.
В смысле, может ты только поменял предпоследние 0x28 байт у EBOOT.BIN в папке BLES?

Сообщение от SergeSm

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

Логично. По-моему, при шифровании в NPDRM этот ELF проходит 2 этапа. Сначала он преобразуется через make_self, а затем через make_fself.

А кто-нибудь знает утилиту, которая декриптует и вытаскивает отдельно Metadata? Потому что мы видим на выходе только чистый ELF, а секция метаданных декриптуется в памяти и остаётся невидимой глазу.

**SergeSm** · 20.08.2017, 19:41

Сообщение от ErikPshat

В смысле, может ты только поменял предпоследние 0x28 байт у EBOOT.BIN в папке BLES?

менял в обоих файлах (в двух папках), для подстраховки, а в PSN-игре там всего одна папка.

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

**E2E41** · 19.08.2017, 14:28

вообще в качестве эксперимента предлагаю переподписать один eboot от дисковой версии [BLUS30767] в NPDRM если добьемся 100% совпадению eboot из патча думаю будет проще понять сам механизм(патч не изменяет версию приложения там какие то фиксы к геймархивам)

**SergeSm** · 19.08.2017, 20:55

мне тоже показалось, что если взять подготовленную к переносу PSN-игру (к тому же маленькую), то будет проще экспериментировать.

в спецификации там вроде все понятно. но по-полочкам разложить было бы очень полезно, наверное, много таких как я, которые не очень в материале, потому что пропустили в свое время переподписи под прошивку 3.55 и работу с прогами от геохота и т.п.
да, еще... вот если бы полностью доделать тот волшебный файл закладок для HWP... но там, наверное, слишком много сложностей, условий и всякого... а так очень помогает!
ну и единственное, мне непонятно вычисление смещений (офсетов) в заголовке файла. получается, это не смещение от текущей позиции, а абсолютный адрес от начала файла? (тут я, наверное, просто туплю, говорят же: заменить байты по офсету 0хХХХХ, подразумевая смещение от начала файла)

ну и по-поводу переподписи до 100% совпадения... рано или поздно придется определиться, первые 16 байт после content_id[48] в NPD-секции - это просто случайный набор или все-таки контрольная сумма файла, как там и написано:
uint8_t digest[16]; // sha-1 hash of debug self/sprx created with make_fself_npdrm
дебаг версия - это же незашифрованная версия файла? можно ли получить такое же число из имеющегося зашифрованного файла?
просто, если этот параметр важен, то замена этих сумм один к одному на нерабочем файле - даст опять же нерабочий файл...

сори, наверное, непонятно объясняю...

ErikPshat · 19.08.2017, 21:52

Сообщение от SergeSm

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

HBK для HWSHP

Ну в заголовке SCE - это статичные смещения от начала файла. В Hex Workshop можешь нажать редактирование закладки и там увидишь, либо прямое смещение, либо формулу, которая делает прыжки и прибавки к смещениям. Там же, в заголовке SCE, указаны основные позиции секций, а потом в каждой секции идут свои абсолютные смещения. Поэтому сначала идёт прыжок на секцию из SCE, а затем в той секции есть свой заголовок, где указаны смещения и размеры параметров. Вообщем, никакого шаманства, чистая математика.

Сообщение от SergeSm

первые 16 байт после content_id[48] в NPD-секции - это просто случайный набор или все-таки контрольная сумма файла, как там и написано:
uint8_t digest[16]; // sha-1 hash of debug self/sprx created with make_fself_npdrm

Собственно этот NPD собирается так же, как EDAT/SDAT файлы, а там, после content_id[48] вроде бы ничего не говорится про хэши. Там просто генерится рандомный набор чисел, который подставляется, как соль. Поэтому многие туда вписывают названия, типа DRINK TO VODKA. всё равно следом 16 байт генерится хэш от названия файла и следом 16 байт Хеш предыдущих 0x60 байт. Вот, как внизу слева я подписал эти строчки на первых двух скриншотах: https://www.pspx.ru/forum/showpost.php?p=1114677

Насчёт sha-1 hash - это вообще нужно проверить. Взять EBOOT от любого обновления (NPDRM), декриптовать его, затем зашифровать его как дебаг с помощью make_fself_npdrm, посчитать SHA-1 и сверится с этой строкой в оригинале. Дебаг - это скорее подписанный файл, но не с DRM шифрованием. Эмм, не всё сразу, нужно бы мысли собрать, а для начала нужно бы дорожную карту сообразить и нарисовать библиотеку для справки и сверки.

ErikPshat · 22.08.2017, 05:39

Сообщение от SergeSm

ну и по-поводу переподписи до 100% совпадения... рано или поздно придется определиться, первые 16 байт после content_id[48] в NPD-секции - это просто случайный набор или все-таки контрольная сумма файла, как там и написано:

uint8_t digest[16]; // sha-1 hash of debug self/sprx created with make_fself_npdrm

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

Короче, я посмотрел на Спецификацию PKG и понял, что это значит debug.
Смотрите по ссылке в таблице второе смещение:

pkg_revision - 80 00 for retail (finalized), 00 00 for debug (non finalized)

То есть, debug - это не финализированная версия, получаемая при первом проходе - это не шифрованная версия файла и без вставленных ещё <license>, <type> и <cID>, а во втором проходе получается финализированная retail (finalized), где файл шифруется и заполняются эти параметры, присущие финализированной версии.

А теперь смотри в позиции 0x60, тот код digest после ContentID, про который ты говоришь и который одинаково расположен у любых NPD:

digest - sha1 from debug files and attributes together merged in one block

То есть, в переводе - это SHA1 от debug файлов и атрибутов, объединенных в один блок.

Короче, я решил провести эксперимент на файле EDAT. Взял официальный файл licensee.edat из Update Patch к игре "Call of Duty Ghosts NPEB01835", о которой писал постом выше.
Вот я подготовил архив необходимых файлов scetool.zip (распаковать в папку ps3tools\tools\scetool) - в архиве licensee.edat, EBOOT.BIN и RAP от этой игры + оригинальный make_npdata + исправленный ScetoolGuiPSPx.exe.

Сначала декриптуете официальный EDAT следующей командой:

make_npdata -v -d licensee.edat licensee.dat 0 RAPS/EP0002-NPEB01835_00-CALLDUTYGHOSTSDL.rap

Процесс декриптовки:

Вот это официальный EDAT в хексе и выделена строка 16 байт того самого sha-1 hash

licensee.edat.png

Затем компилируете в DEBUG этот декриптованный licensee.dat в папку edat, чтобы не затёрся оригинал, вот команда:

make_npdata -v -e licensee.dat edat/licensee.edat 1 0 4 0 16

Процесс компиляции в DEBUG:

Вот такой получается файл DEBUG и внизу смотрим контрольную сумму SHA-1 (сравниваем первые 16 байт с выделением на картинке выше)
SHA-1 = 8A AA D3 DB 8C FF 18 C2 F3 0F 53 9D 58 E0 63 A2 F4 89 07 99

licensee.edat (DEBUG).png

Достаём KLicensee от игры:

**E2E41** · 22.08.2017, 15:00

так я и не понял чего не хватает чтобы подписать нужный файлик?