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?

[guino]

@Ierlandfan you can use binwalk and extract ppsapp -- in the ppsapp file there's the version information. In linux I usually do this command to pull up the date/model information used to display the firmware version: strings ppsapp | grep -A10 -B10 ppstrong

If you post your firmware file or ppsapp I can tell you the version.

[Ierlandfan]

I am still not sure whether the ppsapp on the device is the same as original but let's say it is. ppsapp version is
c51-tuya2-lcs according to ppsapp and ppsdsry

md5: 50ad9c96c65c0e446d8b3d5c8c828957

The device does something. Without a card a red light. Without a card and holding the reset button just a red light. With card and holding the reset button the light blinks blue for a brief moment and goes to red.

Attached you will find it.
ppsapp.zip

[guino]

Your firmware is this one:

LSC Smart Connect Smart Doorbell

firmware version	hardware version	original ppsapp MD5	device
ppstrong-c51-tuya2_lcs-2.9.6.20200628	BE8S_H1_V10_433	50ad9c96c65c0e446d8b3d5c8c828957	Bell 8S

ppsapp-rtsp.zip please use this HOW TO PATCH GUIDE
snap.cgi and mjpeg.cgi address: 0x0047494c
play.cgi request address: 0x0477404

If your device is responding to the reset button during boot you should try restoring it as described in the TROUBLESHOOTING / RESTORE section here: #2

If the restore doesn't work, then something has gone bad with the device (as that basically restores factory boot loader settings). I have seen one user reporting that the built-in flash chip went bad (confirmed by hardware programmer reading the flash) -- when that happens just part of the flash chip goes bad (not the whole thing) but since everything is needed the device won't work anymore unless you replaced the chip and had an original flash dump to restore it. Unfortunately the only way to confirm it is if you can get a flash dump -- you may be able to do it using #11 -- definitely worth a try.

[Ierlandfan]

Here's the firmware dump (Using programmer)
camera.zip
Maybe you can see whether everything is on it.

[guino]

@Ierlandfan do you have access to UART ? The firmware seems ok but I did see some differences compared to my (2.9.6 but different brand). It looks like at some point you used #2 which would require the files from #2 in the SD card during boot for the device to boot at all. Did you try the restore process and it did not work ?

[Ierlandfan]

@guino The restore worked! It's back online! I never saw that part in #2. Great Job! A camera with Onvif back.
Not sure what it was but well it works!
So I took the plunge and connected the programmer to the other camera (5.0.5) since that one does have onvif but not enabled.
It even has busybox and telnet (but not enabled) My Ghidra fu is not that great so maybe you can have a look?
(I don't mind ruining the 5.0.5 version since I only care about Onvif
camera-5.0.5.zip
)

[guino]

@Ierlandfan that's awesome you got it working again!

This is first version 5.x that I see that seems to have linux running -- did you try #11 and/or any URLs to see if they work (including with ppsfactorytool.txt) ?

[guino]

@Ierlandfan looks like this 505 firmware should have onvif support like the 4.0.x versions do (with tuya_config.json to enable it and set the password). It would be just a matter of finding the right address to load the hack into uboot which seems a little different on this one.

Based on the kernel you could try applying: https://github.com/guino/Merkury1080P#conclusionusing the address 0x20008000 in env and ppsMmcTool.txt file (replacing the 0x81C08000 addresses -- one on each file) -- if it doesn't work it should not hurt the device either (plus you have a backup of the firmware).

The thing to notice about this firmware is that I was unable to quickly locate any code that would allow snap/mjpeg.cgi and/or play.cgi to work.

[guino]

@Ierlandfan ppsFactoryTool.txt should work on 5.0.5 as well -- the URLs need to be requested under port 8090 like http://admin:056565099@IP:8090/proc/cmdline

[Ierlandfan]

ppsFactoryTool.txt works indeed. It opens port 8090. Sifting through the extracted firmware I saw in /etc/init.d/S90app:

hostname Meari
mkdir -p /opt/pps
MTDNUM=`cat /proc/cmdline | sed 's/.*ppsAppParts=\([0-9]\).*/\1/'`

\# debug\
MTDNUM=2

echo '--- mount cramfs ---'

case $MTDNUM in
     2)
      mount -t cramfs /dev/mtdblock$MTDNUM /opt/pps
      break
      ;;
     0)     
      sleep 10
      mount -t vfat /dev/mmcblk0p1 /opt/pps
      break
      ;;
     *)
      MTDNUM=5
      mount -t cramfs /dev/mtdblock$MTDNUM /opt/pps
       ;;
esac

echo "/opt/pps/" > /tmp/meari.runpath
[ -e /opt/pps/initrun.sh ] && cp /opt/pps/initrun.sh /tmp/PPStart && chmod +x /tmp/PPStart && /tmp/PPStart`

So that would suggest (No # ) that the hack will not work default I guess.
I do see some references to /mnt/mmc01/ppsDebugTool.txt. (And the defaults like ppsFactory etc.)
Have you played with that (ppsDebugTool.txt) or do you know what is needs to be enabled?

[guino]

@Ierlandfan were you able to get a /proc/cmdline after opening port 8090 ? From looking at the code it seems like when ppsFactoryTool.txt is present it will open port 8090 but it may not work 'normally' (connecting to cloud and starting services, etc), but we just need information to do the hack then ppsFactoryTool.txt can be removed.

The main thing is finding which address the boot loader uses to load the kernel (so we can apply new boot loader settings) like I posted here: #62 (comment), the second thing is making sure the scripts are set to work with the right firmware layout -- in this case it looks like line 6 of initrun.sh (from Merkury1080P repository: https://github.com/guino/Merkury1080P/tree/main/mmc) should have this: mount -t cramfs /dev/mtdblock2 /opt/pps as the S90app script above is forcing it to be 2 regardless of the boot parameter.

It usually is easier to find the boot address using UART but I don't know if that's an option for you, but it does seem like this device can be rooted with the right changes in the firmware at least.

[Ierlandfan]

ppsFactoryTool worked:

http://192.168.1.66:8090/proc/cmdline:

console=/dev/null LX_MEM=0x3fe0000 mma_heap=mma_heap_name0,miu=0,sz=0x1d00000 pcbversion=B3S_S1_V10 sensor=gc2063mipi
Since I have access to the files using the dump I can look through all the files if there's a need for that.

[guino]

@Ierlandfan if you want to just root this device and be done with it, my suggestion (since you have a hardware programmer) is to do what I did originally on my doorbell which was to modify initrun.sh and rebuild the cramfs partition:

mkfs.cramfs -b 4096 -e 1 -N little -n ppsapp mycramfs-root/ my.cramfs
cp bazz.bin mybazz.bin
dd conv=notrunc if=my.cramfs of=mybazz.bin bs=1 seek=3604480

Obviously the values would have to be adjusted for your firmware.

If you'd like to help others with similar firmware then we really need to find the load address for your firmware so we can create the env+ppsMmcTool.txt files that work on 5.0.5.

I'm willing to help either way it's just a question of how much time/effort you're willing to spend on it.

[Ierlandfan]

I want to give back tot the community as always and I love the challenge. So if we can root this one and find more info for 5.0.5 or 5.0.6 maybe that would be awesome. Time and effort are no problem. I will try your suggestions tomorrow since I am little distracted by some Dutch winner! Outlook voor Android<https://aka.ms/AAb9ysg> downloaden

…

________________________________ From: Wagner ***@***.***> Sent: Sunday, December 12, 2021 6:14:46 PM To: guino/BazzDoorbell ***@***.***> Cc: Ierlandfan ***@***.***>; Mention ***@***.***> Subject: Re: [guino/BazzDoorbell] Finding correct firmware version (Bricked device) (Issue #62) @Ierlandfan<https://github.com/Ierlandfan> if you want to just root this device and be done with it, my suggestion (since you have a hardware programmer) is to do what I did originally on my doorbell which was to modify initrun.sh and rebuild the cramfs partition: mkfs.cramfs -b 4096 -e 1 -N little -n ppsapp mycramfs-root/ my.cramfs cp bazz.bin mybazz.bin dd conv=notrunc if=my.cramfs of=mybazz.bin bs=1 seek=3604480 Obviously the values would have to be adjusted for your firmware. If you'd like to help others with similar firmware then we really need to find the load address for your firmware so we can create the env+ppsMmcTool.txt files that work on 5.0.5. I'm willing to help either way it's just a question of how much time/effort you're willing to spend on it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#62 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABWNEDJSC7PBGH7CTSEDEPLUQTKANANCNFSM5JQWVBKQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Ierlandfan]

Can you elaborate on the command a little more just to make sure I replaced the right data.

mkfs.cramfs -b 4096 -e 1 -N little -n ppsapp
mycramfs-root/ my.cramfs // block size 4096,ok,) my. cramfs is the name of the new binary I guess, what to do with ppsapp, patch original ppsapp and then use it here? (Sorry, Google is letting me down)
cp bazz.bin mybazz.bin //Copy two files? Or copy bazz.bin to my bazz. bin
dd conv=notrunc if=my.cramfs (Obvious)

[guino]

@Ierlandfan I would not patch ppsapp in the firmware, the only change I would make is in initrun.sh to run a script from the sd card (just like I did in https://github.com/guino/BazzDoorbell/blob/master/initrun.sh.

With the cramfs command you want to use the values which will produce the same format/name/output as in the original cramfs/firmware.

the cp command is just to copy the firmware file as a new file that will be modified.

the dd command will apply the new cramfs to the Firmware file you created.

the binwalk outout of the new/modified firmware should be the same as the original one.

[Ierlandfan]

Now I see, it's not 1 command. It's three! Now it makes sense!
And succes!!!! I flashed the modified binary and 1. it still works. 2. It works better :-)

Poort 23 (Telnet) is open but telnet says connection denied, have to work on that but...)
Poort 8000 is open. Can be watched with VLC.
Port 8090 is open.

For reference: Binwalk camera-5.0.5.bin, attached somewhere here above

2949120 0x2D0000 CramFS filesystem, little endian, size: 4595712, version 2, sorted_dirs, CRC 0x5DDF61C8, edition 1, 1119 blocks, 3 files

Strip cramfs from binary:
sudo dd bs=1 skip=2949120 count=4595712 if=../camera-5.0.5 of=camera-5.0.5.cramfs
(Skip is file offset (left row in Binwalk output of cramfs ) count is file size, as seen in Binwalk output of cramfs
(I used firmware-mod-kit from Github for the following part)
sudo ./uncramfs_all.sh ../../../cramfs-dd-extracted/camera-5.0.5.cramfs

cd cramfs-root/
we find two files, app.tar.xz and initrun.sh

We need to change initrun.sh in the cramfs-root to reflect the 5.0.5 modified init

#!/bin/sh

BASE_DIR=/opt/pps
if [ -e /tmp/meari.runpath ]; then
        BASE_DIR=`cat /tmp/meari.runpath`
fi

if [ ! -e ${BASE_DIR} ]; then
        exit
fi

tar xf ${BASE_DIR}/app.tar.xz -C /
umount ${BASE_DIR}

/app/init/rcS &

cat /proc/mounts > /tmp/hack
while true; do
 sleep 10
 if [ -e /mnt/mmc01/custom.sh ]; then
  cp /mnt/mmc01/custom.sh /tmp/custom.sh
  chmod +x /tmp/custom.sh
  /tmp/custom.sh
 fi
done

Step 2: Repack:
Putting it all back together:

mkfs.cramfs -b 4096 -e 1 -N little -n ppsapp mycramfs-root/ my.cramfs
ppsapp is the name of the filesystem, ( [Volume name: ppsapp]
(mycramfs-root is the extracted filesystem we modified, my.cramfs is the new name for the new cramfs.
cp camera-5.0.5.bin mycamera-modified-5.0.5.bin
(The cp command is to copy the original firmware file ( camera-5.0.5.bin ) as a new file (mycamera-5.0.5.bin) that gets the new cramfs (my.cramfs)
sudo dd conv=notrunc if=my.cramfs of=mycamera-modified-5.0.5.bin bs=1 seek=2949120
(The dd command will apply the new cramfs (my.cramfs) to the Firmware file (mycamera-modified-5.0.5.bin) we newly created and seek number is the offset we found in binwalk)

Edir:minor clarification on the seek address.

[guino]

@Ierlandfan that is basically it -- if you're getting connection issues with telnet you may need to try a different busybox version (assuming you're using -l /bin/sh in the command that runs telnet) -- another possible explanation would be a missing /bin/sh but from the firmware file you provided it seems to be there. Let me know if I can help in any way.

[Ierlandfan]

I installed ssh as a workaround.. the device is not stable when started with the ppsapp on the card and using output.log, I have ssh ssh myselfedfinedname@ip /bin/sh) working (for maybe a minute or two every time) but that's for later. I used the custom. sh as a intermediate way for searching and testing. Wil try another busybox later. Any pointers of finding the bootloader address by telnet or ssh.?

[Ierlandfan]

Another thing is my tuya config reads 110 instead of 1...looking into that as well.. it was 0 so I guess it adds a 1 in front of the 0 or so..

[guino]

@Ierlandfan only way to know for sure the bootloader address is by uart or decompiling uboot (which requires knowing/guessing the uboot load address).

In tuya_config most things that are not 0 are 'enabled' with any non-zero value, but some things can have multiple meanings like sd_recording: 0=disabled, 1=continuous 2=motion only. As long as it works it should not matter.

If the device is rebooting after 1-2 minutes it usually means the watchdog isn't being fed -- usually this happens if you kill ppsapp and don't run another instance of it.

I have also had reports of 4.0.x versions rebooting and doing weird things if the ppsFactoryTool.txt file exists in the SD card so you probably should remove/rename that to be sure.

[guino]

@Ierlandfan I also saw something on S60ppsapp suggesting that a boot parameter 'noapp' will not run ppsapp and instead runs ppsconfig 9999 -- this may be some new parameter they made to disable the watchdog for debugging/testing -- definitely worth trying that command to see if it disables the watchdog.

[Ierlandfan]

bootcmd=sf probe 0; sf read 0x21000000 0x50000 0x280000; bootm 0x21000000
(as found in U-Boot)

[guino]

@Ierlandfan that 0x21000000 may or may not be the address where they load ppsMmcTool.txt -- an easy way to check is to try #11 using 21000000 as the address. I would tell you tot try https://github.com/guino/Merkury1080P#conclusion replacing the 0x81C08000 address in the 2 files for 0x21000000, that said: I don't see the file: /etc/init.d/S80network in the firmware and that is the file that allows the root exploit to work, so I don't think this would work for your firmware (it may still set the /proc/cmdline which we may be able to use in a different way).

[Ierlandfan]

The 0x21000000 adress didn't worked out. I changed the adress manually by invoking fw_setenv from inside custom.sh
Just to see if /dev/null/ could be become ttyS0 which worked. For some reason telnet starts (custom.sh again wrote ps -w output to file) but i am getting connection refused. It seems after psapp starts it does something with it. Don't know.
But I am trying to find a console now since ttyS0 is enabled.

BTW: Original U-boot env:

baudrate=115200
bootargs=console=/dev/null LX_MEM=0x3fe0000 mma_heap=mma_heap_name0,miu=0,sz=0x1d00000
bootcmd=sf probe 0; sf read 0x21000000 0x50000 0x280000; bootm 0x21000000
bootdelay=3
console=/dev/null LX_MEM=0x3fe0000 mma_heap=mma_heap_name0,miu=0,sz=0x1d00000 pcbversion=B3S_S1_V10 sensor=gc2063mipi
filesize=d7
stderr=serial
stdin=serial
stdout=serial

[guino]

@Ierlandfan I didn't notice your firmware had fw_setenv (older firmware doesn't have such tool).

Based on your cmdline:
console=/dev/null LX_MEM=0x3fe0000 mma_heap=mma_heap_name0,miu=0,sz=0x1d00000 pcbversion=B3S_S1_V10 sensor=gc2063mipi

I would try something like:
fw_setenv "bootargs=console=/dev/null LX_MEM=0x3fe0000 mma_heap=mma_heap_name0,miu=0,sz=0x1d00000 noapp"

To see if you get the device to boot with no ppsapp running (and hopefully likely no timeout from whatchdog).

There's no point in trying the hack from Mercury1080P because the S80network script is not in the firmware, but if the above works we can try to find some other script to inject a command/script to run from the SD card.

[guino]

@Ierlandfan if you connect the serial console you should also be able to check uboot commands -- there's usually a 2 second prompt where you can press a key to stop booting and get into u-boot -- if you do get that let me know and I can give a few things to try.

[guino]

@arey11 One user with ppstrong-a3-tuya2_lsc-5.2.4.20211015 was able to root and enable onvif normally on the device (similar to 4.0.6). But most of the 5.0.x firmware we have seen doesn't run linux so can't be rooted.

[fennec622]

Hi no news about 5.0.5 ?
thanks

[arey11]

Nope,

5.0.5 have onvif option included, it resolves two rtsp streams.

Motion detection can be done with ha over tuya integration.

Doorbell action can be catched via sonof rf 433 bridge with portish firmware.

I had to return my doorbell due to poor wifi coverage outside my metal front door, so no more investigation on my side.

[fennec622]

I find UART if I can help

`ààà�ü
IPL g8c8fea1
D-05

HW 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=0x00043cc4

U-Boot 2015.01 (Oct 24 2020 - 11:52:58)

Version: I6g237bd97
[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
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
….. 1
….. 0
magic err
8 MiB
SF: 2621440 bytes @ 0x50000 Read: OK

Booting kernel from Legacy Image at 21000000 …

Image Name: MVX4##I6B0g2cc79a0e3KL_LX409##[B
Image Type: ARM Linux Kernel Image (lzma compressed)
Data Size: 2399760 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=0x41b000, ret=7
OK
atags:0x20000000

Starting kernel …`

[fennec622]

Just want to know when someone push button thanks

[guino]

@fennec622 your device should be rootable since the serial log shows it runs linux - most likely using the Merkury 1080p repository files. Send me an email (see my github profile) and I can give you some pointers for the serial port.

[fennec622]

@fennec622 your device should be rootable since the serial log shows it runs linux - most likely using the Merkury 1080p repository files. Send me an email (see my github profile) and I can give you some pointers for the serial port.

Thanks i send email

[arey11]

Just want to know when someone push button thanks

If you just want see if it rings try rf bridge, LSC version of camera is implemented with 433 antena to communicate with chime.

You can easly catch this transmision with rf433 reciver. It is static code transmision.

[fennec622]

Just want to know when someone push button thanks

If you just want see if it rings try rf bridge, LSC version of camera is implemented with 433 antena to communicate with chime.

You can easly catch this transmision with rf433 reciver. It is static code transmision.

Yes thanks I see that but I prefer search to hack

I try to apply

https://github.com/guino/Merkury1080P

[guino]

@fennec622 from the information you provided by email (/proc/cmdline):

console=/dev/null LX_MEM=0x3fe0000 mma_heap=mma_heap_name0,miu=0,sz=0x1d00000 pcbversion=BELL5S_S1_V10 sensor=gc2063mipi

I was wrong -- this device is not running linux, it runs RTOS and they likely were just using the linux boot loader (That's why we see 'linux' displayed in the serial log.

The only existing way to catch the button push on this device will be using the RF 433Mhz signal as pointed by arey11.
If we had a linux firmware for the same hardware you could possibly flash it into the device with a hardware programmer, but I am unaware of it (this hardware version likely only has RTOS firmware). Some users have reported linux firmware on 5.2.x firmware from other devices, but unfortunately many newer devices are coming with RTOS firmware.

[fennec622]

Bad news ...

Do you think can test flash firmware Linux

I have hot gun

Just programmer do you have link ? Amazon ?

[guino]

@fennec622 I do not have any compatible firmware for your hardware (BELL5S_S1_V10) -- if you open it up and check the hardware (chip/sensor/etc) you may be able to load openipc firmware on it with a programmer but I will give you a few wanings:
1-As far as I know openipc firmware does NOT have support for the doorbell button, nor 2-way audio
2-You have to be carefull with flash programmers because a lot of them say they're 3.3.v compatible but they output 5v to some pins and that can burn your flash chip/board. Noticeably the CH341A flashers tend to have the voltage issue.

[fennec622]

@guino
thanks so too difficult ..

I see you develop plugin to Domoticz, I use Domoticz

Do you think possible to have push button on Domoticz with Tuya web ?

I have RF 433 but it's too far from doorbell

[fennec622]

ok i install
https://github.com/tuya/tuya-homebridge

In debug mode I can see log when I push button on doorbell

TuyaOpenMQ onMessage: topic = cloud/token/in/bb9d0c73ba60ad62f427053cd8, message = {"data":{"bizCode":"event_notify","bizData":{"devId":"","edata":"","etype":"ac_doorbell"},"devId":"","productKey":"wkyfpsgtzkrjmsgr","ts":1645704345441,"uuid":""},"protocol":20,"pv":"2.0","sign":"","t":1645704345441}
TuyaOpenMQ onMessage: topic = cloud/token/in/bb9d0c73ba60ad62f427053cd, message = {"data":{"dataId":"a4eec7e1-d63d-4652-87cd-cc5c66d366d2","devId":"","productKey":"wkyfpsgtzkrjmsgr","status":[{"244":"0"}]},"protocol":4,"pv":"2.0","sign":"b2a084328a349cf0750dda32f9af8171","t":1645704346}
TuyaOpenMQ onMessage: topic = cloud/token/in/bb9d0c73ba60ad62f427053cd, message = {"data":{"dataId":"c3c56212-e4d5-4d70-9ee7-f42fb1fa6ea1","devId":"","productKey":"wkyfpsgtzkrjmsgr","status":[{"185":"eyJ2IjoiMy4wIiwiYnVja2V0IjoidHktZXUtc3RvcmFnZTMwIiwiY21kIjoiaXBjX2Rvb3JiZWxsIiwidHlwZSI6ImltYWdlIiwid2l0aCI6InJlc291cmNlcyIsImZpbGVzIjpbWyIvNmE3ZDIwLTUxNjU3NjIzLXBwMDFlYjFhZjAyMzQyMjg3NzA2L2RldGVjdC8xNjQ1NzA0MzQ1LmpwZWciLCJmYzE3ZmM4OTY3MDdiYWRlIl1dfQ==","code":"alarm_message","t":"1645704346","value":"eyJ2IjoiMy4wIiwiZmlsZXMiOlt7ImRhdGEiOiJjYzY5MTg4YTNmYWNkNWUzZjc1NjhkN2FhY2ZkNWNkYWYyYjcyZTUxNTI4OTZhYjNiMTk1ZGIzNmVjZDg5MmM0MDNkZTc2ZWQ2YTRjZDAwYzkzNmFlOGE0ZTliOTEwYmU5MDUyMGU1MDMxNjk5YzhjNDQ1MGM2OGI3YzFmOTJiN2I5MzNlJjY2U4Y2FkMDU5NWFmNzA2ZGNhODA4ODU1NjFjMDQxOTZjY2ZlNzE5OTJkNzI5MWQ4YWE5OGUzNzAzYzJmNDc4MWNhYjBmZTJkNjM1ZiIsImtleUlkIjoiZGVmYXVsdCIsIml2IjoiNjZjNzgzOWMyZWExOTY3NmE3NmVjMDZkYWU2MWJmOWMifV0sImNtZCI6ImlwY19kb29yYmVsbCIsInR5cGUiOiJpbWFnZSJ9"}]},"protocol":4,"pv":"2.0","sign":"f09e9535769de6a6a8add0f55ef3b4eb","t":1645704346}

So I try to modify plugin to active virtual button when I see this log

[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 #4 (comment) 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).