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

[ErikPshat]

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;

[E2E41]

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

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

[ErikPshat]

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

[E2E41]

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

[ErikPshat]

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 всё по другому. Но можно подумать использовать подобный механизм.

Сообщение от ErikPshat то можно конец ELF забивать нулями настолько

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

[Strong-Men]

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

[ErikPshat]

Сообщение от Strong-Men Что такое 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

[Strong-Men]

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

[ErikPshat]

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 байт и игра не заведётся.

[Strong-Men]

Сообщение от ErikPshat А вот попробуй занулить хоть один байт из предпоследних 40 байт и игра не заведётся.

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

[E2E41]

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

[rhish777]

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

[ErikPshat]

Сообщение от rhish777 Я тут не писал, но загадку подписи ECDSA я разгадал в том году.

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

[rhish777]

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

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

[ErikPshat]

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

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

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

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

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

[rhish777]

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


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

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

[ErikPshat]

Сообщение от rhish777 ErikPshat, Вы так и не поняли что scetool предназначена для локальной подписи. Файлы же от самой сони подписаны совсем по другому.

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

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

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

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

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

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

[rhish777]

ErikPshat,
Ну блин не ужели не понятна эта формула?


rhish777 добавил 10.11.2017 в 13:05

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

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

[ErikPshat]

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

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

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

[rhish777]

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

[ErikPshat]

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

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