search

banksy-git / lidl-gateway-freedom

Freeing the Silvercrest (Lidl/Tuya) Smart Home Gateway from the cloud.
https://paulbanks.org/projects/lidl-zigbee/
GNU General Public License v3.0
215 stars 65 forks source link

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

Open Hedda opened 3 years ago

Hedda commented 3 years ago

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/

image

image

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 commented 3 years ago

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...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ chipno chipid mfrid devid cap_id size_sft dev_size chipSize @ 0000000h 0c84018h 00000c8h 0000040h 0000018h 0000000h 0000018h 1000000h @ blk_size blkcnt 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 commented 3 years ago

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 commented 3 years ago

Booting...

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

@

@ chipno chipid mfrid devid 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 commented 3 years ago

FYI, I do not actually have a TYGWZ-01 myself but @MattWestb made it sound like TYGWZ01 works in https://github.com/zigpy/zigpy/discussions/650 discussion?

banksy-git commented 3 years ago

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

banksy-git commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

banksy-git commented 3 years ago

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

MattWestb commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

Maybe try :

TuyaSmart@2019.

;-)

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

chaisaeng commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago 

# 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 commented 3 years ago

Sweet. The password for that hash is:

tuya123

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

MattWestb commented 3 years ago

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 commented 3 years ago

:-) 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 commented 3 years ago

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 commented 3 years ago

Sweet. The password for that hash is:

tuya123

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

Great work @banksy-git !

Hedda commented 3 years ago

... 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:

image

image

image

azmat007 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

Sorry for digging on old thread but I think it's still the best place for such information, I bought this particular gateway: 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.

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 commented 1 year ago

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:

Hope it will be helpful for someone.

parasite85 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

parasite85 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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.