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

сомневаюсь

если ecdsa проверяет только размер файла, то можно подогнать eboot.bin под этот размер?

E2E41, эмм, в смысле? Если подписывать из ELF, то можно конец ELF забивать нулями настолько, чтобы после подписывания получился файл с таким же размером, как в оригинале. И вставить туда тот самый ECDSA. Но я сомневаюсь, что собственное подписывание сделает рабочим файл.

кто мешает попробывать, если на cfw будет рабочим то и возможно на ofw

E2E41, попробуй :) у тебя же есть PS3.

В PSP мы используем следующий хак...

1. Берётся заголовок от игры-демки. Там просто демки не проверяются и свободно запускаются на официальной прошивке. Заголовок 0x150 байт менять нельзя ни байтика, в нём записаны кирки и чексуммы самого сжатого и подписанного ELF и потом заголовок подсчитан и подписан, поэтому его трогать нельзя. Механизм подписи тела известен.
2. А в заголовке прописано 3 значения - это размер декриптованного ELF, размер сжатого ELF и всего файла целиком.
3. Мы берём кастомное Хоумбрю-приложение, добиваем нулями декриптованный ELF до размера, указанного в заголовке.
4. Сжимем его пофигу чем, например с помощью 7-Zip или libzip, вернее в формат Gzip, который понимает PSP.
5. Затем добиваем нулями этот архив до размера, указанного в заголовке. Там хоть на гигабайт добавь в конец нули, он всё равно распакуется.
6. Потом этот правильный архив шифруем кирком от заголовка (это механизм PSP, а на PS3 шифруется ключами под версию EBOOT)
7. Ну и вставляем шифрованное тело к оригинальному официальному заголовку этой игры и ву-а-ля.
8. По всем проверкам на размеры игры кастомное Хоумбрю проходит и запускается на оффпрошивке.

Вообщем, если интересно, почитай, начиная с этого поста: https://www.pspx.ru/forum/showthread.php?p=1070631
Правда на PS3 всё по другому. Но можно подумать использовать подобный механизм.

Эмм, в заголовке EBOOT.BIN должен же быть где-то записан размер декриптованного ELF.

Что такое R S в ECDSA?

Смотри в этих файлах:

• https://github.com/naehrwert/scetool...master/ecdsa.h
• https://github.com/naehrwert/scetool/blob/master/ec.cpp - Нажми в браузере CTRL+F и вставь в поиск: static int check_ecdsa
• https://github.com/naehrwert/scetool/blob/master/np.cpp - Нажми в браузере CTRL+F и вставь в поиск: Generate signature
• https://github.com/naehrwert/scetool...master/sce.cpp - Нажми в браузере CTRL+F и вставь в поиск: Generate signature

Как я понимаю подпись ECDSA содержит в себе хеш файла,можно ли вытащить этот хеш?

Strong-Men, оу, это я тебе точно сказать щас ничего не могу, т.к. я ещё сам не рассматривал этот момент. Это надо разбирать весь код и соображать, что там и как всё устроено. Могу точно сказать, что ECDSA состоит из двух частей = R и S, которые состоят из хэшей по 0x14 байт, итого 0x28 байт.

• R - это хеш от vsh_curves, этот файл ты можешь увидеть в папке ps3tools\tools\scetool\data или ps3tools\tools\scetool\.ps3
• S - это тоже хеш, но я вообще без понятия откуда он берётся. Это, по-моему, хэш всех ключей, которые встраиваются в EBOOT.BIN, могу ошибаться.

И эти 2 хеша записываются один за другим и получается ECDSA 0x28 байт. Или в десятичном виде ровно 40 байт (2 раза по 20).
Короче, я тебя сразу что-то не понял, но теперь понял, что последние 8 байт хеша SHA1 не проверяются и их можно даже занулить.
А вот попробуй занулить хоть один байт из предпоследних 40 байт и игра не заведётся.

это точно не заведется уже проверил,но вот что интерестно ISO.BIN.DAT PSOne Classics подписан реальной подписью ECDSA а прога sign.np генерирует эту подпись(кстати генерирует каждый раз новую подпись на один и тот же файл но игра заводится) и игры работают,вполне возможно что EBOOT.BIN подписан той же подписью вот только нужно знать какую часть файла она хеширует или может это хеш debug версии или EBOOT.ELF ...

что интересно у мультимэна присутствует подпись ECDSA

Слежу за темой взлома. Если все получится, то мы сможем вытаскивать приватный ключ из консольки, тогда и подпись заработает. Я тут не писал, но загадку подписи ECDSA я разгадал в том году. Однако поняв, что приватный ключ на всех современных прошивках, каждой консольке разный, не стал писать. Ибо нет в этом смысла. А тут вроде обещают полный доступ к ядру в ближайшее время.

Ну так что ж ты молчишь? Если бы ты нам дал бы разгадку ECDSA, так мы в том году бы подправили scetool и спокойно подписывали бы EBOOT.BIN.

Пока что поправлять ничего не нужно. На официалке EBOOT.BIN не работает потому, что у всех приватный ключ разный.
А до прошивки 3.55 он был у всех одинаковый, потому то в те времена PS3 легко и взломали.

rhish777, меня интересует - что ты там разгадал в прошлом году :D и не стал писать :xDD:

А приватный ключ не может быть разный у каждой консоли, потому что тогда нужно для каждой консоли выпускать индивидуальный диск с EBOOT.BIN, подписанным индивидуально под каждый приватный ключ у каждой консоли. Даже пусть не диск, а игра из PSN, но и тогда для каждого скачивающего EBOOT.BIN должен вытаскиваться из PKG, переподписываться Соней под консоль скачивающего и одновременно паковаться обратно в PKG. Однако, насколько нам известно, все PKG с игрой, скачиваемые из любого места в мире, имеют один и тот же PKG с одним и тем же EBOOT.BIN по MD5 или SHA-1 контрольной суммой.

А ты подумал над тем, что все игры имеют статичную подпись ECDSA? То есть, она для всех консолей у каждой игры одинаковая и почему-то на всех консолях запускается, несмотря на то, как ты придумал, что приватный ключ (пароль к архиву) у всех разный :D

Я понимаю, что к каждой подписи подмешивается соль - это рандомный набор цифр. Но дело в том, что какой бы ты набор цифр не подмешивал, то конечно ECDSA будет всегда изменяться, но алгоритм подсчёта всегда остаётся прежним. Если взять любой конкретный EBOOT.BIN, то мы свободно можем генерировать ту самую соль постоянно точно так же, как её сгенерировала Сони в данном EBOOT, как мы и проводили опыт в данной теме ранее. поэтому мы можем в точности восстановить метод создания файла, нам только требуется узнать метод генерации ECDSA. А ты оказывается всё это время знал и нам не раскрывал :)

Единственное, что я знаю, так эти данные записаны в самом EBOOT.BIN. Это VSH Curve должно записываться в метаданные в шифрованную область, потом оно раскладывается кубиками и прямоугольниками, переставляются местами по определённому алгоритму в зависимости от флага, как шарик-малик-келишь-мелишь-трёшь-мнёшь-тратр-ватр-экскаватр, потом вычисляется его SHA-1 и длина этого блока, ксорятся (совокупляются) с приватным ключом соответствующей прошивки и раскладывается на R и S.

ErikPshat, Вы так и не поняли что scetool предназначена для локальной подписи. Файлы же от самой сони подписаны совсем по другому. Все приставки с CFW по сей день сидят на одном одинаковом ключе self_type=NPDRM priv=009EF86907782A318D4CC3617EBACE2480E73A46F6 от 3.55 прошивки. Ответ же всегда был перед глазами.


Как работает подпись для всех сразу?
А для абсолютной подписи для OFW нам нужен приватный ключ самой СОНИ. Публичный ключ есть в каждой приставке.
Где же мы его возьмем? Давай в сапорт напишем. Вышлите нам приватный ключ для подписи пожалуйста. :D

ВЫВОД Имеется два ключа для подписи. Один хранится в пристаке и с ним будет запускаться EBOOT.BIN только на нашей плойке. Другой хранится у сони с ним будет работать на всех плоечках. Такова работа ECDSA

Что я не понял? :) Если ты не в курсе, то у нас на форуме лежат во вложении scetool, meke_npdata и многие прочие тулзы, во многом исправленные и скомпилированные лично вашим слугой капитаном КО https://www.pspx.ru/forum/cleardoc/misc/kapitan_2012.png. Ты же наверное заметил, что теперь всё отображается ровными рядами со специальными отступами для красивого копирования кода в сообщения форума в тег [CODE], а не как было раньше всё вперемешку в одну строчку со сдвигами хер знает куда. И думаешь я там просто так ковырялся только лишь для косметических изменений? А make_npdata теперь же не требует отдельной утилиты make_c00_edat, потому что она одна создаёт универсальный EDAT, подходящий под разные задачи.

Да, я прекрасно знаю, подо что scetool делалась. Она заточена под дисковые Non-DRM EBOOT.BIN. Там правда есть возможность создания NPDRM, но всё оставили под дисковые SELF, потому что в NPDRM всегда 0x33 ключа и нету дополнительной расширенной секции, по поводу которой мы тут много говорили насчёт True/False (лень вспоминать её точное название). True как раз означает наличие этой доп-секции, которая всегда присутствует в NPDRM из PSN.

Но это всё фигня. Это всё можно было воссоздать, пораскидывать мозгами, только какой в этом толк, когда мы не знаем механизма генерации ECDSA. Ведь достоверно известно, что при изменении хоть одного байтика в официальном файле, в частности в футере (в конце) секции ECDSA, так файл перестаёт работать.

Там есть полностью комплектованные ключи под 3.30, 3.42, 3.50, 3.55.
А вот с 4.21 я верю, что просто заполнили фейковыми ключами под CFW, т.к. они все одинаковые.

Но кто мешает подписывать игры под 3.30-3.55? Или ты думаешь, что они все в чёрном списке? Возможно.
Но я что-то сомневаюсь, что те копии игр, распространённых миллионными тиражами на дисках и через PSN, которые требовали прошивки 3.30-3.55 и это в период бурного расцвета PS3 с активными продажами - и вдруг все эти игры оказались забанены по причине подписи их скомпрометированными ключами? Они что, теперь не запускаются на последующих прошивках, которые были подписаны утёкшими приватными ключами?
Что-то мне твоя разгадка подписи ECDSA не устраивает такими доводами.

ErikPshat,
Ну блин не ужели не понятна эта формула?
https://www.blogcdn.com/www.engadget...domization.jpg

rhish777 добавил 10.11.2017 в 13:05
Все старье подписано не лакальным приватником с консоли, а приватным ключем самой компании SONY.
Все работает естественно. Ключ настоящий еще некто не получил этот.

rhish777, эту картинку из детского сада я уже видел на каком-то сайте. Это ты детям показывай, что там неужели не понятно :D
Я тебе уже объяснял насчёт соли, как она рандомно генерируется и я прекрасно знаю все смещения, куда она записывается, уже показывал на скриншотах ранее в этой же теме. А ты эту картинку видимо только увидел, как что-то новое и типа она всё объясняет :D

Это знаешь, можно собрать вокруг школьников, сделать умный вид, показать эту картинку и сказать, типа вы все лохи, вот вам секрет ECDSA. Ну и вся школота будет махать гривами и соглашаться, типа теперь всё понятно :) Короче, не парь мне и людям мозги. Я уже по этому разговору вижу, насколько глубоко ты разбираешься в этом ECDSA, это можешь детям сказки рассказывать, но только не мне. И все ключи 3.30-3.55 настоящие, включая приватные. Где-то тут была тема с тех времён, когда мы сами эти ключи вытаскивали из файлов прошивки и сами же заполняли текстовик keys. И приватные ключи дампили из кирка. Вот почитай примерный ход исследования и добычи ключей для PSP, а на PS3 примерно то же самое и есть алгоритм формирования этого ECDSA, только никто пока не разгадал складывание байтов в этот кубик рубика. Если имеется один и тот же файл, подсаливается одной и той же солью (мы можем это дело взять под контроль и сделать статичным явлением по своему хотению, вместо рандомной генерации), ксорится одними и теми же приватными ключами, тогда и ECDSA всегда у этого файла будет на выходе одна и та же, иначе никакой приватный ключ дешифровки от Sony не сможет расшифровать свой же архив.

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

ErikPshat, Давай подождем взлома и проверим. До сей поры не было взлома 4k консолей.

rhish777, насчёт ключей, можешь сам по инструкции в 4-5 постах проверить, настоящие они или нет.
Вот тема для ознакомления: https://www.pspx.ru/forum/showthread.php?t=103760

Я не проверял, но возможно можно декриптовать прошивку 4.81...
Кстати, я сам лично проверял EBOOT.BIN NPDRM подписанный под 4.75. Так вот, я его полностью декриптовал.
А это намекает, что ключи после 3.55 не совсем фейковые, как ты уверял.
И при желании, при отсутствии лени, их все можно проверить на валидность.