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

[riku.kh3]

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

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

[SergeSm]

Сообщение от 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]

Сообщение от 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]

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

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

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