ES-5300 to ES-6800 and possibly others.
So I have been reading tons of often outdated information on these forums for the last week or so, but I still don't feel any smarter. I can easily get to TDM, after some helpful hints, and also get to the "VDLinux#> ", but there the happy music ends, since we're not allowed to enter any other characters than HEX. I've been playing around with settings and menus to the point of almost bricking my TV several times, driven by the belief that the Samsung service guys must have a hidden setting where they can get full shell access. Now, it's enough and I need some better help.
For reference, these have been the most helpful threads on this topic:
Access Linux Shell of TV on CI+ without "Game Menu" (B)
executing custom script on CI+ (B)
Roll back LExxB5xx, LExxB62x, UExxB6xxx (B)
Hacking TV over Hotel mode (most C series models) (C)
C series shell input filtration removal (C)
Got my D550 back. Came with T-MSV4AUSC. Rooted. (D)
exeDSP from SWU_T-ECPAKUC_001012_I03_ES000KS000RS000_120308 (E)
Review:
To enter the "VDLinux#" shell prompt:
First we have to enter the console unlock code and then the Top Debug Menu
(TDM) code, to get full debug access.
Code: Select all
1198282 <-- From kernel cmdline: "SELP_ENABLE=1198282" ( onboot.bin / u-boot.bin ).
20089999 <-- From the exeDSP binary inside the exe.img disk image.
since terminal echo (or loopback) will be turned on from now on.
Then, after you enter the last code, you will be presented with the TDM:
Code: Select all
[TOP Debug Menu]
--> (11) "TD Debug"
--> (20) "System Shell"
VDLinux#>
we cannot enter anything else than capital hexadecimal characters, backspace,
space and newline: [0-9A-F \b\n]. This filtering is probably due to the config
defines in the VDLinux device driver n_tty.c, in the following code segments:
Code: Select all
...
#define MAX_ARRAY 19
int allow_char[] = {
48, 49, 50, 51, 52, 53, 54, 55, 56, 57 /* 0~9 */,
65, 66, 67, 68, 69, 70 /* A~F */,
32 /*space*/,
13 /*enter*/,
8 /*backspace*/
};
...
#ifdef CONFIG_SERIAL_INPUT_ENABLE_ONLY_NUMBER
// additional checking 0~9, space, enter, backspace, SPTEAM 2010-02-07
check = i = 0;
while(i < MAX_ARRAY ) {
if( allow_char[i] == c ) {
check = 1;
break;
}
i++;
}
if( !check ) return;
#endif
...
This file can be found in the Kernel Sources of UExxES6xxx with this path (after extraction):
/UExxES6xxx/VDLinux_2.6.35.11/linux-2.6.35.11/drivers/char/n_tty.c
So after reading above, we find that one way to circumvent the HEX character limitation, is to try to manipulate the code above, after it has been compiled into machine code. The problem is then to find this code in memory and subsequently write the appropriate changes into that location. Thus it is obvious that different firmwares (and hardware) have different locations, making it difficult to find. In addition, there are a few other things to think about:
- the memory writing abilities of the Debug Menu is very limited and sometimes not accessible (AFAIK), as TZ enabled processors can have memory protected.
- the physical memory location might not be the same as the offest in the exeDSP file.
- the machine code (assembly) for that function may depend on compiler used.
- the machine code in memory depends on the endianess. (ARM == Dual Endian, but little by default, MIPS = big endian.)
- searching huge chunks of memory is unfeasible, unless you are root and can dump the memory with dd , viewmem or lime.
- For each firmware release we need to fire up IDA and search for the code above and dump a minimally, but exclusive hex string, that can be used for an automatic memory search.
- Compare actual running memory offset with file offset (if any).
- Write the binary code into memory while running Debug Menu (if available).
