Secure Practice for sharing (selected) MTD contents

A user with the same hardware of two of my routers has had an MTD problem, and has asked for copies. I believe that 0:art is the most crucial one for him.

There are 20 mtd partitions. Which can I share with him, and which should NOT be shared due to the configs (including passwords, etc.) being contained therein. I understand that it will be in Layer3, but I’m not sure which partition(s) that would be.

root@AirDisk2:/tmp# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00180000 00020000 "0:sbl1"
mtd1: 00100000 00020000 "0:mibib"
mtd2: 00380000 00020000 "0:qsee"
mtd3: 00080000 00020000 "0:devcfg"
mtd4: 00080000 00020000 "0:rpm"
mtd5: 00080000 00020000 "0:cdt"
mtd6: 00080000 00020000 "0:appsblenv"
mtd7: 00180000 00020000 "0:appsbl"
mtd8: 00080000 00020000 "0:art"
mtd9: 00900000 00020000 "0:wififw"
mtd10: 00080000 00020000 "0:ethphyfw"
mtd11: 00080000 00020000 "u_env"
mtd12: 00040000 00020000 "s_env"
mtd13: 00040000 00020000 "devinfo"
mtd14: 00800000 00020000 "kernel"
mtd15: 04a00000 00020000 "rootfs"
mtd16: 00800000 00020000 "alt_kernel"
mtd17: 04a00000 00020000 "alt_rootfs"
mtd18: 00200000 00020000 "sysdiag"
mtd19: 04400000 00020000 "syscfg"

Thanks for any guidance you can provide.

There isn't really anything "safe-safe" here.

First of all, it's NAND (assuming based on the size), so there is a topic ECC/ BBT (wear-leveling and badblock handling, which on NAND (usually) is in-band, meaning it can easily end up in your backup (which would be harmful to restore on a different device). Even if you do it 'properly' (with NAND aware tools, like nanddump and friends), 'some' of the early boot (OEM) partitions may need to be raw - it's difficult and needs close inspection.

Second, ART is device specific - it's meant to calibrate the hardware to reality, alleviating component variances. Without expensive (6-figures) calibration equipment and NDA'ed software, it can't be generated/ recovered. Using an ART partition from another device might get the WLAN back up, but it will run out-of-spec, so your CE/ FCC/ MKAA/ etc. certification is null and void (you're in active regulatory violation and subject to being fined and other legal repercussions), but it also means it's more than likely you aren't hitting the frequencies correctly, resulting in bad usability.
ART does reserve storage for the wireless MAC addresses (for each radio), cloning those is never great (deadly, if you're in proximity, messing up geolocation if you aren't - which may cause more subtle issues to you) - not all devices use these MAC addresses though (~= prefer inheriting them from different locations).

On modern devices, all partitions in front/ including u-boot (appsbl) may be singed and checked via secure boot, so any changes there can brick the device - and they are usually not touched by OEM firmware upgrades (appsbl may be upgraded), so the signatures may apply to only certain h/w revision ranges (unclear).

appsblenv, u_env, s_env, devinfo, sysdiag, syscfg all may contain hardware specific data, ranging from MAC addresses to other information used by various OEM firmware (but less commonly OpenWrt), you may find the original wifi- and login access credentials in there, but also VPN certificates used by the OEM firmware (and those may not even be user-upgradable, so remain the same for all eternity).

kernel/ alt_kernel 'should' be relatively safe, but that you can extract from OEM- or OpenWrt images.
rootfs/ alt_rootfs may look innocent at first, until you realize that at least OpenWrt usually splits those into real rootfs and overlay, the later containing all your OpenWrt configuration/ access credentials in clear text. Given that flash isn't regularly zeroed during upgrades, you may find lots of older sensitive info in there.

What is safe to share - or not, pretty much always depends on the individual models and needs careful checking. Modern devices have only gotten more diverse in this regard, than the traditional brcm47xx or ath79 based devices (due to NAND rather than spi-nor, secure boot, mandated device specific access credentials/ wifi pins and much more diverse set of targets and OEM manufacturers).

I strongly suggest to backup the flash partitions (as mentioned, you will have to determine how to do this (BBT or raw) on a case-by-case basis) as soon as you get a new device - and to keep those safe. If you lose it (original and backup), it's game-over. I -very personally- may share some selected partition after careful consideration (the ones that are expected to be generic for all devices of a model range, which of that are that is to be determined/ guessed). sbl1, mibib, qsee (questional), rpm, cdt, appsbl, wififw, ethphyfw (all with the caveats above and considering secure boot) - perhaps. But -for me- none of the others, appsblenv maybe, after careful checking and sanitation (clearing of my MAC addresses, pins, access credentials, OEM config, etc. - so quite some pains involved already). I wouldn't share ART to anyone (at least not if I expect them to flash it, might be different if a develop asks privately for examples to parse it correctly), I wouldn't make myself complicit to intentional regulatory domain violations, nor risk fun with false geoloc stuff.

Take the above with a grain of salt, it really depends on all the details.

1 Like

Unfortunately, ART generally shouldn't be shared. This is because it contains calibration data unique to each individual device.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.