Add Tuya TYGWZ-01 / TuyaGo TYGWZ01 pictures and links to project website

[Hedda]

Pictures of Tuya TYGWZ-01 / TuyaGo TYGWZ01 and links to official product page is missing project website:

https://paulbanks.org/projects/lidl-zigbee/

Suggest mention "Tuya TYGWZ-01 (also known as TuyaGo TYGWZ01)" as well as add links plus one or a few images:

Product dimensions：90x90x23mm (Package dimensions：1000x1000x50mm)

https://go.tuya.com/en/productDetail?code=83jt6kkktau3

https://zigbeealliance.org/zigbee_products/tuya-smart-gateway/

The obvious advantage of the original TYGWZ-01 (non-Lidl/Silvercrest) gateway is its availability outside of Europe.

Such wide availability should benefit all people and project whose goal it is to hack it for other purposes than its intended use.

It is also sold under different rebranded names such as Lonsonho, Moes, BENEXMART, Kstyhome, Moniclern, OWSOO, Zemismart, as well as in combination with Zigbee devices:

https://www.amazon.com/Zigbee-Switch-standard-Control-gateway/dp/B082B2FT6V

https://www.amazon.com/Gateway-Control-Temperature-humidity-gateway/dp/B083PRPYQ8/

https://www.amazon.com/OWSOO-Gateway-Wireless-Control-Compatible/dp/B08YNG15XQ

https://www.amazon.com/Moniclern-Powered-Gateway-Connection-Products/dp/B08HV1BNLG

https://www.amazon.com/Kstyhome-Powered-Gateway-Connection-Products/dp/B08XY37L49/

https://www.amazon.com/OWSOO-Powered-Gateway-Connection-Products/dp/B08768DMJJ/

https://www.amazon.com/OWSOO-Temperature-Humidity-Automation-Security/dp/B0868QJ1NV/

https://www.amazon.com/OWSOO-Temperature-Humidity-Automation-Security/dp/B0868NZHJZ/

As you all probably already know TYGWZ01 is also available in online stores in the European Union and the United Kingdom:

https://www.amazon.de/ZigBee-Gateway-zentraler-Controller-Hub-ZigBee-Ger%C3%A4te/dp/B083584M99/

https://www.amazon.co.uk/Zigbee-Gateway-Central-Controller-Devices/dp/B083584M99/

https://www.amazon.co.uk/TYGWZ-01-Gateway-Central-Controller-Devices/dp/B07N65MXD4/

https://www.amazon.de/BENEXMART-PIR-Sensor-Temperatur-Feuchtigkeitssensor-Combination/dp/B07SCXNG14/

https://www.amazon.co.uk/BENEXMART-PIR-Sensor-Temperatur-Feuchtigkeitssensor-Combination/dp/B07SCXNG14/

It can of course be ordered from Chinese stores like BangGood, Gearbest, or Aliexpress, but shipping from China is slow now.

https://www.gearbest.com/other-car-gadgets/pp_3008504694819915.html?wid=2000001

https://www.banggood.com/Zemismart-Tuya-ZB-Gateway-Hub-Smart-Home-Bridge-Smart-Life-APP-Wireless-Remote-Controller-Works-with-Alexa-Google-Home-p-1837198.html

https://www.aliexpress.com/item/1005002441359324.html

https://www.aliexpress.com/item/4000071525839.html

https://www.aliexpress.com/item/1005002340919938.html

https://www.aliexpress.com/item/1005002007026244.html

https://www.aliexpress.com/item/1005002341316609.html

https://www.aliexpress.com/item/4001263689776.html

https://www.aliexpress.com/item/4001263868157.html

https://www.aliexpress.com/item/1005002545821613.html

You just have to do a little research before placing an order to really get the Ethernet ("wired") version and not the WiFi version.

[chaisaeng]

I bought this from aliexpress but I can not get the root password from the device
following is the serial log from my device during trying to get the necessary key to decode the root password
Booting...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
@ chip__no chip__id mfr___id dev___id cap___id size_sft dev_size chipSize
@ 0000000h 0c84018h 00000c8h 0000040h 0000018h 0000000h 0000018h 1000000h
@ blk_size blk__cnt sec_size sec__cnt pageSize page_cnt chip_clk chipName
@ 0010000h 0000100h 0001000h 0001000h 0000100h 0000010h 000004eh GD25Q128
@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
DDR1:32MB

---RealTek(RTL8196E)at 2019.01.23-17:03+0800 v3.4T-pre2 16bit
P0phymode=01, embedded phy
check_image_header return_addr:05010000 bank_offset:00000000
no sys signature at 00010000!

---Escape booting by user
P0phymode=01, embedded phy

---Ethernet init Okay!

nknown command !

FLR 80000000 401802 16
Flash read from 00401802 to 80000000 with 00000016 bytes ?
(Y)es , (N)o ? --> y
Flash Read Successed!
DW 80000000 4
80000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FLR 80000000 402002 32
Flash read from 00402002 to 80000000 with 00000032 bytes ?
(Y)es , (N)o ? --> y
Flash Read Successed!
DW 80000000 8
80000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
80000010: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

The result is all FFFFFFFF which it seem the address of tuya label is not correct therefore no flash content in that location so it get all FFFFFFF. I can not decode it with the python scripts. the script throw exception with these input string.

[banksy-git]

If you allow the device to boot completely do you see somewhere in the console output a table like this:

0x000000020000-0x000000200000 : "linux"
0x000000200000-0x000000400000 : "rootfs"
0x000000400000-0x000000420000 : "tuya-label"
0x000000420000-0x000001000000 : "jffs2-fs"

I think it happens when Linux loads the MTD driver and it will say where the tuya-label is.

[chaisaeng]

Booting...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@

@ chip__no chip__id mfr___id dev___id cap___id size_sft dev_size chipSize

@ 0000000h 0c84018h 00000c8h 0000040h 0000018h 0000000h 0000018h 1000000h

@ blk_size blk__cnt sec_size sec__cnt pageSize page_cnt chip_clk chipName

@ 0010000h 0000100h 0001000h 0001000h 0000100h 0000010h 000004eh GD25Q128

@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

DDR1:32MB

---RealTek(RTL8196E)at 2019.01.23-17:03+0800 v3.4T-pre2 16bit

P0phymode=01, embedded phy

check_image_header return_addr:05010000 bank_offset:00000000

no sys signature at 00010000!

P0phymode=01, embedded phy

---Ethernet init Okay!

tuya:start receive production test frame ...

Jump to image start=0x80c00000...

decompressing kernel:
Uncompressing Linux... done, booting the kernel.
done decompressing kernel.
start address: 0x80003780
Linux version 3.10.90 (huangxh@zp-VirtualBox) (gcc version 4.6.4 (Realtek RSDK-4.6.4 Build 2080) ) #2 Wed Jan 23 17:07:04 CST 2019
CPU revision is: 0000cd01
Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
Zone ranges:
Normal [mem 0x00000000-0x01ffffff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000-0x01ffffff]
icache: 16kB/16B, dcache: 8kB/16B, scache: 0kB/0B
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS0,38400 root=/dev/mtdblock2
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 27700k/32768k available (2479k kernel code, 5068k reserved, 525k data, 192k init, 0k highmem)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:128
console [ttyS0] enabled
Calibrating delay loop... 398.13 BogoMIPS (lpj=1990656)
pid_max: default: 4096 minimum: 301
Mount-cache hash table entries: 512
reg e0=0
reg e1=0
reg e2=0
reg e3=0
reg e4=0
reg e5=0
reg e6=0
reg e7=0
reg f0=0
reg f1=0
reg f2=0
reg f3=0
reg f4=0
reg f5=0
reg f6=0
NET: Registered protocol family 16
bio: create slab at 0
NET: Registered protocol family 2
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 54
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x18002000 (irq = 9) is a 16550A
serial8250: ttyS1 at MMIO 0x18002100 (irq = 13) is a 16550A
Realtek GPIO Driver for Flash Reload Default
tuya_gpio_init ok, scan expire time:50
SPI INIT
------------------------- Force into Single IO Mode ------------------------
|No chipID Sft chipSize blkSize secSize pageSize sdCk opCk chipName |
| 0 c84018h 0h 1000000h 10000h 10000h 100h 84 0 GD25Q128|

SPI flash(GD25Q128) was found at CS0, size 0x1000000
boot+cfg offset=0x0 size=0x20000 erasesize=0x10000
linux offset=0x20000 size=0x1e0000 erasesize=0x10000
rootfs offset=0x200000 size=0x200000 erasesize=0x10000
tuya-label offset=0x400000 size=0x20000 erasesize=0x10000
jffs2-fs offset=0x420000 size=0xbe0000 erasesize=0x10000
5 rtkxxpart partitions found on MTD device flash_bank_1
Creating 5 MTD partitions on "flash_bank_1":
0x000000000000-0x000000020000 : "boot+cfg"
0x000000020000-0x000000200000 : "linux"
0x000000200000-0x000000400000 : "rootfs"
0x000000400000-0x000000420000 : "tuya-label"
0x000000420000-0x000001000000 : "jffs2-fs"
PPP generic driver version 2.4.2
nf_conntrack version 0.5.0 (432 buckets, 1728 max)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
NET: Registered protocol family 17
l2tp_core: L2TP core driver, V2.0
8021q: 802.1Q VLAN Support v1.8
Realtek FastPath:v1.03

Probing RTL819X NIC-kenel stack size order[1]...
eth0 added. vid=9 Member port 0x10f...
eth1 added. vid=8 Member port 0x10...
[peth0] added, mapping to [eth1]...
VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
Freeing unused kernel memory: 192K (802f0000 - 80320000)

init started: BusyBox v1.13.4 (2019-01-23 17:02:04 CST)
udhcpc (v1.13.4) started
Sending discover...

Please press Enter to activate this console. SELF_PWD=/
run /tuya/tuya_start.sh
Received SIGTERM
udhcpc (v1.13.4) started
Sending discover...
Password for 'root' changed
start.conf is exist
current run dir:/tuya/tuya_user1
killall: tyZ3Gw: no process killed
Sending discover...
Sending discover...
nlRecvFromAppSock sg_netlinkKeyPid:171
nlRecvFromAppSock port link sg_netlinkPid:171

Yes you are right from the full boot log I get from serial terminal above it clearly state the flash lay out. but I still can not get the KEK and AUS KEY using the command FLR 80000000 401802 16 and FLR 80000000 402002 32
so maybe the address of those keys are not correct for my device?

[Hedda]

FYI, I do not actually have a TYGWZ-01 myself but @MattWestb made it sound like TYGWZ01 works in zigpy/zigpy#650 discussion?

[banksy-git]

Interesting. Has it ever been connected to Tuya cloud or is it straight from the shop? 😄

[banksy-git]

If someone has a full original flash dump I'll take a look to see what's changed. I'm wondering if the first connect to the cloud initializes the tuya-label data. Or perhaps they just moved it? Hard to guess.

[MattWestb]

I have dumped (from Linux shell not boot loader) one TYGZ01 and one LIDL ZBGW but both was having contact with the cloud before dumping them and i have getting the password from both (but messed up the LIDL one).
I think easiest way download on app and connecting it on time and then deleting the ZBGW in the app and then looking what the bootloader readings is saying.

But most interesting is if some one can sharing on dumped flash that is strange with @banksy-git !!

[chaisaeng]

My device never contact to the cloud or include in the official app yet. out of the box I did dump_flash.py according to the guide python dump_flash.py --serial-port /dev/ttyUSB0 --output-file rootfs.bin --start-addr 0x200000 --end-addr 0x400000 then perform step to gain access to root but still out of luck. I still get invalid logon for the original
rootfs.zip I'm interesting to have other know working rootfs image shared as well so I can try on my device.

[banksy-git]

@chaisaeng - I replied in other forum but change your passwd file so it uses /bin/sh instead of /bin/bash. :)

[banksy-git]

@MattWestb - Mine was also connected to Tuya first. Could this be the missing link!

[MattWestb]

You is the master mind but its sounds very likely that the "clean device" is getting the keys from the server so tuya is knowing all and can putting custom parameters in it if they like (or if LIDL have paying for it or not).

[MattWestb]

@banksy-git Do you have reading from the Realteck source if its being one "default" password or "root root" if not being sett in the custom way ?
Or is it working calculating it with all "FF" and its working ??
tuya must have on way writing the to the FS from Linux then populating the keys and they need being root for that (i think).

[chaisaeng]

I already try the default root/root after I failed to get the password decode from key that all FF. It definitely not root/root for sure. also during boot following message show that it have some mechanism to change the root password on the device as well, see the following part of the boot log.
run /tuya/tuya_start.sh Received SIGTERM udhcpc (v1.13.4) started Sending discover... Password for 'root' changed

[banksy-git]

Maybe try :

TuyaSmart@2019.

;-)

Can you post the contents of your /tuya/config/passwd after it's been set by tuya_start?

[chaisaeng]

I

Maybe try :

TuyaSmart@2019.

;-)

Can you post the contents of your /tuya/config/passwd after it's been set by tuya_start?

I already flashed the device with modified roofts already. not sure how to reverse back to the stock rootfs. I'm sorry can not fulfill your request. BTW. the current conteent in that directory which I'm think it was changed once as followed

# ls
app_upgrade.sh          serialgateway           tuya_user1
config                  start.conf              tuyamtd
gpio_ctl.sh             tuya_net_start.sh       udhcpc.script
iperf                   tuya_start.original.sh
log_dir                 tuya_start.sh
# cd config/
# ls
passwd   passwd-
# ls -al
drwxrwxr-x    2 1001     1001            0 Jan  1 00:00 .
drwxr-xr-x    6 root     0               0 Jan  1 00:00 ..
-rwxrwxr-x    1 1001     1001           37 Jan  1 00:00 passwd
-rwxrwxr-x    1 1001     1001           37 Jan  1 00:00 passwd-
# cat passwd
root:XX6QJaZ8f55r.:0:0:root:/:/bin/sh# 
# cat passwd-
root:XX6QJaZ8f55r.:0:0:root:/:/bin/sh# ```

[MattWestb]

Can you sharing your original dumped files that was not working = is not having your device root password with @banksy-git ?

I think its one very interesting opening to rooting devices without have connecting it to tuya cloud.

[chaisaeng]

Can you sharing your original dumped files that was not working = is not having your device root password with @banksy-git ?

I think its one very interesting opening to rooting devices without have connecting it to tuya cloud.
I have to zip it because github not allow me to attach .bin file

rootfs.zip

[MattWestb]

Thanks very much i hope maestro @banksy-git have time looking in it.
Perhaps its possible erasing some sectors in the flash and using the magic password and not need repacking root FS also after have connected the to tuya cloud.

[chaisaeng]

Thanks very much i hope maestro @banksy-git have time looking in it.
Perhaps its possible erasing some sectors in the flash and using the magic password and not need repacking root FS also after have connected the to tuya cloud.

tuya-label.zip
I also have tulabel dumped using command python3 dump_flash.py --serial-port /dev/ttyUSB0 --output-file tuya-label.bin --start-addr 0x400000 --end-addr 0x420000

boot+cfg and linux partition was not successfully dumps as it failed for some reason the last partion take too long time so I abandon it as i though it not needed in gaining root access. The reason that I have tried that because I thought it'd be a good idea to have a complete backup of flash but eventually I can not achieved that goal.

[banksy-git]

That file has the auzkey in plain text right at the top! :) I wonder if the password was derived from it in the same way?

[chaisaeng]

That weird, I can confirm that it have the auzkey and uuid in plain text
{"auzkey":"jQjxu6K1ANAva9fV0mWW9nWd96760rTW","uuid":"6157802868572d116432"}
not sure we can decode it or not for root password
btw. great finding

[banksy-git]

If you post your /tuya/config/passwd (that's different from the one you changed in the root-fs which is /etc/passwd) we can check! :)

[chaisaeng]

# cd tuya
# ls
app_upgrade.sh          serialgateway           tuya_user1
config                  start.conf              tuyamtd
gpio_ctl.sh             tuya_net_start.sh       udhcpc.script
iperf                   tuya_start.original.sh
log_dir                 tuya_start.sh
# cd config/
# ls
passwd   passwd-
# ls -al
drwxrwxr-x    2 1001     1001            0 Jan  1 00:00 .
drwxr-xr-x    6 root     0               0 Jan  1 00:00 ..
-rwxrwxr-x    1 1001     1001           37 Jan  1 00:00 passwd
-rwxrwxr-x    1 1001     1001           37 Jan  1 00:00 passwd-
# cat passwd
root:XX6QJaZ8f55r.:0:0:root:/:/bin/sh# 
# cat passwd-
root:XX6QJaZ8f55r.:0:0:root:/:/bin/sh# ```

[banksy-git]

Sweet. The password for that hash is:

tuya123

:-) I'll amend the guide to suggest people try that first!

[MattWestb]

Nice one but little short for my taste of passwords ;-)))

So very likely ist tuya "factory password" before connecting to cloud and downloading new firmware and setting individual root password.

Perhaps no need hacking if not connecting to the cloud.

12 points to Milano !!

[challs]

:-) I'll amend the guide to suggest people try that first!

Great work @banksy-git !

I've just realised something too which you should also say - don't connect it to the internet!

By looking at my jffs image, I realised that the password was changed multiple times. And one of those password corresponds to the last 8 characters of the auzkey which /tuya/tuyamtd read auzkey gives. I hadn't realised at first, because the python script only gave me the first half of the auzkey, not the whole thing so I had connected it to my network while attempting to copy flash images around.

So it seems that I did originally have a root password on the device that corresponded (almost) to the key it is possible read out with your python routine. But that password was changed when the box booted when connected to the tuya cloud.

[MattWestb]

I was using one USB-Eth adapter for uploading the dumped flash with no internet access for the ZBGW and still hocked up with serial console so tuya was not connecting to the cloud after starting hacking it.
But i was using dd in the Linux shell and the root password for doing it and tftp the bin files to my laptop.

By the way in the tuya app directory its one updating program for the zigbee module but i was not getting it working then i was already on the latest tuya version (EZSP 6.5.x) and is one images for the zigbee module in my 2 ZBGW but it can being its coming with the update from the cloud.

And if you is having older EZSP you need using one different command for rebooting the zigbee module in to bootloader mode then its using one older version of the protocol but you can finding it in NCP.PY that is used of Silabs and the community for updating EM35X devices that i was taking the commands used in the updating script (version 7 and 8 is in the script 4-6 is not).

[chaisaeng]

Sweet. The password for that hash is:

tuya123

:-) I'll amend the guide to suggest people try that first!

Great work @banksy-git !

[Hedda]

... I'll amend the guide ...

Other than the two images from the first post of the original Tuya TYGWZ-01 / TuyaGo TYGWZ01 might also want to add some of these additional pictures taken from online stores as well as mention that other than under the name "Lidl Silvercrest" it is also sold under many different rebranded names such as example; Lonsonho, Moes, BENEXMART, Kstyhome, Moniclern, OWSOO, Zemismart, plus the fact that the bridge/gateway is sold both seperate and in combination with other Zigbee devices:

[azmat007]

hi, iam still faciong the same issue i went through all the conversation and tried to follow the steps but i kind of didnt understand in between since iam not an experienced coder. But the problem is where i live the only available device is Tuya TYGWZ-01 (with a different name but same model ) i tried using 'Putty' to get into terminal using USB TTL. at first i got the codes but when i tried to decode it didnt work using python script. Now the device doesnt show anymore on Putty and iam unable to get into the terminal to upload the script given by banksy-git. Please help as i have just this device to work with since none of the courier is getting my conbee device or anyother zigbee communicating device that could work with Home assistant. There are many more people here stucked with the same issue.

[MattWestb]

Some is using the 3.3 V from the USB-TTL converter and its working OK without using the UBS power (I have doing 2.5 with it).
Some USB-TTL converters is putting out 5 V and not 3.3 V power for supplying the device so cant being used (5 V its burning your board).
Some is doing 3.3 V but not enough current for driving the hole board with Ethernet and Zigbee module, then connect RX, TX and GND plus the USB power for supplying the board but not connect the 3.3 V then you is getting problems.

Also then repower the board it can being that the USB-TTL converter is hanging so need being reconnected for working.

You was having it working landing in the bootloader so if the board is not being broken (from 5 V) it shall being possible getting inside it one more time and getting the keys bring read.

And have the USB-TTL adapter connected all the time then you is doing the rest things so you can using the local terminal if getting problems with SSH connection then ding the configuration and testing.

[dominch]

Sorry for digging on old thread but I think it's still the best place for such information,
I bought this particular gateway:

On board there was ID-BOARD: TYGWZ1 and REV1.0.3
This seems to be newer version than the one from here (I found that tutorial works up to V1.0.2). Beside different case there are some changes.

• board is smaller and less regular shape
• ssh is running on default port 22
• root password is no longer tuya123
• I connected my gateway to tuya application but user partition remains empty (all 0) - I'm not sure should I do anything else for that - when checked via UART was just empty
• because of previous point - I could not use script to generate root password - no AUSKEY etc

I connected board to flash to eeprom reader and dumped content (faster than via UART), changed root password hash, logged in, then yet again reverted original flash and extracted hash for root account which is:
root:XX6QJaZ8f55r.:0:0:root:/:/bin/sh
password for this hash is:
mswG8vck

Maybe someone find this useful and confirm that it's default password for this revision or startup for this version is different, without AUSKEY and partition init and root password is changed in system partition. @banksy-git - have You updated page for tuya123 password? If so then You can add mine there too ;)

[parasite85]

Hello Guys,
Some time ago i have bought a simple tuya gateway on aliexpress but i have switched to the Home Assistant. I have used different gateway for HA. Now got some spare time to play with the old gateway.
My gateway it is not Lidl one. It has following label on the PCB. DMD2CC-V1.0.
I have soldered J1 pins and tried to get the boot prompt. Unfortunately, without any success. Boot prompt must be disabled or locked. I've took different approach. I read dump of SPI FLASH and I wanted to extract auzkey (authkey) from the tuya-label partition on flash drive. Unfortunately, this partition is empty (all space is filled with 0xFF values). Instead of it I`ve modified /etc/passwd to get access.
However, I was curious where the AUZKEY is located. It might be useful some for people which owned Lidl gateway or any other gateway with enabled bootloader. They don't need to buy programmer and do any desolder/solder stuff.

I did little research on tuyamd executable and I have succesfully extracted (or decoded) auzkey.
To extract auzkey you need to:

• dump jffs2 partition (using bootloader or using programmer)
• extract jffs2 partition - Jefferson github
• get two files: config/License.file1 and config/License.key
• Use following program to decode it:
  decode.txt
  It will give you output:
  Decrypted data
  b'{"bsn":"XXXX","master_mac":"XXXXXX","auzkey":"XXXXXXXXXXXXX","uuid":"XXXXXXXXXX","prodtest_exit":"true"}\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f'
  Also file License.out will be produced.

Hope it will be helpful for someone.

[parasite85]

Guys, spent some more time on bootloader. Indeed it is locked, however, it can be unlocked using a wire.
So no programmer needed, no soldering/desoldering of flash needed
For more info: My repo

[dominch]

@parasite85 thanks for sharing, is password just digits? if it's 8-digits only then it's easy to decode that just from hash.

[challs]

Hey @parasite85, great job on unlocking your box and finding the way to get at the key. Thanks so much for sharing!

[parasite85]

@parasite85 thanks for sharing, is password just digits? if it's 8-digits only then it's easy to decode that just from hash.

Yes, i did little research in firmware binaries. At least for my gateway, password is 8 chars. I cannot say if it is a general rule for all gateway firmware.
Anyway, You can set permanent password as root (you dont need to know the current passowrd) - using this technique https://paulbanks.org/projects/lidl-zigbee/#backup
or you can retreive password from jffs2 partition. You need to get backup via boot promt - this part i have not described but basically same link: https://paulbanks.org/projects/lidl-zigbee/#bootloader there is section Backup once you got backup of binary you can use binwalk to get jffs2 data.

[dominch]

@parasite85 - of course I was able to get into my gateway and do needed changes, but this required disassembly and UART interface. The whole point of this question was to try to find out factory password for root. On some gateways jffs2 partition was not initialised and root password just not set up. I'm trying now to find out how this looks in different boards/revisions. Do You have original has for root?

[parasite85]

@dominch: Well, my device was initialized/connected to tuya. If you / anyone reading this message have access to uninitialized device then please do dump using boot prompt. We can go further with this dump.

[dominch]

@parasite85 My gateway was not initilized, jffs2-fs was all in zeros so I could read password hash from rootfs. You could read original hash file from it even efter initialization (new password is mounted on top of that).

[parasite85]

@dominch:
Maybe we have different firmware.
I have extracted the firmware from original EEPROM dump. From this dump I have extracted squashfs:
squashfs-root/etc/ ls -al
lrwxrwxrwx 1 xxx xxx 9 lis 26 21:56 passwd -> /dev/null
so this is symlink to /dev/null, no password here
also
squashfs-root/etc/init.d there is file called rcS which is directly calling two things:
mount -t jffs2 /dev/mtdblock4 /tuya
and
/tuya/tuya_net_start.sh

According to this, in my case, Squashfs requires JFFS2 to be initialized.
I do not know what is happening next in case of not "commissioned" gateway.

I do not know the details about your gateway.
Hard to give you any constructive comment here.