What about new mtd_exe/rc.local script philosophy?

[geo650]

Hello.
I'd like to ask you (especially developers) if we could change some things in our way of patching the firmware. Until now, we edit /mtd_exe/rc.local script using patching script to add /mtd_rwarea/SamyGO.sh& line before exeDSP is called. This is working well, of course. But...

But there must be SamyGO.sh script placed in /mtd_rwarea directory, where many important files are stored.

My proposal is to create one (root) direcotry for all SamyGO scripts, including starting one. For example, it could be /mtd_rwarea/SamyGO. Then inside this directory we could put all our scripts, make subdirs etc.

Then it would be easier to make backups of our patched environment. You would copy /mtd_rwarea/SamyGO directory with its contents only. Nothing more.

To achieve this, new /mtd_exe/rc.local script should be written. I have prepared such script:

Code: Select all

#!/bin/sh

export MAPLE_DEFAULT_PATH=/mtd_cmmlib/InfoLink/lib
export MAPLE_MANAGER_WIDGET_PATH=/mtd_down/widgets/manager
export MAPLE_NORMAL_WIDGET_PATH=/mtd_down/widgets/normal
export MAPLE_WIDGET_DATA_PATH=/mtd_down
export MAPLE_WIDGET_INCLUDE_PATH=/mtd_down/widgets/inc
export MAPLE_PLUGIN_DATA_PATH=/mtd_cmmlib/InfoLink/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/mtd_cmmlib/YWidget_LIB
export KF_SLEEP_READ=-2
echo 30000 > /mtd_rwarea/DelayValue.txt
#touch /mtd_rwarea/DoPrintYahoo.txt
export KF_NO_INTERACTIVE=1
export KF_LOG=/dev/null

# set SamyGO root directory export
export SamyGOpath="/mtd_rwarea/SamyGO"

# run autorun script in the background (if exists)
if [ -f "$SamyGOpath/autorun.sh" ]; then
$SamyGOpath/autorun.sh&
else
# no autorun script? run telnet
mount -t devpts devpts /dev/pts
telnetd
fi

# run exeDSP.sh script if exists
if [ -f "$SamyGOpath/exeDSP.sh" ]; then
$SamyGOpath/exeDSP.sh
fi

# and run original exeDSP
cd /mtd_exe
./exeDSP

This script should be put into the firmware and flashed into TV.
As you can see, I created an export variable called $SamyGOpath pointing to the root directory of SamyGO files, which could be used in the scripts called later. There is also one more thing: starting script will be located in /mtd_rwarea/SamyGO/autorun.sh. Finally, there is a way to run exeDSP by script (/mtd_rwarea/SamyGO/exeDSP.sh) giving even more possibilites. This rc.local script should work also without any user-scripts: in such case it runs telnet, then exeDSP.

What do you think? Is it too late for such (drastic) modification? Are we ready for changing /mtd_rwarea/SamyGO.sh to $SamyGOpath/autorun.sh ?

[reaper7]

I think that is a great idea - unification - one place for all "mods"!

just tell me - why telnet inside /mtd_exe/rc.local is started only when autorun.sh not exists ?
I understand that if autorun.sh exist - some "*.so" file start telnet,
but for me will be more secure if telnet in rc.local will be run before checking whether autotun.sh exist

[erdem_ua]

I think you forgot something.
Firmware Patcher can change file but not inject bytes to it.
If you inject, FAT structure will broken.
If you enter strings like that, you needed to manually modify exe.img which is dangerous and most of users cannot make such thing.

[geo650]

I think that is a great idea - unification - one place for all "mods"!

just tell me - why telnet inside /mtd_exe/rc.local is started only when autorun.sh not exists ?
I understand that if autorun.sh exist - some "*.so" file start telnet,
but for me will be more secure if telnet in rc.local will be run before checking whether autotun.sh exist

I think telnetd should be started in autorun.sh because it could be easily disabled in case you want to. If we put telnetd before autorun.sh script, then telnetd will start always and cannot be disabled by script. My idea was to allow user to disable telnetd. So why is it run by rc.local when autorun.sh doesn't exist? Because I wanted to allow user to create his/her own autorun.sh in this case.
Of course, it will be good to run telnetd at the very beginning of the autorun.sh script.

I think you forgot something.
Firmware Patcher can change file but not inject bytes to it.
If you inject, FAT structure will broken.
If you enter strings like that, you needed to manually modify exe.img which is dangerous and most of users cannot make such thing.

What do you mean in the word "injection"? I thnink there is no big difference to the present patching script, because we can expand rc.local script by filling zeros of the cluster in which it resides. Only 2 additional bytes must be updated in FAT to correct the file size. When this modification will be made by patching script, it wouldn't be dangerous for anyone. Besides, you can mount ("de-xored") FAT partition before flashing to check if your changes are done well.

[erdem_ua]

I think you forgot something.
Firmware Patcher can change file but not inject bytes to it.
If you inject, FAT structure will broken.
If you enter strings like that, you needed to manually modify exe.img which is dangerous and most of users cannot make such thing.

What do you mean in the word "injection"? I thnink there is no big difference to the present patching script, because we can expand rc.local script by filling zeros of the cluster in which it resides. Only 2 additional bytes must be updated in FAT to correct the file size. When this modification will be made by patching script, it wouldn't be dangerous for anyone. Besides, you can mount ("de-xored") FAT partition before flashing to check if your changes are done well.

I already write FAT table detection for extract file in python script on FW patcher code. We can extract it and inject later but I don't check before cluster sizes and if there is any bytes available to it. So you have a right, we can change file size up to cluster size than. But you code has needed "Bootloop breaker code" check for the USB's usb.sh because If TV enters bootloop, there is no easy way to recover it...

This could be "new advanced way", but needed to change Firmware Patcher to support it.

[arris69]

...
I already write FAT table detection for extract file in python script on FW patcher code. We can extract it and inject later but I don't check before cluster sizes and if there is any bytes available to it. So you have a right, we can change file size up to cluster size than. But you code has needed "Bootloop breaker code" check for the USB's usb.sh because If TV enters bootloop, there is no easy way to recover it...

This could be "new advanced way", but needed to change Firmware Patcher to support it.

i hope you mean logical sector size

arris

[erdem_ua]

Yes, since we talking about FS image, not HDD

[geo650]

I already write FAT table detection for extract file in python script on FW patcher code. We can extract it and inject later but I don't check before cluster sizes and if there is any bytes available to it. So you have a right, we can change file size up to cluster size than. But you code has needed "Bootloop breaker code" check for the USB's usb.sh because If TV enters bootloop, there is no easy way to recover it...

This could be "new advanced way", but needed to change Firmware Patcher to support it.

Because I don't know Python, yesterday, I made my own patching script: one BAT file (with some additional files) for MSWindows that patches the firmware very easily by one click. You cannot damage anything. It produces full firmware directory to put on pendrive from original firmware. I'll share this thing with you after doing full tests on my TV.

I'd like to implement something like "Bootloop breaker code", but there is a problem with that. If you apply USB checking at start, the TV will be starting very slowly becase USB must be "settled down". This mechanism is good enough for SamyGO.sh (autorun.sh) script but is not acceptable for rc.local script or exeDSP.sh script. exeDSP application should start as quick as possible. Or maybe there is another way to protect for bootlooping (without delays)?

[erdem_ua]

I bet that if you tried to write in python, it takes smaller time than coding in batch

[geo650]

I bet that if you tried to write in python, it takes smaller time than coding in batch

Maybe, but I tried and resigned. With my zero-knowledge of Python, I would learn it at least for a few days. Instead of this, I made fully working patching system i one day. Of course, there is also one executable file with this batch. Exe is made in C++ (compiled by gcc) so I think it can be ported to linux, too. Certainly, nobody is forced to use my piece of software

I'm after first test. Almost successful. "Almost" - because there was a bug in my rc.local script: one missed space It is corrected already (in the first post above, too) and I am going to flash my TV again.

------------------
EDIT:

Test #2: Well, now all seems to be functioning as expected. As I promised, there is my patcher attached below. DON'T USE IT IF YOU DON'T KNOW WHAT EXACTLY YOU'RE DOING. Instructions are included in the following archive.

geoPatcher 1.04 - alternative FW patcher for T-CHL7DEUC 2005.0 firmwares only:
http://sourceforge.net/projects/samygo/ ... p/download