Talk:SELF - SPRX: Difference between revisions

Revision as of 16: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	1 -- level 0 2 -- level 1 3 -- level 2 4 -- application 5 -- isolated SPU module 6 -- secure loader 8 -- NP-DRM application
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

0: retail type 0
1: retail
2: retail type 1
0x8000: devkit
4: unknown, games that require 3.42.
7: unknown, all games that require 3.50 have that flag.

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

NoPDRM V1

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.

npdrm-fix_v2

@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 */

74

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.

http://pastebin.com/SuAukd8B

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

Talk:SELF - SPRX: Difference between revisions

Revision as of 16:25, 3 January 2012

self-capabilities flags

NPDRM Header

App Info header:

Appinfo offset 0x08

Encrypted phdr offset entry

Meta Checksums

SDK Flags added

Region locking

moved from old talk page

nas_plugin.sprx

lv2_kernel.self

NPDRM Self algorithm

VSH

LV2

AppLdr

hex

Part 2

RIF key

RIF's act.dat index decryption key

Part 2 - responce

Part 3

Part 3 - responses

Part 4

NPDRM ps3tools

v1

v2

v2 Newsitem

Reaction

v3

Reaction

NoPDRM

npdrm-fix_v2

EDAT Stuff

JuanNadie

EXE.trim.ALL

JuanNadie

JuanNadie

JuanNadie

JuanNadie

JuanNadie

Sign executables for 3.73+

Navigation menu

Search