Hash partition structure

Article describes structure and partition numbers for most known Samsung TV models.

B series CI+ TV`s

Almost all read only partitions on B series are observed by secure boot and modifying them may convert TV in to the brick.
What for the hell are hashes and how do we calculate them? Read here: Hashes.

• Hashes for the u-boot (/dev/bml0/2), fnw (dev/bml0/4) and kernel (dev/bml0/5) are stored in /dev/bml0/3 and begin at offset 0x1000.
• Hashes of firmware files (exe.img and appdata.img) are stored at other place on TV. begin at offset 0x0.
  

Hashes on /dev/bml0/3

We have the following structure within this file (at offset 0x1000)

• Image [16 bytes hash] [4 bytes length]
• u-boot [16 bytes hash] [4 bytes length]
• fnw [16 bytes hash] [4 bytes length]
• authuld [16 bytes hash] [4 bytes length]
• rootfs [16 bytes hash] [4 bytes length]
• boot [16 bytes hash] [4 bytes length]

For example, bml0/3 of T-CHLCIPDEUC 2006.0. The hash for kernel (Image) starts at offset 0x1000 and it's length starts at offset 0x1010:

# hexdump -C ./bml0_3_dump
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  26 7a 0e f7 6f f0 e4 9f  79 1b c5 74 54 10 2e d9  |&z..o...y..tT...|
00001010  e0 3c 2f 00  72 ab f2 09  a8 ea d4 bc e5 4b 24 a8  |.</.r........K$.|
00001020  7b 1d f6 bb  dc 21 04 00  62 41 92 96 d0 4c 2f b1  |{....!..bA...L/.|
00001030  17 00 81 0f b5 78 47 ca  b4 ba 02 00 3d 8a 03 f3  |.....xG.....=...|
00001040  1c f0 b8 15 30 a1 4b f7  42 d8 4d fa b8 95 00 00  |....0.K.B.M.....|
00001050  c0 d5 c5 4b bf 04 e5 28  ef 3b c8 4a 5b 75 aa 07  |...K...(.;.J[u..|
00001060  00 10 33 00 b0 5a b0 71  00 32 84 11 e2 f7 fe 45  |..3..Z.q.2.....E|
00001070  a4 83 fe 5e 00 e0 0d 00  79 f0 81 7f 56 65 61 93  |...^....y...Vea.|
00001080  00 10 31 00 81 6a a0 6c  0a 06 a3 94 23 f4 06 2e  |..1..j.l....#...|
00001090  b8 f0 68 3e 00 b0 0d 00  92 4c 61 38 a1 1a f0 0b  |..h>.....La8....|
<...>
00020000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00080000

Where: hash of kernel comes first and it is:

26 7a 0e f7 6f f0 e4 9f  79 1b c5 74 54 10 2e d9

Image lengh (hexadecimal)is: e0 3c 2f 00, which has to be read backwards. So the real length is:

00 2f 3c e0 (hex) = 3095776 (decimal)

Calculation made with dumps of LE40B650T2P-2006.0 let you understand better structure of bml0/3:

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -L 0x1000 8 bml0_3_dump *
hash[ 0] = 267a0ef76ff0e49f791bc57454102ed9   length =  3095776  :  bml05.dmp
hash[ 1] = 72abf209a8ead4bce54b24a87b1df6bb   length =   270812  :  bml02.dmp
hash[ 2] = 62419296d04c2fb11700810fb57847ca   length =   178868  :  bml04.dmp
hash[ 3] = 3d8a03f31cf0b81530a14bf742d84dfa   length =    38328  :  authuld
hash[ 4] = c0d5c54bbf04e528ef3bc84a5b75aa07   length =  3346432  :  bml06.dmp
hash[ 5] = b05ab07100328411e2f7fe45a483fe5e   length =   909312  :  bml07.dmp

Now you will know, that after you modify any of those partitions, you have also modify hex signature (hash) as well. MANDATORY at same TV session. Don`t reboot you you haven`t restored hash partition with updated hashes.

exe.img and appdata.img

The hashes for mtd_exe and mtd_appdata are in /dev/bml0/18 and /dev/bml0/19 for a 1Gb flash type TV models (it differs for other flash sizes).

Structureis similar to bml0/3, just hashes are at the beginning of file:

• mtd_exe [16 bytes hash ] [4 bytes lengh], the next [16 bytes ] [4 bytes] are for mtd_appdata
  

For example T-CHLCIPDEUC-2006.0:

00000000  43 72 15 c3 a6 ff 21 14  ac ac 65 9f cd 5a 25 eb  |Cr....!...e..Z%.|
00000010  00 f0 40 03 07 7c b3 32  41 ec cd b1 dd f0 40 fd  |..@..|.2A.....@.|
00000020  f4 21 82 9d 00 d0 ca 01  00 00 00 00 00 00 00 00  |.!..............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Hash of exe.img:

43 72 15 c3 a6 ff 21 14  ac ac 65 9f cd 5a 25 eb

Lengh of it: 00 f0 40 03, but backwards it is:

03 40 f0 00 = 54587392 bytes (decimal)

This is exact size in bytes of decrypted exe.img! :)

./chkhash -k 7CED26D8CA2FA0F80BC637E2FF07EC46 -L 0x0 3 bml19.dmp *
hash[ 0] = d960b582b2ad80eb3203c6bc23735bca   length = 54587392  :  exe.img
hash[ 1] = 077cb33241eccdb1ddf040fdf421829d   length = 30068736  :  appdata.img

Authuld

After boot of kernel and mounting of rootfs, /bin/authuld is called and it is checking hashes of active partitions and authuld itself.
It is important to understand that this check takes some time (this is the delay experienced until authuld reboots the system if it detects modifications, should be approx 1 minute). If it matches, nothing happens (besides an authuld completed successfully message), if it doesn't match, the kernel tells Micom to reboot the system (Micom cmd 143).

On B series (differs from C/D/E series) here are one set of partitions which is always checked (hashes stored on /dev/bml0/3 AND two sets of firmware files (checked only active). Example LExxB650T2P:

1nd. /dev/bml0/8 and /dev/bml0/10
2nd. /dev/bml0/9 and /dev/bml0/11

After authuld finishes checking of partitions whose hashes are stored on /dev/bml0/3, it starts to check firmware active partitions, depends from what boot flag is present on /mtd_rwarea:

PartitionSwitch_0_0 - 1st set of partitions is booting and hashes are checked on 1st strmackeypartition
PartitionSwitch_1_0 - 2nd set of partitions is booting and hashes are checked on 2nd strmackeypartition

At boot time neither hashes of alternative (inactive) partitions, nor its strmackeypartition are checked.

Known numbers of strmackeypartitions

1Gb flash size B series models (like B650...)

/dev/bml0/18 is the 1st strmackeypartition
/dev/bml0/19 is the 2nd strmackeypartition

2Gb flash size B series models (like B7000/8000...)

/dev/bml0/16 is the 1st strmackeypartition 
/dev/bml0/17 is the 2nd strmackeypartition

128Mb flash size models (like B550...)

/dev/bml0/13 is the 1st strmackeypartition 
/dev/bml0/14 is the 2nd strmackeypartition

Key partition

We until today don`t know what is stored on that partition and what is used this info for.
For above mentioned models it`s number is:

1Gb flash - /dev/bml0/20
2Gb flash - /dev/bml0/18
128Mb flash /dev/bml0/15

Example of hex data on that partition (1Gb flash, T-CHLCIPDEUC 2006.0)

hexdump -C ./bml20.dmp
00000000  27 07 79 19 2d 65 f1 22  86 29 40 6c 90 0d af 55  |'.y.-e.".)@l...U|
00000010  17 c7 99 2a 27 07 79 19  ff ff ff ff ff ff ff ff  |...*'.y.........|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00100000

If anyone has some ideas, what is needed for, please share with us on forum. Thanks!

References

1. research of cyberdemon79

C series TV`s

Almost all read only partitions on C series are observed by secure boot and modifying them may convert TV in to the brick.
What for the hell are hashes and how do we calculate them? Read here: Hashes.

For knowing what it's talked about here is the whole partition list of a UE46C7700 T-VALDEUC 3011.0:

# cat /mtd_exe/partition.txt
partitionID flash_device_name flash_device_size flash_image_name flash_device_type flash_upgrade_type	flash_partition_map flash_mount_path default_block_size flash_format_option flash_mount_option
0  /dev/bml0/1  262144    onboot.bin    DEVICE OTHER BOOTLOADER0 NONE         	262144	NONE	NONE
1  /dev/bml0/2  262144    u-boot.bin    BML    OTHER BOOTLOADER1 NONE         	262144	NONE	NONE
2  /dev/bml0/3  262144    uboot_env.bin BML    OTHER BOOTLOADER2 NONE         	262144	NONE	NONE
3  /dev/bml0/4  262144    fnw.bin       BML    OTHER BOOTLOADER3 NONE         	262144	NONE	NONE
4  /dev/bml0/5  4194304   Image         BML    USER  KERNEL0     NONE         	262144	NONE	NONE
5  /dev/bml0/6  3670016   rootfs.img    BML    USER  RFS0        NONE         	262144	NONE	NONE
6  /dev/bml0/7  4194304   Image         BML    USER  KERNEL1     NONE         	262144	NONE	NONE
7  /dev/bml0/8  3670016   rootfs.img    BML    USER  RFS1        NONE         	262144	NONE	NONE
8  /dev/bml0/9  262144    NONE          BML    OTHER SECUREMAC0  NONE         	262144	NONE	NONE
9  /dev/bml0/10 262144    NONE          BML    OTHER SECUREMAC1  NONE         	262144	NONE	NONE
10 /dev/bml0/11 262144    key.bin       BML    OTHER SECUREMAC2  NONE         	262144	NONE	NONE
11 /dev/bml0/12 262144    NONE          BML    OTHER NONE        NONE         	262144	NONE	NONE
12 /dev/stl0/13 11272192  NONE          STL    OTHER NONE        /mtd_contents	4096	ERASE:,STL:-r_7,FAT:-S_1024_-s_1 -t_rfs_-o_codepage=utf8
13 /dev/stl0/14 26214400  NONE          STL    OTHER NONE        /mtd_rwarea	4096	ERASE:,STL:-r_7,FAT:-S_1024_-s_1 -t_rfs_-o_codepage=utf8
14 /dev/stl0/15 93323264  exe.img       STL    USER  EXE0        /mtd_exe	4096	ERASE:,STL:-r_2	NONE
15 /dev/stl0/16 58195968  appdata.img   STL    USER  APP_DATA0   /mtd_appdata	4096	ERASE:,STL:-r_2	NONE
16 /dev/stl0/17 93323264  exe.img       STL    USER  EXE1        /mtd_exe	4096	ERASE:,STL:-r_2	NONE
17 /dev/stl0/18 58195968  appdata.img   STL    USER  APP_DATA1   /mtd_appdata	4096	ERASE:,STL:-r_2	NONE
18 /dev/stl0/19 52953088  rocommon.img  STL    OTHER CONTENT0    /mtd_rocommon	4096	ERASE:,STL:-r_2	NONE
19 /dev/stl0/20 104857600 NONE          STL    OTHER NONE        /mtd_swu	4096	ERASE:,STL:-r_16,FAT:-S_4096_-s_4 -t_rfs
20 /dev/stl0/21 411566080 NONE          STL    OTHER NONE        /mtd_rwcommon	4096	FAT:-S_4096_-s_1 -t_rfs_-o_codepage=utf8

Just for completeness: SECUREMAC2 (/dev/bml0/11) is the strmackeypartition here.

Typical hash data structure

For all hashes the structure is as follows:
[16 bytes hash][4 bytes length]

16 bytes hash is calculated using chkhash.
4 bytes length is the byte count the hash is/was calculated over. It is stored backwards (see B series for details).

Partition hash data

The hashes of the images exe.img, appdata.img, Image (kernel) and rootfs.img are stored in that order sequentially within a separate partition, sometimes called cmac (hash) partition. These four images are stored in separate partitions. As all four partitions exist twice (one for active set, one for inactive set) there also exist two cmac partitions: SECUREMAC0 and SECUREMAC1

During boot process the hashes of inactive partition are not checked.

The relation is as follows:
SECUREMAC0 (/dev/bml0/9): EXE0 (/dev/stl0/15), APP_DATA0 (/dev/stl0/16), KERNEL0 (/dev/bml0/5) and RFS0 (/dev/bml0/6)
SECUREMAC1 (/dev/bml0/10): EXE1 (/dev/stl0/17), APP_DATA1 (/dev/stl0/18), KERNEL1 (/dev/bml0/7) and RFS1 (/dev/bml0/8)

For example cmac partition for 2nd partition set (/dev/bml0/10) of T-VALDEUC 3011.0 looks like this:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  48 F5 8B FA 80 50 D8 8E A1 75 79 57 DC F7 EB C5  Hõ‹ú€PØŽ¡uyWÜ÷ëÅ
00000010  00 70 55 05 58 03 6F E3 6C 3F E1 58 56 13 A9 45  .pU.X.oãl?áXV.©E
00000020  51 AE 92 00 00 40 7D 02 7E E4 E5 37 96 1A A0 DE  Q®’..@}.~äå7–. Þ
00000030  C4 95 3B AE D4 AD CE 99 90 A4 38 00 9B 86 63 05  Ä•;®Ô.Ι.¤8.›†c.
00000040  0A 8F FA 3B 66 07 BA 93 1D BF BE 2B 14 F0 37 00  ..ú;f.º“.¿¾+.ð7.
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Where

48 F5 8B FA 80 50 D8 8E A1 75 79 57 DC F7 EB C5

is the hash of exe.img (stored in /dev/stl0/17), the image byte size is 0x05557000 (00 70 55 05 read backwards)

58 03 6F E3 6C 3F E1 58 56 13 A9 4 51 AE 92 00

is the hash of appdata.img (stored in /dev/stl0/18), the image byte size is 0x027D4000 (00 40 7D 02 read backwards)

7E E4 E5 37 96 1A A0 DE C4 95 3B AE D4 AD CE 99

is the hash of Image (kernel) (stored in /dev/bml0/7), the image byte size is 0x0038A490 (90 A4 38 00 read backwards)

9B 86 63 05 0A 8F FA 3B 66 07 BA 93 1D BF BE 2B

is the hash of rootfs.img (stored in /dev/bml0/8), the image byte size is 0x0037F014 (14 F0 37 00 read backwards)

authuld hash data

The binary authuld is stored within read-only rootfs partition (is NOT image!). Although rootfs's hash is already checked authuld's hash is checked separately! authuld's hash is stored 0x1000 (4096 dez) byte in front of the end of partition (is NOT image!) rootfs.

For example rootfs partition for 2nd partition set (/dev/bml0/8) of T-VALDEUC 3011.0 looks like this:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0037EFF0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0037F000  05 C7 9B 14 D3 DF 2B A0 88 C3 EB CB 4C A9 3E B5  .Ç›.Óß+ ˆÃëËL©>µ
0037F010  68 98 00 00 FF FF FF FF FF FF FF FF FF FF FF FF  h˜..ÿÿÿÿÿÿÿÿÿÿÿÿ
0037F020  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Notice: Referring to the partition list written above the partition size of rootfs is 3670016 byte (0x380000). So the hash data for authuld is located at offset 0x37F000 (0x380000 - 0x1000).

Where

05 C7 9B 14 D3 DF 2B A0 88 C3 EB CB 4C A9 3E B5

is the hash of binary authuld, the binary byte size is 0x00009868 (68 98 00 00 read backwards)

After boot of kernel and mounting of rootfs, /bin/authuld is called and it is checking hashes of active partitions and authuld itself. It is important to understand that this check takes some time (this is the delay experienced until authuld reboots the system if it detects modifications, should be approx 1 minute). If it matches, nothing happens (besides an authuld completed successfully message), if it doesn't match, the system reboots.

Bootlader hashes

Not available as far as i could figure out. (maybe because its not used (anymore))

References

1. Modifying /mtd_exe of active partition
2. Patch kernel image
3. Modifying rootfs image

D series TV`s

ToDo

E series TV`s

ToDo

F series TV`s

ToDo

BluRay players

ToDo

Work in progress, to be updated.