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

ErikPshat · 22.11.2016, 11:09

scetool v0.2.9.2

Консольная утилита для де/криптовки файлов PS3 + GUI

SceToolGui.gif

Readme

scetool (C) 2011-2013 by naehrwert
NP local license handling (C) 2012 by flatz

==> Setup <==
 - /data/keys : Keyfile.
 - /data/ldr_curves : Loader curves (7744 bytes).
 - /data/vsh_curves : VSH curves (360 bytes).
 - /data/idps : IDPS as binary file
 - /data/act.dat : act.dat
 - /rifs/* : *.rif files
 - /raps/* : *.rap files

==> Keyfile Format <==
 [keyname]
 type={SELF, RVK, PKG, SPP, OTHER}
 revision={00, ..., 18, 8000}
 version={..., 0001000000000000, ...}
 self_type={LV0, LV1, LV2, APP, ISO, LDR, UNK_7, NPDRM}
 key=...
 erk=...
 riv=...
 pub=...
 priv=...
 ctype=...

==> Keyset Example <==
 [metldr]
 type=SELF
 revision=00
 self_type=LDR
 erk=0000000000000000000000000000000000000000000000000000000000000000
 riv=00000000000000000000000000000000
 pub=00000000000000000000000000000000000000000000000000000000000000000000000000000000
 priv=000000000000000000000000000000000000000000
 ctype=00

==> NPDRM Key(set) Names <==
 - [NP_tid]: Title ID OMAC1 key.
 - [NP_ci]: Control info OMAC1 key.
 - [NP_klic_free]: Free klicensee.
 - [NP_klic_key]: klicensee key.
 - [NP_idps_const]: IDPS constant.
 - [NP_rif_key]: rif key.
 - [NP_sig]: Footer signature ECDSA keyset.

==> Override Keyset <==
 It should be a single hex-string consisting of: 
 32 bytes (Key) 16 bytes (IV) 40 bytes (Pub) 21 bytes (Priv) 1 byte (CType).

==> History <==
Version 0.2.9.2
 - Extended Info for ELF Header and other types.
 - Added keysets 19, 1A, 1B 1C 1D for 3.74 - 4.81 FW. 
Version 0.2.9.1
 - Minor update 0.0.1 --self-fw-version for APP by someone
   http://www.maxconsole.com/threads/uniofficial-minor-update-to-scetool.31333/
Version 0.2.9
 - Plaintext sections will now take less space in metadata header keys array.
 - Added option to specifiy a template SELF to take configuration values from.
 - Added option to override the keyset used for en-/decryption.
 - Fixed NP application types.
 - [Firmware Version] will now be written to control info only.
 - [Application Version] will now be written to application info only.
Version 0.2.8 (intermediate release):
 - Fixed minor bugs where scetool would crash.
 - Added SPP parsing.
 - Decrypting RVK/SPP will now write header+data to file.
Version 0.2.7:
 - Added local NP license handling.
 - Added option to override klicensee.
 - Added option to disable section skipping (in SELF generation).
Version 0.2.5:
 - Added option to use provided metadata info for decryption.
 - "PS3" path environment variable will now be searched for keys/ldr_curves/vsh_curves too.
Version 0.2.4:
 - Added option to display raw values.
 - Moved factory Auth-IDs to <public build> (as they are on ps3devwiki now).
Version 0.2.2:
 - Added options to override control/capability flags (32 bytes each).
 - Fixed where a false keyset would crash scetool when decrypting a file.
 - Some source level changes and optimizations.
Version 0.2.1:
 - zlib is required to use scetool.
 - 'sdk_type' was changed to 'revision' in data/keys.
 
==> Greetings to <==
 - ps3dev.net
 - you know who you are!

==> Trivia <==
 http://bit.ly/QUji89

Последние изменения

Version 0.2.9.2
- - Extended Info for ELF Header and other types.
- - Added keysets 19, 1A, 1B 1C 1D for 3.74 - 4.81 FW.

Инструкция по использованию:

Удерживая SHIFT, в папке с утилитой нажмите правой кнопкой в пустом месте папки и выберите "Открыть окно команд".
В открывшемся окне консоли введите команду: scetool - вы увидите полный список команд.
Для русской версии введите в консоли команду: scetool_ru - вы увидите полный список команд на русском.
Так же, вы можете воспользоваться графической оболочкой GUI (только для EBOOT.BIN): запустите файл ScetoolGui.exe
- По кнопке "Help" выводится список всех команд;
- По кнопке "Show Keys" выводится список имеющихся ключей для разных прошивок;
- По кнопке "Show File Info" выводится информация о загруженном EBOOT.BIN.

Список команд:

scetool 0.2.9.2 <PRIVATE BUILD:ErikPshat> (C) 2011-2013 by naehrwert
NP local license handling (C) 2012 by flatz
[Build Date/Time: Dec 23 2016/03:15:47]

USAGE: scetool [options] command

COMMANDS                Parameters            Explanation

 -h, --help                                   Print this help.
 -k, --print-keys                             List keys.
 -i, --print-infos      File-in               Print SCE file info.
 -d, --decrypt          File-in File-out      Decrypt/dump SCE file.
 -e, --encrypt          File-in File-out      Encrypt/create SCE file.

OPTIONS                 Possible Values       Explanation

 -v, --verbose                                Enable verbose output.
 -r, --raw                                    Enable raw value output.
 -t, --template         File-in               Template file (SELF only)
 -0, --sce-type         SELF/RVK/PKG/SPP      SCE File Type
 -1, --compress-data    TRUE/FALSE(default)   Whether to compress data or not.
 -s, --skip-sections    TRUE(default)/FALSE   Whether to skip sections or not.
 -2, --key-revision     e.g. 00,01,...,0A,... Key Revision
 -m, --meta-info        64 bytes              Use provided meta info to decrypt.
 -K, --keyset           32(Key)16(IV)
                        40(Pub)21(Priv)1(CT)  Override keyset.
 -3, --self-auth-id     e.g. 1010000001000003 Authentication ID
 -4, --self-vendor-id   e.g. 01000002         Vendor ID
 -5, --self-type        LV0/LV1/LV2/APP/ISO/
                        LDR/NPDRM             SELF Type
 -A, --self-app-version e.g. 0001000000000000 Application Version
 -6, --self-fw-version  e.g. 0003004100000000 Firmware Version
 -7, --self-add-shdrs   TRUE(default)/FALSE   Whether to add ELF shdrs or not.
 -8, --self-ctrl-flags  32 bytes              Override control flags.
 -9, --self-cap-flags   32 bytes              Override capability flags.
 -a, --self-indiv-seed  256 bytes             Individuals Seed (ISO only)
 -b, --np-license-type  LOCAL/FREE            License Type
 -c, --np-app-type      SPRX/EXEC/USPRX/UEXEC App Type (U* for updates)
 -f, --np-content-id                          Content ID
 -l, --np-klicensee     16 bytes              Override klicensee.
 -g, --np-real-fname    e.g. EBOOT.BIN        Real Filename
 -j, --np-add-sig       TRUE/FALSE(default)   Whether to add a NP sig. or not.

Примеры шифрования:

Пример декриптовки EBOOT.BIN:

scetool.exe --decrypt EBOOT.BIN EBOOT.ELF

Пример шифрования EBOOT.BIN:

scetool.exe --sce-type=SELF --compress-data=TRUE --skip-sections=TRUE --key-revision=0A --self-auth-id=1010000001000003 --self-vendor-id=01000002 --self-type=APP --self-app-version=0001000000000000 --self-fw-version=0003005500000000 --self-cap-flags=00000000000000000000000000000000000000000000003B0000000100040000 --encrypt EBOOT.ELF EBOOT.BIN

Расшифровка параметров:
Знак = (равно) указывать не обязательно, а в сокращённых командах запрещено, только через пробел или вообще без пробела.

--sce-type=SELF                      // указываем тип SCE, могут быть SELF/RVK/PKG/SPP
--compress-data=TRUE                 // указываем сжимать или нет, выставляем одно из двух - TRUE/FALSE(default)
--skip-sections=TRUE                 // указываем пропускать секции или нет, одно из двух - TRUE(default)/FALSE
--key-revision=0A                    // указываем Ревизию ключа в зависимости от прошивки - 00, 01, ..., 1D.
--self-auth-id=1010000001000003      // указываем ID Аутентификации, для ретэйл-игр и обновлений - всегда такой.
--self-vendor-id=01000002            // указываем ID Производителя, для CoreOs/dev_flash files/Games - всегда такой.
--self-type=APP                      // указываем тип приложения, для дисковых игр - APP, для PSN игр - NPDRM.
--self-app-version=0001000000000000  // указываем версию приложения, тут просто v1.0
--self-fw-version=0003005500000000   // указываем версию прошивки, под ревизию ключа 0A идёт прошивка 3.55
--self-cap-flags=00000000000000000000000000000000000000000000003B0000000100040000 // 32 байта capability флаги
--encrypt EBOOT.ELF EBOOT.BIN        // указываем, что производим шифрование ELF в BIN

Тоже самое, только сокращёнными параметрами:

scetool -0 SELF -1 TRUE -s TRUE -2 0A -3 1010000001000003 -4 01000002 -5 APP -A 0001000000000000 -6 0003005500000000 -9 00000000000000000000000000000000000000000000003B0000000100040000 -e EBOOT.ELF EBOOT.BIN

Скачать: scetool_v0.2.9.2.zip (полная сборка с GUI и исходниками)
Скачать: ps3tools.7z (сборник утилит комплекта ps3tools)
Источник 1: https://github.com/naehrwert/scetool
Источник 2: https://github.com/nevik-xx/psl1ght/.../tools/scetool
Источник 3: https://github.com/euss/ps3tools - ps3tools (компиляция: `autoreconf -i; ./configure; make; make install')
Источник 4: https://github.com/ErikPshat/scetool

Ветка 3.0 (изменены команды):

Источник: https://github.com/Sorvigolova/sceto...master/Release

SELF File Format and Decryption:

SELF File Format and Decryption

Введение
Это формат, используемый исполняемыми файлами на PS3. В нем есть определенный заголовок, который называется SCE-заголовком, где он хранит все параметры для этого процесса

SCE Header - Заголовок SCE
Он состоит из информации о структуре и смещениях self. Первая часть находится в открытом виде до Metadata Info.
Metadata Info - Информация о метаданных
Информация о метаданных сама по себе находится под AES 256 CBC. Эта часть содержит KEY + IV для дальнейшей расшифровки заголовка с использованием AES 128 CTR.
Metadata - Метаданные
Заголовок метаданных, Заголовки секций метаданных, Хеш секции, Возможности и Подпись находятся под AES 128 CTR слоем и дешифруются с помощью ключа выше.
Metadata Header - Заголовок метаданных
Заголовок метаданных содержит информацию, необходимую для аутентификации заголовка и структуры метаданных. Подпись представляет собой ECDSA хеша SHA1 собственного файла, начинающегося с 0x0 и заканчивающегося на 0x0 + signatureInputLength.
Data Sections - Секции данных
Секции данных могут быть зашифрованы с использованием AES 128 CTR и/или сжаты. HMAC-SHA1 используется для аутентификации, они не должны быть изменены.

Примечание: в этот формат могут быть подписаны не только файлы ELF/PRX, другие известные файлы с заголовком SCE:

revoke (e.g. RL_FOR_PACKAGE.img/RL_FOR_PROGRAM.img and pkg.srvk/prog.srvk)
spp (e.g. default.spp)
package (e.g. .pkg/.spkg_hdr.X)
edat

Криптография
Это небольшое резюме о том, как работает криптография в self. В основном здесь находятся шаги, выполняемые загрузчиками:

Все загрузчики имеют статический ключ и iv, называемый соответственно erk и riv, это ключи для первого этапа дешифрования, которые используются для дешифрования первых первых 0x40 байтов метаданных self, используя AES256CBC.
Затем результат используется как ключ и iv для дешифровки остальной части метаданных с использованием AESCTR, наконец, дешифрованные метаданные содержат ключи и iv для каждого раздела данных, которые все еще дешифруются через AES128CTR. Эта модель безопасности основана на том факте, что первые 0x40 байт метаданных self, однажды дешифрованные статическим ключом AES256CBC в загрузчике, никогда не должны быть одинаковыми от одного бинарника к другому. То же самое относится к любому другому значению, используемому в качестве ключа AES128CTR или iv.
Загрузчики также участвуют в распаковке бинарных файлов с использованием zlib.
SELF аутентичность основана на других независимых шагах, HMAC-SHA1 от секции данных и ECDSA для актуальной сигнатуры в заголовке.

SCE Header - Заголовок SCE
Для начала, перед разбором кода структуры заголовка, давайте разберёмся, что означают эти странные значения и столбцы.

Слева - мы видим смещение в файле, а через пробел - его название, столбиком по порядку, смещение за смещением.
Справа - мы видим комментарии к этому смещению, заключённые между символами /* ... */ (такой вид комментария может использоваться в многострочном режиме, тогда как такой вид // только в однострочном)
Что означают uint8_t, uint16_t, uint32_t, uint64_t?
- u - unsigned - беззнаковое
- int - integer - целое
- 8/16/32/64 - число, кол-во битов, где 8 бит = 1 байт, значит 16 бит = 2 байта, 32 бит = 4 байта, 64 бит = 8 байт.
- Что в целом означает: беззнаковое целое число, а буква _t - означает, что это Тип данных, а не функция или процедура.

typedef struct {
 uint32_t magic;                 /* 53434500 = SCE\0 */
 uint32_t hdr_version;           /* header version */
 uint16_t key_revision;          /* key_revision */
                                 /* 0x0 retail (type 0)
                                  * 0x1 retail (0.92-3.30)
                                  * 0x2 retail (type 1)
                                  * 0x3 unknown (npdrm1?)
                                  * 0x4 retail (3.40-3.42)
                                  * 0x5 unknown (npdrm1?)
                                  * 0x6 unknown (npdrm2?)
                                  * 0x7 retail (3.50)
                                  * 0x8 unknown (npdrm1?)
                                  * 0x9 unknown (npdrm2?)
                                  * 0xa retail (3.55)
                                  * 0xb unknown (npdrm1?)
                                  * 0xc unknown (npdrm2?)
                                  * 0xd retail (3.56)
                                  * 0xe unknown (npdrm1?)
                                  * 0xf unknown (npdrm2?)
                                  * 0x10 retail (3.60-3.61)
                                  * 0x11 unknown (npdrm1?)
                                  * 0x12 unknown (npdrm2?)
                                  * 0x13 retail (3.65)
                                  * 0x14 unknown (npdrm1?)
                                  * 0x15 unknown (npdrm2?)
                                  * 0x16 retail (3.70-3.74)
                                  * 0x17 unknown (npdrm1?)
                                  * 0x18 unknown (npdrm2?)
                                  * 0x19 retail (4.00-4.11)
                                  * 0x1A unknown (npdrm1?)
                                  * 0x1B unknown (npdrm2?)
                                  * 0x1C retail (4.20-)
                                  * 0x1D unknown (npdrm1?)
                                  * 0x1E unknown (npdrm2?)
                                  * 0x8000 DEBUG (devkit)
                                  */
 uint16_t header_type;           /* 1 self, 2 srvk/img, 3 pkg , 4 spp - : "category" SCE_File_Types */
 uint32_t metadata_offset;       /* metadata offset */
 uint64_t header_length;         /* SCE file header length */
 uint64_t data_length;           /* length of encapsulated data */
} __attribute__((packed)) SCE_HDR;

Ну и для закрепления этой секции SCE Header, предлагаю посмотреть визуально смещения этих 7-ми позиций:

SCE Header.gif

SELF Header - Заголовок SELF

typedef struct {
 uint64_t header_type;           /* 3 - SELF */
 uint64_t appinfo_offset;        /* app info offset */
 uint64_t elf_offset;            /* ELF #1 offset */
 uint64_t phdr_offset;           /* program header offset */
 uint64_t shdr_offset;           /* section header offset */
 uint64_t section_info_offset;   /* section info offset */
 uint64_t sceversion_offset;     /* version offset */
 uint64_t controlinfo_offset;    /* control info offset */
 uint64_t controlinfo_length;    /* control length */
 uint64_t padding;               /* padding */
} __attribute__((packed)) SELF_HDR;

Комментарий: Реальные данные ELF расположены после заголовка SCE (см. размер заголовка). Он зашифрован, если флаг не равен 0x8000. unfself работает, вырезав заголовок SCE из (фейкового) SELF.

Визуальное отображение этих 10-ти позиций:

SELF Header.gif

App Info

typedef struct {
 uint64_t authid;                /* auth id */
 uint32_t vendor_id;             /* vendor id */
 uint32_t self_type;             /* app type
                                  * 1 level0,
                                  * 2 level1,
                                  * 3 level2,
                                  * 4 application,
                                  * 5 isolated SPU module,
                                  * 6 secure loader,
                                  * 7 unknown, handled by appldr,
                                  * 8 NPDRM app */
 uint64_t version;               /* app version */
 uint64_t padding;               /* UNKNOWN */
} __attribute__((packed)) APP_INFO;

Комментарий: Выровнено по 0x10 байт.

ELF Header - Заголовок ELF

 typedef struct {
   uint8_t e_ident[16];              /* ELF identification */
   uint16_t e_type;                  /* object file type */
   uint16_t e_machine;               /* machine type */
   uint32_t e_version;               /* object file version */
   uint64_t e_entry;                 /* entry point address */
   uint64_t e_phoff;                 /* program header offset */
   uint64_t e_shoff;                 /* section header offset */
   uint16_t e_flags;                 /* processor-specific flags */
   uint32_t e_ehsize;                /* ELF header size */
   uint16_t e_phentsize;             /* size of program header entry */
   uint16_t e_phnum;                 /* number of program header entries */
   uint16_t e_shentsize;             /* size of section header entry */
   uint16_t e_shnum;                 /* number of section header entries */
   uint16_t e_shstrndx;              /* section name string table index */
 } __attribute__((packed)) ELF;

Комментарий: смотрите спецификацию здесь: ELF Header ELF-64 Object File Format

ELF Program Headers

 typedef struct {
   uint32_t p_type;                  /* type of segment */
   uint32_t p_flags;                 /* segment attributes */
   uint64_t p_offset;                /* offset in file */
   uint64_t p_vaddr;                 /* virtual address in memory */
   uint64_t p_paddr;                 /* reserved */
   uint64_t p_filesz;                /* size of segment in file */
   uint64_t p_memsz;                 /* size of segment in memory */
   uint64_t p_align;                 /* alignment of segment */
 } __attribute__((packed)) ELF_PHDR;

Комментарий: смотрите спецификацию здесь: ELF Program Headers

ELF Section Headers

 typedef struct {
   uint32_t sh_name;                 /* section name */
   uint32_t sh_type;                 /* section type */
   uint64_t sh_flags;                /* section attributes */
   uint64_t sh_addr;                 /* virtual address in memory */
   uint64_t sh_offset;               /* offset in file */
   uint64_t sh_size;                 /* size of section */
   uint32_t sh_link;                 /* link to other section */
   uint32_t sh_info;                 /* miscellaneous information */
   uint64_t sh_addralign;            /* address alignment boundary */
   uint64_t sh_entsize;              /* size of entries, if section has table */
 } __attribute__((packed)) ELF_SHDR;

Segment Information

typedef struct {
 uint64_t offset;
 uint64_t size;
 uint32_t compressed; // 2=compressed
 uint32_t unknown1;
 uint32_t unknown2;
 uint32_t encrypted; // 1=encrypted
} __attribute__((packed)) SECTION_INFO;

SCE Version Info

typedef struct {
 uint32_t subheader_type; // 1 - sceversion
 uint32_t present;        // 0 - FALSE / 1 - TRUE
 uint32_t size;
 uint32_t unknown4;
} __attribute__((packed)) SCEVERSION_INFO;

Data

typedef struct {
 uint16 unknown_1;
 uint16 unknown_2; //0x0001
 uint32 unknown_3;
 uint32 unknown_4; //Number of sections?
 uint32 unknown_5;
 ////
   uint64 offset;    //Data offset.
   uint64 size;      //Data size.
 //// <- these are supposed to be sections
} SCE_VERSION_DATA_30;

Control Information

typedef struct {
 uint32_t type; // 1==control flags; 2==file digest; 3==npdrm
 uint32_t size;
 uint64_t next; // 1 if another Control Info structure follows 0 if not

 union {
   // type 1 0x30 bytes
   struct {
     uint32_t ctrl_flag1; // ctrl_flag  0x80000000(all?);0x40000000(root);0x20000000(dbg);0x00000000(normal?) 
     uint32_t unknown2;
     uint32_t unknown3;
     uint32_t unknown4;
     uint32_t unknown5;
     uint32_t unknown6;
     uint32_t unknown7;   // 0;8;9;0xC
     uint32_t unknown8;   // 0;1;2;4
   } control_flags;

   // type 2 0x40 bytes
   struct {
     uint8_t digest1[20]; //hash digest, same for every file
     uint8_t digest2[20]; //sha1 hash digest calculated of .elf file...
     uint64_t padding;
   } file_digest40;

   // type 2 0x30 bytes
   struct {
     uint8_t digest1[20];
     uint64_t unknown2;
   } file_digest30;

   // type 3 0x90 bytes
   struct {
     uint32_t magic;
     uint32_t unknown2;
     uint32_t license; /* license_type  1 network, 2 local, 3 free */
     uint32_t type; /* app_type  1 exec, 0x21 update */
     uint8_t content_id[48];
     uint8_t digest[16];    // sha-1 hash of debug self/sprx created with make_fself_npdrm
     uint8_t invdigest[16]; //hash_cid_fname
     uint8_t xordigest[16]; //hash_ci
     uint64_t unknown3;
     uint64_t unknown4;
   } npdrm;
 };
} __attribute__((packed)) CONTROL_INFO;

Metadata Information

typedef struct {
 uint8_t key[16];
 uint8_t key_pad[16];
 uint8_t iv[16];
 uint8_t iv_pad[16];
} __attribute__((packed)) METADATA_INFO;

Metadata Header

typedef struct {
 uint64_t signatureInputLength;
 uint32_t unknown02;            //Should be signature algorithm. It always = 1(ECDSA)
 uint32_t sectionCount;
 uint32_t keyCount;
 uint32_t optHeaderSize;
 uint32_t unknown06;
 uint32_t unknown07;
} __attribute__((packed)) METADATA_HEADER;

Комментарий:

Заголовок метаданных расположен после информации метаданных в файле SELF.
Он расшифровывается с использованием AES128CTR с помощью записей ключа и ivec из информации метаданных.
Длина входной сигнатуры - это количество байтов, которые используются для генерации SHA-1, который используется для генерации сигнатуры ECDSA. Длина должна быть от начала до самой подписи. Используется расшифрованная версия входных данных.
Это присутствует только в том случае, если присутствует метаданные.

Metadata Section Headers

typedef struct {
 uint64_t data_offset;
 uint64_t data_size;
 uint32_t type; // 1 = shdr, 2 == phdr, 3 == unknown
 uint32_t program_idx;
 uint32_t hashed; //2=yes
 uint32_t sha1_idx;
 uint32_t encrypted; // 3=yes; 1=no
 uint32_t key_idx;
 uint32_t iv_idx;
 uint32_t compressed; // 2=yes; 1=no
} __attribute__((packed)) METADATA_SECTION_HEADER;

Комментарий:

Заголовки разделов метаданных расположены после заголовка метаданных в файле SELF.
Количество разделов указывается в элементе sectionCount в заголовке метаданных.
Они дешифруются с использованием AES128CTR с помощью записей ключа и ivec из информации метаданных.
Данные разделов дешифруются с использованием AES128CTR с ключом и ivec из ключей метаданных, заданных keyIndex и ivecIndex.
Секционные данные также должны быть несжаты с использованием zlib.
ДанныеОценты заголовков секций метаданных соответствуют, в общем, данным о данных о сегментах.
Это присутствует только в том случае, если присутствует заголовок метаданных.

Section Hash

typedef struct {
 uint8_t sha1[20];
 uint8_t padding[12];
 uint8_t hmac_key[64];
} __attribute__((packed)) SECTION_HASH;

Комментарий:

Ключи метаданных (хеш раздела) расположены после заголовков раздела метаданных в файле SELF.
Количество ключей указывается в элементе keyCount в заголовке метаданных.
Они дешифруются с использованием AES128CTR с помощью записей ключа и ivec из информации метаданных.
Если sha1Index указывает на ключ, тогда ключ [sha1Index] и ключ [sha1Index + 1] образуют 160-битный хеш. Key [sha1Index + 2] на клавишу [key [sha1Index + 6] образуют 512-битный ключ для HMAC-SHA1. HMAC-SHA1 рассчитывается по дешифрованным данным и перед декомпрессией.

Capabilities Info

typedef struct {
 uint32_t Type; // 1,2
 uint32_t capabilities_size; // capabilities  Type 1 0x30, Type 2 0x100
 uint32_t next; // 1 if there is another cap flag structure after this, 0 if not
 uint32_t unknown2;
 uint64_t unknown3;
 uint64_t unknown4;
 uint64_t flags;
 uint32_t unknown6;
 uint32_t unknown7;
} __attribute__((packed)) CAPABILITIES_INFO;

Signature

typedef struct {
 uint8_t r[21];
 uint8_t s[21];
 uint8_t padding[6];
} __attribute__((packed)) SIGNATURE;

Комментарий:

Подпись находится после информации подписи в файле SELF.
Это даже присутствует, если информация подписи отсутствует.
Он расшифровывается с использованием AES128CTR с помощью записей ключа и ivec из информации метаданных.

Self Section Info

typedef struct {
 uint8_t *data;
 uint64_t size;
 uint64_t offset;
} SELF_SECTION;

ErikPshat · 03.05.2017, 05:55

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

**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** · 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.

**YAGAMI55** · 04.05.2017, 21:31

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

ErikPshat · 04.05.2017, 22:04

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

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

так что я уже стар для этого.

**YAGAMI55** · 04.05.2017, 22:48

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

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

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

так что я уже стар для этого.

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

in1975 · 06.05.2017, 06:07

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

**riku.kh3** · 06.05.2017, 08:33

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

**E2E41** · 06.08.2017, 23:50

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

ECDSA подпись в конце файла - это 0x28 байт, не считая последних 8 байт.

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

ErikPshat · 07.08.2017, 12:05

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

или эти 0x28 байт вторая половина контрольной суммы

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

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

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

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

**SergeSm** · 18.08.2017, 22:45

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

ErikPshat · 19.08.2017, 01:17

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

Предпоследние 0х28 байт можно забить любой фигней - запустится и на CFW и на OFW (если взять изначально рабочий файл), причем без пересчета контрольной суммы (что логично).

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

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

**SergeSm** · 19.08.2017, 09:55

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

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

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

**E2E41** · 19.08.2017, 14:28

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

ErikPshat · 19.08.2017, 17:47

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

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

если заменить три контрольных суммы сгенерированными из пустышки через make_npdata?

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

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

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

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

предлагаю переподписать один eboot от дисковой версии [BLUS30767] в NPDRM

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