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

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;

**SergeSm** · 19.08.2017, 20:55

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

сори, наверное, непонятно объясняю...

**riku.kh3** · 19.08.2017, 21:35

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

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

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

ErikPshat · 19.08.2017, 21:52

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

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

HBK для HWSHP

Ну в заголовке SCE - это статичные смещения от начала файла. В Hex Workshop можешь нажать редактирование закладки и там увидишь, либо прямое смещение, либо формулу, которая делает прыжки и прибавки к смещениям. Там же, в заголовке SCE, указаны основные позиции секций, а потом в каждой секции идут свои абсолютные смещения. Поэтому сначала идёт прыжок на секцию из SCE, а затем в той секции есть свой заголовок, где указаны смещения и размеры параметров. Вообщем, никакого шаманства, чистая математика.

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

первые 16 байт после content_id[48] в NPD-секции - это просто случайный набор или все-таки контрольная сумма файла, как там и написано:
uint8_t digest[16]; // sha-1 hash of debug self/sprx created with make_fself_npdrm

Собственно этот 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 шифрованием. Эмм, не всё сразу, нужно бы мысли собрать, а для начала нужно бы дорожную карту сообразить и нарисовать библиотеку для справки и сверки.

**SergeSm** · 20.08.2017, 06:25

Сообщение от riku.kh3

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

по версиям не подскажу, а так, в последний раз использовались:
- Farming Simulator 15 [BLES02108] с патчем - заменялись предпоследние 0х28 байт в обоих EBOOT.BIN;
- Super Stardust HD [NPEA00014] скачанная отсюда - заменялись предпоследние 0х28 байт и перед ними 0х08 байт с пересчетом контрольной суммы.
Если нужно какие-то еще протестить - то особых сложностей нету, лишь бы игра была с возможностью запуска на OFW через УПД... или такую сложно найти для версии ниже 3.55? (в смысле, патч будет для более старшей версии)

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

Насчёт sha-1 hash - это вообще нужно проверить. Взять EBOOT от любого обновления (NPDRM), декриптовать его, затем зашифровать его как дебаг с помощью make_fself_npdrm, посчитать SHA-1 и сверится с этой строкой в оригинале. Дебаг - это скорее подписанный файл, но не с DRM шифрованием. Эмм, не всё сразу, нужно бы мысли собрать, а для начала нужно бы дорожную карту сообразить и нарисовать библиотеку для справки и сверки.

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

ну, это просто мои предположения, возможно проблема вовсе не в этом, тут надо бы, чтобы разобрались разбирающиеся в вопросе люди)))

P.S.: начиналось все с того, что есть игрушка After Hours Athletes [BCES01335] - в ней кроме EBOOT.BIN есть три .self файла (для каждой игры) и один из них содержится в оф.патче и работает на OFW (то есть, можно сравнить? правда она без мува не запускается). А еще есть же бесплатный singstar, правда не знаю, поможет ли он чем-нибудь. если надо - могу скачать и выложить куда-нибудь...

ErikPshat · 20.08.2017, 15:08

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

по версиям не подскажу

Ну это видно в ScetoolGui в строке FW Version.
А ты случайно не спутал, в игре есть 2 папки, папка NPEB выступает как загрузочная Bootable и оттуда происходит запуск EBOOT.BIN, а папка BLES как данные игры, поэтому, лежащий в ней EBOOT.BIN просто так лежит мёртвым грузом. Ну и конечно в обоих папках лежит один и тот же EBOOT.BIN от обновления из PSN.
В смысле, может ты только поменял предпоследние 0x28 байт у EBOOT.BIN в папке BLES?

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

плойка вряд ли будет перешифровывать игровой файл в дебаг, чтобы получить контрольную сумму...

Логично. По-моему, при шифровании в NPDRM этот ELF проходит 2 этапа. Сначала он преобразуется через make_self, а затем через make_fself.

А кто-нибудь знает утилиту, которая декриптует и вытаскивает отдельно Metadata? Потому что мы видим на выходе только чистый ELF, а секция метаданных декриптуется в памяти и остаётся невидимой глазу.

**SergeSm** · 20.08.2017, 19:41

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

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

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

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

ErikPshat · 22.08.2017, 05:39

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

ну и по-поводу переподписи до 100% совпадения... рано или поздно придется определиться, первые 16 байт после content_id[48] в NPD-секции - это просто случайный набор или все-таки контрольная сумма файла, как там и написано:

uint8_t digest[16]; // sha-1 hash of debug self/sprx created with make_fself_npdrm

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

Короче, я посмотрел на Спецификацию 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", о которой писал постом выше.
Вот я подготовил архив необходимых файлов scetool.zip (распаковать в папку ps3tools\tools\scetool) - в архиве licensee.edat, EBOOT.BIN и RAP от этой игры + оригинальный make_npdata + исправленный ScetoolGuiPSPx.exe.

Сначала декриптуете официальный EDAT следующей командой:

make_npdata -v -d licensee.edat licensee.dat 0 RAPS/EP0002-NPEB01835_00-CALLDUTYGHOSTSDL.rap

Процесс декриптовки:

Вот это официальный EDAT в хексе и выделена строка 16 байт того самого sha-1 hash

licensee.edat.png

Затем компилируете в DEBUG этот декриптованный licensee.dat в папку edat, чтобы не затёрся оригинал, вот команда:

make_npdata -v -e licensee.dat edat/licensee.edat 1 0 4 0 16

Процесс компиляции в DEBUG:

Вот такой получается файл DEBUG и внизу смотрим контрольную сумму SHA-1 (сравниваем первые 16 байт с выделением на картинке выше)
SHA-1 = 8A AA D3 DB 8C FF 18 C2 F3 0F 53 9D 58 E0 63 A2 F4 89 07 99

licensee.edat (DEBUG).png

Достаём KLicensee от игры:

**E2E41** · 22.08.2017, 15:00

так я и не понял чего не хватает чтобы подписать нужный файлик?

**riku.kh3** · 22.08.2017, 15:25

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

так я и не понял чего не хватает чтобы подписать нужный файлик?

Ключей. KaKaRoTo говорил:

The signature on the NPDRM self file uses the exact same ECDSA curve and the same key as the one used in PS3 .pkg files, so no one has (or could have) the private key for it. What this means is that, even though we finally figured out the missing piece and we now know how the NPDRM self is built, we simply cannot duplicate it.

**E2E41** · 22.08.2017, 15:54

тоесть 28 байт в конце перед хешем файла

ErikPshat · 22.08.2017, 18:52

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

так я и не понял чего не хватает чтобы подписать нужный файлик?

Ну для начала нужно восстановить по порядку правильную структуру файла.
Как я выше писал, на примере EDAT можно восстановить первую SHA-1 хеш-сумму, как у оригинала. У тебя получилось?

А вот с EBOOT.BIN и с PKG у меня пока не получилось получить из DEBUG-файла верную SHA-1 контрольную сумму.
Вот её нужно научиться правильно генерировать, чтобы пойти дальше к сходству с оригиналом. А, как я понял, всякие утилиты генерируют фейковый digest. И это уже может проверяться в экзешниках и это может быть первой ошибкой в утилите.

Маленькие официальные PKG для тестов:

**E2E41** · 22.08.2017, 21:27

почему то у меня каждый раз меняются контрольные суммы у дебаг файла

ErikPshat · 22.08.2017, 21:47

E2E41, у EDAT или у EBOOT?

Для EDAT я в этом сообщении загрузил специально комплект исправленных утилит, в частности оригинальная make_npdata, без всяких извращений. Она, при создании debug генерирует всегда один и тот же файл.

А вот утилиты для EBOOT и PKG, каким-то образом патченные и там генерируется каждый раз рандомный хеш в debug. Сейчас пытаюсь скачать с меги 4.75 SDK, чтобы вытащить официальные утилиты make_fself_npdrm и make_package_npdrm, чтобы убедиться в чистоте утилиты. Но пока не удаётся скачать через браузер, пишет типа памяти не хватает.

ErikPshat · 24.08.2017, 11:55

Короче, залил на диск официальную коллекцию утилит из СДК475 (200 MB).

P.S. Естессна они все делают DEBUG-файлы для DEX-консоли, что нам и нужно для экспериментов.
Проверил пока только EDAT с помощью make_edata_npdrm.exe - получается правильный DEBUG.

--help по командам:

Команда элементарная, по умолчанию никаких опций не надо, там автоматом подставляется block size (default 16) и --format4 (4.0.0.W), если не указывается иное:

make_edata_npdrm licensee.dat licensee.edat

Затем замеряем контрольную сумму SHA-1 и сверяем с шифрованным оригиналом в позиции 0x40.

**Strong-Men** · 03.09.2017, 18:35

Провел эксперимент с EBOOT.BIN от игры "1942: Joint Strike" занулил последние 8 байт которые являются частью контрольной суммы SHA-1 и игра отлично завелась,занулил ещё 8 байт влево пс3 выдала ошибку 80010017,удалил 8 байт таже ошибка,так что в эти 8 байт можно вписать любые значения но без этих 8 байт игра не заведётся.

ErikPshat · 03.09.2017, 22:54

Strong-Men, выходит игра проверят размер файла.

**Strong-Men** · 04.09.2017, 18:15

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

Strong-Men, выходит игра проверят размер файла.

Похоже на то,но зачем сони вставили эти фейковые 8 байт?

**E2E41** · 04.09.2017, 19:04

это число для выбора точки на эпилептической кривой(хотя могу и заблуждаться)
вот похожий механизм генерации:
https://github.com/uofw/upspd/wiki/K...multiplication

**Strong-Men** · 04.09.2017, 20:10

Можно ли сгенерировать подпись прогой sign.py по методу подписи ISO.BIN.DAT ?

**E2E41** · 04.09.2017, 20:12

сомневаюсь