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: https://github.com/guino/BazzDoorbell/issues/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: https://github.com/guino/BazzDoorbell/issues/62#issuecomment-991429834, 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 Androidhttps://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)

@Ierlandfanhttps://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 GitHubhttps://github.com/guino/BazzDoorbell/issues/62#issuecomment-991935710, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABWNEDJSC7PBGH7CTSEDEPLUQTKANANCNFSM5JQWVBKQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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.

[RichardIstSauer]

I also have the LSC Doorbell with the firmware version 5.0.5 and you can enable ONVIF basically at the tuya app. But I want RTSP but this http://admin:056565099@ip/proc/self/root/etc/init.d/S90PPStrong shows nothing.

[nvschilleman]

I also have the LSC Doorbell with the firmware version 5.0.5 and you can enable ONVIF basically at the tuya app. But I want RTSP but this http://admin:056565099@ip/proc/self/root/etc/init.d/S90PPStrong shows nothing.

Just enable onvif in the tuya app and use the following rtsp links:

rtsp://admin:[email protected]:8554/Streaming/Channels/101
rtsp://admin:[email protected]:8554/Streaming/Channels/102 

[guino]

@RichardSauer on the 5.0.5 firmware I saw above they changed the file to S90app so if it is the same or similar firmware the link will be: http://admin:056565099@ip/proc/self/root/etc/init.d/S90app

If you can enable it on the app, you should be able to use the links posted by @nvschilleman -- ONVIF is basically RTSP + extra features around it.