[solved] Cycle reboot UE46C7700 - T-VALDEUC

[juusso]

But there is not enough time to flash i suspect

you lose nothing

Code: Select all

stl.restore /dev/stl0/17 /mtd_swu/exe.img
sync

ps, chkhash i use on my old armv5 based NAS. Good news about filesize
p.p.s. FF are empty bytes and tool (the exeDSP as well) skips it for hash calculations. It is enough to reflash cutted binary (w/o ff`s) and that`s all.

[hedak]

ps, chckhash i use on my old armv5 based NAS. Good news about filesize

Ahh, i already read somewhere here

you lose nothing

Hmmm, ATM it's working somehow. But if flash/restore fails (broke up because of forced shutdown) and some exeDSP byte (for example) get crippled it's not working anymore! -> I will first try to calculate the correct hashes.

BTW, do you have a working toolchain for C series to build chkhash for me? That would really help a lot! Otherwise i cannot check the hashes on the tv and never be sure...

PS: to flash only the cutted binary of the dump means: 85,3MByte

[juusso]

no need to recompile, older arm versions are supported automatically by never ones!

Code: Select all

./chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 89485312 ./stl17.dmp 

[hedak]

Ohhh, thank you very much for the working chkhash! v0.02 didn't run :/

It seems as if chkhash doesn't ignore FF's (or i misunderstood you ):

Code: Select all

# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 89485312 /mtd_rwcommon/stl17.dmp
Hash: 9471d1acb79458834655c4c382392cc6, length = 89485312
# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 0 /mtd_rwcommon/stl17.dmp
Hash: 6d7d81d7b54bb38950274f1d27d854f1, length = 93323264

Then some strange length output(/dev/stl0/16 is exe.img from 1st partition, /18 from 2nd):

Code: Select all

# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 0 /dev/stl0/16
Hash: 8887f9c275a1a5d22e70e2bba0327553, length = 58195968
# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 0 /dev/stl0/18
Hash: befbb4f6ee76cc52aaee496f9bea2d53, length = 58195968
# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 89485312 /dev/stl0/18
Wrong input data. Check if file /dev/stl0/18 exists and its size is less or equal to 89485312 bytes

But finally the hash for decrypted exe.img was correct:

Code: Select all

# /mtd_rwarea/chkhash -k 6f6bc7e1fc7f86bf9c150a82f343e2e0 -h 0 /mtd_rwcommon/exe17.img
Hash: 48f58bfa8050d88ea1757957dcf7ebc5, length = 89485312

So i can calculate the hash for my dumped modified partition

[hedak]

OK, FINALLY IT WORKED! TV doesn't shutdown anymore! chkhash did the trick!

(i will check if all features are working again, on friday - as is still get '##### System Execution!!! #####' right after 'Application is started..')

Thank you so much!

PS: if everything is working fine again now, i will do some EEPROM research with you as promised

[juusso]

Congratts! Well, i was incorrect, FF are to be cutted off while calculating hash, but doesn`t matter when flashing. Anyway, everything worked, glad to know.
Sure i would like you chekced eeprom thing!

btw, if interested, full shell enabled kernel is ready for T-VALDEUC - no more input restrictions on exlink.

[greenhorn]

Great job guys. This one should go on wiki....
@juuso
Do FW upgrade affect full shell enabled kernel is ready for T-VALDEUC? I already had on FW 3005.1. Later I updated to 3009 and now 3011.

[juusso]

yes, fw upgrade change kernel.

[hedak]

After a one day break of celebrating my tv's resurrection i'm back

I attached a compiled chkhash (32 bit) for windows (compiled under win7x86 using mingw). I had to add 'O_BINARY' to open() calls (otherwise files were opened in textmode (thx windows) and reading the first 0x00 would fail the operation). It calculated all my hashes correctly If this upload harms any license regulations please remove it.

My next step is to repair the 1st partiton (just hash of exe.img). Then the kernel's input filtration follows (although this is interesing too: viewtopic.php?f=10&t=1818)
Is there any interest of dumping cuurent fw of 1st partition: T-VALDEUC-1001.4

EDIT: updated attachment (added 'O_BINARY' flag to all open())

[juusso]

1. Prepare one full working set of partitions and switch to (current ressurected 2nd partition)
2. Do whatever you like on 1st set of partittions (kernel/rootfs/exe...)

you will always able to switch to 2nd stable set if something go wrong. Don`t touch any of bml`s0-4...

p.s. no problem, thanks for chkhash32!
p.p.s

(although this is interesing too: viewtopic.php?f=10&t=1818)

No, this is wrong way, you have to bml.restore patched kernel + correct i`ts hash in key partition like you did it for exe.img
correct approach here: viewtopic.php?f=10&t=2165