LIC.DAT: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
mNo edit summary
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=Description=
= Description =
Location: /dev_bdvd/PS3_GAME/LICDIR/LIC.DAT (soon LIC.EDAT)


Checked within Level 2 Kernel and possible via lv2syscall476<br>
*Paths
**dev_bdvd/'''PS3_GAME'''/LICDIR/'''LIC.DAT'''
**dev_bdvd/'''PS3_GM01'''/LICDIR/'''LIC.DAT'''
**dev_bdvd/'''PS3_GM02'''/LICDIR/'''LIC.DAT'''
**etc...


Final File size is: 0x10000 Bytes
Checked within Level 2 Kernel and possible via lv2syscall476<br>.


See also {{talk}} page
File size is always 0x10000 Bytes.


= example =
See also {{talk}} page.
 
= Example =


  00000000 50 53 33 4C 49 43 44 41 00 00 00 01 80 00 00 00 PS3LICDA........
  00000000 50 53 33 4C 49 43 44 41 00 00 00 01 80 00 00 00 PS3LICDA........
Line 17: Line 22:
  ...
  ...


= structure =
= Structure =
The structure is dependant of how the file is generated in PC and processed by the PS3
The structure is a consequence of how the file is generated in PC and validated by the PS3.


Generation - The file is created in 2 steps, the file generated in first step contains the header (with a crc32 filled with zeroes intended as a placeholder) and the licenses table, in second step is calculated the crc32 of the file and is added in the header, and filled with zeroes at the end up to 0x10000
*CRC32 generation (in PC)
<!--previous steps of how is generated the file could be longer to explain and not so easy to deduce-->
**A temporal file<!--or debug LIC.DAT for master disc?--> is created composed by: ''header'' + ''license table''. The crc32 value stored at offset 0x20 is filled with zeroes and works as a placeholder
**Now is calculated the crc32 of the temporal file
**The crc32 calculated in previous step is stored at offset 0x20 replacing the zeroes placeholder
**A padding is added after the '''lic_table_end''' offset to increase the final size of LIC.DAT up to 0x10000


Processing - PS3 first reads the file LIC.DAT (header + licenses table, not included the padding at end), then it makes a copy of it (because is needed to edit it)... then it reads the crc32 area from the header and stores it separatedlly, then it fills the crc32 area with zeroes... and finally... it calculates the crc32 of the edited file
*CRC32 validation (in PS3)
**LIC.DAT is readed from disc, and copyed to a different location excluding the padding at the end of the file (cropped from first byte of file up to '''lic_table_end''' offset)
**The crc32 value stored at offset 0x20 is replaced by zeroes
**Now is calculated the crc32 of the edited file
**The crc32 calculated in previous step is validated against the crc32 value stored at offset 0x20 of the original LIC.DAT


The CRC32 hash stored in the final LIC.DAT file.... is the hash of the file generated in step 1 (with the crc32 area on the header filled with zeroes) and a total size smaller than  0x10000 (because doesnt have the padding added at the end of step 2) <!-- yes, thats weird -->
== Header ==
 
== header ==


{|class="wikitable"
{|class="wikitable"
! Offset !! Length !! Example !! Name !! Description
|-
|-
! Offset !! Length !! Example !! Name !! Description
| 0x0 || 0x8 || 'PS3LICDA' || '''magic''' || LIC.DAT identifyer
|-
|-
| 0x0 || 0x8 || 'PS3LICDA' || Magic ||
| 0x8 || 0x4 || 0x00000001 || '''version''' || DAT structure version
|-
|-
| 0x8 || 0x4 || 0x1 || Version || DAT version or license version ?
| 0xC || 0x4 || 0x80000000 || '''flag'''  <!--type of what, master/retail disc?... or type of the EBOOT.BIN asociated with the first license in the table?--> || 0x80000000 = retail (used in LIC.DAT under directory PS3_GAME)<br>0x00000000 = debug (used in LIC.DAT under directory PS3_GM01, PS3_GM02, etc...)
|-
|-
| 0xC || 0x4 || 0x80000000 || License type ? || 0x00000000 = debug<br>0x80000000 = retail
| 0x10 || 0x4 || 0x00000900 || '''lic_table_end''' || License table, absolute end offset. Calculated by: ''license table start + (license amounts * license size)''
|-
|-
| 0x10 || 0x4 || 0x00000900 || License table, absolute end offset || chunks end (can be calculated with the formula: ''chunks start + chunk amounts * chunk size'')
| 0x14 || 0x4 || 0x00000800 || '''lic_table_start''' || License table, absolute start offset. Always found 0x800 (static)
|-
|-
| 0x14 || 0x4 || 0x00000800 || License table, absolute start offset || chunks start (static)
| 0x18 || 0x4 || 0x00000100 || '''lic_size''' || License size. Always found 0x100 (static)
|-
|-
| 0x18 || 0x4 || 0x00000100 || License size || chunk size (static)
| 0x1C || 0x4 || 0x00000001 || '''lic_num''' || License amount. Values found: 0x1 (single boot discs), 0x2 (dual boot discs), 0x3 (triple boot discs)
|-
|-
| 0x1C || 0x4 || 0x00000001 || License amount || chunk amounts
| 0x20 || 0x4 || 0x8CD3A9D8 || '''crc32''' || CRC32 from the first byte of LIC.DAT till the end of license table (includes the CRC32 placeholder filled with zeroes)
|-
|-
| 0x20 || 0x4 || 0xD8A9D38C|| crc32 || CRC32 from the first byte till the end of last chunk (without CRC32 value)
| 0x24 || ? || 0x0000... || '''padding''' || is unknown where the header ends, probablly aligned to 0x200 but there are much more zeroes after it
|}
|}


==License table==
== License table ==


=== chunk ===
Composed by one or more license entries.
 
=== License entry ===


{|class="wikitable"
{|class="wikitable"
|-
|-
! Offset !! Length !! Value !! Description
! Relative Offset !! Length !! Example !! Name !! Description
|-
|-
| 0x800+i*0x100 || 0x1 || 0x1 || kind of ID
| 0x0 || 0x1 || 0x1 || '''id_type''' || 0x01 = [[Productcode|Title ID]]<br>0x02 = [[SKU ID]]<br>0x03 = [[Content ID]]
|-
|-
| 0x801+i*0x100 || ID depending || 'BLES01623' || Title ID / Contend ID
| 0x1 || 0x0A (if '''id_type''' = 0x01)<br>0x2A (if '''id_type''' = 0x02)<br>0x25 (if '''id_type''' = 0x03) || 'BLES01623' || '''id''' || Bootable content identifyer (EBOOT.BIN related)
|-
| 0x0B (if '''id_type''' = 0x01)<br>0x2B (if '''id_type''' = 0x02)<br>0x26 (if '''id_type''' = 0x03) || up to '''lic_size''' || 0x0000.... || '''padding''' || padding to fill the entry with zeroes up to the "license size" specifyed in the header
|}
|}


Explanation:
The first byte indicates type and size of following text:
The first byte indicates type and size of following text:
* 0x01 means 0xA bytes, a regular TitleID (ex. BLES01623) with \0 terminating  
* 0x01 means 0xA bytes, a regular TitleID (ex. BLES01623) with \0 terminating  
Line 67: Line 85:
* 0x03 means 0x25 bytes, a regular npdrm ContentID (ex. UP0002-BLES01623_00-0000111122223333) with \0 terminating
* 0x03 means 0x25 bytes, a regular npdrm ContentID (ex. UP0002-BLES01623_00-0000111122223333) with \0 terminating


==Padding==
== Padding ==
 
Padding added at bottom of LIC.DAT file is to make the total size a multiplier of bluray disc sectors, and to protect the laser lens because otherway it is too tiny and so stressing for the laser.
 
This padding is added in the last step when the file is generated in PC, and removed in the first step before the crc32 hash is validated by the PS3.
 
= Multiboot PS3 Game Discs =
 
There is a special type of PS3 game disc that contains several EBOOT.BIN with several LIC.DAT. These LIC.DAT files are a bit special because contains the TITLE_ID of all the EBOOT.BIN. The first game found using this disc structure was: ''Metal Gear Solid The Legacy Collection'' (BLJM-91001 on PS3_DISC.SFB), and the second one: ''Fighting edition'' (BLES-02129 on PS3_DISC.SFB).
 
<strike>Total size of the file is always 0x10000, license "slots" starts at 0x800 so... 0x10000 - 0x800 = 0xF800 (available size) and 0xF800 / 0x100 = 0xF8 (available license slots). So the maximun number of bootable contents in a "multiboot disc" is limited to 248</strike> --> Wrong, the path PS3_GM01, PS3_GM02, etc... only allows for 2 digits... so up to 99 + main bootable content in PS3_GAME makes a total of 100.
 
== Exemple of Dualboot: Metal Gear Solid The Legacy Collection (BLJM-91001) ==
 
Dual boot disc structure, using folders '''PS3_GAME''', and '''PS3_GM01'''.
 
*dev_bdvd/PS3_GAME/LICDIR/LIC.DAT
**Header
***<span style="background:#4C4943;">Magic:</span> "PS3LICDA"
***<span style="background:#766572;">Version:</span> 1
***<span style="background:#66ff66;">Flag:</span> 0x80000000 (retail)
***<span style="background:#ff66ff;">licenses ending:</span> 0x0A00
***<span style="background:#f6ff6f;">beginning of licenses:</span> 0x0800
***<span style="background:#6f66f6;">license size (static):</span> 0x0100
***<span style="background:#6ffff6;">license amounts:</span> 2
***<span style="background:#C1C132;">CRC32:</span> 01 0F 95 0E
**Licenses
***First license, type 0x01 = BLJM61001 @ offset 0x800 (for EBOOT.BIN under directory PS3_GAME)
***Second license, type 0x01 = BLJM60351 @ offset 0x900 (for EBOOT.BIN under directory PS3_GM01)

00000000  <span style="background:#4C4943;">50 53 33 4C 49 43 44 41</span> <span style="background:#766572;">00 00 00 01</span> <span style="background:#66ff66;">80 00 00 00</span>  PS3LICDA....€...
00000010  <span style="background:#ff66ff;">00 00 0A 00</span> <span style="background:#f6ff6f;">00 00 08 00</span> <span style="background:#6f66f6;">00 00 01 00</span> <span style="background:#6ffff6;">00 00 00 02</span>  ................
00000020  <span style="background:#C1C132;">01 0F 95 0E</span> 00 00 00 00 00 00 00 00 00 00 00 00  ..•.............
...
00000800  01 42 4C 4A 4D 36 31 30 30 31 00 00 00 00 00 00  .BLJM61001......
...
00000900  01 42 4C 4A 4D 36 30 33 35 31 00 00 00 00 00 00  .BLJM60351......
...
0000FFF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
 
*dev_bdvd/PS3_GM01/LICDIR/LIC.DAT:
**The file is the same, only is changed the flag to debug = 0x00000000 (and the crc32 because the flag is included before hash is calculated)
**This means the file LIC.DAT under directory PS3_GAME is different than any of the others under paths PS3_GM01, PS3_GM_02, etc... (because the flag in main is retail and in the others is debug). But all the others are exactlly the same file because all them have the flag debug.


== Example of Tripleboot: Fighting edition (BLES-02129) ==


Triple boot disc structure, using folders '''PS3_GAME''', '''PS3_GM01''', and '''PS3_GM02'''


{{File Formats}}
{{File Formats}}
<noinclude>[[Category:Main]]</noinclude>
<noinclude>[[Category:Main]]</noinclude>

Revision as of 08:03, 11 September 2018

Description

  • Paths
    • dev_bdvd/PS3_GAME/LICDIR/LIC.DAT
    • dev_bdvd/PS3_GM01/LICDIR/LIC.DAT
    • dev_bdvd/PS3_GM02/LICDIR/LIC.DAT
    • etc...

Checked within Level 2 Kernel and possible via lv2syscall476
.

File size is always 0x10000 Bytes.

See also Discussion page.

Example

00000000 50 53 33 4C 49 43 44 41 00 00 00 01 80 00 00 00 PS3LICDA........
00000010 00 00 09 00 00 00 08 00 00 00 01 00 00 00 00 01 ................
00000020 8C D3 A9 D8 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
00000800 01 42 4C 45 53 30 31 36 32 33 00 00 00 00 00 00 .BLES01623......
...

Structure

The structure is a consequence of how the file is generated in PC and validated by the PS3.

  • CRC32 generation (in PC)
    • A temporal file is created composed by: header + license table. The crc32 value stored at offset 0x20 is filled with zeroes and works as a placeholder
    • Now is calculated the crc32 of the temporal file
    • The crc32 calculated in previous step is stored at offset 0x20 replacing the zeroes placeholder
    • A padding is added after the lic_table_end offset to increase the final size of LIC.DAT up to 0x10000
  • CRC32 validation (in PS3)
    • LIC.DAT is readed from disc, and copyed to a different location excluding the padding at the end of the file (cropped from first byte of file up to lic_table_end offset)
    • The crc32 value stored at offset 0x20 is replaced by zeroes
    • Now is calculated the crc32 of the edited file
    • The crc32 calculated in previous step is validated against the crc32 value stored at offset 0x20 of the original LIC.DAT

Header

Offset Length Example Name Description
0x0 0x8 'PS3LICDA' magic LIC.DAT identifyer
0x8 0x4 0x00000001 version DAT structure version
0xC 0x4 0x80000000 flag 0x80000000 = retail (used in LIC.DAT under directory PS3_GAME)
0x00000000 = debug (used in LIC.DAT under directory PS3_GM01, PS3_GM02, etc...)
0x10 0x4 0x00000900 lic_table_end License table, absolute end offset. Calculated by: license table start + (license amounts * license size)
0x14 0x4 0x00000800 lic_table_start License table, absolute start offset. Always found 0x800 (static)
0x18 0x4 0x00000100 lic_size License size. Always found 0x100 (static)
0x1C 0x4 0x00000001 lic_num License amount. Values found: 0x1 (single boot discs), 0x2 (dual boot discs), 0x3 (triple boot discs)
0x20 0x4 0x8CD3A9D8 crc32 CRC32 from the first byte of LIC.DAT till the end of license table (includes the CRC32 placeholder filled with zeroes)
0x24 ? 0x0000... padding is unknown where the header ends, probablly aligned to 0x200 but there are much more zeroes after it

License table

Composed by one or more license entries.

License entry

Relative Offset Length Example Name Description
0x0 0x1 0x1 id_type 0x01 = Title ID
0x02 = SKU ID
0x03 = Content ID
0x1 0x0A (if id_type = 0x01)
0x2A (if id_type = 0x02)
0x25 (if id_type = 0x03)		 'BLES01623' id Bootable content identifyer (EBOOT.BIN related)
0x0B (if id_type = 0x01)
0x2B (if id_type = 0x02)
0x26 (if id_type = 0x03)		 up to lic_size 0x0000.... padding padding to fill the entry with zeroes up to the "license size" specifyed in the header

Explanation: The first byte indicates type and size of following text:

  • 0x01 means 0xA bytes, a regular TitleID (ex. BLES01623) with \0 terminating
  • 0x02 means 0x2A bytes, a regular SKU ID (ex. UP0002-BLES01623_00-0000111122223333-E001) with \0 terminating
  • 0x03 means 0x25 bytes, a regular npdrm ContentID (ex. UP0002-BLES01623_00-0000111122223333) with \0 terminating

Padding

Padding added at bottom of LIC.DAT file is to make the total size a multiplier of bluray disc sectors, and to protect the laser lens because otherway it is too tiny and so stressing for the laser.

This padding is added in the last step when the file is generated in PC, and removed in the first step before the crc32 hash is validated by the PS3.

Multiboot PS3 Game Discs

There is a special type of PS3 game disc that contains several EBOOT.BIN with several LIC.DAT. These LIC.DAT files are a bit special because contains the TITLE_ID of all the EBOOT.BIN. The first game found using this disc structure was: Metal Gear Solid The Legacy Collection (BLJM-91001 on PS3_DISC.SFB), and the second one: Fighting edition (BLES-02129 on PS3_DISC.SFB).

Total size of the file is always 0x10000, license "slots" starts at 0x800 so... 0x10000 - 0x800 = 0xF800 (available size) and 0xF800 / 0x100 = 0xF8 (available license slots). So the maximun number of bootable contents in a "multiboot disc" is limited to 248 --> Wrong, the path PS3_GM01, PS3_GM02, etc... only allows for 2 digits... so up to 99 + main bootable content in PS3_GAME makes a total of 100.

Exemple of Dualboot: Metal Gear Solid The Legacy Collection (BLJM-91001)

Dual boot disc structure, using folders PS3_GAME, and PS3_GM01.

  • dev_bdvd/PS3_GAME/LICDIR/LIC.DAT
    • Header
      • Magic: "PS3LICDA"
      • Version: 1
      • Flag: 0x80000000 (retail)
      • licenses ending: 0x0A00
      • beginning of licenses: 0x0800
      • license size (static): 0x0100
      • license amounts: 2
      • CRC32: 01 0F 95 0E
    • Licenses
      • First license, type 0x01 = BLJM61001 @ offset 0x800 (for EBOOT.BIN under directory PS3_GAME)
      • Second license, type 0x01 = BLJM60351 @ offset 0x900 (for EBOOT.BIN under directory PS3_GM01)

 

00000000  50 53 33 4C 49 43 44 41 00 00 00 01 80 00 00 00  PS3LICDA....€...
00000010  00 00 0A 00 00 00 08 00 00 00 01 00 00 00 00 02  ................
00000020  01 0F 95 0E 00 00 00 00 00 00 00 00 00 00 00 00  ..•.............
...
00000800  01 42 4C 4A 4D 36 31 30 30 31 00 00 00 00 00 00  .BLJM61001......
...
00000900  01 42 4C 4A 4D 36 30 33 35 31 00 00 00 00 00 00  .BLJM60351......
...
0000FFF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  • dev_bdvd/PS3_GM01/LICDIR/LIC.DAT:
    • The file is the same, only is changed the flag to debug = 0x00000000 (and the crc32 because the flag is included before hash is calculated)
    • This means the file LIC.DAT under directory PS3_GAME is different than any of the others under paths PS3_GM01, PS3_GM_02, etc... (because the flag in main is retail and in the others is debug). But all the others are exactlly the same file because all them have the flag debug.

Example of Tripleboot: Fighting edition (BLES-02129)

Triple boot disc structure, using folders PS3_GAME, PS3_GM01, and PS3_GM02

SCE File Types
Certified File
NPDRM
NPDRM · App Types · ACT.DAT · RIF
PKG
EDAT
RCOXML
CXML
XMBML
XMB Config
DB Config
Databases
System Data
XMB Preload
Licences
 ·
Games/Apps
PS3
Emulators
Web
Unsorted
Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=LIC.DAT&oldid=50293"