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

**E2E41** · 25.04.2017, 08:42

для сведения последние блок из EBOOT.BIN от патча длинною 8 это последняя часть контрольной суммы SHA-1 если выкинуть блок длинною 30

ErikPshat · 25.04.2017, 15:32

E2E41, ах, ты имеешь в виду, что в EBOOT.BIN из PSN последние 8 байт являются частью контрольной суммы SHA-1 всего файла, без учёта последних 0x30 (48) байт. Ну так ведь и надо объяснять по-русски

Да, действительно так, спасибо за полезную информацию

Вот я скачал Update-патч для игры "AFRO SAMURAI [BLUS30264]". Извлёк из PKG файл EBOOT.BIN, выделил от начала до конца весь файл и отступил от конца 0x30 байт, потом посчитал контрольную сумму SHA-1 выделения:

AFRO SAMURAI [BLUS30264].png

SHA-1: F9302F5AC6AEAC7D1B8B76282AAAF64C1F1F65CE

ErikPshat · 02.05.2017, 09:56

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

если есть, скиньте EBOOT.BIN и .sprx

Есть: http://rgho.st/8cMZk2mlP
Скачал демку "NPEB90473 DmC Devil May Cry Demo", вроде ты её хотел. Залил во вложение, пригодится.
Только в EBOOT.BIN и в SPRX в секции NPD записан ContentID

00000440 4E 50 44 00 00 00 00 01 00 00 00 03 00 00 00 01 NPD.............
00000450 45 50 30 31 30 32 2D 4E 50 45 42 39 30 34 37 33 EP0102-NPEB90473
00000460 5F 30 30 2D 44 4D 43 44 45 4D 4F 30 30 30 30 30 _00-DMCDEMO00000
00000470 30 30 30 31                                     0001

Так что тебе придётся дисковую версию под этот NPEB90473 и ContentID подгонять. Либо в этой секции менять ContentID на дисковый и подсчитывать новую контрольную сумму. Ну ты думаю знаешь как это делается при подписывании файлов с новым ContentID через make_npdata, тем более уже найдена контрольная сумма всего файла, записанная в конце.

По поводу вопроса ко мне, то я фиг знает что с этим делать. Я предлагаю заняться доработкой исходников scetool, там требуется только дописать этот недостающий блок 0x30 байт, появившийся в NP TRUE.

in1975 · 02.05.2017, 16:48

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

Я предлагаю заняться доработкой исходников scetool, там требуется только дописать этот недостающий блок 0x30 байт, появившийся в NP TRUE.

ErikPshat, а что в этих 30 байтах д.б ?

ErikPshat · 02.05.2017, 19:48

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

ErikPshat, а что в этих 30 байтах д.б ?

Вот на скриншоте я выделял жёлтым цветом: https://www.pspx.ru/forum/showpost.php?p=1109690

Там на дисковых EBOOT.BIN и SPRX эта жёлтая секция имеет размер 0x10 (16) байт - одна строка 16-ричного кода.
А в NP (из PSN) EBOOT.BIN и SPRX эта жёлтая секция имеет размер 0x30 (48) байт - три строки 16-ричного кода.

Вот фактически в этом основная разница.
В жёлтой секции смотри, вторые 4 байта показывают TRUE 00000001 - это NP EBOOT.
А вот если вторые 4 байта 00000000, значит это FALSE - это дисковый EBOOT.
Ну и в NP эти 2 строчки с кодом не хватает, поэтому не запускается переподписанный с HDD и нельзя переподписать Мультимен.

Ну возьми любой NP EBOOT и декриптуй. Потом снова подпиши, он получится дисковы и сравни с оригиналом. Там я выложил HBK для дискового и NP, он всё покажет.

in1975 · 02.05.2017, 20:19

ErikPshat, первые 16 байт (0х10) одинаковые у всех дисковых EBOOT.BIN (у разных игр)

ErikPshat · 02.05.2017, 20:30

in1975, да, поэтому у дисковых стоит в третьих 4 байтах 00000010 вместо 00000030 - это размер этой секции, где я выделил синим прямоугольником.

Только не пиши биты - это одна восьмая от одного байта

1 байт = 8 бит.

in1975 · 02.05.2017, 21:19

вроде в дисковой также. может в PSN меньше?
диск1.jpg

in1975 · 02.05.2017, 21:38

Посмотрел несколько eboot. ContentID в дисковых eboot не вижу (смотрите картинки). Похоже в этом и разница.

PSN

Disk

З.ы. не смотрите на патчи, они же из PSN

ErikPshat · 02.05.2017, 23:53

in1975, эмм, я имею в виду, когда подписываешь файл через scetool, то там секция всегда получается 0x10, вместо 0x30.

**YAGAMI55** · 03.05.2017, 09:23

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

ErikPshat · 03.05.2017, 21:11

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

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

Вот и вся махинация. Эта секция NPD генерируется точно так же, как EDAT.
Открой любой EDAT, например LIC.EDAT, подписанный моей утилитой make_npdata из моей утилиты "PS3GameConvert_v091".
Ты увидишь в начале Magik Header - NPD. Не правда ли какое удивительное сходство с тем, что имеется в SPRX и EBOOT?

Затем смотри далее, ты увидишь ContentID игры в этом EDAT.
А следом ты увидишь, после строчки с нулями вроде бы, эти 3 странные строки, заполненные какими-то данными. Вот про них я и говорю, про эти 3 ключа по 16 байт. Причём в первом ключе там написан копирайт нашего сайта

что-то типа "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"):

echo. Encrypting LIC.DAT to LIC.EDAT:
echo.
%tools%\sfk partcopy "%DEST%\%NAME%\USRDIR\EBOOT.BIN" 0x450 0x24 %temp%\6.tmp -yes
echo.
set /p contentID=<%temp%\6.tmp
set cID=%contentID:~0,7%%DIRNAME%%contentID:~16,20%
%tools%\make_npdata -e LIC.DAT "%DEST%\%DIRNAME%\LICDIR\LIC.EDAT" 1 1 3 0 16 3 00 %cID% 1
echo. LIC.EDAT succesfully encripted.

То есть, это 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.

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

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

ErikPshat · 03.05.2017, 23:20

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

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

Step1.png

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

Step2.png

<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
Приступаем к шифрованию пустышки:

make_npdata -e FILE.DAT NTJOBCODE.PPU.SPRX 1 1 1 0 16 3 00 EP0102-NPEB90473_00-DMCDEMO000000001 1

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

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

Step3.png

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

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

**YAGAMI55** · 04.05.2017, 02:13

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

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

ErikPshat · 04.05.2017, 03:33

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

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

make_npdata -e FILE.DAT NTJOBCODE.PPU.SPRX 1 1 1 0 16 3 00 EP0102-NPEB90473_00-DMCDEMO000000001 8 4034250AB9018EF901C098E1790A907F

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

Сравнение с оригиналом:

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

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

**YAGAMI55** · 01.05.2017, 21:44

Кто знает в демке DmC есть .sprx?
если есть, скиньте EBOOT.BIN и .sprx
хотя мне кажется FULL в DEMO превратится
но похимичу,если скините,сам не могу скачивать игрухи с нэта,извиняюсь,но трафиковая система до сих пор в моем гос-ве

YAGAMI55 добавил 01.05.2017 в 21:44
ErikPshat, вопрос к тебе непосредственно, хотя и другие помогут если скажут мне как запустить PSN "FREE" игры
например Bioshok 2 из Rapture Edition
суть такая-pkg игра,устанавливается с диска,но без самого диска не играется(привязка к LIC.DAT)
если поместить LIC.DAT и LIC.EDAT в игру,ничего не меняется
если поменять у игры HG на DG то LIC.EDAT виден для запуска,запускается игра,но поврежденные данные надпись красуется

**YAGAMI55** · 03.05.2017, 01:11

ErikPshat, попробовал
все таки одной контрольной суммы мало

ErikPshat · 03.05.2017, 05:55

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

**YAGAMI55** · 04.05.2017, 10:34

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

ErikPshat · 04.05.2017, 14:52

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

Чтобы декриптовать мой маленький файл и посмотреть что там написано, нужно использовать такой скрипт:

make_npdata -v -d NTJOBCODE.PPU.SPRX FILE.DAT 8 4034250AB9018EF901C098E1790A907F

И у меня есть ещё подозрение, что в играх, где есть такие 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.