YAGAMI55, а кто сказал, что там одна контрольная сумма? Я говорил, что помимо контрольной суммы всего файла нужно подсчитать ещё другую контрольную сумму секции NPD, вернее там 2 хэша, которые подсчитывает сама make_npdata.

ErikPshat, поясни,голова не варит
через make_npdata подпишу без разницы во что EDAT/SDAT файл ради CN_HASH? потом впишу 8 б из SHA-1?
распиши по порядку,точнее что с make_npdata делать

YAGAMI55, да забей, у тебя думаю не получится. После ContentID идёт рандомный ключ "Digest" 16 байт. Затем идут 2 хеша по 16 байт. Итого 3 строчки ключей.

1. Первая строка - рандомный ключ 16 байт
2. Вторая строка - хеш "Названия файла" вместе с расширением 16 байт
3. Третья строка - хеш всех предыдущих строк секции NPD, включая ключи первой и второй строки.

Вот и вся махинация. Эта секция NPD генерируется точно так же, как EDAT.
Открой любой EDAT, например LIC.EDAT, подписанный моей утилитой make_npdata из моей утилиты "PS3GameConvert_v091".
Ты увидишь в начале Magik Header - NPD. Не правда ли какое удивительное сходство с тем, что имеется в SPRX и EBOOT? :)
Затем смотри далее, ты увидишь ContentID игры в этом EDAT.
А следом ты увидишь, после строчки с нулями вроде бы, эти 3 странные строки, заполненные какими-то данными. Вот про них я и говорю, про эти 3 ключа по 16 байт. Причём в первом ключе там написан копирайт нашего сайта :D что-то типа "GoodLuckFromPSPx" (точно дословно не помню уже) - это и есть первый рандомный ключ 16 байт.
Далее идёт строка с хешем 16 байт. Она генерируется от названия файла с расширением "NTJOBCODE.PPU.SPRX".
Далее третья строка с хешем, которая потом берёт предыдущие 0x60 байт и генерирует контрольную сумму 16 байт.
И следом идёт ещё строка, обычно забита нулями - это 8 байт "времени подписи" и ещё 8 байт тоже какого-то времени, всего 16 байт Но они не используются, поэтому нулевые.
А дальше, этот заголовок секции NPD, больше ничем похоже не проверяется. Нам туда лезть не следует, там идёт шифрованное тело файла с метаданными и прочей хнёй. Там есть ещё проверочные хеши, но это отдельно хеш только секции метаданных и т.д.

Так вот, тебе же надо подменить ContentID одной игры на другую. У тебя сразу изменится хеш 3-го ключа. Усекаешь?
Первй рандомный ключ уже вставлен готовый, но у тебя именно с ним могут возникнуть проблемы, я тебе ниже объясню.
Второй хеш уже и так готовый под название этого файла.

Как тебе подсчитать этот 3-ий хеш? Ты ведь подменил ContentID на другой.
А ответ я тебе уже говорил - нужно воспользоваться утилитой make_npdata :) и подписать любой файл, пусть даже пустой, с новым ContentID и теми же параметрами, как у подопытного. Но название этого пустого файла должно быть при подписи указываться такое же - "NTJOBCODE.PPU.SPRX".
А параметры я смотрю у файла такие:
NPD Version = 1
License Types = 3 Free License
Content ID = как записано в LIC.EDAT при конвертировании дисковой версии. Ты не забыл ещё? У нас при конвертировании там записывается вот что (смотри исходники "PS3GameConvert_v091"):
То есть, это 0x24 байта берутся из EBOOT.BIN апдейта из позиции 0x450. Где вместо cID вставляется вот это cID=%contentID:~0,7%%DIRNAME%%contentID:~16,20%. То есть, в этот ContentID вставляется вместо %DIRNAME% - TitleID игры NP, например NPUB12345.
Так вот, генерируешь EDAT с такими параметрами и получаешь готовую секцию NPD с тремя хешами.
Первый 16 байт - рандомный набор цифр - типа "GoodLuckFromPSPx"
Второй 16 байт - хеш названия генерируемого файла
Третий 16 байт - хеш всего заголовка NPD с новым ContentID (0x60 байт).
Теперь забираешь этот блок и вставляешь в SPRX.
Затем, в конце файла, если ты не забыл, нужно подсчитать новую контрольную сумму всего файла, минус 0x30 байт. Это последние 8 байт от SHA-1.

Уфф, не хотел отвечать на нубские вопросы, знал, что придётся много объяснять :D

---

in1975, вот что ты за скриншоты хекс-редактора выкладываешь?
Я же буквально в предыдущих постах объяснял по несколько раз, что одна строка 16-ричного кода - это 16 байт.
А ты выкладываешь скриншоты, где у тебя в строке 24 байта.
У тебя же съехали все смещения, нарушилось 0x10 выравнивание и код становится нечитаемой кашей. Ну как можно так читать код?
И закрой ты все лишние окна, которые пустые и в данном случае не нужны и вообще очень редко используются - это слева выезжающее окно "Data Visualiser", потом "Structures" и справа "Data Inspector".

YAGAMI55, короче, ещё раз...

Вот я беру оригинальный файл из PSN - NTJOBCODE.PPU.SPRX

Вложение 12755

А это я создаю пустой текстовик и переименовываю его как угодно, например FILE.DAT.
Теперь шифрую его с тем же ContentID и теми же параметрами, как в исходнике SPRX и получаю вот такой маленький файл:

Вложение 12756

• <format>: 1 - EDAT
• <data>: 1 - Finalized data
• <version>: 1 - EDAT version 1
• <compress>: 0 - Disable compression
• <block>: Block size in KB (16)
• <license>: 3 - Free license (uses klic as key)
• <type>: 00 - Common
• <cID>: Content ID (EP0102-NPEB90473_00-DMCDEMO000000001)
• <klic>: 1 - NPDRM OMAC key 1 (free license key)

Получился формат кодирования: 1 1 1 0 16 3 00 EP0102-NPEB90473_00-DMCDEMO000000001 1
Приступаем к шифрованию пустышки:
И вот что получаем на скриншоте выше. Я специально поместил скриншоты поближе, чтобы можно было сравнить все байты. Как видно, они все сходятся с оригиналом, за исключением 3-ёх строк хешей.
1-ая строка рандомного хеша отличается, потому что у меня там свой рандомный набор цифр "GoodLuckFromPSPx". Если туда забить тот же самый набор цифр, как у оригинала, а это можно сделать в исходниках вместо этого моего копирайта и заново скомпилировать make_npdata, тогда эта строка была бы в точности, как у оригинала, т.е. совпала бы точно. Я тебе писал об этой сложности, почему у тебя не получится, но потом удалил, т.к. в принципе это не имеет значения. Этот рандомный набор символов просто соль, которой подсаливается обычно хеш, чтобы он всегда был разный.
2-ая строка, как видно, совпала точно, потому что я использовал то же имя файла с расширением.
3-ья строка уже сгенерировалась другая, в соответствии с предыдущими данными 0x60 байт. И это правильно. Таким образом у нас изменённый ContentID стал валидным. А вот если бы я подогнал бы первый рандомный хеш, как у оригинала, тогда бы у меня и 3-ья контрольная сумма совпала.

Теперь осталось только подсчитать контрольную сумму всего файла:

Вложение 12757

После этого NPD блока идёт секция метаданных, даже если мы подписывали пустой файл. А далее идёт контрольная сумма блока метаданных и ECDSA, которая, как мы знаем, не проверяется, потому что в EDAT мы туда генерируем так же рандомные значения ECDSA от фонаря фейковые. Я в утилите make_npdata её вообще занулил, чтобы не мозолила глаза.

То есть, на этом примере я тебе показал, что можно сгенерировать даже оригинал с нуля, тупо из ничего, из пустого файла. И это даёт надежду, что можно подменить ContentID без палева.

ErikPshat, вот это я и хотел прочесть
просто суть в том,что подписывая файлы через разные утилиты,эти хэши не всегда одинаковые,например TASR и BREAK-N-MAKE разные хэши дают,поэтому переспросил,проверю,отпишусь

YAGAMI55 добавил 04.05.2017 в 02:13
Проверил,результат отрицательный

YAGAMI55, а разные хеши потому у разных утилит, потому что они генерируют разный рандомный первый ключ. Отсюда и разный подсчёт третьего хеша. А второй хеш всегда должен быть одинаковым, т.к. название файла одинаковое.

Ах да, ещё один момент, только дошло до меня. Эти данные в EBOOT вместе с SPRX подписываются ведь кликом.
Я вытащил его: 4034250AB9018EF901C098E1790A907F
Команда для подписывания пустышки будет такая:

---

И вот тебе прикол. Я специально скомпилировал make_npdata, как говорил, под тот самый рандомный ключ в SPRX, второй ключ сам хешируется из названия файла такой же, а вот третий ключ генерируется на основании первых двух вместе со всей предыдущей секцией 0x60 + klicense, которая заложена в EBOOT и SPRX. И что ты представляешь? Третий хеш тоже получился в точности такой. Можешь сам посмотреть, сравнить с оригинальным SPRX и удивиться. Получилась точная копия оригинала в заголовке NPD.
Так что переделывай свою работу, но уже с кликом и моим make_npdata под этот SPRX (хотя наверное не обязательно, т.к. тут важет клик). Потом выделяешь готовый заголовок NPD - это 0x70 байт (там как раз захватится весь заголовок NPD вместе с тремя хешами) и в SPRX так же выделяешь эти 0x70 байтов и аккуратно вставляешь. Следи, чтобы последующий код не сдвинулся, а то все смещения похерятся.

И тебе задание: декриптуй этот файл (он формата EDAT естессна) и напиши мне ответ, что я там написал...

ErikPshat, я с клик подписал
файл все равно не рабочим получается,там что то ещё есть
BREAK-N-MAKE при декриптовки жалуется на неверную сигнатуру,не описывая где именно ошибка,понять бы...

YAGAMI55, эмм, ты не ответил на моё задание, что я там написал в пустышке...

Чтобы декриптовать мой маленький файл и посмотреть что там написано, нужно использовать такой скрипт:
И у меня есть ещё подозрение, что в играх, где есть такие SPRX, они все подписаны с кликом из EBOOT.
Поэтому возможно эти FALSE SPRX можно так же сконвертировать в SDAT-формат, но используя для них клик, а не просто фри-лицензию, как для остальных файлов.

И это, ты знаешь, как получить Klicense для SPRX из EBOOT.BIN?
Просто кидаешь эти шифрованные EBOOT.BIN и SPRX (обязательно оба) в папку ps3tools\tools\scetool и запускаешь утилиту BruteForce.exe (только снять галочку "Fix EBOOT Version @ 0x428). Она сама декриптует EBOOT, переименует и заново его переподпишет, следом она найдёт Klicense и декриптует SPRX, потом его переименует и переподпишет. Ну это для теста переподписывание.

Потом, я тебе писал про SPRX. А как ты подменял ContentID в EBOOT?
Надеюсь ты для начала посмотрел этот заголовок секции NPD, а там такие данные (на скриншоте выше я не просто так указал эти данные у SPRX):

• NPD version: 1 - EDAT version 1
• NPD license: 3 - Free license (uses klic as key)
• NPD type: 01 - PS2 EDAT and Theme/Avatar/Activation key

То есть, в EBOOT появился 01 в конце строчки NPD. Это значит, что эта демка активируется файлом Активации (Activation key).
Собсно это уже наталкивает на мысль, что подделывать эту секцию нужно по другому. Хотя возможно наверное можно отвязать активацию и сменить тип на 0.
Но в декриптованном EBOOT есть в двух местах упоминание на NPEB90473, что мы пока поменять не можем. Поэтому тут подмена ContentID на BLUS/BLES не проканает. Нужно тогда дисковую версию подгонять под NPEB90473, а не наоборот. И там видимо понадобится Activation key.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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