SamyGO

Here is what I've done to have the full screen stretch:

1) first decoded the exe.img.enc to exe.img (simple XOR with 'T-CHL7DEUC')
2) it is a FAT image so I've opened it with winhex and extracted the exeDSP main elf program that runs on the TV
3) disassembled this exeDSP (full ARM 32bit code) --- took very loooong time

Then finding the code was not so hard:
1) found the 'Fit' and 'Original' unicode messages and found some xrefs to them
2) the xrefs were in a big table called g_ToolsWStringEng
3) it is used in the CToolApp::t_CreateResource routine
4) so after that I saw these resources are loaded dinamically into 'g_ToolResMgr' when you change the OSD language so every messages are handled with their indexes (id).
5) I've checked some xrefs of g_ToolResMgr and then I figured out that there is a CResourceManager::GetWString function with the resource string ID input
6) 'Fit' was the 0x53th and 'Original' was 0x54th string in the ToolsWStringEng list
7) so I tried to find a function where GetWString was called with 0x53 and/or 0x54 ---> CToolMmbDisplaySizeItem::GetToolItemTextData
8) from this routine it can be clearly seen that CMMPlayerWrapper::GetMmpProfile with some special inputs returns 1 for FIT and 2 for ORIGINAL
9) this is when I got stuck ..... tried to continue the steps of SetMmpProfile but ended up with some kind of function pointer tables that are filled in ram so no way to find out where is the picture size set
10) after a while I had the idea check what kind of functions have the 'DisplaySize' in their name and bingo I found these worth checking:
- CMovieCore::CalculateDisplaySize
- CMovieCore::GetDisplaySize
- CMovieCore::SetDisplaySize
11) After deep analyzing the CalculateDisplaySize I saw that case 1,2,3 and "else" handled and case 2 puts the input video frames size into the center of panel screen. Case 3 still don't understand what does but the 'else' case sets DisplaySize the same as PanelSize --> screen is sctreched

So after these I took lots of deep breaths and made the patch (first for case 3 and then case 'else')

So I've modified the PressLeftRightKey and GetToolItemTextData to have 1 and 4 values to DisplaySize variable and then you get the full strech view.

Modified exeDSP written back to the FAT exe.img --- crc32 recalc and write into validinfo.txt and then encode exe.img to exe.img.enc

That's all. Browsing through the code I saw functions where the return value not just the frame size than there are some aspect ratio info is (at least the variable name is that) so I hope some aspect ratio info is recovered by the software "just" not used.

Thank you for explain.
I needed to fix/quest that you said

3) disassembled this exeDSP (full ARM 32bit code) --- took very loooong time

Actualy exeDSP is 64 bit code, right? It uses R0... registers to send variables to functions, don't use stacks for it...

newagehun wrote: [...] 3) disassembled this exeDSP (full ARM 32bit code) --- took very loooong time [...]
Modified exeDSP written back...

Hello everyone. Thank you newagehun for your great work. I've been testing your fix on my TV. Works as expected.

Can you tell us what tools did you use to disassemble exeDSP file and how did you compile it back to exe?

geo650 wrote:

newagehun wrote: [...] 3) disassembled this exeDSP (full ARM 32bit code) --- took very loooong time [...]
Modified exeDSP written back...

Hello everyone. Thank you newagehun for your great work. I've been testing your fix on my TV. Works as expected.

Can you tell us what tools did you use to disassemble exeDSP file and how did you compile it back to exe?

Hi!
You can use any disassembler that supports ARM library. I prefer IDA, the best tool for disassembly. IDA Pro Standard Licenses start at 539 USD or 389 EUR. It's expensive but think as an ferrari of disassemblers. You have some other alternatives, like using DEMO

I've used IDA but forgot to start with IDA x64 and used IDA 32bit so I have now a 32bit IDB file with lots of comments that I wont migrate to ida i64 database (unless there is a converter... anyone know of it? ida x64 cannot open IDB files)

The code is pure 32bit arm code. I haven't seen any THUMB codes (16bit). As usual the c compiler puts first 4 parameters into R0, R1, R2, R3 and if there are more then those are put to stack. Function results are as usual in R0.

How I put back the modification:
1) in IDA I can see that the bytes I want to modify where are in the exeDSP file itself
2) in WinHex I search for the arounding 16-32 bytes in the FAT image --- if one hit found then I modify the fat image

Later if I'll do more complex modifications I'll do it my usual way of patching ARM/THUMB binaries: I've made a KEIL MDK-ARM compatible arm asm/c project that when compiled patches the binary (this way I make code injections also).

Also probably I'll make a update builder tool (puts exeDSP back into the fat image and encode the image and update 32bit checksums).

I think our problem may that the 'TDiMpeg::GetResolutionInfo' functions are not implemented.

I insist lucky numbers for LNXXB6XX series VideoAR Fix on T-CHEAUSC Firmware version 1012.3 (Usualy named as 2009_DTV_1G_firmware.exe)
The Lucky Number is: Warning! This values are for exeDSP only, not for whole IMAGE!
Not verified by executing on tv, But It's same ASM code with LExxB65x, thus it will work as intended.

I've made a new firmware related to this issue. Now the firmware has lot of settings for the display size option:

Fit
Original
Full Screen
4:3
Non Anamorph
16:9
Anamorph
1.85:1
2.35:1
2.37:1
2.39:1
2.76:1

Upon request I can send the sources (asm, c) of the patch or if anyone tell how I can upload to the file section of this project.

Hello!

I've uploaded the sources to the files section. erdem_ua removed all the problematic stuff from the package
The full package can be downloaded from my website.

Why not use hexdiff:
1) don't familiar with it yet
2) I've wrote down my opinion about that in other topic.

NA