Reverting to OEM FW for WRC-X3200GST3

I have installed OpenWrt on WRC-X3200GST3, but trying to go back to original FW.

it seems OEM FW is already based on OpenWrt 17.01, and taking a look at the header of FW from the manufacturer's page looks just like OpenWRT factory image.

would I follow this guide below, cut off 32 bytes off OEM FW, then mtd -r write?
https://openwrt.org/docs/guide-user/installation/generic.uninstall

Don't follow this guide! There is no general way to go back to stock for all devices. Each device is different in this regard. And as this device is nand/ubi based you cannot use the mtd tool.

The commit for this device does not have instructions for reverting back to stock:

_https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=58b3b557b629f6a2046414e0e1b39189d918133f

I see we have a thread about there already:

_Unbricking the Elecom WRC-X3200GST3

The guy bricked it using mtd.

So I would advise you to wait for someone knowing the device giving you instructions to go back to OEM if possible. This could take a while because this device is rare here. Be patient and don't act like the guy in the thread mentioned above.

1 Like

Thanks for the information, I also read through the link above.
Looks like committer wrote some information in his blog, which states:

  1. He only committed UBI-version, since he did not want to modify original bootloader.
  2. To revert to OEM FW, remove header then split 6MiB from the start of the file, write first part to kernel and rest to ubi partition.

now trying to find out how long header is on the OEM FW....

Y, I've read the same. But through google translate only. So I don't know if this is correct.

In theory kernel and rootfs image should be enough writing it back by booting an OpenWrt initramfs image via serial connection. If you have dual partitions you could write the ones not in use and change the bootorder. But I don't really know anything about this device.

I'm unsure about this 6MB splitting. Ofc its maximum kernel size allowed. But I would do it like:

binwalk --signature --term WRC-X3200GST3_v1.27.bin
->

DECIMAL       HEXADECIMAL     DESCRIPTION
-----------------------------------------------------------------------------------------------------------------------
32            0x20            Flattened device tree, size: 2638628 bytes, version: 17
264           0x108           LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed
                              size: 7862944 bytes
2609604       0x27D1C4        Flattened device tree, size: 28248 bytes, version: 17
2752544       0x2A0020        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 13777791 bytes,
                              2754 inodes, blocksize: 262144 bytes, created: 2022-05-09 01:48:29

-> header = 32

dd if=WRC-X3200GST3_v1.27.bin of=rootfs.img bs=1 skip=2752544 count=13777791

file rootfs.img
-> rootfs.img: Squashfs filesystem, little endian, version 4.0, xz compressed, 13777791 bytes, 2754 inodes, blocksize: 262144 bytes, created: Mon May 9 01:48:29 2022

dd if=WRC-X3200GST3_v1.27.bin of=WRC-X3200GST3_v1.27-noheader.bin bs=32 skip=1

binwalk --signature --term WRC-X3200GST3_v1.27-noheader.bin
->

DECIMAL       HEXADECIMAL     DESCRIPTION
-----------------------------------------------------------------------------------------------------------------------
0             0x0             Flattened device tree, size: 2638628 bytes, version: 17
232           0xE8            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed
                              size: 7862944 bytes
2609572       0x27D1A4        Flattened device tree, size: 28248 bytes, version: 17
2752512       0x2A0000        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 13777791 bytes,
                              2754 inodes, blocksize: 262144 bytes, created: 2022-05-09 01:48:29

dumpimage -l WRC-X3200GST3_v1.27-noheader.bin
->

Image contains unit addresses @, this will break signing
FIT description: ARM64 OpenWrt FIT (Flattened Image Tree)
Created:         Tue Jan  2 07:38:35 2024
 Image 0 (kernel@1)
  Description:  ARM64 OpenWrt Linux-4.4.198
  Created:      Tue Jan  2 07:38:35 2024
  Type:         Kernel Image
  Compression:  lzma compressed
  Data Size:    2609014 Bytes = 2547.87 KiB = 2.49 MiB
  Architecture: AArch64
  OS:           Linux
  Load Address: 0x41080000
  Entry Point:  0x41080000
  Hash algo:    crc32
  Hash value:   af3b9145
  Hash algo:    sha1
  Hash value:   8f6d938c69a6b4ea2e718fb13cca26148191c81d
 Image 1 (fdt@1)
  Description:  ARM64 OpenWrt MTK-AX3200-MT7531 device tree blob
  Created:      Tue Jan  2 07:38:35 2024
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    28248 Bytes = 27.59 KiB = 0.03 MiB
  Architecture: AArch64
  Hash algo:    crc32
  Hash value:   f922ef34
  Hash algo:    sha1
  Hash value:   b2a3095ec197bec41e11c083a7c5e3a66e1b357a
 Default Configuration: 'config@1'
 Configuration 0 (config@1)
  Description:  OpenWrt
  Kernel:       kernel@1
  FDT:          fdt@1
dumpimage -T flat_dt -p 0 WRC-X3200GST3_v1.27-noheader.bin -o kernel.img

So you have kernel and rootfs extracted from OEM firmware.

I don't have enough knowledge about ubiformat. For this someone else needs to help further. Esp. about the paramters which have to be used.

BTW: You could change the title of the topic referencing the device name. Without its a bit broad. If you need help regarding ubiformat you could open a new thread about how to proceed.

Hey pwned,

Thank you for the detailed information, I'll give binwalk with OEM FW a try and study some more.
Since now I know that reverting is more device specific thing for OpenWRT, let me change the topic title to include WRC-X3200GST3.

1 Like

I've used 4 commands here: "binwalk", "dumpimage", "file" and "dd". binwalk is a standalone program, dumpimage is part of u-boot-tools, dd and file are included in each linux distribution.

EDIT: I've found this page:

_https://memo205.wordpress.com/tag/mt7621a/

Seems to be identical with WN-DEAX1800GR?

What is "cat /proc/mtd" showing for your device? If its dualboot you would just need to find out how to change the bootorder assuming that the other partitions are not overwritten during sysupgrade. But even then you could write the kernel and rootfs and change bootorder after without serial access.
It seems also it has tftp boot available via serial access.

EDIT2:

_https://memo205.wordpress.com/tag/wrc-x3200gst3/
According the bootlog there is no dualboot in place:

[    0.481374] 0x000000000000-0x000000080000 : "Preloader"
[    0.487429] 0x000000080000-0x0000000c0000 : "ATF"
[    0.492609] 0x0000000c0000-0x000000140000 : "u-boot"
[    0.498300] 0x000000140000-0x0000001c0000 : "u-boot-env"
[    0.504336] 0x0000001c0000-0x0000002c0000 : "factory"
[    0.510611] 0x0000002c0000-0x000001bc0000 : "firmware"
[    0.541038] 2 fit-fw partitions found on MTD device firmware
[    0.546697] Creating 2 MTD partitions on "firmware":
[    0.551653] 0x000000000000-0x0000003a0000 : "kernel"
[    0.560417] 0x0000003a0000-0x000001900000 : "rootfs"
[    0.586806] mtd: device 7 (rootfs) set to be root filesystem
[    0.592598] 1 squashfs-split partitions found on MTD device rootfs
[    0.598780] 0x000000820000-0x000001900000 : "rootfs_data"
[    0.621120] 0x000001bc0000-0x0000020c0000 : "tm_pattern"
[    0.631675] 0x0000020c0000-0x0000021c0000 : "tm_key"
[    0.637897] 0x0000021c0000-0x0000030c0000 : "user_data"
[    0.658204] 0x0000030c0000-0x000008000000 : "reserved"

But tftp is available:

TFTP from server 192.168.2.2; our IP address is 192.168.2.1

You could ask the manufactuerer if there is any recover without serial possible or consult the manual.

But to me it looks like you have to invoke tftp through uboot console. So you would need to get an usb-to-serial adapter to revert to stock. If you got one then you would be able to restore to factory.

The serial connection is marked on the pictures from the other bricked device. I cannot figure out how the order is. The pictures are to bad. But I can see a VCC label. Never connect anything to VCC. If you don't have experience using serial console ask there or search here in forums.

Mentioned at https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=58b3b557b629f6a2046414e0e1b39189d918133f

1 Like