Modifying rootfs image

[hedak]

Hallo SamyGO community,

i just wanted to share some information/experience about modifying my C7700's rootfs. My basic knowledge is based on this post: viewtopic.php?f=2&t=68&sid=a378ceaac127 ... 459e0#p343

Following this i wanted to add some CIP rescue scripts in case of cyclic reboot loop (i already had before). Sadly this bricked my 1st partition (once more ) and i had to 'force toggle' to working 1st partition via micom EEPROM content modification. So i hope the following will prevent you from this

Some theory:
At the end of the rootfs's dump there are 20 bytes after a block of about 150kB zero bytes followed by 20 bytes of interest. During my investigation i found out that the miss of these 20 byte bricks the tv as the size comparison of /bin/authuld binary fails (see below). As other members already found out bytes 18 to 15 equal the size of /bin/authuld binary. Furthermore the offset of these bytes are important. Just placing these 20 bytes behind the mksquashed modified rootfs doesn't work neither. I think the offset for these bytes is hardcoded in the corresponding kernel image. I couldn't yet figure out the meaning of the first 16 bytes, maybe one of you knows or has a guess. First 16 bytes are authuld's binary hash: https://forum.samygo.tv/viewtopic.php?f ... 937#p54972

The practical part:
Be warned that doing something wrong will most probably brick your tv. If you don't have the possibility to write on the tv's i2c bus of micom EEPROM you better don't do it!
I tested this ONLY on both partitions of my C7700 T-VALDEUC-3011.0!

rootfs's filesystem is squashfs which is defined to be read-only. That's why you can't mount it on tv and easily modify it. Furthermore you need to know that a process called authuld checks the hash of some images including rootfs during tv boot. So any change on rootfs (and other images) need the recalculation of these hashes and writing it in the correct locations. Basic hash knowledge can be obtained here: http://wiki.samygo.tv/index.php5/Hash_p ... _structure. C series specific dev<->image mapping can be found at the end here: http://wiki.samygo.tv/index.php5/Remove ... rnel_image

Requirements:
Already hacked/rooted tv
Access to tv's filesystem via telnet (i.e. putty as client)
getmkey, download here: http://wiki.samygo.tv/index.php5/Hashes (precompiled contained in chkhash-0.2.zip)
chkhash, download here: https://forum.samygo.tv/viewtopic.php?f ... =50#p54217
Hex editor of your choice
Linux distribution (i used CentOS 5.3 in a virtual machine (preinstalled (just google), any linux will do it i think) using VMware Player)
squashfs-tools 3.0 (creates SQUASHFS 3:0 superblocks as original rootfs) and 3.4 (has '-s' option), download here: http://sourceforge.net/projects/squashf ... /squashfs/


Assuming we are on 2nd partition the procedure of modification is as follows:

1) Dump hash (cmac) image of 1st partition:

Code: Select all

cat /dev/bml0/9 > /mtd_rwarea/bml9_ori.dmp

2) Dump rootfs image of 1st partition:

Code: Select all

cat /dev/bml0/6 > /mtd_rwarea/bml6_ori.dmp

3) Unsquash dump:
This is a little bit extensive: TV natively doesn't support unsquasing. SamyGO extensions have unsquash tool but it didn't work for me (reported errors using Lseek). So i used linux and compiled squashfs-tools 3.0 and 3.4 sources as described here: http://www.tldp.org/HOWTO/SquashFS-HOWT ... html#tools
(at first try compiling failed because of missing zlib.h, so i installed zlib-devel using package manager (i.e. Add/Remove software) in linux)

First get some information about the original rootfs using unsquashfs 3.4:

Code: Select all

unsquashfs -s bml6_ori.dmp > bml6_ori.dmp.stat

Now unsquash it using unsquashfs 3.0:

Code: Select all

unsquashfs -d bml6_ori_unsquashed bml6_ori.dmp

4) Modify extracted rootfs:
Do whatever you want in bml6_ori_unsquashed/ but dont add to much data to not exceeding rootfs's image max size of 3584kB (got this size from 'cat /proc/partitions' and rootfs's dump size: 3670016 Bytes)
DON'T forget to set correct permissions for the files you added. I'm no linux pro, so i also changed owner and group of the files i added to the files placed in the same folder!

NEW: when modifying authuld's binary you have to update its hash (first 16 bytes) and size (last 4 bytes) in step 6)

5) Squash extracted rootfs:
(mksquashfs was compiled when compiling unsquashfs also use mksquashfs 3.0)

Code: Select all

mksquashfs bml6_ori_unsquashed bml6_mod.dmp -le -b 65536

Get some information of the modified rootfs using unsquashfs 3.4:

Code: Select all

unsquashfs -s bml6_mod.dmp > bml6_mod.dmp.stat

Compare bml6_ori.dmp.stat to bml6_mod.dmp.stat and check if the fs parameters match. If you added i.e. four files you should have four more inodes in your modified rootfs.

6) Append the important 20 bytes at the correct offset of modified image:
This step is new relating to the base post!

Open bml6_ori.dmp with the hex editor and go to the end - you will see 0xFF's only. Now scroll up until there are any other bytes then 0xFF. It COULD look like this:

Code: Select all

0037efe0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0037eff0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0037f000h: 05 C7 9B 14 D3 DF 2B A0 88 C3 EB CB 4C A9 3E B5 ; .?.??+?????L?>?
0037f010h: 68 98 00 00 FF FF FF FF FF FF FF FF FF FF FF FF ; h?..????????????
0037f020h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ; ????????????????
0037f030h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ; ????????????????

One important thing seems to be the last two bytes before the two trailing zero bytes (here at offset 0x0037f010: 0x00009868)
That's the size of the authuld's binary. As i didn't append this stuff 20 bytes to my bml6_mod.dmp at first try, my tv was bricked giving this output on exlink:

Code: Select all

[CIP_KERNEL] /dev/tfsr11 can read  (after=0)
[CIP_KERNEL] /dev/tfsr6
[CIP_KERNEL] /bin/authuld size is wrong (pre:-1, real:39016)
[CIP_KERNEL] >>> (/bin/authuld) file is illegally modified!! <<< 
[CIP_KERNEL] authuld authentication failed
[waiterd]System Down.
[waiterd]System Down.
[waiterd]System Down.

(my TV read 0xFFFF (which gave -1 interpreted as signed int16) my TV read 0xFFFFFFFF (which gave -1 interpreted as signed int32) at 0x0037f010 because my dump ended at 0x0035a000 and all (following) bytes were FF'd when restoring the modified dump)

So now we have to append 00's to bml6_mod.dmp up to the offset of the last 20 bytes before the 0xFF block in bml6_ori.dmp (here: offset 0x0037efff) and behind that append the following 20 bytes (here: from 0x0037f000 to 0x0037f014) so that it looks like the byte sequence from bml6_ori.dmp (here: up to 0x0037f014).

Copy bml6_mod.dmp to tv (i.e. to /mtd_rwarea/)

7) Calculate modified dump's hash:
We need the image size of the modified rootfs. There are now three ways to obtain that and ALL of them have to result in the SAME value:
A) in bml6_ori.dmp convert the offset of the start of the 0xFF block from hex to decimal (here: 0x0037f014 -> 3665940)
B) get the filesize of your bml6_mod.dmp
C) open bml9_ori.dmp in hex editor, you will see something like this:

Code: Select all

   00000030h: 11 C6 4B 7F 0E 20 2B 2A 90 C4 38 00 30 27 58 6E ; .?K. +*??8.0'Xn
   00000040h: EC 12 54 88 8E 33 A9 C9 76 67 A9 BA 14 F0 37 00 ; ?.T??3??vg??.?7.

Read the bytes from 0x4F to 0x4C (here: 0037F014). It must be the same as in A) and B)

We use the tool getmkey to get a key for calculating the correct hashes:
Copy it on your tv (i.e. to /mtd_rwarea/) and just run it: /mtd_rwarea/getmkey
The last line gives you the mkey you need at next step (i.e 6f6bc7e1fc7f86bf9c150a82f343e2e0)

We use the tool chkhash to calculate the hash:
Copy it on your tv (i.e. to /mtd_rwarea/) and run it as follows:
/mtd_rwarea/chkhash -k <your_mkey> -h <your_rootfs_size_decimal> bml6_mod.dmp
The last line gives you the hash you need in 8) (i.e B66F4BB690DACBF040B5B746E78E24C4)


8) Write hash of 7) in cmac dump from 1):
Open bml9_ori.dmp in hex editor and replace values from offset 0x3C to 0x4B byte by byte with the hash from 7). Save it as bml9_mod.dmp. I.e. the result should look like this:

Code: Select all

   00000030h: 11 C6 4B 7F 0E 20 2B 2A 90 C4 38 00 B6 6F 4B B6 ; .?K. +*??8.?oK?
   00000040h: 90 DA CB F0 40 B5 B7 46 E7 8E 24 C4 14 F0 37 00 ; ????@??F??$?.?7.

Copy bml9_mod.dmp to tv (i.e. to /mtd_rwarea/)


ATTENTION: NOW you change the tv's filesystem and enter the RISKY way!

9) Flash modified rootfs image of 7):

Code: Select all

bml.restore /dev/bml0/6 /mtd_rwarea/bml6_mod.dmp
sync
sync
sync

10) Calculate and check the hash of flashed modified rootfs image of 1st partition:

Code: Select all

/mtd_rwarea/chkhash -k <your_mkey> -h <your_rootfs_size_decimal> /dev/bml0/6

The hash must be the same as in last step of 7)

11) Flash modified cmac image from 8):

Code: Select all

bml.restore /dev/bml0/9 /mtd_rwarea/bml9_mod.dmp
sync
sync
sync

12) toggle partition:

Code: Select all

sync
/sbin/toggle

pray

Feel free to correct me or suggest some improvements!

Edit: added my firmware version as info
Edit2: corrected statement about interpreting size of authuld's binary size

[beatfreak]

We need the image size of the modified rootfs. There are now three ways to obtain that and ALL of them have to result in the SAME value:
A) in bml6_ori.dmp convert the offset of the start of the 0xFF block from hex to decimal (here: 0x0037f014 -> 3665940)
B) get the filesize of your bml6_mod.dmp

so my modified rootfs image has to be the exact same size as the original?

[hedak]

With my current knowledge: yes!

In detail: the size doesn't really matter (as long as it is smaller than the max size) because you can correct the size and the hash in cmac partition/image. The limiting factor is the need of authuld's binary correct size at the correct offset. But as i wrote above there are still ~150kB of zeroes between real image's end and the location of authuld's binary size. So you could add maybe 140kB of data. (i just added 3kB)

One could try to use the original rootfs image and append some zeroes and correct the cmac partition. I guess it would work, although it wouldn't make any sense

Clear so far?

[beatfreak]

yes, i saw it when i was rethinking the procedure after my post that the "payload" of the rootfs image may differ / be bigger but as we fill the rest with zeros and append a fixed known bytestring (as the size of authuld wouldn't change with mod) the total size of the image wouldn't change.
i think it would be also possible to get these steps done automated with a little exe...
as our crucial 20 bytes dont change/ can be computed and are prefixes by a lot of 00 00 and suffixed by ff ff
the rest should be at the same risk level as a bios update...

and for the record: bml6 from UE40C6500 3011.1

Code: Select all

0037:EFF0 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0037:F000 | 05 C7 9B 14  D3 DF 2B A0  88 C3 EB CB  4C A9 3E B5 | .?..??+?.???L?>?
0037:F010 | 68 98 00 00  FF FF FF FF  FF FF FF FF  FF FF FF FF | h...????????????

[hedak]

Yes, that is imaginable, but luxury

For me it is more interesting to figure out the meaning of the first 16 of theses 20 bytes and where the offset to these 20 bytes is hardcoded/located. Maybe i could do this by zeroing the first 16 bytes of these 20 bytes and see what happens on exlink during boot. Maybe samsung tells me

Edit: OK, the first part was easy: the 16 bytes in front are authuld's hash (calculated the same way as for the images):

Code: Select all

# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 39016 /bin/authuld
Hash: 05c79b14d3df2ba088c3ebcb4ca93eb5, length = 39016

So its only one question left

[hedak]

Second question is answered now too: offset of authuld's hash and size in rootfs is hardcoded in kernel (getAuthUld() in secureboot.c). Hint was given here: viewtopic.php?f=2&t=655&p=15338&hilit=0x1000#p15338
As its stated there, the offset is 0x1000 (4096 decimal) before the end of device of rootfs:

Code: Select all

sys_lseek(fd, -4096, SEEK_END);
sys_read(fd, (void *)mac_authuld, sizeof(MacInfo_t));

Happy rooting

[juusso]