Difference between revisions of "Hash partition structure"
m (→B series CI+ TV`s) |
m (→kernel, fnw, u-boot) |
||
| Line 6: | Line 6: | ||
*Hashes of firmware files (exe.img and appdata.img) are stored at other place on TV. begin at offset 0x0.<br> | *Hashes of firmware files (exe.img and appdata.img) are stored at other place on TV. begin at offset 0x0.<br> | ||
| − | == | + | == Hashes on /dev/bml0/3 == |
We have the following structure within this file (at offset 0x1000) | We have the following structure within this file (at offset 0x1000) | ||
[16 bytes kernel hash] [4 bytes kernel length] | [16 bytes kernel hash] [4 bytes kernel length] | ||
[16 bytes uboot hash] [4 bytes uboot length] | [16 bytes uboot hash] [4 bytes uboot length] | ||
[16 bytes fnw hash] [4 bytes fnw length] | [16 bytes fnw hash] [4 bytes fnw length] | ||
| + | [16 bytes authuld hash] [4 bytes authuld length] | ||
| + | [16 bytes rootfs hash] [4 bytes rootfs length] | ||
| + | [16 bytes boot.img hash] [4 bytes boot.img 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 | # hexdump -C ./bml0_3_dump | ||
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| | 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...| | + | 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$.| | + | 00001010 '''{{green|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/.| | 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.....=...| | 00001030 17 00 81 0f b5 78 47 ca b4 ba 02 00 3d 8a 03 f3 |.....xG.....=...| | ||
| Line 33: | Line 35: | ||
000010e0 00 4c 4c 02 00 90 c5 01 07 04 00 00 05 00 00 00 |.LL.............| | 000010e0 00 4c 4c 02 00 90 c5 01 07 04 00 00 05 00 00 00 |.LL.............| | ||
<...> | <...> | ||
| − | Where: hash of kernel is: | + | 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 (hex)is: {{green|e0 3c 2f 00}}, which has to be read {{red|backwards}}. So the real length is: | |
| − | 00 | + | 00 2f 3c e0 = 3095776 (in dec). |
| + | <br> | ||
| + | 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. | ||
<br> | <br> | ||
Revision as of 11:43, 6 January 2013
Article describes structure and partition numbers for most known Samsung TV models.
Contents
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: 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)
[16 bytes kernel hash] [4 bytes kernel length] [16 bytes uboot hash] [4 bytes uboot length] [16 bytes fnw hash] [4 bytes fnw length] [16 bytes authuld hash] [4 bytes authuld length] [16 bytes rootfs hash] [4 bytes rootfs length] [16 bytes boot.img hash] [4 bytes boot.img 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....|
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 comes first and it is:
26 7a 0e f7 6f f0 e4 9f 79 1b c5 74 54 10 2e d9
Image lengh (hex)is: e0 3c 2f 00, which has to be read backwards. So the real length is:
00 2f 3c e0 = 3095776 (in dec).
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.
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:
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! :)
Authuld
After boot of kernel and mounting of rootfs, /sbin/authuld is called and it is checking hashes of active partitions.
On B series (difers from C/D/E series) here are one set of partitions for kernel and rootfs (hashes stored on /dev/bml0/3 AND two sets of firmware files (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 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!
C series TV`s
D series TV`s
E series TV`s
BluRay players
References
Work in progress, to be updated.
