Rooted version FW 5.0.5 by hw programmer - sdcard option in progress ( was finding correct firmware version (Bricked device) )

[Ierlandfan]

I have a semi-bricked Camera, I think it was on 2.9.6 but I am not sure. I attached the programmer and read the firmware correctly. Device is not booting (Red light) and nothing gets written to the card. This was using the old bootcommand.
How or where do I find the right firmware version in the firmware?

[fennec622]

Ok i find way to have MQTT push when button push

first create account on

https://iot.tuya.com

After create Cloud Project

On your project add devices Link Tuya App

Use data center from your region

You must App Account with 1 device

After note Authorization Key

Access ID/Client ID and Access Secret/Client Secret

now install

https://github.com/jasonacox/tinytuya

and start

python -m tinytuya wizard You must write API Key it's Access ID/Client ID Secret it's Access Secret/Client Secret DeviceID. you find in app Tuya Region eu for me

With that you can have key for your device id

[ { "name": "Visiophone Wifi", "key": "e177111111111", "id": "bf5ad111111111" } ]

Now install https://github.com/TheAgentK/tuya-mqtt

setup config.json for mqtt setting And with tinytuya you have create devices.json rename in devices.conf and put in folder tuya-mqtt

and start

DEBUG=tuya-mqtt:* ./tuya-mqtt.js

And after each button push you can see message like that

tuya-mqtt:state MQTT DPS JSON: tuya/visiophone_wifi/dps/state -> {"244":"0"} +67ms tuya-mqtt:state MQTT DPS244: tuya/visiophone_wifi/dps/244/state -> 0 +1ms tuya-mqtt:tuyapi Received JSON data from device bf5ada2f1c3c05e3cfi86t -> {"244":"0"} +16s tuya-mqtt:state MQTT DPS JSON: tuya/visiophone_wifi/dps/state -> {"244":"0"} +16s tuya-mqtt:state MQTT DPS244: tuya/visiophone_wifi/dps/244/state -> 0 +2ms tuya-mqtt:tuyapi Received JSON data from device bf5ada2f1c3c05e3cfi86t -> {"244":"0"} +12s tuya-mqtt:state MQTT DPS JSON: tuya/visiophone_wifi/dps/state -> {"244":"0"} +12s tuya-mqtt:state MQTT DPS244: tuya/visiophone_wifi/dps/244/state -> 0 +1ms

{"244":"0"} is when button push

[guino]

@fennec622 looks like you found a viable way to get the button push notifications using the tuya cloud API -- I was unaware they had any kind of mqtt public api available.

If you're running this stuff in linux/mac you should be able to something like this on a script (untested):

while true; do
 tail -n 0 -f logfile | grep -m 1 '{"244":"0"}'
 << mosquitto_pub / mqtt_pub / curl / wget command to notify domoticz/homeassist etc >>
done

Basically it will loop forever monitoring the logfile until the match is found (button push) then it will execute the command and resume monitoring the log file.

This would be an example command to notify home assistant (parameters must be adjusted and mosquitto_pub client must be installed): mosquitto_pub -h 192.168.2.143 -m "pushed" -t home/doorbell/button

You should probably check that the 'motion' alert generates a different event or e may get confused with the doorbell push event (and/or you could have another similar script to monitor/notify of motion events).

[guino]

For anyone running 5.0.5 -- I would like you to try and reach URL: http://admin:056565099@ip:8090/download/iperf3 (you'll probably need ppsFactoryTool.txt -- I see in the ppsapp obtained with a programmer if it shows a page allowing you to upload a file. If that works there's a potential change that we can upload a script to be executed (and hopefully enable telnet) so we can configure the device (i.e.e tuya_config.json) and get more information.

[fennec622]

@guino Yes it's work

[guino]

@fennec622 I'll try to put together a package you can try to upload to see if we can enable telnet that way. I have to review the code and do some testing.

[fennec622]

@fennec622 I'll try to put together a package you can try to upload to see if we can enable telnet that way. I have to review the code and do some testing.

@guino thanks a lot I have two doorbell one for test

[tvall43]

if i were to totally hypothetically attempt rooting my feit electric doorbell and managed to not get a good dump of the flash before stupidly overwriting it, how screwed am i? would flashing firmware from a merkury720 have any chance of working? or does someone happen to have firmware from a more similar device? it was running 4.0.10, can get any more info if needed

[guino]

@tvall43 for it to have any chance of working it would have to at least match the hardware string. Even then one of the two devices (firmware source or your device) would have to be used offline as they’ll have the same keys and won’t work online at the same time. If your device is compatible with one of the openipc firmware it would work as a camera with it (not as doorbell) unless you made some sort of custom notification system for it (which should be possible).

You could potentially buy another one to copy the flash from it and use one of them offline.

Full firmware dumps are hard to come by, I only have the ones from my devices and maybe one other that’s been posted for review, but none are 4.x version.

[jilleb]

For anyone running 5.0.5 -- I would like you to try and reach URL: http://admin:056565099@ip:8090/download/iperf3 (you'll probably need ppsFactoryTool.txt -- I see in the ppsapp obtained with a programmer if it shows a page allowing you to upload a file. If that works there's a potential change that we can upload a script to be executed (and hopefully enable telnet) so we can configure the device (i.e.e tuya_config.json) and get more information.

Wow, I haven't checked this repository for some time, but this looks promising. I still have a V5.05 device somewhere in my desk drawer.

Maybe there's some vulnerability in this upload form we could abuse. Did anyone ever dig deeper into this?

[guino]

@jilleb I started to look into it but without the device to try it is going to be very difficult for me. I checked a few paths and extraction locations to see if I could overwrite something but didn't immediately find anything.

[ihrapsa]

Hi @Ierlandfan and @guino I've followed instructions from here to edit the cramfs initrun.sh and wrote only to the cramfs address on the flash using instructions from #12 with the following ppsMmcTool.txt:

style=upgrade,,writeAddr=0,,password=nothing,,writeLen=0,,fileName=flash.bin;sf probe;sf write 212D0000 2D0000 3FC000,,

212D0000 = the read address 21000000 (fixed address where flash.bin is loaded) + 2D0000 (the offset of cramfs inside flash.bin) 2D0000 = the target/destination address in the flash memory (offset of changes in the flash.bin file) 3FC000 = the size of the cramfs partition to write (4177920 = 3FC000 in hex).

• According to serial output, 0x21000000 seems to be the address where ppsMmcTool.txt is loaded

Here is the binwalk of the flash.bin dumped with the mmc uboot commands:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
83131         0x144BB         xz compressed data
84032         0x14840         CRC32 polynomial table, little endian
196608        0x30000         uImage header, header size: 64 bytes, header CRC: 0x24CDF17F, created: 2021-08-17 03:20:24, image size: 102472 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xB95FE55F, OS: Firmware, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "MVX4##I6B0gf0fcd12CM_UBT1501#XVM"
196672        0x30040         xz compressed data
327680        0x50000         uImage header, header size: 64 bytes, header CRC: 0x9D77B5F9, created: 2021-08-17 03:34:33, image size: 2406380 bytes, Data Address: 0x20008000, Entry Point: 0x20008000, data CRC: 0x810E56DF, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "MVX4##I6B0gf0fcd1230KL_LX409##[B"
327744        0x50040         xz compressed data
2949120       0x2D0000        CramFS filesystem, little endian, size: 4177920, version 2, sorted_dirs, CRC 0x267C501C, edition 1, 1017 blocks, 3 files
7798784       0x770000        JFFS2 filesystem, little endian
7864400       0x780050        Zlib compressed data, compressed

Here is the serial output of the writing proccess.

This also shows that ppsMmcToo.txt is loaded at 0x21000000:

Click me

``` IPL g8c8fea1 D-05 WDT Reset SPI 54M 64MB BIST0_0001-OK MXP found at 0x00020000 offset:00010000 Checksum OK IPL_CUST g1554082 MXP found at 0x00020000 offset:00030000 XZ decomp_size=0x00044f58 U-Boot 2015.01 (Aug 17 2021 - 11:20:20) Version: I6gf0fcd12 [WDT] Enalbe WATCHDOG 60s Watchdog enabled I2C: ready DRAM: WARNING: Caches not enabled MMC: MStar SD/MMC: 0 nor_flash_mxp allocated success!! 8 MiB MXP found at mxp_offset[3]=0x00020000, size=0x1000 8 MiB pcbversion:BELL5S_S1_V10 sensor:gc2063mipi env_offset=0x4F000 env_size=0x1000 8 MiB In: serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. reset key pressed! cmd:fatload mmc 0 0x21000000 ppsMmcTool.txt reading ppsMmcTool.txt 190 bytes read in 10 ms (18.6 KiB/s) cmdBuf:fatload mmc 0 0x21000000 flash.bin;sf probe;sf write 212D0000 2D0000 3FC000 reading flash.bin 8388608 bytes read in 592 ms (13.5 MiB/s) 8 MiB SF: 4177920 bytes @ 0x2d0000 Written: OK size:8388608 error: Pack header size error! error: upgrade.bin unpack error! ..... 1 ..... 0 8 MiB SF: 2621440 bytes @ 0x50000 Read: OK ## Booting kernel from Legacy Image at 21000000 ... Image Name: MVX4##I6B0gf0fcd1230KL_LX409##[B Image Type: ARM Linux Kernel Image (lzma compressed) Data Size: 2406380 Bytes = 2.3 MiB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... [XZ] !!!reserved 0x21000000 length=0x 1000000 for xz!! XZ: uncompressed size=0x428000, ret=7 OK atags:0x20000000 Starting kernel ... ```

Here is the normal (no reset pressed) serial output

Click me

``` IPL g8c8fea1 D-05 WDT Reset SPI 54M 64MB BIST0_0001-OK MXP found at 0x00020000 offset:00010000 Checksum OK IPL_CUST g1554082 MXP found at 0x00020000 offset:00030000 XZ decomp_size=0x00044f58 U-Boot 2015.01 (Aug 17 2021 - 11:20:20) Version: I6gf0fcd12 [WDT] Enalbe WATCHDOG 60s Watchdog enabled I2C: ready DRAM: WARNING: Caches not enabled MMC: MStar SD/MMC: 0 nor_flash_mxp allocated success!! 8 MiB MXP found at mxp_offset[3]=0x00020000, size=0x1000 8 MiB pcbversion:BELL5S_S1_V10 sensor:gc2063mipi env_offset=0x4F000 env_size=0x1000 8 MiB In: serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. magic err ..... 1 ..... 0 8 MiB SF: 2621440 bytes @ 0x50000 Read: OK ## Booting kernel from Legacy Image at 21000000 ... Image Name: MVX4##I6B0gf0fcd1230KL_LX409##[B Image Type: ARM Linux Kernel Image (lzma compressed) Data Size: 2406380 Bytes = 2.3 MiB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Uncompressing Kernel Image ... [XZ] !!!reserved 0x21000000 length=0x 1000000 for xz!! XZ: uncompressed size=0x428000, ret=7 OK atags:0x20000000 Starting kernel ... Meari login: ```

The Problem:

Problem is now the doorbell does not seem to start the ppsapp (no audio feedback, no wifi connection, only red led stais on). It reaches Starting kernel message then the login prompt (since I have ttyS0 in console bootarg) but I don't know the password. After 60-65 sec it reboots.

Any idea where I could've messed up?

Thank you all!!!

[guino]

@ihrapsa I sent you some information in reply to your email. Chances are something went wrong with either reading or writing the firmware data. The 60s reboot is the watchdog doing its job, since ppsapp isn't starting nothing is feeding it, so it reboots. There's a watchdog feeder in the offline cloud https://github.com/guino/BazzDoorbell/issues/4#issuecomment-742434771 that can be used but that's only helpful if you're running a shell.

[ihrapsa]

Hi, I've been reading through the u-boot docs and managed to flash the modified flash.bin using the ppsMmcTool.txt. The trick was to erase the chip first with sf erase 0 800000 then sf write 21000000 0 800000 (for 8mb chips) or sf erase 0 1000000 then sf write 21000000 0 1000000 (for 16mb chips).

Load address for firmware 5.2.2 and 5.2.8 (the only ones I've tested) is indeed 21000000 even if binwalk and serial log sais ~20008000~

These are the contents of the ppsMmcTool.txt file:

style=upgrade,,writeAddr=0,,password=nothing,,writeLen=0,,fileName=flash.bin;sf probe;sf erase 0 800000;sf write 21000000 0 800000,,

and the hex dump:

ppsMmcTool.txt

[guino]

@ihrapsa That's one way to do it. The ppsMmcTool.txt option is meant to be used with a 'formatted' upgrade file that the device understands and flashes automatically. I assume you have UART access on your device ? if so drop me an email and I can send you some information.

[ihrapsa]

@ihrapsa That's one way to do it. The ppsMmcTool.txt option is meant to be used with a 'formatted' upgrade file that the device understands and flashes automatically. I assume you have UART access on your device ? if so drop me an email and I can send you some information.

@ihrapsa That's one way to do it. The ppsMmcTool.txt option is meant to be used with a 'formatted' upgrade file that the device understands and flashes automatically. I assume you have UART access on your device ? if so drop me an email and I can send you some information.

Just dropped you an email. What do you mean by 'formatted' upgrade file? I thought I dropped the info regarding the sf erase command here since I haven't seen anyone with fw 5.x.x flash a modified/exploited firmware with the existing ppsMmcTool.txt files without issues (provided the load address is correct).