Talk:SELF - SPRX: Difference between revisions
m (→Region locking) |
|||
Line 57: | Line 57: | ||
u32 unknown2; // So far always 0 | u32 unknown2; // So far always 0 | ||
u32 magic; // 0x4E504400(NPD) | u32 magic; // 0x4E504400(NPD) | ||
u32 unknown3; // 1 | u32 unknown3; // 1; 3. | ||
u32 license; // 1 - Network License; 2 - Local License; 3 - Free | u32 license; // 1 - Network License; 2 - Local License; 3 - Free | ||
u32 type; // 1 - Executable; 21 - Update for Disc Based Game | u32 type; // 1 - Executable; 21 - Update for Disc Based Game |
Revision as of 15:25, 3 January 2012
To be merged with SELF File Format and Decryption
self-capabilities flags
appldr 0x17 = 0x78 xsetting 0x17 = 0x3B
0x1B = 0x01 0x1D = 0x02
ps3swu 0x17 = 0x7B
0x1B = 0x01 0x1D = 0x11 0x1E = 0x60
lv2 0x17 = 0x7B
0x1B = 0x01
lv1 0x17 = 0x7B
0x1B = 0x01
libfs 0x17 = 0x7B
0x1B = 0x01
icolaunch0x17 = 0x3B
0x1B = 0x01 0x1D = 0x04
hddcopy 0x17 = 0x7B
0x1B = 0x01 0x1D = 0x08
flowers 0x17 = 0x3B
0x1B = 0x01 0x1E = 0x20
fdm_spu 0x17 = 0x38 emu_drm 0x17 = 0x3B
0x1D = 0x02
bdj 0x0F = 0x01
0x17 = 0x27 0x1D = 0x02
0x0C = 0x00000001 0x14 = 0x00000038 / 0x0000003B / 0x00000078 / 0x0000007B / 0x00000027 0x18 = 0x00000001 0x1C = 0x00002000 / 0x00020000 / 0x00040000 / 0x00080000 / 0x00116000
0x14:
#define CAP_FLAG_REFTOOL 0x08 #define CAP_FLAG_DEBUG 0x10 #define CAP_FLAG_RETAIL 0x20 #define CAP_FLAG_SYSDBG 0x40
Some more cap flags: http://pastie.org/3090973 and http://pastie.org/3090976 (appldr 356 white(?)list)
NPDRM Header
typedef struct { u32 block_type; // this is 3(NPDRM) u32 block_size; // this is 0x90(sizeof(Self_NPDRM)) u32 unknown1; // So far always 0 u32 unknown2; // So far always 0 u32 magic; // 0x4E504400(NPD) u32 unknown3; // 1; 3. u32 license; // 1 - Network License; 2 - Local License; 3 - Free u32 type; // 1 - Executable; 21 - Update for Disc Based Game u8 titleid[0x30]; u8 hash_unknown[0x10]; u8 hash1[0x10]; u8 hash2[0x10]; u8 padding[0x10]; } Self_NPDRM
Located after the Self Control Info.
App Info header:
Aligned to 0x10 bytes.
field | offset | type | notes |
---|---|---|---|
authid | 0x00 | u64 | |
unknown | 0x08 | u32 | |
app_type | 0x0c | u32 |
|
app_version | 0x10 | u64 |
Appinfo offset 0x08
for some reason named vendor_id there.
In geo makeself it was used as: set_u32(&(output_self_info_header.i_magic), 0x01000002);
Not directly related to Authentication IDs, but seems to have many simularities with it, seems also related to SM ; LPAR's and their order suggests hierarchy/permission from high (can do everything) to low (lesser abilities).
'vendorid' | count | filetype |
---|---|---|
0xff000000 | 16 | lv1.self's |
0x07000001 | 180 | iso spu self's |
0x05000002 | 17 | lv2_kernel.self's |
0x02000003 | 45 | ps2_emu self's |
0x01000002 | 6147 | CoreOs / dev_flash files |
Encrypted phdr offset entry
There is one of these entries for each phdr entry in the elf file so that the ps3 knows where to decrypt the data from. (because it might also be compressed.)
field | offset | type | notes |
---|---|---|---|
Encrypted Data Offset | 0x00 | u64 | |
Encrypted Data Size | 0x08 | u64 | |
unknown | 0x10 | u32 | This has been 1 in all the examples I have seen. |
unknown | 0x14 | u32 | Always 0, as far as I know. |
unknown | 0x18 | u32 | Always 0, as far as I know. |
unknown | 0x1c | u32 | This is 2 for loadable segment types, and 0 for other types. |
Meta Checksums
There are 3 checksums at the offset specified by meta_offset.
- The first is the sha1 checksum of the entire self file.
- The 2nd checksum is the inverse of the first checksum.
- The 3rd checksum is the first checksum XORed with 0xAAAAAA..AAAAAB
The PSJailbreak payload ignores the actual checksums, but checks that the 3rd checksum is the 2nd checksum XORed with 0xAAAAAA..AAAAAB
SDK Flags added
field | offset | type | notes |
---|---|---|---|
Magic | 0x0 | u32 | Must be "SCE\0" |
version | 0x4 | u32 | This must be 2 or the Self loader will abort |
flags | 0x8 | u16 |
0001: FW 1.00 (app version 1.0.0) ... 0001: FW 3.15 (app version 3.15.0) 0001: FW 3.20 (app version 3.20.0) 0001: FW 3.21 (app version 3.21.0) 0001: FW 3.30 (app version 3.30.0) 0004: FW 3.40 (app version 3.40.0) 0004: FW 3.41 (app version 3.40.0) 0004: FW 3.42 (app version 3.40.0) 0007: FW 3.50 (app version 3.55.0) 000a: FW 3.55 (app version 3.55.0) 000d: FW 3.56 (app version 3.56.0) 0010: FW 3.60 (app version 3.60.0) 0010: FW 3.61 (app version 3.61.0) 0013: FW 3.65 (app version 3.65.0) 0013: FW 3.66 (app version 3.66.0) 0016: FW 3.70 (app version 3.70.0) 0016: FW 3.72 (app version 3.70.0) 0016: FW 3.73 (app version 3.73.0) |
Region locking
SELF or SFO? http://www.ps3devwiki.com/index.php?title=File:Badregion-4.jpg
moved from old talk page
Talk:Signed Executable and Linkable Format (SELF)
nas_plugin.sprx
SELF 00000000 53 43 45 00 00 00 00 02 00 04 00 01 00 00 02 40 |SCE............@| magic SCE - version=2 - flags=4 - type=1=self - meta_offset=0x240 00000010 00 00 00 00 00 00 05 80 00 00 00 00 00 06 4d 58 |..............MX| header_len=0x580 - elf filesize=0x64d58 00000020 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 70 |...............p| unknown=3 - appinfo_offset=0x70 00000030 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 d0 |................| elf_offset=0x90 - phdr_offset = 0xd0 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 80 |................| shdr_offset=0x00 - section_info_offset=0x180 00000050 00 00 00 00 00 00 01 e0 00 00 00 00 00 00 01 f0 |................| sceversion_offset=0x1e0 - controlinfo_offset=0x1f0 00000060 00 00 00 00 00 00 00 70 00 00 00 00 00 00 00 00 |.......p........| controlinfo_size=0x70 - unknown=0 APP INFO: 00000070 10 70 00 00 52 00 00 01 01 00 00 02 00 00 00 04 |.p..R...........| authid - unknown 00000080 00 03 00 40 00 00 00 00 00 00 00 00 00 00 00 00 |...@............| programversion=0x030040 - unknown ELF: 00000090 7f 45 4c 46 02 02 01 66 00 00 00 00 00 00 00 00 |.ELF...f........| ident 000000a0 ff a4 00 15 00 00 00 01 00 00 00 00 00 00 00 00 |................| type=0xffa4 - machine=0x15 - version=1 - entry_point=0x00 000000b0 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 |.......@........| phdr_offset=0x40 - shdr_offset=0 000000c0 01 00 00 00 00 40 00 38 00 03 00 00 00 00 00 00 |[email protected]........| flags=0x100 - elf_header_size=0x40 - phentsize=0x38 - phnum=3 - shentsize=shnum=shstrndx=0 PHDR: 000000d0 00 00 00 01 00 40 00 05 00 00 00 00 00 00 00 f0 |.....@..........| type=1 - flags=0x400005 - offset_in_file=0xf0 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 04 5a 20 |..............Z | virtual_addr = 0x0 - physical_addr=0x45a20 000000f0 00 00 00 00 00 04 99 88 00 00 00 00 00 04 99 88 |................| segment_size=0x49988 - seg_mem_size = 0x49988 00000100 00 00 00 00 00 00 00 10 alignment=0x10 00 00 00 01 00 60 00 06 |.............`..| type=1 - flags=0x600006 00000110 00 00 00 00 00 04 9a 80 00 00 00 00 00 04 99 90 |................| offset_in_file=0x49a80 virtual_addr = 0x49990 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 39 a8 |..............9.| physical_addr=0x0 - segment_size=0x39a8 00000130 00 00 00 00 00 00 77 18 00 00 00 00 00 00 00 10 |......w.........| seg_mem_size = 0x7718 - alignment=0x10 00000140 70 00 00 a4 00 00 00 00 00 00 00 00 00 04 d4 30 |p..............0| type=0x700000a4 - flags=0x00 - offset_in_file=0x4d430 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| virtual_addr = 0x0 - physical_addr=0x0 00000160 00 00 00 00 00 01 79 28 00 00 00 00 00 00 00 00 |......y(........| segment_size=0x17928 - seg_mem_size = 0x0 00000170 00 00 00 00 00 00 00 10 alignment=0x10 00 00 00 00 00 00 00 00 |................| padding SECTION INFO: 00000180 00 00 00 00 00 00 06 70 00 00 00 00 00 02 00 17 |.......p........| offset=0x670 - size=0x20017 00000190 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 |................| compressed=2 - unknown=0 - unknown=0 - encrypted=1 000001a0 00 00 00 00 00 02 06 90 00 00 00 00 00 00 1c ac |................| offset=0x20690 - size=0x1cac 000001b0 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 |................| compressed=2 - unknown=0 - unknown=0 - encrypted=1 000001c0 00 00 00 00 00 02 23 50 00 00 00 00 00 00 4b 0c |......#P......K.| offset=0x22350 - size=0x4b0c 000001d0 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 |................| compressed=2 - unknown=0 - unknown=0 - encrypted=1 SCE VERSION INFO: 000001e0 00 00 00 01 00 00 00 00 00 00 00 10 00 00 00 00 |................| unknown=1 - unknown=0 - unknown=0x10 unknown=0 CONTROL INFO: 000001f0 00 00 00 01 00 00 00 30 00 00 00 00 00 00 00 01 |.......0........| type=1=control_flags - size=0x30 - unknown=1 00000200 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@...............| 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000220 00 00 00 02 00 00 00 40 00 00 00 00 00 00 00 00 |.......@........| type=2=file_digest - size=0x40 - unknown0 00000230 62 7c b1 80 8a b9 38 e3 2c 8c 09 17 08 72 6a 57 |b|....8.,....rjW| digest1 ## metadata info: unknown 00000240 9e 25 86 e4 70 99 02 ae b8 65 22 59 09 70 2f ed |.%..p....e"Y.p/.| digest1 (4 bytes) - digest2 00000250 cb da 56 87 a5 24 54 8e 00 00 00 00 00 00 00 00 |..V..$T.........| digest2 - padding METADATA INFO: 00000260 e6 18 5e 1c 6b 3f 6c 6a 75 47 5d a4 f9 b1 3d 78 |..^.k?ljuG]...=x| key 00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| key 00000280 d2 5a 0b 9a 13 fe 60 ca a9 2b 90 a7 f1 df 35 7c |.Z....`..+....5|| iv 00000290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| iv METADATA HEADER: 000002a0 00 00 00 00 00 00 05 00 00 00 00 01 00 00 00 03 |................| signature_input_length=0x500 - unknown=1 - section_count=3 000002b0 00 00 00 18 00 00 00 30 00 00 00 00 00 00 00 00 |.......0........| key_count=0x18 - signature_info_size=0x30 - unknown=0 - unknown=0 METADATA SECTION HEADER: 000002c0 00 00 00 00 00 00 06 70 00 00 00 00 00 02 00 17 |.......p........| data_offset=0x670 - data_size=0x20017 000002d0 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00 00 |................| unknown=2 - program_idx=0 - unknown=2 - sha1_index=0 000002e0 00 00 00 03 00 00 00 06 00 00 00 07 00 00 00 02 |................| encrypted=3=yes - key_index=6 ivec_index=7 compressed=2=yes 000002f0 00 00 00 00 00 02 06 90 00 00 00 00 00 00 1c ac |................| data_offset=0x670 - data_size=0x20017 00000300 00 00 00 02 00 00 00 01 00 00 00 02 00 00 00 08 |................| unknown=2 - program_idx=1 - unknown=2 - sha1_index=8 00000310 00 00 00 03 00 00 00 0e 00 00 00 0f 00 00 00 02 |................| encrypted=3=yes - key_index=14 ivec_index=15 compressed=2=yes 00000320 00 00 00 00 00 02 23 50 00 00 00 00 00 00 4b 0c |......#P......K.| data_offset=0x670 - data_size=0x20017 00000330 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 10 |................| unknown=2 - program_idx=2 - unknown=2 - sha1_index=10 00000340 00 00 00 03 00 00 00 16 00 00 00 17 00 00 00 02 |................| encrypted=3=yes - key_index=16 ivec_index=17 compressed=2=yes METADATA KEYS: 00000350 f8 2b ca 1f 5b 03 16 30 69 75 82 8c b4 95 76 c5 |.+..[..0iu....v.| key1 00000360 bd 03 09 ae 00 00 00 00 00 00 00 00 00 00 00 00 |................| key2 00000370 cb 18 c1 9e 44 d3 90 be db d9 6d 59 00 54 fd 30 |....D.....mY.T.0| key3 00000380 4a b4 75 27 d1 bb b7 e0 0f 5b 60 4c 8b 67 c6 da |J.u'.....[`L.g..| key4 00000390 83 98 13 bf ea 53 0f bd af 83 52 17 51 a1 74 0a |.....S....R.Q.t.| key5 000003a0 ab ea 6c 9e b9 f3 4b 8b 0a db e1 e6 96 7e 17 a6 |..l...K......~..| key6 000003b0 c6 5a c0 d3 a7 68 e1 7a 89 41 2a 32 15 73 82 1b |.Z...h.z.A*2.s..| key7 000003c0 2c e6 7f 70 62 86 6e a9 36 ec f8 99 3a d4 ed 88 |,..pb.n.6...:...| key8 000003d0 69 7a ee a0 13 64 c9 38 7d 27 88 9e 95 76 ea 4a |iz...d.8}'...v.J| key9 000003e0 2f 31 8e 13 00 00 00 00 00 00 00 00 00 00 00 00 |/1..............| key10 000003f0 cb 18 c1 9e 44 d3 90 be db d9 6d 59 00 54 fd 30 |....D.....mY.T.0| key11 00000400 4a b4 75 27 d1 bb b7 e0 0f 5b 60 4c 8b 67 c6 da |J.u'.....[`L.g..| key12 00000410 83 98 13 bf ea 53 0f bd af 83 52 17 51 a1 74 0a |.....S....R.Q.t.| key13 00000420 ab ea 6c 9e b9 f3 4b 8b 0a db e1 e6 96 7e 17 a6 |..l...K......~..| key14 00000430 c6 5a c0 d3 a7 68 e1 7a 89 41 2a 32 15 73 82 1b |.Z...h.z.A*2.s..| key15 00000440 2c e6 7f 70 62 86 6e a9 36 ec f8 99 3a d4 ed 88 |,..pb.n.6...:...| key16 00000450 ec 9a bc 91 0f 41 44 69 02 14 b2 8f bd 02 79 c4 |.....ADi......y.| key17 00000460 51 6d ac 7a 00 00 00 00 00 00 00 00 00 00 00 00 |Qm.z............| key18 00000470 cb 18 c1 9e 44 d3 90 be db d9 6d 59 00 54 fd 30 |....D.....mY.T.0| key19 00000480 4a b4 75 27 d1 bb b7 e0 0f 5b 60 4c 8b 67 c6 da |J.u'.....[`L.g..| key20 00000490 83 98 13 bf ea 53 0f bd af 83 52 17 51 a1 74 0a |.....S....R.Q.t.| key21 000004a0 ab ea 6c 9e b9 f3 4b 8b 0a db e1 e6 96 7e 17 a6 |..l...K......~..| key22 000004b0 c6 5a c0 d3 a7 68 e1 7a 89 41 2a 32 15 73 82 1b |.Z...h.z.A*2.s..| key23 000004c0 2c e6 7f 70 62 86 6e a9 36 ec f8 99 3a d4 ed 88 |,..pb.n.6...:...| key24 SIGNATURE INFO: 000004d0 00 00 00 01 00 00 00 30 00 00 00 00 00 00 00 00 |.......0........| unknown=1 - signature_size=0x30 - unknown=0 000004e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| unknown=0 - unknown=0 000004f0 00 00 00 00 00 00 00 7b 00 00 00 01 00 02 00 00 |.......{........| unknown=0 - unknown=0 00000500 00 1a 7a b5 11 0a 4a 41 2b 8e d6 8b 9e 18 1c 74 |..z...JA+......t| R[21] 00000510 58 5b 0e 94 a7 00 c2 24 cd 2d d1 1f 9b e2 81 71 |X[.....$.-.....q| R (5 bytes) - S[21] 00000520 dc 45 22 83 db 9e 72 38 2f 94 00 00 00 00 00 00 |.E"...r8/.......| S (10 bytes) - padding 00000530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 00000540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 00000550 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 00000560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 00000570 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding ENCRYPTED ELF HEADER?: 00000580 36 2a 61 73 99 41 75 19 cc a7 42 22 fb f4 b5 cc |6*as.Au...B"....| 00000590 68 06 c7 c1 7e b3 8d 49 d5 41 a7 ec b7 07 02 3b |h...~..I.A.....;| 000005a0 b9 db ca 53 04 fb 64 b9 e8 82 f4 3c 58 13 60 0d |...S..d....<X.`.| 000005b0 97 80 25 f5 13 a7 1b 09 35 e5 dd 9a 56 79 b2 a3 |..%.....5...Vy..| 000005c0 ba c9 fb f2 f6 10 47 22 f2 a7 94 a9 06 b8 68 7b |......G"......h{| 000005d0 f6 3d 07 5b 29 51 e6 70 12 17 93 8e c8 01 bb 80 |.=.[)Q.p........| 000005e0 8d f6 c1 93 94 60 51 0c 76 43 99 4a dd 26 1a 56 |.....`Q.vC.J.&.V| 000005f0 4d ba 8d be df 91 70 93 46 ca b2 2d 67 24 5f 40 |M.....p.F..-g$_@| 00000600 ba 4d 92 b2 f0 c7 c8 67 92 f4 fe 24 ba 42 4d 90 |.M.....g...$.BM.| 00000610 9c 93 b9 9d 01 4a dc 4d 99 95 8d e9 92 97 2e ed |.....J.M........| 00000620 8d 82 a4 0a 19 5b 85 3d 53 cf 24 a3 61 50 5f 42 |.....[.=S.$.aP_B| 00000630 a6 44 78 67 29 f5 ae 04 55 fd 7a cd fe 63 d9 63 |.Dxg)...U.z..c.c| 00000640 e4 18 95 0c 65 e5 22 a6 ba 8b fe ca a5 2e 0f 77 |....e."........w| 00000650 b7 3b c3 7b 81 03 72 67 f3 7c 16 68 ab 05 30 78 |.;.{..rg.|.h..0x| 00000660 d4 dc 5e 11 30 d5 cf 1a 55 fe 65 94 f9 18 b9 ab |..^.0...U.e.....| PROGRAM SECTION 0: 00000670 78 9c e4 bd 0f 7c 54 d5 99 3f 7c ce bd 13 92 00 |x....|T..?|.....| 00000680 6a d0 a0 a1 24 90 00 76 c1 60 89 5b ec 6f 62 82 |j...$..v.`.[.ob.| 00000690 4e 14 f7 73 31 d8 37 76 61 8d 8a ed 84 40 37 29 |N..s1.7va....@7)| [....] 00020670 4b e6 31 a2 f7 0a 34 bf 4e cb 29 8c 61 c8 0a 22 |K.1...4.N.).a.."| 00020680 f7 ff 01 c0 d7 e4 42 bc 3f 7a 48 af 45 ef 28 3a |......B.?zH.E.(:| PROGRAM SECTION 1: 00020690 78 9c d5 9a 8d 5f d5 e5 dd c7 7f e7 9c 9f 0e 2d |x...._.........-| 000206a0 8b 9a 95 36 2b d7 50 f1 91 c3 83 88 88 82 8a 8a |...6+.P.........| 000206b0 8a 8a 0f 6b 6c b3 3b 89 07 41 11 f0 80 0a 8a 0a |...kl.;..A......| [...] 00022330 4e bb 13 f9 17 07 fd 1f 90 b6 10 8a bc 3f 7a 48 |N............?zH| 00022340 af 45 ef 28 3a 05 98 10 3f e8 79 3a da 48 d5 2c |.E.(:...?.y:.H.,| PROGRAM SECTION 2: 00022350 78 9c 75 bd 7b b4 9d f5 79 df b9 cf d1 91 10 12 |x.u.{...y.......| 00022360 11 ba 9c fb f5 3d f7 fb fd 0e 42 da a0 2b e8 82 |.....=....B..+..| 00022370 84 24 74 01 27 1b 73 13 08 1b 01 02 24 ae 5b 20 |.$t.'.s.....$.[ | 00022380 09 64 0b 24 21 01 72 4d d2 9d c4 ed f2 4c 3d 0d |.d.$!.rM.....L=.| [...] 00026e20 5d f5 3c 0f 1e ea eb 59 99 79 f0 f0 6d d7 21 fa |].<....Y.y..m.!.| 00026e30 e1 d5 7a ff 61 1e 3c 7c 5b eb 6b 1e 3c 7c db 75 |..z.a.<|[.k.<|.u| 00026e40 08 1e 7e cd be 61 fe b0 5a df bf 9e 2f e0 73 b2 |..~..a..Z.../.s.| 00026e50 d2 d1 0f 0f be fa ff 01 59 ad 0c 11 |........Y...| 00026e5c
lv2_kernel.self
SELF: 00000000 53 43 45 00 00 00 00 02 00 00 00 01 00 00 01 e0 |SCE.............| magic SCE - version=2 - flags=0 - type=1=self - meta_offset=0x1e0 00000010 00 00 00 00 00 00 05 00 00 00 00 00 00 35 93 98 |.............5..| header_len=0x500 - elf filesize=0x359398 00000020 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 70 |...............p| unknown=3 - appinfo_offset=0x70 00000030 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 d0 |................| elf_offset=0x90 - phdr_offset = 0xd0 00000040 00 00 00 00 00 17 47 58 00 00 00 00 00 00 01 40 |......GX.......@| shdr_offset=0x174758 - section_info_offset=0x140 00000050 00 00 00 00 00 00 01 80 00 00 00 00 00 00 01 90 |................| sceversion_offset=0x180 - controlinfo_offset=0x190 00000060 00 00 00 00 00 00 00 70 00 00 00 00 00 00 00 00 |.......p........| controlinfo_size=0x70 - unknown=0 APP INFO: 00000070 10 50 00 00 03 00 00 01 05 00 00 02 00 00 00 03 |.P..............| authid - unknown 00000080 00 03 00 55 00 00 00 00 00 00 00 00 00 00 00 00 |...U............|programversion=0x030055 - unknown ELF: 00000090 7f 45 4c 46 02 02 01 66 00 00 00 00 00 00 00 00 |.ELF...f........| ident 000000a0 00 02 00 15 00 00 00 01 80 00 00 00 00 00 01 00 |................| type=0x02 - machine=0x15 - version=1 - entry_point=0x8000000000000100 000000b0 00 00 00 00 00 00 00 40 00 00 00 00 00 35 90 d8 |[email protected]..| phdr_offset=0x40 - shdr_offset=0x3590d8 000000c0 00 00 00 00 00 40 00 38 00 02 00 40 00 0b 00 0a |[email protected]...@....| flags=0x0 - elf_header_size=0x40 - phentsize=0x38 - phnum=2 - shentsize=0x40 - shnum=11 shstrndx=10 PHDR: 000000d0 00 00 00 01 00 00 00 05 00 00 00 00 00 01 00 00 |................| type=1 - flags=0x5 - offset_in_file=0x10000 000000e0 80 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 |................| virtual_addr=0x8000000000000000 - physical_addr=0x8000000000000000 000000f0 00 00 00 00 00 33 29 48 00 00 00 00 00 33 29 48 |.....3)H.....3)H| segment_size=0x332948 - seg_mem_size = 0x332948 00000100 00 00 00 00 00 01 00 00 alignment=0x10000 00 00 00 01 00 00 00 06 |................| type=1 - flags=0x6 00000110 00 00 00 00 00 34 29 80 80 00 00 00 00 33 29 80 |.....4)......3).| offset_in_file=0x342980 - virtual_addr=0x8000000000332980 00000120 80 00 00 00 00 33 29 80 00 00 00 00 00 01 67 10 |.....3).......g.| physical_addr=0x8000000000332980 - segment_size=0x16710 00000130 00 00 00 00 00 13 23 e0 00 00 00 00 00 01 00 00 |......#.........| seg_mem_size=0x1323e0 - alignment=0x10000 SECTION INFO: 00000140 00 00 00 00 00 01 05 00 00 00 00 00 00 15 e8 cf |................| offset=0x10500 - size=0x15e8cf 00000150 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 |................| compressed=2 - unknown=0 - unknown=0 - encrypted=1 00000160 00 00 00 00 00 16 ee 10 00 00 00 00 00 00 58 ff |..............X.| offset=0x16ee10 - size=0x58ff 00000170 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 |................| compressed=2 - unknown=0 - unknown=0 - encrypted=1 SCE VERSION INFO: 00000180 00 00 00 01 00 00 00 00 00 00 00 10 00 00 00 00 |................| unknown=1 - unknown=0 - unknown=0x10 unknown=0 CONTROL INFO: 00000190 00 00 00 01 00 00 00 30 00 00 00 00 00 00 00 01 |.......0........| type=1=control_flags - size=0x30 - unknown=1 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001c0 00 00 00 02 00 00 00 40 00 00 00 00 00 00 00 00 |.......@........| type=2=file_digest - size=0x40 - unknown0 000001d0 62 7c b1 80 8a b9 38 e3 2c 8c 09 17 08 72 6a 57 |b|....8.,....rjW| digest1 ## metadata info: unknown 000001e0 9e 25 86 e4 db 07 41 be 58 79 52 c4 5c 72 aa a9 |.%....A.XyR.\r..| digest1 (4 bytes) - digest2 000001f0 15 bf a6 78 b2 6a 71 f2 00 00 00 00 00 00 00 00 |...x.jq.........| digest2 - padding METADATA INFO: 00000200 f3 f3 d1 7d 4d d1 54 0f 1c 83 7a 1f d2 ba 4a f8 |...}M.T...z...J.| key 00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| key 00000220 ab 43 41 53 e8 2e 40 43 63 2b 44 6d 47 12 bb 83 |.CAS..@Cc+DmG...| iv 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| iv METADATA HEADER: 00000240 00 00 00 00 00 00 04 80 00 00 00 01 00 00 00 03 |................| signature_input_length=0x480 - unknown=1 - section_count=3 00000250 00 00 00 16 00 00 00 30 00 00 00 00 00 00 00 00 |.......0........| key_count=0x16 - signature_info_size=0x30 - unknown=0 - unknown=0 METADATA SECTION HEADER: 00000260 00 00 00 00 00 01 05 00 00 00 00 00 00 15 e8 cf |................| data_offset=0x10500 - data_size=0x15e8cf 00000270 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00 00 |................| unknown=2 - program_idx=0 - unknown=2 - sha1_index=0 00000280 00 00 00 03 00 00 00 06 00 00 00 07 00 00 00 02 |................| encrypted=3=yes - key_index=6 ivec_index=7 compressed=2=yes 00000290 00 00 00 00 00 16 ee 10 00 00 00 00 00 00 58 ff |..............X.| data_offset=0x16ee10 - data_size=0x58ff 000002a0 00 00 00 02 00 00 00 01 00 00 00 02 00 00 00 08 |................| unknown=2 - program_idx=1 - unknown=2 - sha1_index=8 000002b0 00 00 00 03 00 00 00 0e 00 00 00 0f 00 00 00 02 |................| encrypted=3=yes - key_index=14 ivec_index=15 compressed=2=yes 000002c0 00 00 00 00 00 17 47 58 00 00 00 00 00 00 02 c0 |......GX........| data_offset=0x174758 - data_size=0x2c0 000002d0 00 00 00 01 00 00 00 03 00 00 00 02 00 00 00 10 |................| unknown=1 - program_idx=3 - unknown=2 - sha1_index=16 000002e0 00 00 00 01 ff ff ff ff ff ff ff ff 00 00 00 01 |................| encrypted=1=no - key_index=-1 ivec_index=-1 compressed=1=no METADATA KEYS: 000002f0 a0 40 36 6b 2d 8a 50 99 1e b3 0c 53 e5 9b 5d 6e |[email protected]..]n| key1 00000300 61 2c ac b8 00 00 00 00 00 00 00 00 00 00 00 00 |a,..............| key2 00000310 a0 79 91 e9 66 93 d8 d0 cc 57 c7 da c5 7d df 40 |.y..f....W...}.@| key3 00000320 78 d3 5a 96 be 8d 67 10 44 0b 4a 2d 8e cc a0 61 |x.Z...g.D.J-...a| key4 00000330 28 18 04 78 21 95 6b 69 2c d1 35 1f 69 a3 52 5f |(..x!.ki,.5.i.R_| key5 00000340 97 1c 93 d8 99 52 2a 91 e4 3a b5 10 26 14 df 44 |.....R*..:..&..D| key6 00000350 b7 f9 6f 37 6f 86 f2 96 0d e5 92 ba 45 93 2f ee |..o7o.......E./.| key7 00000360 53 6e 64 e9 ac 34 53 b6 85 57 4b 8e f8 9b 78 91 |Snd..4S..WK...x.| key8 00000370 30 7a 7b df 71 a5 95 ba 4a 2a 37 90 92 15 25 e6 |0z{.q...J*7...%.| key9 00000380 ef 65 b9 ee 00 00 00 00 00 00 00 00 00 00 00 00 |.e..............| key10 00000390 a0 79 91 e9 66 93 d8 d0 cc 57 c7 da c5 7d df 40 |.y..f....W...}.@| key11 000003a0 78 d3 5a 96 be 8d 67 10 44 0b 4a 2d 8e cc a0 61 |x.Z...g.D.J-...a| key12 000003b0 28 18 04 78 21 95 6b 69 2c d1 35 1f 69 a3 52 5f |(..x!.ki,.5.i.R_| key13 000003c0 97 1c 93 d8 99 52 2a 91 e4 3a b5 10 26 14 df 44 |.....R*..:..&..D| key14 000003d0 b7 f9 6f 37 6f 86 f2 96 0d e5 92 ba 45 93 2f ee |..o7o.......E./.| key15 000003e0 53 6e 64 e9 ac 34 53 b6 85 57 4b 8e f8 9b 78 91 |Snd..4S..WK...x.| key16 000003f0 5e a2 e9 83 2d a2 4a 14 ce 8c 6f 9c 31 b1 4f 3f |^...-.J...o.1.O?| key17 00000400 f0 73 f2 d8 00 00 00 00 00 00 00 00 00 00 00 00 |.s..............| key18 00000410 a0 79 91 e9 66 93 d8 d0 cc 57 c7 da c5 7d df 40 |.y..f....W...}.@| key19 00000420 78 d3 5a 96 be 8d 67 10 44 0b 4a 2d 8e cc a0 61 |x.Z...g.D.J-...a| key20 00000430 28 18 04 78 21 95 6b 69 2c d1 35 1f 69 a3 52 5f |(..x!.ki,.5.i.R_| key21 00000440 97 1c 93 d8 99 52 2a 91 e4 3a b5 10 26 14 df 44 |.....R*..:..&..D| key22 SIGNATURE INFO: 00000450 00 00 00 01 00 00 00 30 00 00 00 00 00 00 00 00 |.......0........| unknown=1 - signature_size=0x30 - unknown=0 00000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| unknown=0 - unknown=0 00000470 00 00 00 00 00 00 00 7b 00 00 00 01 00 00 00 00 |.......{........| unknown=7b - unknown=0x100 - unknown=0 SIGNATURE: 00000480 00 c6 39 a4 4e b4 3f d9 b5 dd 06 f2 e3 b0 88 5e |..9.N.?........^| R[21] 00000490 5d 7a d9 ee a5 00 5f 33 6a ff c2 8b 70 eb cf 50 |]z...._3j...p..P| R (5 bytes) - S[21] 000004a0 2e b8 07 36 2e db 37 5b db f4 00 00 00 00 00 00 |...6..7[........| S (10 bytes) - padding 000004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 000004c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 000004e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding 000004f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| padding ENCRYPTED ELF HEADER?: 00000500 36 2a 61 73 99 41 75 19 cc a7 42 22 fb f4 b5 cc |6*as.Au...B"....| 00000510 41 7a bf 27 c8 f6 c1 13 7c f3 d2 03 e9 67 35 09 |Az.'....|....g5.| 00000520 40 21 6b b8 81 9f 69 fa 7d 8a 1b 29 b1 8c 97 23 |@!k...i.}..)...#| 00000530 f9 ff e3 dc 3e 82 91 f9 78 28 f8 2b e4 b4 ee 69 |....>...x(.+...i| [...] 000104c0 94 68 af d6 3f 1d 1d ce fa b8 75 92 e8 c2 54 da |.h..?.....u...T.| 000104d0 5a 32 f2 44 c1 f8 72 66 5f 8f ac ae 1e d1 43 8d |Z2.D..rf_.....C.| 000104e0 f6 5b bb 24 91 f7 9c 1b f5 6b cc ca 89 93 8c c4 |.[.$.....k......| 000104f0 bc b4 de ed 70 36 4d 22 f4 3f 71 27 03 e1 28 b4 |....p6M".?q'..(.| PROGRAM SECTION 0: 00010500 78 9c ec bd 0f 7c 54 d5 9d 37 fc bb 93 49 32 01 |x....|T..7...I2.| 00010510 5c 43 3b d6 28 ff 06 c1 32 01 6a 62 45 3b 31 01 |\C;.(...2.jbE;1.| 00010520 26 82 f5 42 60 37 56 2c 58 b5 9d 08 b6 a0 f6 f3 |&..B`7V,X.......| 00010530 a0 8b dd 8b 99 61 26 10 dd 50 e9 fb 84 aa db a0 |.....a&..P......| 00010540 01 87 0a 14 56 7d 16 1f a9 a2 05 0c fe 61 a1 ea |....V}.......a..| [...] 0016edd0 3f 7a 48 af 45 ef 28 3a 05 98 10 3f e8 79 3a da |?zH.E.(:...?.y:.| 0016ede0 48 d5 2c 75 e5 4d 70 57 a4 1e b5 ae 32 16 6e 57 |H.,u.MpW....2.nW| 0016edf0 5c 26 d6 4f c4 90 0b 9a 87 4f 85 43 68 76 ca 8b |\&.O.....O.Chv..| 0016ee00 e0 0f fd 68 eb 4b de e0 2d 3f 4e 8d 02 ce a2 37 |...h.K..-?N....7| PROGRAM SECTION 1: 0016ee10 78 9c ed 9d 09 5c 54 55 fb f8 ef b0 09 8a 0a ae |x....\TU........| 0016ee20 b8 8f 3a 2a 29 0e 33 30 22 ee 93 6d 53 b9 a0 59 |..:*).30"..mS..Y| 0016ee30 e1 92 82 82 82 2b 89 0b 9a cb a8 2d 96 a9 98 4b |.....+.....-...K| 0016ee40 a6 65 94 96 64 6e f5 a6 99 2d 8e a9 89 b9 61 ae |.e..dn...-....a.| 0016ee50 65 1a 5a 9a 5a 99 bb b8 ff 0f de ef 45 e6 32 17 |e.Z.Z.......E.2.| 0016ee60 06 93 de de ff af f9 38 3e f7 dc 7b ce 73 9e fd |.......8>..{.s..| [...] 00174710 e4 12 72 5f 3d 18 15 7b 9f fc 9d ea 2e 55 67 c0 |..r_=..{.....Ug.| 00174720 5a 73 60 83 ab 41 23 a0 ad c1 7c ba 3a 40 c9 63 |Zs`..A#...|.:@.c| 00174730 c0 f7 38 5e 58 42 f7 dc 77 74 4d 53 b3 0b 19 22 |..8^XB..wtMS..."| 00174740 f6 70 4d 22 d6 fc 11 51 9b 20 81 e7 81 09 cb 82 |.pM"...Q. ......| 00174750 f9 71 76 a4 3b 02 cd 10 SECTION HEADERS 3: 00 00 00 00 00 00 00 00 | ........| name_idx=0x00 type=0x0=unused 00174760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| flags=0 - virtual_addr=0x00 00174770 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| offset_in_file=0x00 - size=0x00 00174780 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| link=0 - info=0 - addr_align=0x00 00174790 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 0b 00 00 00 01 |................| name_idx=0xb type=1=progbits 001747a0 00 00 00 00 00 00 00 07 80 00 00 00 00 00 00 00 |................| flags=0x7 - virtual_addr=0x8000000000000000 001747b0 00 00 00 00 00 01 00 00 00 00 00 00 00 00 30 28 |..............0(| offset_in_file=0x10000 - size=0x3028 001747c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |................| link=0 - info=0 - addr_align=0x04 001747d0 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 11 00 00 00 01 |................| name_idx=0x11 type=1=progbits 001747e0 00 00 00 00 00 00 00 06 80 00 00 00 00 00 30 80 |..............0.| flags=0x6 - virtual_addr=0x8000000000003080 001747f0 00 00 00 00 00 01 30 80 00 00 00 00 00 2b 87 04 |......0......+..| offset_in_file=0x13080 - size=0x2b8704 00174800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |................| link=0 - info=0 - addr_align=0x04 00174810 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 17 00 00 00 01 |................| name_idx=0x17 type=1=progbits 00174820 00 00 00 00 00 00 00 02 80 00 00 00 00 2b b7 90 |.............+..| flags=0x2 - virtual_addr=0x80000000002bb790 00174830 00 00 00 00 00 2c b7 90 00 00 00 00 00 02 41 9c |.....,........A.| offset_in_file=0x2cb790 - size=0x2419c 00174840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................| link=0 - info=0 - addr_align=0x08 00174850 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 1f 00 00 00 01 |................| name_idx=0x1f type=1=progbits 00174860 00 00 00 00 00 00 00 03 80 00 00 00 00 2d f9 30 |.............-.0| flags=0x3 - virtual_addr=0x80000000002df930 00174870 00 00 00 00 00 2e f9 30 00 00 00 00 00 00 00 80 |.......0........| offset_in_file=0x2ef930 - size=0x80 00174880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................| link=0 - info=0 - addr_align=0x08 00174890 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 26 00 00 00 01 |...........&....| name_idx=0x26 type=1=progbits 001748a0 00 00 00 00 00 00 00 03 80 00 00 00 00 2d f9 b0 |.............-..| flags=0x3 - virtual_addr=0x80000000002df9b0 001748b0 00 00 00 00 00 2e f9 b0 00 00 00 00 00 00 5f 10 |.............._.| offset_in_file=0x2ef9b0 - size=0x5f10 001748c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................| link=0 - info=0 - addr_align=0x01 001748d0 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 2c 00 00 00 01 |...........,....| name_idx=0x2c type=1=progbits 001748e0 00 00 00 00 00 00 00 03 80 00 00 00 00 2e 58 c0 |..............X.| flags=0x3 - virtual_addr=0x80000000002e58c0 001748f0 00 00 00 00 00 2f 58 c0 00 00 00 00 00 04 2c 78 |...../X.......,x| offset_in_file=0x2f58c0 - size=0x42c78 00174900 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................| link=0 - info=0 - addr_align=0x08 00174910 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 31 00 00 00 01 |...........1....| name_idx=0x31 type=1=progbits 00174920 00 00 00 00 00 00 00 03 80 00 00 00 00 32 85 40 |.............2.@| flags=0x3 - virtual_addr=0x8000000000328540 00174930 00 00 00 00 00 33 85 40 00 00 00 00 00 00 a4 08 |.....3.@........| offset_in_file=0x338540 - size=0xa408 00174940 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................| link=0 - info=0 - addr_align=0x08 00174950 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 36 00 00 00 01 |...........6....| name_idx=0x36 type=1=progbits 00174960 00 00 00 00 00 00 00 03 80 00 00 00 00 33 29 80 |.............3).| flags=0x3 - virtual_addr=0x8000000000332980 00174970 00 00 00 00 00 34 29 80 00 00 00 00 00 01 67 10 |.....4).......g.| offset_in_file=0x342980 - size=0x16710 00174980 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 |................| link=0 - info=0 - addr_align=0x80 00174990 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 3c 00 00 00 08 |...........<....| name_idx=0x3c - type=8=nobits 001749a0 00 00 00 00 00 00 00 03 80 00 00 00 00 34 90 90 |.............4..| flags=0x3 - virtual_addr=0x8000000000349090 001749b0 00 00 00 00 00 35 90 90 00 00 00 00 00 11 bc d0 |.....5..........| offset_in_file=0x359090 - size=0x11bcd0 001749c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 |................| link=0 - info=0 - addr_align=0x8000 001749d0 00 00 00 00 00 00 00 00 entries_size=0x00 00 00 00 01 00 00 00 03 |................| name_idx=0x1 - type=3=strtable 001749e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| flags=0x00 - virtual_addr=0x00 001749f0 00 00 00 00 00 35 90 90 00 00 00 00 00 00 00 41 |.....5.........A| 00174a00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 |................| link=0 - info=0 - addr_align=0x01 00174a10 00 00 00 00 00 00 00 00 |........| entries_size=0x00 00174a18
NPDRM Self algorithm
THIS DOES NOT ALLOW TO OBTAIN 3.60+ keys, nor piracy as you require the rif, act.dat and IDPS
On NPDRM self decryption all the security levels of the PS3 are involved: user space (vsh), kernel space(lv2), hypervisor( lv1) and isolated SPU (metldr + appldr)
The process start on vsh.elf...
VSH
Once the vsh detects that user is trying to start a self, it looks for the appinfo header type. If the type is 8, then the control digest element type 3 (NPD element) is located. From this NPD header the vsh gets the license type (free, local or network license).
If a free content(type 3) is detected then a generic klicense will be use for further steps (go to LV2). That klicensee is already public (see geohot npdrm_omac_key_1).
npdrm_omac_key1 : 72F990788F9CFF745725F08E4C128387 # ps3publictools/include/oddkeys.h npdrm_omac_key2 : 6BA52976EFDA16EF3C339FB2971E256B # ... npdrm_omac_key3 : 9B515FEACF75064981AA604D91A54E97 # ...
However if a paid content is to be loaded the vsh loads the act.dat and the rif associated to the content (if local it will locate a file with the same titleid on NPD element, if remote it will download to vsh process memory)
Then the signature is checked (last 0x28 bytes of both RIF and act.dat). The curves used are on vsh.self. It is a 3 element table, having the first curve nulled. The curve index for rif/act is 2. The curve values are negated as in the apploader and has the following structure
struct curve { uint8_t p[0x14]; uint8_t a[0x14]; uint8_t b[0x14]; uint8_t N[0x14]; uint8_t Gx[0x14]; uint8_t Gy[0x14]; }
If the curve checks then vsh will process the rif:
struct rif { uint8_t unk1[0x10]; //version, license type and user number uint8_t titleid[0x30]; //Content ID uint8 padding[0xC]; //Padding for randomness uint32_t actDatIndex; //Key index on act.dat between 0x00 and 0x7F uint8 key[0x10]; //encrypted klicensee uint64_t start_timestamp; // timestamp of when the content was bought uint64_t expire_timestamp; // timestamp for expiration of content (PS+ for example) uint8_t rs[0x28]; };
struct ACTDAT { uint8_t unk1[0x10]; //Version, User number uint8_t keyTable[0x800]; //Key Table ...... uint8_t signature[0x28]; }
Using the RIF_KEY it will obtain the actdatIndex:
AES_KEY rifKey; uint8_t rif_key[0x10] = { 0xda, 0x7d, 0x4b, 0x5e, 0x49, 0x9a, 0x4f, 0x53, 0xb1, 0xc1, 0xa1, 0x4a, 0x74, 0x84, 0x44, 0x3b }; int result = AES_set_decrypt_key(rif_key, 0x80, &rifKey); AES_decrypt(&rif->padding, &rif->padding, &rifKey);
And finally having the actDat key index the execution pass to LV2 syscall 471
LV2
Lv2 is accessed using syscall471 which haves the following syntax:
int syscall_471(uint32_t type, char* titleID, void* klicensee, uint8_t* actdat, uint8_t* rif, int32_t licenseType, uint8_t* magicVersion);
The function has different parameters depending if the content is debug, free or paid:
FREE: syscall471(npd.type, &npd.titleID, freeklicensee, NULL, NULL, npd.license, &npd); PAID: syscall471(npd.type, &npd.titleID, NULL, &actdat.keyTable[rif.actDatIndex], &rif.key, npd.license, &npd);
The lv2 keeps a memory table with contentID and the associated key. When it receives a free content (r5 is not null) then copies the titleID and the klicensee to the table. For a paid content the rif.key is converted to the klicensee using:
AES_KEY IDPSKey, ConstKey, ActDatKey; uint8_t constactdat[0x10] = { 0x5e, 0x06, 0xe0, 0x4f, 0xd9, 0x4a, 0x71, 0xbf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }; uint8_t encrConst[0x10]; uint8_t decryptedActDat[0x10]; uint8_t klicensee[0x10]; int result = AES_set_encrypt_key(&IDPSVariation, 0x80, &IDPSKey); AES_encrypt(constactdat, &encrConst, &IDPSKey); result = AES_set_decrypt_key(&encrConst,0x80,&ConstKey); AES_decrypt(actDat,&decryptedActDat,&ConstKey); result = AES_set_decrypt_key(&decryptedActDat,0x80,&ActDatKey); AES_decrypt(rif,&klicensee,&ActDatKey);
where CONSTACTDAT is a constant value on lv2, IDPSVaritaion appears to be IDPS (actually is the plain IDPS) (not checked but DRM_Manager_initialize (see graf_chokolo's "bible") to something with the same structure), actdat are the 0x10bytes selected by rif keyIndex, and rif is rif.key (bytes 0x50-0x5f).
Once transformed it is stored on memory table...
I haven't check further steps on vsh nor lv2 so perhaps there are further transformations on the paid case (NOT FOR THE FREE AS I HAVE DECRYPTED THOSE) so we are jumping directly to the appldr
AppLdr
As you can see from graf_chokolo payloads a parameter is passed on spu_args.field60. That parameter is the previously stored klicensee.
However this key must be transformed (again) even for the free case. The transformation is:
uint8_t decryptedKLicensee[0x10] uint8_t KLicenseeDecryptKey[] = {0xf2, 0xfb, 0xca, 0x7a, 0x75, 0xb0, 0x4e, 0xdc, 0x13, 0x90, 0x63, 0x8c, 0xcd, 0xfd, 0xd1, 0xee}; AES_KEY KLicenseeKey int result = AES_set_decrypt_key(KLicenseeDecryptKey,0x80,&KLICENSEEKEY); AES_decrypt(klicensee,&decryptedKLicensee,&KLicenseeKey); EY is another key located inside the apploader and klicensee is the parameter.
Then we can finally remove the NPDRM layer using:
AES_KEY key; uint8_t iv[0x10]; memset(&iv[0],0,0x10); int result = AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&key); AES_cbc_encrypt(self + self->metaoffset + 0x20, self + self->metaoffset + 0x20,0x40,&key,&iv,0);
Observe the above code in action at [1]
Once that layer is removed we proceed as normal:
- Decrypt using AESCBC256 with the NPDRM keys to obtain the metadata keys
- Decrypt using AESCTR128 the data sha,hmac,iv keys
- Decrypt the data.
Source: http://www.ps3hax.net/showpost.php?p=259713&postcount=1 JuanNadie
Footnote: KLicenseeDecryptKey is located in appldr twice, e.g.
1.00:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 000187C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000187D0 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 000187E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000187F0 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî
3.15:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00018EB0 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 00018EC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00018ED0 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 00018EE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
3.55:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00019730 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 00019740 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00019750 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 00019760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
3.56:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0001F920 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 0001F930 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0001F940 F2 FB CA 7A 75 B0 4E DC 13 90 63 8C CD FD D1 EE òûÊzu°NÜ..cŒÍýÑî 0001F950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
hex
appldr/npdrm 0.92-3.31: rev_0x01.rar (2.39 KB)
Part 2
Thank to all of you. I hope someone is able to code a program using this info.
First of all, I want to congratulate Euss of ps3devwiki on finding the klicensee decrypt key and provide a proof of concept of the AppLoder part of the algorithm. Check http://ps3devwiki.com/index.php?title=Talk:SELF_File_Format_and_Decryption Now you have the tools to decrypt all free executable content.
Euss they key is not duplicated... there are two cases that lead to the same (similar to the keys, two cases so two repeated tables).
Some of you asked what this algorithm is for. It has several use from backing up PSN games so they can be used with/without license (some countries allow backups, but NEVER sharing copyrighted material....) or use game updates on lower firmwares (some updates are NPDRM so they could not be decrypted and downgraded). I don't know if DUPLEX used this method or if they replaced the data with debug versions as some implied...
Also, it can be use is to modify geohot's make_self_npdrm to use non static keys for encoding. I don't know if that would be enough to make a self runnable on 3.56+ firmware. However it is a step on the right direction (I think extra modifications are required). If someone knows which parts of the self is whitelisted it would be an interesting addition to the thread. Sony was publishing 3.55 after 3.56 went online so I really interested to see which part of the SELF was whitelisted.
Others asked for the keys. I can not provide them nor functional code to avoid being sued... Graf and geohot were sued for providing the keys and/or functional code.
RIF key
However, I can provide a tip on getting the RIF key.... once decrypted bytes 0x40 to 0x4F should be xx xx xx xx xx xx xx xx xx xx xx xx 00 00 00 aa where x is random and aa is a number between 0x00 and 0x7F. It is located on the VSH.elf (remember that PPC64 has 8 byte aligment). That is a plaintext attack + dictionary(vsh). You don't need the curves as you can not sign rif nor act.dat (You can only check that file is valid). And the vsh keys can be easily find... graf chokolo called IDPS as device_id_ptr.... and the CONST is very near on code execution...
edit:
RIF's act.dat index decryption key
actdatix_dec_key : DA7D4B5E499A4F53B1C1A14A7484443B Actually in vsh.self
To <X>: That is a piracy related question. In addition you have published confidential info, which anyone who does RCE should avoid (I do not have the SDK). The answer is NO. Why?. See this code:
ret = sceNpDrmVerifyUpgradeLicense("FAKE_CONTENT_TO_DETECT_CFW"); if(ret == 0){ banConsole(); print("CFW detected. Game will exit"); exit(-1); } ret = sceNpDrmVerifyUpgradeLicense("REAL_CONTENT"); if (ret == 0) { int fd = openEncryptedContent("REAL_CONTENT.edat",......,keyForFile,sizeof(KeyForFile)); if (fd > 0) { //Do things } }
First part is an example of how a developers can easily catch that modification and stop execution making it dangerous (could get a ban!!!). You modification says that the console has access to a fake content, which only CFW will have. When patching code the modification should be done only to the case you want to fix. That modification should go on the executable not on npd libraries. That way we do not patch the first verify but we will patch the second...
The second part is the real reason why it wont work... you REQUIRE the rif for opening the edat. The rif holds the klicensee for both SELF and EDAT. In fact I assume that the klicensee follows the same transformation upto the apploader. That key that you see on the command it is only used to check the HMAC on the NPD element (see geohot make_self_npdrm omac calculations)
For executable the problem is similar as when trying to run another PPU executable the program will finish and ask the vsh to run the other process which will undergo the full decryption algorithm... again you need the rif.
But.... what will happen if we decrypt the paid edat/SELF using the rif and then resign and encrypt as a free content before executing the code??? (Assuming we can sign edat)
WE CAN SIGN EXECUTABLES UPTO 3.55 THANKS TO FAIL0VERFLOW'S EPIC FAIL..... I think people do not really understands what that means...
Source: http://www.ps3hax.net/showpost.php?p=260574&postcount=8
Part 2 - responce
There is a reference for PSP's act.dat rif edat format posted here: http://www.emunewz.net/forum/archive/index.php/thread-8134.html
there may be similarities between PS3 and PSP below:
EDAT/SPRX format: [HEADER] 0x00: 00 50 53 50 -> .PSP 0x04: 45 44 41 54 -> EDAT 0x08: 02 00 00 00 -> Content key format (0x2000000 fixed key from npdrm / 0x2000100 version key from act.dat) 0x0C: 90 00 -> Header size 0x0E: 01 01 -> Header format (01 01 = sprx; 00 01 = edat) 0x10 - 0x40 -> Content ID 0x40 -> Hash generated from Content ID 0x50: 00 00 00 00 -> NULL 0x54: 00 00 00 00 -> NULL 0x58 - 0x70 -> Signature 0x80 -> Hash generated from signature [HEADER] 0x90: [Encrypted PRX (SPRX)] / [PGD (EDAT)]
RIF format: 0x00: 00 00 00 01 -> License version (shared with act.dat) 0x04: 00 00 00 02 -> File version 0x08 - 0x10 -> Account ID 0x10 - 0x40 -> Content ID 0x40 -> Hash generated from private key 0x50 -> Hash generated from license key 0x60: 00 00 01 1F -> License start time 0x64: C5 16 7B D8 -> License expiration time 0x68: 00 00 00 00 -> NULL 0x6C: 00 00 00 00 -> NULL 0x70 - 0x90 -> Signature
ACT.DAT format: 0x00: 00 00 00 01 -> License version (shared with .rif) 0x04: 00 00 00 01 -> File version 0x08 - 0x10 -> Account ID 0x10 - 0x1010 -> Data hashes 0x1010 - 0x1030 -> Signature[/CODE]
A MU link contains a sample act.dat and rif file for ps3 can be found if you search for "COD:BO First Strike DLC Activation blus30591" with google.
I'm reading PSP forums, and it may possible to code an utility for cfw PS3 users, that decrypts their purchased content (A valid act.dat and rif required) if knowledge matures I see the reason that, some users lost their bought DLC because of someting not related with piracy, for example updating fw, hdd, etc. A PC utility could be written only if npdrm self contains a free license, etc...
Source: http://www.ps3hax.net/showpost.php?p=260672&postcount=9
Part 3
That link was very useful. The riff structure is very similar although the signature algorithm is different.
I have some bad news. The IDPS has been confirmed as the plain IDPS with no variations (I expected it to be user ID). That means that some step is missing in the paid algorithm. For some time, people have been able to use DLC bought by other people by changing their user ID. That means that info could be extracted on any PS3, so a value coded by IDPS (which is different on EACH console) can not be part of the algorithm. I think that the value calculated by 471 is some kind of signature to validate act.dat. It will fail on different console which explains why the act.dat is deleted every time the machine boots.
So I'm going to restudy the VSH looking for the missing part. We don't know the meaning of byte 0x810 to 0x1010 of act.dat. Previously I discarded that the act.dat contained an entry for each content as it has a fixed size but it is the only place to store keys. It is a slow process so please be patient.
Meanwhile we can improved make_self_npdrm and decrypt updates (for disc games).
By the way more info on keys:
VSH CURVE TABLE: Len: 360 SHA1: 870ce226c65325a64dae9362cf9d43665d13194b PUB_KEY: Len: 40 SHA1: 7b365a6a821fc03b1a9a764e5e695db3599ff7bc
edit: The contents of the above:
u8 vsh_pub_key[] = { 0x62, 0x27, 0xb0, 0x0a, 0x02, 0x85, 0x6f, 0xb0, 0x41, 0x08, 0x87, 0x67, 0x19, 0xe0, 0xa0, 0x18, 0x32, 0x91, 0xee, 0xb9, 0x6e, 0x73, 0x6a, 0xbf, 0x81, 0xf7, 0x0e, 0xe9, 0x16, 0x1b, 0x0d, 0xde, 0xb0, 0x26, 0x76, 0x1a, 0xff, 0x7b, 0xc8, 0x5b, };
u8 vsh_curves[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x9a, 0x2e, 0xb7, 0x73, 0xfc, 0xa6, 0x1d, 0xcb, 0x52, 0x36, 0xa4, 0x2c, 0x6f, 0x7f, 0xeb, 0x42, 0x6e, 0x5a, 0xda, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xfe, 0x4a, 0x39, 0xe8, 0x0d, 0x6f, 0x15, 0x1e, 0x24, 0x52, 0x70, 0xdd, 0xa6, 0x53, 0x11, 0xea, 0xb7, 0x63, 0x4f, 0x69, 0x57, 0x7d, 0x0f, 0x51, 0xe3, 0x06, 0x02, 0x71, 0x1a, 0x07, 0x05, 0x9f, 0xbc, 0xa7, 0xba, 0x92, 0xf5, 0xe3, 0x4d, 0x6f, 0x72, 0x16, 0xf0, 0xd8, 0x28, 0xa3, 0x7d, 0x41, 0x3e, 0xf7, 0x3f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x59, 0x74, 0x12, 0x3c, 0xcb, 0xe7, 0xfd, 0x63, 0xe2, 0xc3, 0x1c, 0xc4, 0x65, 0xcd, 0xe0, 0x33, 0x44, 0x61, 0xf0, 0xf4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x4a, 0x51, 0xc3, 0xad, 0xc1, 0x9c, 0x6b, 0xb0, 0xde, 0xd8, 0xed, 0x71, 0x3b, 0xda, 0x9b, 0x78, 0x02, 0x70, 0x20, 0x9b, 0x1d, 0xbc, 0x84, 0x3f, 0x5e, 0x09, 0x2a, 0x50, 0x21, 0xd3, 0xa6, 0xa7, 0xaa, 0x81, 0x4e, 0x24, 0xff, 0xed, 0x9f, 0xbd, 0xaa, 0xdb, 0x24, 0x3c, 0x86, 0x2a, 0x53, 0xa0, 0xb5, 0x20, };
edit: vsh-pub-curves.rar (367 Bytes)
I apologize for providing an incomplete solutions and I hope that me or someone else completes the info.
Source: http://www.ps3hax.net/showpost.php?p=261043&postcount=10
Part 3 - responses
I'm not sure about that... It sounds weird. People had the opportunity to use DLC from others with account sharing. I log psn with your account and the psn generates a new act and rif for me (based on my IDPS??) So maybe your work isn't incomplete.
And also, if syscall471 is used to verify act.dat, what's the purpose to call that also for free content?
Source: http://www.ps3hax.net/showpost.php?p=261065&postcount=11
Don't doubt yourself, JuanNadie! The algorithm you posted is correct. It is indeed the plain IDPS. Using your posted algorithm I was able to completely remove the NPDRM layer on an encrypted, paid SELF to get the decrypted metadata keys. I suspect the game sharing people download games while logged in to a friend's PS3. When they download the game to their friend's PS3, the NPDRM layer is added using their friend's IDPS.
Source: http://www.ps3hax.net/showpost.php?p=261140&postcount=13
I can confirm it, the algo is correct
Source: http://www.ps3hax.net/showpost.php?p=261294&postcount=15
Part 4
Did it really work? Wowww... I never tested that last step as i don't have an act.dat for my current PS3 (the other has YLOD). I released the info so somenone else could test it. I modified the first message to credit you for testing
Then we have the NDPDRM algorithm solved and a new mystery (why changing userID at xregistry.sys allows using other's act.dat and rif).
If someone has access to two consoles with act.dat he should check if values from 0x10 to 0x810 decrypts to the same. If the decrypted tables are equal them we can improve the algorithm to avoid using the IDPS, so anyone that lost their act.dat but have their rif could recover their games.
IDPS for 3.55 kmeaws is located at 0x80000000003C2EF0. You will also need a program for getting it (two LV2 peeks).
AppLoader keys are at 0x32510 (program memory address for 3.56 appLdr not file offset).There are 16 keys. Then there is another unknown key and then NPDRM keys at 0x32B70. Again 16 entries (some of them nulled). Then a copy of NPDRM keys at 0x33170. The revision value on self header is use as index for these table (the fail0verflow code tested all the values until it found zero padding). scekrit could be modified to get the private keys
And now we wait until someone has guts to release a working code.
Source: http://www.ps3hax.net/showpost.php?p=261963&postcount=21
NPDRM ps3tools
v1
ps3tools-npdrm.tar.gz (78.56 KB)
v2
unself2 and readself2 working. see questions about section type 3 in the readme
ps3tools-npdrm-v2.tar.gz (79.45 KB)
readme:
Based off of gitbrew's 215d8903bc86539ca1da53519e2ac10eeafc4c27 ps3tools. .git folder not included to protect senstive info about the author. Sorry about the fucked up tabs, TAB = 4 SPACES 4 LYFE!!! Add the files in the npdrm_keystuff folder to your ps3 keys folder. Create a file with your console's 16 byte IDPS in the 'idps' file in your ps3 keys folder (e.g. ~/.ps3/idps). Copy your PS3's exdata folder containing your act.dat and rif files to your ps3 keys dir (e.g. ~/.ps3/exdata/act.dat). Compile and have fun with your LEGALLY purchased NPDRM games! Also works on free games without exdata/idps. Apologies for any existing bugs in unself. Adding these changes to unself2 is left as an exercise for the reader. v2 info: Added npdrm magic to unself2 and readself2 unself2 doesn't like the metadata section with type 3 in my game. This section looks to be some kind of linking information. Here is a snippet: crt0:p190002crt1:p190002libaudio_stub:p190002libaudio_stub:p190002 I haven't yet looked around to see if this is type of section is documented anywhere. Thanks: *fail0verflow for the orginal tools *JuanNadie for figuring out NPDRM *euss for his endless hours of work on the wiki <drama> Why didn't you beat me to the punch, Team PS360? I didn't need to reverse a single instruction! It isn't that hard... </drama>
v2 Newsitem
http://www.ps3hax.net/2011/10/compile-your-legally-purchased-npdrm-games/
Reaction
I checked my notes on Metadata Section Header. Value on unk2 indicates the type of data:
- 1: the section header itself
- 2: program data. program index indicates which program section.
- 3: section data. program index indicates which section.
I have checked several game updates and Sony removes some of the section info (I have seen the section header removed). That data is not needed on loading game (just program header, elf header and of course the program data). The ¿lv2? creates a memory image from only the data at segment Information. It never knows the contents of the metadata section headers.
For backing up a game I think is not necessary to decrypt the data just the Self header and then modify the license type to 3 (free) reencode the NPD element resign the header with the priv and reencrypt the Self header.
I don't have info on EDATA.... yet. On EDATA the index for act.dat uses the same key what I don't know if it uses the same table
http://www.ps3hax.net/showpost.php?p=262858&postcount=34
v3
readme:
unself2 now ignores metadata sections of type 3 instead of aborting. Additional help with any remaining bugs would be greatly appreciated. I'm sorry if everyone got the impression that these unself/readself modifications can, by themselves, "reactivate" your NPDRM content. These are just the first steps in the process. To those who say this is useless because you need act.dat and rif files: unless you can get unencrypted (debug) or easily decrypted (free, demos) PSN content, the only way to get the unencrypted files is by decrypting it with act.dat and the content's rif file. There are no "crypto fails" here, proper decryption with the true keys is the only way forward. Using the NPDRM algo with the right keys is the only way to decrypt unless you let GameOS do it for you and hook into GameOS to either grab intermediate keys or dump decrypted content. Using hacks to restore the NPDRM decryption info to jailbroken PS3s is only a partial fix. For instance, unless you patch vsh or set the SRTC to some time in the past, some content (even non-demos and non-trials!) expires until you log into PSN and reauthenticate. <drama> Sorry about your "technical difficulties", Team PS360. You should L2IRC. </drama>
ps3tools-npdrm-v3.tar.gz (80.05 KB)
npdrm_keystuff.rar (705 Bytes)
Reaction
the edat is completely different. The edat structure is totally different:
- An NPD element
- Then info for the lv2/vsh: the key index, blocksize (the SPU has a max size for reading), and decrypted/decompressed file length.
- Then I expect some metadata for keys.
- Then structures defining length and offset for ¿decryption? and inflating.
- The data itself.
Source: http://www.ps3hax.net/showpost.php?p=263724&postcount=42
NoPDRM
With the release of mallory's NPDRM-enabled ps3tools, it was remarkably simple to re-enable your legally purchased PSN titles.
Overview of steps:
unself2 -> make_self_npdrm -> pkg.py
Tools you need:
- ps3tools modified for NPDRM use (included)
- make_self_npdrm from geohot's tools (included in psl1ght)
- pkg.py (included in psl1ght)
To use the NPDRM ps3tools you need:
- Your console's IDPS
- Your console's exdata folder (/dev_hdd0/home/xxxxxxxx/exdata/)
- Your PSN titles (/dev_hdd0/game/NP*)
The get_idps.pkg file can be installed on your PS3. When run, it creates a file called 'idps' on the root of an attached USB drive. Copy this idps file to your PS3KEYS folder. Make sure that your PS3KEYS folder has the appldr NPDRM keys. One pair was included in mallory's ps3tools release and more can be found at Keys Appldr FTP your PS3's exdata folder to your PS3KEYS folder (e.g. ~/.ps3/exdata). Now the NPDRM modified ps3tools have all the keys they need to decrypt PSN games.
Copy a PSN title to your computer. Run nopdrm.py with the PSN game's folder and the output package names as arguments.
Example:
nopdrm.py NPUB90126 mgsdb.pkg
The resulting package can be installed on your PS3 and will play without any PSN licensing restrictions.
NOTE: PSN titles that use encrypted data files (*.EDAT) will likely not work. nopdrm.py outputs a warning if it detects a EDAT file in the PSN title. Work on decrypting EDAT files is underway. NOTE: All pkgs were tested with OtherOS++ MFW. Results are not guaranteed on other firmwares.
Please report any bugs to #otheros on gitbrew's IRC.
Thanks:
- juan nadie
- glevand
- geohot
- fail0verflow
- gitbrew
Source: http://gitbrew.org/releases/double/
npdrm-fix_v2
granberro I'd like to share with you my fork of failoverfl0w and geohot tools.
I have fixed some bugs on fl0w tools and added all NPDRM stuff as well as @mallory did.
What's different then?
- unself (unself2 should not skip type 3 setction IMHO) is able to save the key/iv used to encrypt the NPDRM and patch the eboot.elf for 3.41 consoles.
- make_self_npdrm2 is able to encrypt elfs with the key/iv extracted by unself and, theoretically being accepted by OFW>3.55
With those tools, I've been able to "downgrade" LBP2 updates 1-4 and install them on a CFW 3.41.
@JuanNadie Gracias. I've just followed your clear explanations.
EDAT Stuff
My WIP on decryting EDATs. I've found 4 likely keys used in EDAT processing inside appldr (included in unedat.c). Mostly non-working unedat
JuanNadie
Actually an EDAT has several keys. One is in the SELF, others are at the rif and others on firmware. That an EDAT works on lower firmware only proves that the firmware has those keys.
BTW I have tricked the PS3 into decrypt an EDAT (Buzz). The procedure involves knowing how the NPD element is used (most of this is already published).
struct { uint32_t magic; uint32_t unknown2; uint32_t license; /* 1 network, 2 local, 3 free */ uint32_t type; /* 1 exec, 21 update */ uint8_t content_id[48]; uint8_t digest[16]; uint8_t titlefilenameHash[16]; uint8_t headerHash[16]; uint64_t unknown3; uint64_t unknown4; } npdrm;
http://www.ps3hax.net/showthread.php?p=275238#post275238
EXE.trim.ALL
Actually as I know:
uint32_t unknown2; /* is */ edat_version[4]; /* 1, 2 or 3 (as I know, 3.15 has version 1 & 2, >=3.40 have 1&2&3 */ /* and some more info for: */ uint32_t license; /* 0 = debug */ uint32_t type; /* 0 - just file */
and uint64_t unknown4 is:
uint8_t finalize[1]; /* 0x00 - finalized edat, 0x01 - finalized sdat, 0x80 - nonfinalized edat, 0x81 nonfinalized sdat */ uint8_t data_type[3]; /* 0x01 - compressed, 0x02 - plain txt, 0x03 - compressed plain txt, 0x05 - compressed, 0x06 - plain txt, 0x07 - compressed plain txt, ..., [B]0x0c - edat[/B], 0x0d - compressed edat, 0x3c - sdat? */ uint8_t block_size[4]; /* default is 16 kbytes = 0x4000 */ uint8_t data_size[8]; /*decoded data size */
JuanNadie
I haven´t fully reversed the EDAT algorithm (I’m missing bytes from 0xB0 to 0xFF) but there is enough info for a post. The explanation is for those with flag (offset 0x80-0x83) equals to 0xC which is a normal EDAT. For others values minor changes should be made. Let’s begin.
USER SPACE: (Probably incomplete (enough for decryption), most of it is guessed) On previous post I mentioned the command useds by developers to open/read an EDAT. That command has 3 parts:
- Verify: This parts verifies the NPD element by checking that user is authorized to open the file (using the devklic). In addition it calls LV2 to create an entry in the memory (probably using syscall471) so for further steps it will use the devklic (free) or the decrypted rif key (paid) (see SELF algorithm). I’ll call this rifkey on the rest of the document.
- Open the file: This will call kernel space. Performs several checks and creates an entry on another table.
- Read: It also calls LV2, which will decrypt and send data back.
<KERNEL SPACE:
- When an open request is received:
- Read the first 0x100 bytes of the file.
- Validates first 0xA0 bytes on EDAT. This uses appldr with the following execution (see below):
- Single execution
- Encrypted arguments
- CMAC. Key: rifkey, expectedHash: data at 0xA0-0xAF
- No Encryption erk:null,riv:null
- Validates metadatasections. Again uses appldr:
- Multi execution. Blocks upto 0xFC00.
- Encrypted arguments
- CMAC. Key: rifkey, expectedHash:data at 0x90-0x9F
- No Encryption: erk:null, riv:null
Once the NPD is validated (We have validated header upto 0xAF and the metadatasections( which validate the data itself)) an entry on a memory table is created, the entry created by syscall471 is erased and returns. I’ll call this the EDATEncryptionDataTable. This table has 10 entries (remember the limitation of simultaneous files opened??...). Each entry has the following structure:
typedef struct { uint64_t fileDescriptor; uint64_t offset; uint64_t fileLen; uint32_t flag; uint32_t blockSize; uint32_tnumBlocks; uint8_t blockBase[0x0C]; uint8_t devklic[0x10]; uint8_t digest[0x10]; }EDATEncryptionData ;
- fileDescriptor: The file descriptor
- offset: An additional offset to calculate the position of the metadataSection. Origin unknown. Values seen 0
- File len: Length of the uncompressed data. Copied from EDAT offset 0x88-0x8F
- flag: Flags required to process the data. Copied from EDAT offset 0x80-0x83. Some flags are:
- 0x80000000: Debug
- 0x01000000: SDAT… for those rifkey is calculated differently. Algorithm is not tested yet.
- 0x00000004: Arguments for appldr are encrypted
- 0x00000001: Data compressed. MetadataSection length will be 0x20 bytes.
- blockSize: The data is stored on blocks of that length. Required for decryption. Copied from EDAT offset 0x84-0x87
- numBlocks: Number of blocks on file. Calculated using: numBlocks = (fileLen + blockSize - 1)/blockSize
- blockBase: Common part of the key used on decryption. First 0xC bytes of headerHash. Copied from EDAT offset 0x60-0x6B.
- devklic: Our rif key. Copied from the entry created by syscall471. FOR SDAT it is calculated using other algorithm.
- padding: the digest from NPD. Will be the IV. Copied from EDAT offset 0x40-0x4F.
- When an read request is received:
- The system determines the blocks required (E.g; read from 0x3FFF to 0x8001 will read blocks 0,1 and 2).
- For each of the blocks:
- Calculate the blockKey as blockBase concat blockNumber.
- Calculate block offset: Start of NPD + offset + 0x100 + metadataSectionLen* numBlocks + blockSize*blockNumber. metadataSectionLen is 0x10 for flag 0xC (if compressed or with special hash would be 0x20).
- Calculate erk: AESECB128Encrypt, key:rifKey, data:blockKey
- Calculate hashKey: For 0xC is erk. (Others have an additional encryption)
- Execute appLdr with the following parameters:
- Single execution
- Encrypted arguments
- CMAC. Key: hashKey, expectedHash: metadataSection[blockIndex].hash
- EncryptionCBC erk:erk, riv:npd.digest
APPLDR:
As you know the appldr is used for decrypting SELFs (that part is documented on the wiki). However there is a second mode that is used for EDAT. To use that mode spu_arg.field35 is 5. For values 0 to 4 it will process a SELF and for others will return error. Graf_chokolo described the structure of spu_args for the SELF. However this changes for EDATs…
typedef struct { uint64_t unk1; uint32_t hashFlags; uint32_t encryptionFlags; uint64_t unk2; uint64_t len; uint64_t unk3; uint64_t stateAddress; uint32_t field30; uint8_t field34; //Must be 0,1,2 uint8_t field35; //Must be 0,1,2,3 uint16_t field36; //Must be 0,1,2,3,4,5 uint64_t field38; uint8_t hashKey[0x10]; uint8_t riv[0x10]; uint8_t erk[0x10]; }spu_args;
Above I indicated several parameters for the appldr. Those parameters are controlled by hashFlag and encryptionFlag.
- HashFlag: The hash is performed on input data not decrypted data. So if hash fails nothing is decrypted
MSB indicates how to use parameter hashKey. 0x10000000: Indicates that hashKey is encrypted. Decrypt it with EDATKEY and RIVKEY 0x20000000: Ignore hashKEY. USE EDATDEFAULTHASHKEY 0x00000000: hashKey is not encrypted. Use it directly
LSB indicates the type of hash. 0x00000001: HMACWithSHA1. Hash Len 0x14 bytes 0x00000002: CMAC128. Hash len 0x10 (obvious) 0x00000004: HMACWithSHA1. Hash Len 0x10 bytes (Hash is trunked)
- EncryptionFlag:
MSB indicates how to use parameters riv and erk 0x10000000: Indicated that erk is encrypted. Decrypt it with EDATKEY and RIVKEY. riv is copied 0x20000000: Ignore riv and erk. Use EDATKEY and RIVKEY 0x00000000: Use erk and riv directly
LSB indicates which encoding is used. 0x00000001: No encryption (algorithm is memcpy) 0x00000002: AESCBC128Decrypt is used.
When a key must be decrypted the algorithm is AESCBC128Decrypt.
Keys SHA1:
EDATKEY: 84E9FC3574EAA11A9462FFA53D5EA46B4D0003BF. Already in wiki RIVKEY: E129F27C5103BC5CC44BCDF0A15E160D445066FF. This is top secret ;D EDATDEFAULTHASHKEY: 8A721A06ABC7BB9BF398C5EF5D6F1FD997BC0A56
The multiple execution /single execution refers to the ability of appLdr to store an encrypted (and hashed) data on main memory to resume the hashing/decryption operations on next execution. That data is stored at stateAddress. Basically the functioning has several submodes. One for initialization (that decrypts erk, riv and hkey) and copies the state to main memory, another for processing data, which retrieves the state, process the data and updates the state, and finally another that receives the expected hash and validates. Another submode does all these ops on a single execution (calls the three submodes).
Summing up (for 0xC) for each block:
- Calculate data offset: 0x100 + offset(0) + metadataSectionLen*numberOfBlocks + currentBlockNumber*blockSize
- Generate block key: concat first 0xC byte of headerHash with current block number
- Encrypt block key with rifKey using AESECB128Encrypt. This would be erk and hkey
- Calculate riv. It is NPD digest field
- Decrypt erk using AESCBC128Decrypt with EDATKEY and RIVKEY -> call result decryptionKey.
- Using AESCBC128Decrypt decrypt data from offset to offset + blockSize( if last block calculate remaining bytes rounded up to 0x10 multiple). Key is decryptionKey iv is riv
- Copy data to output file
Source: http://www.ps3hax.net/showthread.php?p=289101#post289101
JuanNadie
After searching for those missing bytes I did not found any reference on code. So I zeroed them and feed the file to the PS3... The file was properly loaded and decrypted so: -Those bits are a random padding or -They are not checked ,nor required for creating an EDAT.
That means that you are able to "free" your EDATs using the method above. Remember that you're going to need the devklic and the rifkey
@Octopus For p3T you don't require the devklic cause for paid decryption you only need the key from rif... so decrypt it and use it directly like any other theme
@EXE.trim.ALL You're right on version. LV2 uses that value to check which flags are valid. However unk4 (and unk3) which are at 0x70 are zeroes. Your info is for the next 16 bytes located at 0x80. Also you separate finalize and type. From the assembly I can say that the original source code considers it a signed integer (int32_t) (that or they have a really weird compiler cause it always load that field as a word (PPC can read a single byte)).
BTW the text on flowers says something about "werewolves" and the devklic is written as an ASCII text (not binary). It was the first non free content that I decrypted on PC.
It's a pity that I would never enter on efnet (nor other sites) as long as they don't allow proxy and TOR.
- notes:
- actually wiki accepts proxy (and tor?)
- in case you need tor for ef.net, irc.paraphysics.net accepts tor connections
Finally a bit of drama: Hotz8611, I reversed your reactPSN to see the your method and discovered that you just used the info on this post. I haven't check the vsh.self mode but I suppose that youre nullifyng the curve check and generate RAP by encrypting the rifkey (An AES and another crypto algorithm of 5 rounds with shuffle, acummulation and xoring.). I thank you for making people provide me all those RAP than I'm able to transform to rifkey but next time give proper credits (I don't know if your works is based on mallory or mine but obviously is based on info in this topic).
Source: http://www.ps3hax.net/showthread.php?p=289719#post289719
JuanNadie
First of all, here is an implementation of the algorithm. It is not fully tested (for example with ISO.BIN.EDAT it validates but fails when decrypting) and is missing the decompression algorithm (I tried deflate but is does not work if someone identifies the algorithm please post it. Blocks start with 0x05). Also keys have been eliminated. On previous port you have the SHA1.
About compression: Instead of having metadatasections of 0x10 byes the new section is 0x20 bytes long.
Code:
struct compressMetadataSection { uint8_t hash[0x10]; uint64_t fileOffset; uint32_t len; uint32_t isEndOfCompression; }
The obtain bytes 0x10-01F xor of data is used
@jester You probably forgot to decrypt the key. The result of syscall471 must be decrypted using EDATKEY and RIVKEY.
@Octopus to make free files. - Create a memory image of the file. - Decrypt the data, so you have a memory copy of the file decrypted (for compressed no need to decompress) - Modify NPD to make if free (0x03 instead of 0x02). Recalculate hashes using devlikc (that why we need it). - Recrypt each block using the devklic as base to calculate blocks keys (wich will then be transformed again as does the appldr for that type). - Once recrypted, recalculate the hashes of the sections so they matched the new value for the encrypted data. -If compressed recalculate the offset and len on the metadatasection -Using the new metadatasection recalculate data 0x90-0x9F. -Using the new NPD header + new metadatasectionHash calculate hash and place it at 0xA0-0xAF. -Write file to disk (Remember, that file is function of filename, you must overwrite (not recommend while testing) or remember to rename it properly).
Done
Source: http://www.ps3hax.net/showpost.php?p=299753&postcount=83
JuanNadie
The code I posted already implements SDAT. You just need the SDATKEY. The SHA1 is ED2A015EEB1BD0CE06D0447F1A22AF4C1C401E4A
However you won't find it by bruteforce as it is coded as a series of inmediate values. If you check routine sub_5529C at graf_chokolo's dump_lv2 you'll see the routine that checks the edat/sdat header. Few lines below at address 5543C you'll see those inmediate values that are xored with the hash of the NPD to create the fake rifkey (the first 0x100 bytes of the npd are loaded starting at sp + 0x110)
About compression: We don´t know the algorithm but if we decrypt the data and modify the NPD so it looks like a debug you can use make_edata_npdrm to decompress it
Source: http://www.ps3hax.net/showpost.php?p=300371&postcount=89
JuanNadie
First of all a new revision of the algorithm:
http://pastebin.com/E9ghYKj0 (backup: http://pastie.org/private/zanb7y2hjbk9yel71jhpq)
CHANGELOG:
- Added partial support for debug files
- Added NPD version check (between 0 and3)
- Added per version flags check
- Added support for FLAG_0x20. (Untested)
- Added support for versions 0 and 1 (ISO.BIN.EDAT). See below
When version is 0 or 1 instead of using the digest and the hash of the NPD for calculating the block key and the apploader's IV a zeroed byte array is used as base
I hope this helps your project Snowy.
@dsadsadsa I don't think I could help Kakaroto cause most of the checks are not on current code (They probably added further checking on later firmware version) and my expertise is reading assembly which I don't have. However if I can help then in any form they only need to contact me. In fact the only think that I know that is not already public is that 0x20 bytes are copied from the appldr to main memory just before setting mailbox to 7. Those bytes are at 0x890 and probably is the hash for the whitelist.
@EXE.trim.ALL There is no hash for SDAT. Those values are unknow and not checked(not confirmed). The only function as you have seen is to be xored to generate the key. To get the exacts values I'll need to check the SDK as those are generated there.
@Octopus I haven't look for the second part of the act.dat. My hyphotesis is that the second part of the file is used when debug is enabled and is common for all the consoles (will explain the COD trick). About the digest as I said there is no checked (is a hash of the original data which is unknown until the whole file is read so it can not be used as check). Geohot zeroed it on his code, An analysis of make package will obtain then (or wait until Kakaroto has the SELF fix and hope that it included the algorithm)
Source: http://www.ps3hax.net/showpost.php?p=300903&postcount=93
Sign executables for 3.73+
[21:00:58] <Mathieulh> selfs are a mess to generate properly because a lot of values need to be calculated from the original elf file [21:01:11] <Mathieulh> the problem is right now all the public tools use hardcoded values [21:01:19] <Mathieulh> that are grabbed from various self files [21:01:21] <Mathieulh> but are not calculated [21:01:34] <Mathieulh> well that's one of the many problems actually [21:01:35] <jevin> Mathieulh, things other than elf offsets? [21:01:40] <Mathieulh> yah [21:02:03] <Mathieulh> sony also did some fancy things with the compression self format [21:02:12] <Mathieulh> where values are off by a certain offset etc etc [21:02:38] <Mathieulh> if you want to make a proper self tool [21:02:44] <Mathieulh> you first need to reverse make_fself [21:03:06] <jevin> not too hard with hexrays *cough* [21:03:09] <Mathieulh> that's the initial step [21:03:15] <Mathieulh> yeah it's not that hard [21:03:29] <Mathieulh> then you'll figure what a big fuck up the self format really is xD [21:05:14] <Mathieulh> but yeah just my self.cpp is 5 times larger than the entire source for geohot make_self/make_self_npdrm [21:05:27] <Mathieulh> in terms of lines of code [21:05:48] <Mathieulh> so his is missing shitloads of stuffs and only relies on hardcoded values [21:06:06] <jevin> entire headers copypasta'ed from existing selfs [21:06:11] <Mathieulh> pretty much yah xD [21:06:23] <Mathieulh> the ones on the tool I use are generated [21:06:32] <Mathieulh> as in calculated and generated [21:06:36] <Mathieulh> from the original elf [21:06:52] <Mathieulh> btw unself is buggy too [21:06:54] <Mathieulh> just so you know [21:07:16] <jevin> why havent you labeled the control flags? :) [21:08:16] <Mathieulh> jevin I didn't feel the need to, I already know what they do anyway [21:08:37] <Mathieulh> for example 0x40 is root rights, 0x20 is debugger rights and so on [21:09:07] <jevin> im guessing the self capabilities flags are offset 0x20 in the self header [21:09:18] <Mathieulh> capabilities aren't in the header [21:09:23] <Mathieulh> they are part of the metadata [21:09:28] <Mathieulh> as in, they are encrypted and signed [21:10:16] <jevin> offset 0x10 in the section header? [21:10:29] <Mathieulh> it's after the metadata keys [21:10:33] <jevin> no, they wouldnt be per section [21:10:50] <Mathieulh> as in, right after them [21:11:09] <jevin> i see. so unself doesnt have enough fields in the metadata header [21:11:35] <jevin> i really should color in the hex values that are mapped to structures in unself vs ones that arent [21:11:42] <jevin> seems like it is missing a lot [21:11:49] <Mathieulh> everything public is missing tons [21:12:15] <Mathieulh> capabilities are optional mind you [21:12:35] <jevin> are they restrictive or permissive? [21:13:11] <Mathieulh> restrictive [21:13:16] <Mathieulh> (for most) [21:42:15] <jevin> Mathieulh, you said that the geohot npdrm keypair is blacklisted in 3.56 [21:42:30] <jevin> i couldnt find the decrypted or encrypted metadata keypair in 3.56 files [21:42:47] <jevin> where does the blacklisting occur? is it a hash that is blacklisted? [21:43:08] <jevin> its interesting to me because we can make our own keypairs now with juan nadie's work [21:48:45] <Mathieulh> <jevin> Mathieulh, you said that the geohot npdrm keypair is blacklisted in 3.56 <== not only that [21:49:03] <Mathieulh> geohot stuff doesn't generate some of the npdrm specific values [21:49:08] <Mathieulh> those were not checked in 3.55 [21:49:13] <Mathieulh> but they are checked in 3.56 now [21:49:55] <jevin> Mathieulh, gotcha [21:50:09] <jevin> is his keypair actually blacklisted somewhere though? [21:50:10] <Mathieulh> there is no whitelist for npdrm [21:50:22] <Mathieulh> so it's actually possible to generate valid npdrm self for 3.56+ [21:50:42] <jevin> is it a check in appldr? [21:50:43] <Mathieulh> that tool I made a screenshot of actually does that [21:51:02] <Mathieulh> jevin yeah, it's enforced by lv1 though [21:51:16] <jevin> a hash comparison? [21:51:27] <Mathieulh> yeah it's a hash [21:51:30] <Mathieulh> but I won't say more [21:51:35] <jevin> ok :) [21:51:55] <Mathieulh> everything you need is in the 3.56 fw :P [21:52:16] <jevin> rgr, i will poke around later [21:52:34] <jevin> the checks are unmodified in 3.60+? [21:52:43] <jevin> + new keys of course [21:52:51] <Mathieulh> same checks [21:54:53] <Mathieulh> jevin you won't get around crafting valid 3.56+ npdrm selfs without a proper makeself tool though [21:57:18] <jevin> would SCE make npdrm selfs work if actually signed? [21:57:25] <jevin> + crypted