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

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

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

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

Собственно этот 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 шифрованием. Эмм, не всё сразу, нужно бы мысли собрать, а для начала нужно бы дорожную карту сообразить и нарисовать библиотеку для справки и сверки.

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

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

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

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

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

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

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

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

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

Короче, я посмотрел на Спецификацию 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", о которой писал постом выше.
Вот я подготовил архив необходимых файлов Вложение 13240 (распаковать в папку ps3tools\tools\scetool) - в архиве licensee.edat, EBOOT.BIN и RAP от этой игры + оригинальный make_npdata + исправленный ScetoolGuiPSPx.exe.

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

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

Ключей. KaKaRoTo говорил:

тоесть 28 байт в конце перед хешем файла

Ну для начала нужно восстановить по порядку правильную структуру файла.
Как я выше писал, на примере EDAT можно восстановить первую SHA-1 хеш-сумму, как у оригинала. У тебя получилось?

А вот с EBOOT.BIN и с PKG у меня пока не получилось получить из DEBUG-файла верную SHA-1 контрольную сумму.
Вот её нужно научиться правильно генерировать, чтобы пойти дальше к сходству с оригиналом. А, как я понял, всякие утилиты генерируют фейковый digest. И это уже может проверяться в экзешниках и это может быть первой ошибкой в утилите.

почему то у меня каждый раз меняются контрольные суммы у дебаг файла

E2E41, у EDAT или у EBOOT?

Для EDAT я в этом сообщении загрузил специально комплект исправленных утилит, в частности оригинальная make_npdata, без всяких извращений. Она, при создании debug генерирует всегда один и тот же файл.

А вот утилиты для EBOOT и PKG, каким-то образом патченные и там генерируется каждый раз рандомный хеш в debug. Сейчас пытаюсь скачать с меги 4.75 SDK, чтобы вытащить официальные утилиты make_fself_npdrm и make_package_npdrm, чтобы убедиться в чистоте утилиты. Но пока не удаётся скачать через браузер, пишет типа памяти не хватает.

Короче, залил на диск официальную коллекцию утилит из СДК475 (200 MB).

P.S. Естессна они все делают DEBUG-файлы для DEX-консоли, что нам и нужно для экспериментов.
Проверил пока только EDAT с помощью make_edata_npdrm.exe - получается правильный DEBUG.
Команда элементарная, по умолчанию никаких опций не надо, там автоматом подставляется block size (default 16) и --format4 (4.0.0.W), если не указывается иное: Затем замеряем контрольную сумму SHA-1 и сверяем с шифрованным оригиналом в позиции 0x40.

Провел эксперимент с EBOOT.BIN от игры "1942: Joint Strike" занулил последние 8 байт которые являются частью контрольной суммы SHA-1 и игра отлично завелась,занулил ещё 8 байт влево пс3 выдала ошибку 80010017,удалил 8 байт таже ошибка,так что в эти 8 байт можно вписать любые значения но без этих 8 байт игра не заведётся.

Strong-Men, выходит игра проверят размер файла.

Похоже на то,но зачем сони вставили эти фейковые 8 байт?

это число для выбора точки на эпилептической кривой(хотя могу и заблуждаться)
вот похожий механизм генерации:
https://github.com/uofw/upspd/wiki/K...multiplication

Можно ли сгенерировать подпись прогой sign.py по методу подписи ISO.BIN.DAT ?

сомневаюсь