My latest version of tools, which includes getmkey, calchash (it was renamed to chkhash because I have added many useful options, including hash search, etc.) and script mknewfs.sh to build new rootfs, mtd_exe, mtd_appdata as squash filesystem, calculate hashes and write them to correct files and correct offsets, so that these files will be ready to write to firmware... All this stuff (with source code, of course) is uploaded here:
Please, read file README, script mknewfs.sh, and check everything for possible errors before doing anything with your firmware. This toolkit does not include tools for writing firmware and switching partitions, as they can be different for various devices. So, be careful.
Don't worry, you did not. I have asked you about the bug just because you said it without any explanation.probutus wrote:sorry, I did not want to insult you, it was just a question...
Well, in theory yes and I don't know why the module gives different result.- the output from the kernel module gave me this decrypted key: "c0 34 6d bf 20 5b 9e dd e4 7e d1 dc d0 7e d1 dc". Shouldn't be the results identical?
I think that all TVs or bluray players which have identical firmware have identical keys. And different families of devices have different keys. Moreover, it seems that cryptoengine in different models is programmed differently in bootloader or in the kernel (I did not check that). Latest version of getmkey.c accepts cmac key from the command line, so I tried to run it with the seed from the T-VALDEUC TV but the mkey produced by cryptoengine in my bluray player did not match with the real mkey from that TV. Therefore, besides the seed stored in /dev/tfsr11 there is something else for initialization of cryptoengine...- Are the decrypted mkeys identical for all tv's ? (so the cmac key is just a personalized encrypted version of the mkey)?