Samsung H-Series SmartHub overriding MiniHub images

[hacen]

Hi everyone,

I'm currently reverse engineering the SmartHub UI on a rooted Samsung H-series TV (T-NT14UDEUC-1320.0 firmware).

My goal is to customize some of the built-in SmartHub graphics, such as the MiniHub icons.

So far I have found:

CResourceManager::RegisterImage()
image path strings inside exeAPP, for example:
MiniHub/15_FS/common/fs_icon_clearall_bg.png

I also located the actual resource in:

/mtd_rocommon/Images/MiniHub/15_FS/common/fs_icon_clearall_bg.png

I tried patching the image path in the running exeAPP process (via /proc/<pid>/mem) to redirect it to a PNG stored in /mtd_rwarea/, but nothing changed. The memory patch itself succeeds, so I suspect the image is already loaded or cached before I patch the string.

My questions are:

Does SmartHub cache image resources during startup?
Which function is actually responsible for loading PNGs from Filesystem after RegisterImage()?
Is there any known way to override or redirect built-in MiniHub image resources without rebuilding the firmware?
Has anyone previously patched SmartHub UI graphics at runtime?
My exeAPP link: https://drive.google.com/file/d/1N7N_RD ... sp=sharing

Any pointers to the relevant classes or functions would be greatly appreciated.

Thanks!

[fromul]

Static analysis of your data pack file exeAPP shows that SmartHub does cache images, but not directly during the RegisterImage() call.

The analyzed file has the following SHA-256 hash:

Code: Select all

857da4191fadb4d43f66f58564e1f8f9defd99ddede465b780623891cac57c4b

The addresses below therefore apply specifically to this version of exeAPP.

How image loading works
The simplified call chain is:

Code: Select all

CResourceManager::RegisterImage
        ↓ registers names and creates cache slots only
CResourceManager::GetImage
        ↓
CResourceManager::GetPathOfImage
        ↓ builds the full path
SCImage::Create / SCImage::t_Create
        ↓
SCImageManager::Query
        ↓ cache miss
SCImageFileLoader::LoadFile
        ↓ reads bytes from the filesystem
HWDecoderPNG / GFXIMAGE::LoadPNG / DecodePNG
        ↓
SCImageManager::Add

Relevant addresses:

Code: Select all

CResourceManager::RegisterImage   0x01eefd94
CResourceManager::GetImage        0x02af2fe4
CResourceManager::GetPathOfImage  0x02af3904
SCImage::Create                   0x02789990 / 0x02789ce8
SCImage::t_Create                 0x02788240
SCImageManager::Query             0x02779e38
SCImageFileLoader::LoadFile       0x02783d00
GFXIMAGE::LoadPNG                 0x02793a88
GFXIMAGE::DecodePNG               0x02793dc4
SCImageManager::Add               0x0277a250

RegisterImage() therefore does not open the PNG file. It stores the filename table and item count, and, when caching is enabled, creates an empty array of image pointers. The actual load only happens during the first GetImage() call.
The binary also exports a g_MiniSmartHubImage table containing 382 entries. For example, entry 344 contains:

Code: Select all

MiniHub/15_FS/common/fs_icon_clearall_bg.png

Does SmartHub cache images during startup?
Yes, but lazily:
- The cache is initialized during resource registration.
- When a UI element is rendered for the first time, it calls GetImage().
- The resulting SCImage remains cached by its CResourceManager.
- The decoded image may also remain in the shared SCImageManager cache.
In practice, many images are loaded during SmartHub startup because the initial screens need them immediately.
This explains why changing a filename string through /proc/<pid>/mem after startup may have no visible effect: an SCImage object or decoded shared-cache entry may already exist, so the filesystem path is no longer consulted.

Which function actually loads the PNG?
At the higher level, loading is initiated by:

Code: Select all

CResourceManager::GetImage()

The actual file reading is performed by:

Code: Select all

SCImageFileLoader::LoadFile()

It uses SCFileReadStream::Create, obtains the file size, allocates a buffer, and reads the file. The data is then sent to a hardware, software, or external decoder pipeline.
PNG data is decoded by symbols such as:
HWDecoderPNG
GFXIMAGE::LoadPNGFromStream()
GFXIMAGE::DecodePNG()

Redirecting built-in images without rebuilding the firmware
The most reliable approach is to create a bind mount before the image is accessed for the first time:

Code: Select all

mkdir -p /mtd_rwarea/custom/MiniHub/15_FS/common

cp /path/to/new.png \
  /mtd_rwarea/custom/MiniHub/15_FS/common/fs_icon_clearall_bg.png

mount -o bind \
  /mtd_rwarea/custom/MiniHub/15_FS/common/fs_icon_clearall_bg.png \
  /mtd_rocommon/Images/MiniHub/15_FS/common/fs_icon_clearall_bg.png

However, you should first verify the actual resolved path:

Code: Select all

readlink -f /mtd_appdata/Images
ls -ld /mtd_appdata/Images /mtd_rocommon/Images
mount | grep -E 'appdata|rocommon'

The exeAPP binary contains /mtd_appdata/Images as its image root, while the physical file may be exposed through /mtd_rocommon/Images. The bind mount must affect the path that is ultimately opened by SCFileReadStream.
SamyGO uses the same bind-mount principle to replace files stored on read-only firmware partitions—for example, replacing exeDSP using a file under /mtd_rwarea. SamyGO: ExeDSP modifications.
The startup mount can be placed in /mtd_rwarea/SamyGO.sh so that it is applied before the relevant application starts. SamyGO: Advanced mode startup script

If this firmware or kernel does not support a single-file bind mount, the entire directory can be mounted instead. In that case, the replacement directory must contain all the original files; otherwise, the other icons in that directory will disappear.

A second option is a runtime library injected with samyGOso. It could hook one of the following functions:
- SCImageFileLoader::LoadFile
- SCFileReadStream::Create
- CResourceManager::GetPathOfImage
The hook could rewrite selected paths immediately before the file is opened. Runtime injection using samyGOso is a known technique on H-series televisions, although offsets and ABI details depend on the exact firmware version. Example H-series library using samyGOso
I did not find a publicly available, ready-made “MiniHub image override” specifically for the H series. In practice, I would therefore recommend:
1. Place the modified PNG under /mtd_rwarea.
2. Preserve its dimensions and preferably its PNG color format.
3. Apply the bind mount during boot.
4. Restart the television normally—do not manually terminate exeAPP, as it is a central system process.
5. Only if the bind mount is insufficient, create a small runtime path-redirection hook.
Rebuilding and flashing the firmware merely to replace images should not be necessary and carries a considerably greater risk of bricking the television. SamyGO also documents checksum considerations and the risks associated with modified firmware images. SamyGO: Playing with Firmware Images