Next step after telnet access?

[patois]

Hi,

I have rooted my UE55ES6100 using the SmartHub / Test2 application and can connect to it using ftp and netcat/telnet. Now what would be the next step in getting SamyGO extensions to install? I am on a relatively new firmware (v1031). I have spent quite some hours on the forums and the wiki but didn't find explicit information stating on whether SamyGO can be run on my device and whether downgrading/unrestricting the TV is possible. I'll be most grateful for any help!
Thanks in advance,
Dennis

[E3V3A]

I have spent quite some hours on the forums and ...

Don't start your posts with lying.

[patois]

Thanks for your qualified post.

Anyone else willing to help?

[juusso]

actually - nope. Root access is to dangerous and if you don`t know what to do, root access on TV is not best place to start. You can brck TV easily.
In other hand, here is almost nothing what you could improve on E series trough telnet. So this is senseles and has big danger to brick. I hope you understand that we want save your nerves and pocket?

[patois]

hey, thanks for your quick reply! I absolutely understand that you want to protect people from bricking their TVs. Anyway, I would really appreciate being given the information I kindly asked for. If I gonna brick the TV, I won't come back and complain It's just that I did not find the info that I was looking for. Again, thanks a lot for any help.

[patois]

does one have to post disassembled code first in order to be helped?

[Asure]

I agree root is a bad place to start if you damage the filesystem, but i think patois has some experience and won't be killing his tv with some bad chown or rm command.. (correct me if i'm wrong.)

I guess the ES6100 is already a powerfull (and cheap) beast which has most of the features Samy would add. Except SMB mounting maybe.

Out of personal interest, can you post the /proc/cpuinfo, 'free' memory details, 'df' output and 'mount' info? I'm curious to see what's inside in hardware-terms

[patois]

Sorry for the late reply.

Code: Select all

shell>less /proc/cpuinfo
Processor       : ARMv7 Processor rev 0 (v7l)
processor       : 0
BogoMIPS        : 1794.04

processor       : 1
BogoMIPS        : 1794.04

Features        : swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

Hardware        : amber3
Revision        : 0000
Serial          : 0000000000000000
shell>

Code: Select all

shell>free
             total         used         free       shared      buffers
Mem:        509076       504740         4336            0        79916
-/+ buffers:             424824        84252
Swap:       102396            0       102396
shell>

Code: Select all

shell>df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 4208      4208         0 100% /
tmpfs                   254536         8    254528   0% /dev/shm
tmpfs                    40960        24     40936   0% /dtv
tmpfs                    36864      6460     30404  18% /tmp
tmpfs                    12288         0     12288   0% /dsm
tmpfs                    30720         0     30720   0% /core
/dev/mmcblk0p14          98176     98176         0 100% /mtd_exe
/dev/mmcblk0p12          70824      6543     64281   9% /mtd_rwarea
/dev/mmcblk0p10           2872       173      2700   6% /mtd_drmregion_a
/dev/mmcblk0p11           2872       172      2700   6% /mtd_drmregion_b
/dev/mmcblk0p16          45056     45056         0 100% /mtd_appext
/dev/mmcblk0p17         113536    113536         0 100% /mtd_rocommon
/dev/mmcblk0p19          49992        96     49896   0% /mtd_contents
/dev/mmcblk0p21         950208    442448    507760  47% /mtd_rwcommon
/dev/mmcblk0p18         101120     84144     16976  83% /mtd_emanual
/dev/mmcblk0p20           9896         4      9892   0% /mtd_swu
/dev/sda1       
shell>

Code: Select all

shell>mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /dtv type tmpfs (rw,relatime,size=40960k)
tmpfs on /tmp type tmpfs (rw,relatime,size=36864k)
tmpfs on /dsm type tmpfs (rw,relatime,size=12288k)
tmpfs on /core type tmpfs (rw,relatime,size=30720k)
/dev/mmcblk0p14 on /mtd_exe type squashfs (ro,relatime)
none on /sys/fs/cgroup type cgroup (rw,relatime,cpu)
/dev/mmcblk0p12 on /mtd_rwarea type rfs (rw,relatime,vfat,llw,iocharset=utf8)
/dev/mmcblk0p10 on /mtd_drmregion_a type rfs (rw,relatime,vfat,llw,iocharset=utf8)
/dev/mmcblk0p11 on /mtd_drmregion_b type rfs (rw,relatime,vfat,llw,iocharset=utf8)
/dev/mmcblk0p16 on /mtd_appext type squashfs (ro,relatime)
/dev/mmcblk0p17 on /mtd_rocommon type squashfs (ro,relatime)
/dev/mmcblk0p19 on /mtd_contents type rfs (rw,relatime,vfat,llw,iocharset=utf8)
/dev/mmcblk0p21 on /mtd_rwcommon type rfs (rw,relatime,vfat,llw,iocharset=utf8)
/dev/mmcblk0p18 on /mtd_emanual type rfs (rw,relatime,vfat,llw,iocharset=utf8)
/dev/mmcblk0p20 on /mtd_swu type rfs (rw,relatime,vfat,llw,iocharset=utf8)
none on /proc/bus/usb type usbfs (rw,relatime)
/dev/sda1 on /dtv/usb/sda1 type
shell>

Probably not the right thread to ask but does gdb work for you guys over a TCP/Telnet session?
As soon as I attach gdb to the exeDSP pid, the tv freezes/reboots. How do I solve this?

Thanks

[patois]

ok, never mind, I think I just found the answer myself. The firmware apparently employs various anti debugging mechanisms.
I thought I'd share my findings in case anyone's interested.

In an interval of 5 seconds,
1. exeDSP checks whether its parent pid has changed
2. exeDSP reads "/proc/self/status" and checks wether "TracerPid" is present with a pid that is != 0 (they managed to f*ck this up by introducing multiple logic bugs...)

If any of the above evaluates to true, the TV is rebooted by either executing (depending on their presence on the FS)
1. /sbin/reboot
2. /sbin/shutdown -t 0 -r
3. /sbin/micom reboot
4. /mtd_exe/MicomCtrl 143

edit: in an interval of three seconds, exeDSP also checks whether its ppid has changed. If a change is detected, exeDSP attempts to attach to the ppid's process.
On failure (which is the case with gdb for example), it executes one of the above mentioned commands in order to reboot the TV.

There should be various ways to patch this - the ADBG_Start() symbol should be a good starting point.

Have fun!

[juusso]

wow, great findings! thanks. Info is usefull for someone. Definitelly

p.s. don't stop please.