Mercusys h80X / tp-link X50 deco firmware ubinize

For Developers
1

Hi I just go H80X from mercusys for the black friday, which very likely seems to be close to tp-link X50 deco. I'm just willing to get an ssh running on it and ultimately see if I can have 2 differents SSID for 2.4 and 5G network which is not an option from the web/app interface.

First attempt was to look into the board for serial/uart not luck ... (I can apply picture if someone interested no to open the box...

Second option I tried modifying the firmware but I can get the modified firmware accepted.

The firmware itself has 3 main parts:

1/ a 6164 byte header (which seems to be the same for tp-link deco X50) which seemd to start with a 01ba1a7d hex for mercusys H80X, then a 32 bit CRC or MD5 which I can reproduce, then a "fw-type:Cloud", then another section withing a "01 00 aa 55" bloc...

2/ then a ubifs of a kernel image and a rootfs image (which is squashfs). (
img-1203116933_vol-ubi_rootfs.ubifs: Squashfs filesystem, little endian, version 4.0, xz compressed, 23192454 bytes, 2302 inodes, blocksize: 262144 bytes, created: Wed Jul 6 13:08:03 2022)

3/ at last after the ubifs a "support model" section list the supported model of the firmware:

SupportList:
{product_name:H80X,product_ver:1.0.0,special_id:55530000}
{product_name:H80X,product_ver:1.0.0,special_id:45550000}
{product_name:H80X,product_ver:1.0.0,special_id:43410000}
{product_name:H80X,product_ver:1.0.0,special_id:4A500000}
{product_name:H80X,product_ver:1.0.0,special_id:41550000}
{product_name:H80X,product_ver:1.0.0,special_id:4B520000}
{product_name:H80X,product_ver:1.0.0,special_id:49440000}
{product_name:H80X,product_ver:1.0.0,special_id:42340000}
soft_ver:1.1.0 Build 20220706 Rel. 76062
fw_id:0000006AE47B91450B96080000000249
cfg_ver:H80Xh1.0.0V1.1.0P1-63A92A7C04BAEB66D9D8921F1B2C0827

For the header: I could found on the forum that the fw-type:cloud, might mean it try to check RSA key from server, and recommend to change "cloud" by anything else and upload through the u-boot recovery (which you can get into by bootin while pushing the reset button and having an ethernet configured on 192.168.0.xx) but it doesn't work for me as it seems I can't produce the right header for CRC or MD5...

For the ubifs:
I'm able to build the ubifs with the below config an ubinize command

[kernel]
mode=ubi
image=img-1203116933_vol-kernel.ubifs
vol_id=0
vol_type=static
vol_name=kernel
vol_alignment=1
vol_size=6348800

[ubi_rootfs]
mode=ubi
image=img-1203116933_vol-ubi_rootfs.ubifs
vol_id=1
vol_type=dynamic
vol_name=ubi_rootfs
vol_alignment=1
vol_size=23363584

ubinize -v -o /xxxxx.bin -m 2048 -s 2048 -p 131072 -Q 1203116933 ubi.conf

Yet when I try to ubinize the same 2 image from the original firmware I get a very small difference, below hexdump diff (up is generated on, bottom the original one):

295427,295428c295427,295428
< 00482020: 0000 0022 0000 0000 0001 f000 0000 0023  ..."...........#
< 00482030: 0000 0000 2e1a f64e 0000 0000 0000 0000  .......N........
---
> 00482020: 0000 0022 0000 0000 0000 9850 0000 0023  ...".......P...#
> 00482030: 0000 0000 43be 2bef 0000 0000 0000 0000  ....C.+......... 
295430c295430
< 00482050: 9bcf 7a7a ffff ffff ffff ffff ffff ffff  ..zz............
---
> 00482050: 5626 ea8c ffff ffff ffff ffff ffff ffff  V&..............

If anyone has an idea on the MD5 or CR to use to create a proper header, or an idea of the reason for the slight difference between the ubinized generated ubifs ... I could try uploading a modified firmware to the recovery mode...

Thanks.

2

There is no point to attempt anything, until you can get serial console access to the bootloader and can 'safely' try initramfs images. Blindly modifying other firmwares is guaranteed to brick the device, as you can't deduce flash partitioning and similar differences from the binary OEM firmware alone.

1 Like
3

Hi thanks for your message, since the ubifs don't contain any bootloader code, It seems the bootloader recovery firmware update will continue to work even after a wrong firmware woudl be loaded... you can revert to orifinal firmware safely ... Plus the goal here is not to change any partiiton table or kernel image but only the squashfs part to get an ssh / root access.

Benoit

4

Your device - your choice.

But if you don’t know the flash layout you risk overwriting part or all of the ART and permanently killing the wireless interfaces.

Changing anything without a full flash backup and serial access has risks.

5

Good afternoon, any news about the support for the h80x?

6

This looks like it is using the standard TP Link header with MD5 checksums that can be generated by https://github.com/openwrt/firmware-utils/blob/master/src/tplink-safeloader.c

I am digging into the X20, and the firmware looks the same

7

Hello,
please new message on H80X?

8

@slh's reply from Nov '22 still applies.

1 Like