Difference between revisions of "Hash partition structure"


From SamyGO
Jump to: navigation, search
(Created page with "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...")
(No difference)

Revision as of 07:33, 6 January 2013

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 changing them may convert TV in to the brick. What for the hell are hashes and how do we calculate them? Read here: Calculate.
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.
Rootfs is also observed, but in different way - it has hash of authuld binary at the end of rootfs image. Hashes of firmware files (exe.img and appdata.img) are stored at other place on TV. We talk about it later. The first 16 bytes from this position are the hash (of the kernel partition), the next 4 bytes are the length to be checked.
We have the following structure within this file (at offset 0x1000)

[16 bytes kernel hash] [4 bytes kernel length]
[16 bytes uboot hash] [4 bytes uboot length]
[16 bytes fnw hash] [4 bytes fnw length]

So, the hash for fnw starts at offset 0x1064 and it's length starts at offset 0x1074. For example, bml0/3 of T-CHLCIPDEUC 2006.0:

# 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....|
000010a0  61 ed fa e0 cb 5b 01 fc  00 90 4a 03 93 81 18 ae  |a....[....J.....|
000010b0  94 9c d6 be cd 6f 02 22  00 4c 4c 02 00 90 c5 01  |.....o.".LL.....|
000010c0  92 4c 61 38 a1 1a f0 0b  61 ed fa e0 cb 5b 01 fc  |.La8....a....[..|
000010d0  00 90 4a 03 93 81 18 ae  94 9c d6 be cd 6f 02 22  |..J..........o."|
000010e0  00 4c 4c 02 00 90 c5 01  07 04 00 00 05 00 00 00  |.LL.............|
<...>

Where: hash of kernel is:

b0 5a b0 71  00 32 84 11 e2 f7 fe 45 a4 83 fe 5e

Kenel`s image lengh (hex)is: 00 e0 0d 00, which has to be read backwards. So the real length is:

00 0d e0 00 = 909312 (in decimal).


The hashes for mtd_exe and mtd_appdata are in /dev/bml0/18 and /dev/bml0/19 for a 1000MB flash type tv (it differs for other flash sizes). /dev/bml0/18 is the 1st strmackeypartition and /dev/bml0/19 is the second one.

Structureis similar to bml0/3, just hashes are at the beginning of file:
the first 16+4 bytes are for mtd_exe, the next 16+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! :)

C series TV`s

D series TV`s

E series TV`s

BluRay players

References

  1. research of cyberdemon79


Work in progress, to be updated.