EPK file format

From Openlgtv
Jump to: navigation, search

2009 year models EPK file structure

If you look at epak.py, and u-boot sources (include/swu.h and common/cmd_swu.c).

An epk file is just a concatenation of pak file(s) + a header. Take care all number are little endian (reverse order to human reading)

This header is from 0x00 to 0xcf (208 bytes in total), here is those of 3.15 LH3xxx epk :

65 70 61 6b ca f0 3a 01 08 00 00 00 d0 00 00 00 
84 d0 04 00 54 d1 04 00 a6 34 21 00 fc 05 26 00 
28 b5 66 00 24 bb 8c 00 84 a0 37 00 a8 5b c4 00 
84 20 03 00 2c 7c c7 00 84 10 40 00 b0 8c 07 01 
84 00 30 00 34 8d 37 01 68 64 03 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 15 03 00 
48 45 5f 44 54 56 5f 47 50 5f 4d 5f 41 41 41 41 
41 42 41 41 00 00 00 00 00 00 00 00 00 00 00 00 

65 70 61 6b = magic string "epak" for tools to recognize format of file I suppose

ca f0 3a 01 = 0x013af0ca the file size (without header)

08 00 00 00 = 0x08 means 8 pak(s) in epak

After that for each pak then we have adress and size :

d0 00 00 00 = pak 1 start at 0xd0

84 d0 04 00 = pak 1 size is 0x04d084 bytes

We can see there all start adress and size for the 8 paks and that there is room for 20 paks

After that we have :

00 15 03 00 = 00.03.15.00 epak version

And finally the model name or mdel family name for TV sets for which epak applicable:

48 45 5f 44 54 56 5f 47 50 5f 4d 5f 41 41 41 41 41 42 41 41 = HE_DTV_GP_M_AAAAABAA

Then the remaining space if filled by 0x00.

So doing an epak from pak(s) is quite easy, the hard part is doing pak.

2010 year models secured EPK file structure (EPK2)

  • EPAK securing uses symmetric encryption and digital signatures
  • RELEASE uses OpenSSL's libcrypto library for EPAK securing
  • key that is contained in the file 'general_pub.pem' in lgapp partition of the installed firmware is used only for digital signature verification (RSA-SHA1)
  • first 128 bytes in EPK file are a digital signature (RSA-SHA1) for the file content until offset 1460. So signed content size is 1332d bytes.
  • for each contained PAK segment a header in the EPK file exists
  • PAK segment header starts with a 4-byte lower case type code (like 'lgap', 'lgin', see table) and is followed by 16 bytes payload
  • the first PAK segment header starts at file offset 188
  • PAK segment payload maybe splitted into 1...n chunks
  • each chunk is digitally signed and therefore it was added a prefix of 128 bytes representing the digital signature (RSA-SHA1) of it
  • the first PAK segment (or rather its first chunks signature) starts at file offset 1460 as described in EPAK header
  • the chunk payload is symmetrical encrypted (AES) using a secret key that is different from the RSA-SHA1 key above
  • each decrypted PAK chunk payload is preceded with a 0x80 bytes header containing the 4-byte lower case PAK type code (and some other data that are not relevant for extraction) followed by the filesystem image payload
  • a chunk can contain up to 0x400000 bytes (PAK chunk header excluded) filesystem image payload
 offset 
 0-127  contains signature
 128    65 70 61 6B C4 E9 51 04 07 00 00 00 45 50 4B 32   epak..Q.....EPK2  
 144    01 15 05 03 48 45 5F 44 54 56 5F 47 50 32 42 5F   ....HE_DTV_GP2B_ 
 160    41 46 41 41 41 42 41 41 00 00 00 00 00 00 00 00   AFAAABAA........ 
 176    00 00 00 00 34 05 00 00 04 69 99 00 6C 67 61 70   ....4....i..lgap
 192    F3 AE 64 65 00 00 40 00 38 6E 99 00 80 50 00 00   ..de..@.8n...P..
 208    6C 67 69 6E F5 4A BB 44 00 00 40 00 B8 BE 99 00   lgin.J.D..@.....
 224    00 D3 5A 01 6C 67 72 65 AF A2 33 BC 00 00 40 00   ..Z.lgre..3...@. 
 >      contains more PAK headers
 1460   start of first PAK segment (including signature)
 
 EPAK Header (starts with 'epak')
 --------------------------------
 C4 E9 51 04 -> 0x0451E9C4/72477124d = EPK file size in bytes
 07 00 00 00 -> 0x7/7d = number of contained PAKs
 01 15 05 03 -> 03.05.15.01 = firmware version
 34 05 00 00 -> 0x534/1332d = EPAK header size / first PAK segment offset (with all EPAK/PAK signatures excluded)
 
 PAK segment Header (starts with PAK type code, here 'lgap')
 -----------------------------------------------------------
 38 6E 99 00 -> 0x996E38 = next PAK segment offset (with all EPAK/PAK signatures excluded)
 80 50 00 00 -> 0x580/1408d = next PAKs content length
 Possible PAK types
 ------------------
 BOOT = 0x0,
 MTDI = 0x1,
 CRC3 = 0x2,
 ROOT = 0x3,
 LGIN = 0x4,
 MODE = 0x5,
 KERN = 0x6,
 LGAP = 0x7,
 LGRE = 0x8,
 LGFO = 0x9,
 ADDO = 0xA,
 ECZA = 0xB,
 RECD = 0xC,
 MICO = 0xD,
 SPIB = 0xE,
 SYST = 0xF,
 USER = 0x10,
 NETF = 0x11,
 IDFI = 0x12,
 LOGO = 0x13,
 OPSR/OPEN = 0x14,
 YWED = 0x15,
 CMND = 0x16,
 NVRA = 0x17,
 PREL = 0x18,
 KIDS = 0x19,
 STOR = 0x1A,
 CERT = 0x1B,
 AUTH = 0x1C,
 ESTR = 0x1D,
 GAME = 0x1E,
 BROW = 0x1F,
 CE_F = 0x20,
 ASIG = 0x21,
 RESE = 0x22,
 EPAK = 0x23,
 UNKNOWN = 0x42,


Comments


The bad is that we can't use RELEASE mechanism to flash modified firmware versions because we didn't own (and never will get) the needed private key to sign that custom firmware.

The good thing is that mtd partitions on TV is not crypted. And there is no any verification of it's content (like in Samsung TV's) I see only one way - we need to disassemble RELEASE to know how it decrypt epak.

So for me the questions is whether it is needed to decrypt existing EPAKs while we are not able to use that closed format to install custom firmware via RELEASE.