Paid Patch Request

[AppXprt]

6-12 Pack of Beer for a Patch :-D

Need RTSP ASAP for a hybrid Solar / PoE / USB Battery bank powered Raspberry Pi 4 b rev 1.1 Mobile OBS Studio streaming machine.

Raspberry pi 4 model b rev 1.1 with 2 of these Merkury 1080P's already rooted:

mem=64M console=ttySAK0,115200n8 loglevel=10 mtdparts=spi0.0:256k(bld),64k(env),64k(enc),64k(sysflg),3m(sys),4032k(app),640k(cfg) ppsAppParts=5 ip=0 - ip=30;/mnt/mmc01/initrun.sh)&:::::;date>/tmp/hack;(sleep

{"devname":"Smart Home Camera","model":"Mini 11S","serialno":"","softwareversion":"4.0.0","hardwareversion":"M11S_A2_V10_F37","firmwareversion":"ppstrong-a3-tuya2_merkury-4.0.0.20200911","identity":"MR2008250201450521","authkey":"","deviceid":"pp01cccb6aa97251fa7d","pid":"aaa","WiFi MAC":"*","ETH MAC":"00:00:00:00:00:00"}

user 1256 S /mnt/mmc01/busybox telnetd -l /bin/sh user 1252 S /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h

tcp 0 0 0.0.0.0:6668 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:8080 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:23 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:8090 0.0.0.0: LISTEN

-kernel_build_svn 20190403 -kernel_version 197667 -flash 8 -total 64 -hw_id 0 -sensor soif23mipi -osmem 37 -mmz:27 -pcbname M11S_A2_V10_F37 -factoryname PPSTRONG -platform A3 -btnup 0 -btndown 0 -btnpresstime 0 -pcbversion SB2S_A2_V10 -viewmirror vertical_horizontal -inputvolumn none -ouputvolumn none -micphonemode none -distortion none -modename Mini^11S -lensinfo f3.6A -halinfo 3619ev200/

ppsapp.txt

ppsapp2.txt

If you want you can teamview where I already have everything connected and Ghidra open.

[AppXprt]

Seems it still has IPC functionality:

/mnt/mmc01/home/app # LD_TRACE_LOADED_OBJECTS=1 ./ppsapp libakuio.so => /lib/libakuio.so (0xb6f08000) libakaudiocodec.so => /lib/libakaudiocodec.so (0xb6e1d000) libakv_encode.so => /lib/libakv_encode.so (0xb6dcb000) libakispsdk.so => /lib/libakispsdk.so (0xb6dc0000) libakaudiofilter.so => /lib/libakaudiofilter.so (0xb6db0000) libak_mt.so => /lib/libak_mt.so (0xb6da4000) ../../..//arch/arm-anyka3918Ev300-linux/lib/libakmedia.so => /lib/libakmedia.so (0xb6d4d000) libmpi_adec.so => /lib/libmpi_adec.so (0xb6d40000) libmpi_aed.so => /lib/libmpi_aed.so (0xb6d35000) libmpi_aenc.so => /lib/libmpi_aenc.so (0xb6d26000) libmpi_md.so => /lib/libmpi_md.so (0xb6d1b000) libmpi_muxer.so => /lib/libmpi_muxer.so (0xb6d0e000) libmpi_osd.so => /lib/libmpi_osd.so (0xb6d00000) libmpi_venc.so => /lib/libmpi_venc.so (0xb6cee000) libplat_ai.so => /lib/libplat_ai.so (0xb6cdd000) libplat_ao.so => /lib/libplat_ao.so (0xb6ccf000) libplat_ats.so => /lib/libplat_ats.so (0xb6cc3000) libplat_common.so => /lib/libplat_common.so (0xb6cb6000)

--> libplat_ipcsrv.so => /lib/libplat_ipcsrv.so (0xb6cab000) <--

    libplat_its.so => /lib/libplat_its.so (0xb6ca0000)
    libplat_thread.so => /lib/libplat_thread.so (0xb6c96000)
    libplat_venc_cb.so => /lib/libplat_venc_cb.so (0xb6c8b000)
    libplat_vi.so => /lib/libplat_vi.so (0xb6c6f000)
    libplat_tw.so => /lib/libplat_tw.so (0xb6c64000)
    libplat_vpss.so => /lib/libplat_vpss.so (0xb6c56000)
    librt.so.0 => /lib/librt.so.0 (0xb6c4a000)
    libcrypt.so.0 => /lib/libcrypt.so.0 (0xb6c2d000)
    libdl.so.0 => /lib/libdl.so.0 (0xb6c21000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb6c05000)
    libm.so.0 => /lib/libm.so.0 (0xb6bed000)
    libc.so.0 => /lib/libc.so.0 (0xb6b7d000)
    libstdc++.so.6 => /lib/libstdc++.so.6 (0xb6ab9000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6a91000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb6f13000)

-rwxr--r-- 1 1000 1000 17958 Mar 9 2020 /lib/libplat_ipcsrv.so

TUYA IOT SDK V:4.1.1 BS:30.01_PT:2.2_LAN:3.3_CAD:1.0.1_CD:1.0.0 > IPC DEFS < ENABLE_ECHO_SHOW:1 ENABLE_CHROMECAST:1 ENABLE_CLOUD_STORAGE:1 >' < BUILD AT:2020_06_05_20_53_27 BY chenjing FOR linux_wifi AT arm-anykav200-linux-uclibc-4.8.5 >

Also, I still see references to EchoShow in various places...

[AppXprt]

[AppXprt]

One last thing... I've noticed different behavior and log output via different parameters being passed to ppsapp...

Interesting: ./ppsapp 10 is different from: ./ppsapp 16 and: ./ppsapp 32

I have noticed different parameters get to different sections of code, utilizing different libraries which is evident from the output.

Looking through Ghidra I've come up with this, but no idea if it's right or what params belong to which functions: param 1 = buffer ring index channel param 2 = bitrate param 3 = fps param 4 = "max 10 seconds buffer for real-time consideration"

Some extra info I've collected:

TUYA IOT SDK V:4.1.1 BS:30.01_PT:2.2_LAN:3.3_CAD:1.0.1_CD:1.0.0 > IPC DEFS < ENABLE_ECHO_SHOW:1 ENABLE_CHROMECAST:1 ENABLE_CLOUD_STORAGE:1 >' < BUILD AT:2020_06_05_20_53_27 BY chenjing FOR linux_wifi AT arm-anykav200-linux-uclibc-4.8.5 >

ppsapp LDD:

    libakuio.so => /lib/libakuio.so (0xb6f1d000)
    libakaudiocodec.so => /lib/libakaudiocodec.so (0xb6e32000)
    libakv_encode.so => /lib/libakv_encode.so (0xb6de0000)
    libakispsdk.so => /lib/libakispsdk.so (0xb6dd5000)
    libakaudiofilter.so => /lib/libakaudiofilter.so (0xb6dc5000)
    libak_mt.so => /lib/libak_mt.so (0xb6db9000)
    ../../..//arch/arm-anyka3918Ev300-linux/lib/libakmedia.so => /lib/libakmedia.so (0xb6d62000)
    libmpi_adec.so => /lib/libmpi_adec.so (0xb6d55000)
    libmpi_aed.so => /lib/libmpi_aed.so (0xb6d4a000)
    libmpi_aenc.so => /lib/libmpi_aenc.so (0xb6d3b000)
    libmpi_md.so => /lib/libmpi_md.so (0xb6d30000)
    libmpi_muxer.so => /lib/libmpi_muxer.so (0xb6d23000)
    libmpi_osd.so => /lib/libmpi_osd.so (0xb6d15000)
    libmpi_venc.so => /lib/libmpi_venc.so (0xb6d03000)
    libplat_ai.so => /lib/libplat_ai.so (0xb6cf2000)
    libplat_ao.so => /lib/libplat_ao.so (0xb6ce4000)
    libplat_ats.so => /lib/libplat_ats.so (0xb6cd8000)
    libplat_common.so => /lib/libplat_common.so (0xb6ccb000)
    libplat_ipcsrv.so => /lib/libplat_ipcsrv.so (0xb6cc0000)
    libplat_its.so => /lib/libplat_its.so (0xb6cb5000)
    libplat_thread.so => /lib/libplat_thread.so (0xb6cab000)
    libplat_venc_cb.so => /lib/libplat_venc_cb.so (0xb6ca0000)
    libplat_vi.so => /lib/libplat_vi.so (0xb6c84000)
    libplat_tw.so => /lib/libplat_tw.so (0xb6c79000)
    libplat_vpss.so => /lib/libplat_vpss.so (0xb6c6b000)
    librt.so.0 => /lib/librt.so.0 (0xb6c5f000)
    libcrypt.so.0 => /lib/libcrypt.so.0 (0xb6c42000)
    libdl.so.0 => /lib/libdl.so.0 (0xb6c36000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb6c1a000)
    libm.so.0 => /lib/libm.so.0 (0xb6c02000)
    libc.so.0 => /lib/libc.so.0 (0xb6b92000)
    libstdc++.so.6 => /lib/libstdc++.so.6 (0xb6ace000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6aa6000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb6f28000)

LAB_0005ddf8 XREF[1]: 0005dd80(j)
0005ddf8 e0 50 9f e5 ldr r5,[PTR_DAT_0005dee0] = 0022c5e0 0005ddfc 05 50 8f e0 add r5,pc,r5 0005de00 00 70 95 e5 ldr r7,[r5,#0x0]=>DAT_0028a3e4 0005de04 00 00 57 e3 cmp r7,#0x0 0005de08 13 00 00 0a beq LAB_0005de5c 0005de0c d0 20 9f e5 ldr r2,[DAT_0005dee4] = 00196228h 0005de10 d0 30 9f e5 ldr r3,[DAT_0005dee8] = 001962DCh 0005de14 02 20 8f e0 add r2,pc,r2 0005de18 03 30 8f e0 add r3,pc,r3 0005de1c 0c 00 8d e8 stmia sp,{r2,r3}=>s_tuya_ipc_3rd_party_streaming_par = "tuya_ipc_3rd_partystreaming = "===============rtsp url:%s\n"

Also, this custom.sh script will make life a little easier:

!/bin/sh

cp /mnt/mmc01/busybox /bin/busybox

ln -s /bin/busybox /bin/du ln -s /bin/busybox /bin/find ln -s /bin/busybox /bin/wget ln -s /bin/busybox /bin/less ln -s /bin/busybox /bin/nc ln -s /bin/busybox /bin/telnetd ln -s /bin/busybox /bin/httpd ln -s /bin/busybox /bin/watch ln -s /bin/busybox /bin/route ln -s /bin/busybox /bin/nc ln -s /bin/busybox /bin/gzip ln -s /bin/busybox /bin/less ln -s /bin/busybox /bin/more ln -s /bin/busybox /bin/nslookup ln -s /bin/busybox /bin/whoami ln -s /bin/busybox /bin/strings ln -s /bin/busybox /bin/telnetd ln -s /bin/busybox /bin/httpd ln -s /bin/busybox /bin/tee ln -s /bin/busybox /bin/wget ln -s /bin/busybox /bin/unzip ln -s /bin/busybox /bin/lspci ln -s /bin/busybox /bin/lsusb ln -s /bin/busybox /bin/pkill

mkdir /local cp -R /mnt/mmc01/home/app/* /local

if [ ! -e /tmp/customrun ]; then echo custom > /tmp/customrun cp /mnt/mmc01/passwd /etc/passwd telnetd -l /bin/sh httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080 if [ -e /mnt/mmc01/ppsapp ]; then PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}') kill $PPSID

/mnt/mmc01/set record_enable 0

/mnt/mmc01/set enable_event_record 1

/mnt/mmc01/set onvif_enable 1

/mnt/mmc01/ppsapp & fi

/mnt/mmc01/offline.sh &

fi if [ ! -e /tmp/cleanupdate +%Y%m%d ]; then rm -rf /tmp/cleanup* touch /tmp/cleanupdate +%Y%m%d /mnt/mmc01/cgi-bin/cleanup.cgi > /tmp/cleanup.log fi

[guino]

I'm downloading the ppsapp files to take a look right now -- I am assuming that setting onvif_enable in tuya_config.json wasn't enough to get it to enable ONVIF/RTPS (most 4.x firmware work with that setting).

[AppXprt]

Nope, I've tried a lot of different things and nothing so far has worked, although I've learned a lot. Thank you for all your work on all of this including the root. Really awesome work!

It says in the Geeni app that the firmware is up to date, but I'm extremely skeptical, since I've had these off for years and it's reporting a build of 20200911? Around 3 years ago?

[AppXprt]

Here is the config JSON: { "version": 0, "sleep_mode": 0, "alarm_fun_onoff": 0, "alarm_fun_sensitivity": 1, "alarm_fun_mode_switch": 0, "alarm_fun_time_start": 0, "alarm_fun_time_end": 0, "flip_onoff": 0, "light_onoff": 1, "night_mode": 0, "sound_detect_onoff": 0, "sound_detect_sensitivity": 0, "watermark_onoff": 1, "event_record_time": 60, "enable_event_record": 2, "record_enable": 1, "motion_trace": 1, "motion_area_switch": 0, "motion_area": "", "motion_tracking": 0, "cry_detection_switch": 0, "humanoid_filter": 0, "ovnif_enable": 1 }

/home/cfg # /mnt/mmc01/set ovnif_enable 1 ovnif_enable is already set to 1

After a reboot, no 8554: /home/cfg # netstat -t -n -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:6668 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:8080 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:23 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:8090 0.0.0.0: LISTEN

[guino]

Well, looking at your files -- it does NOT have any RTSP or ONVIF support at all. Seems like an in-between version where in 2.9/2.10 they had the old RTSP code and in 4.0.6+ they removed the RTSP code and added ONVIF but your 4.0.0 firmware had the RTSP code removed and the ONVIF code was not yet added.

Have you ran it thru the phone app to see if there's any firmware update available ? Maybe try the merkury app specifically or the tuya app (generic) because I see we have these versions patched which match your hardware exactly:

ppstrong-a3-tuya2_merkury-4.0.2.20200929	M11S_A2_V10_F37	f66274e835bd4f1034dc251679bec61e	Mini 11S

ppstrong-a3-tuya2_merkury-4.0.6.20210207	M11S_A2_V10_F37	e5e559715d01cf8060d56ba97ce4a79c	Mini 11S

ppstrong-a3-tuya2_merkury-4.0.6.20210310	M11S_A2_V10_F37	5ea293a904a3a7c1790be74cc5f7b095	Mini 11S

My recommendation would be to try to update it with the phone app. If for some reason that doesn't work, the best I can do is see if I can find the 4.0.2 update so you can try running the ppsapp from it directly -- I highly advise against it unless you have a backup of the firmware (i.e. https://github.com/guino/BazzDoorbell/issues/11 ) and can restore it later if something goes wrong (i.e. https://github.com/guino/BazzDoorbell/issues/12 or hardware programmer) because a new firmware version might make changes to settings/data in the device which may prevent it from fully booting up.

Let me know what find out / decide.

[AppXprt]

You're awesome! I ran it through the Geeni app, but will try the others you mention. I suspected I would need to force an update, so I'll figure that out and be back soon!

[guino]

@AppXprt If for some reason mjpeg/snap is enough the address for your firmware is 0x29f584 (same for ppsapp2)

[guino]

@AppXprt additionally, you should not need to 'root' the device again. you should be able to boot without the SD card, update the firmware, delete the 'home' folder from the SD card and insert and boot it -- It should l stay rooted like before and the home folder should have the new ppsapp.

[AppXprt]

That's cool, I removed them from Geeni and adding them directly to the Merkury app after a reset.

[AppXprt]

See if you can find a firmware, because nothing I've tried can force an update.

I can only sync to Geeni and tuya app, not the Merkury App, but the Tuya app behaves identically to Geeni.

I also tried setting the time to midnight with the date command and appropriate unix timestamp.

Going to let it sit for a while the wrong time and see if it will trigger a version check since it says it checks during off hours.

[guino]

@AppXprt the closest I found is this

ppstrong-a3-tuya2_merkury-4.0.2.20200929	M11S_A2_V10_F37	f66274e835bd4f1034dc251679bec61e	Mini 11S

which you can download

Like I said, there's a chance you can brick your device so I hope you made a backup first (or don't care about it).

I would run it 'as-is' first (just place it in the root of the SD card) and see if it works at all (with the standard app) -- if it does then you can try patching it the normal way.

[AppXprt]

That triggered an update prompt in the Tuya app to v.4.0.6!

One of them is upgrading!

[AppXprt]

Brick LOL

BUT... I think I figured something out.. This 4.0.0 version doesn't check for updates as far as I can tell and it said it isn't automatically upgradable after trying to upgrade to 4.0.6 and failing, but I suspect it was trying to patch 4.0.6 over 4.0.2 when it was actually 4.0.0.

4.0.2 must actually have checks for newer versions, then when trying to upgrade to 4.0.6 through the Tuya app, it was patching as though it was 4.0.2 (since it was running that version from the SD.)

I have multiple JTAG programmers and a usb serial to UART as well as this other Mini S11 with identical firmware / version so I can probably restore that way and maybe try again a different route.

[AppXprt]

Also it still has some logic, so I know it's not completely bricked. When I plug the power while holding reset for 5-10 seconds, it will alternated between red and blue light and then go back to solid RED, then do it again in a loop.

Otherwise solid red light forever.

I'll dump the firmware of the other, flash it back to this one and see what happens.

[AppXprt]

Did the original root hack use an alternative boot process by holding the reset button while powering and if so, what do you know about that process and do you think there is a way to flash through that since it still presents some logic during this process?

[AppXprt]

Reading this and going to try a few things: https://github.com/guino/BazzDoorbell/issues/12

[guino]

@AppXprt sorry to hear you bricked it. If you can get a copy of the firmware of both cameras (the one working and the bricked one) I should be able to prepare a firmware file with just the rootfs restored (to use with https://github.com/guino/BazzDoorbell/issues/12).

If 4.0.2 'worked' (until you told it to update), we could just modify the version in the ppsapp file to say 4.0.0 (so it doesn't ask to update it) and you could then see if the app works normally (and if RTSP/ONVIF works after patching).

You don't want to just load the entire firmware from one device onto the other as that would copy the cloud certificates and prevent them from being online at the same time.

[AppXprt]

Following your Firmware backup for the working one and then the Firmware Write for the bricked one, I can definitely tell it's writing, because I get new behavior on write, solid blue light. Regardless of failed writes, this still seems to be working for now, but still bricked trying to write flash.bin.

Attaching multiple dumps with various start addresses for the working one: flash-read-attempt-81C08000.bin.txt flash-read-attempt-42000000.bin.txt flash-read-attempt-81808000.bin.txt

binwalk.txt

[AppXprt]

Oops, you know... I should have thought of that.. I have the MAC's, SN, and other info, but not the certs most likely... Maybe... but doubtful...

Edit: I found a ca.crt along with an ASC16 file in a few backups?

[guino]

It looks like all 3 attempts had the same result which may not even be actually reading from the device itself (could be just data left over in the SD card).

Either the update attempt corrupted the flash to the point of the boot loader no longer loading or something didn't work with the 'read' process. Unfortunately I don't have any device with 4.x firmware to try the steps to read the flash myself and see if they need any tweaking.

If you have tools (flash programmer and/or TTL-uart adapter) you could open the device and try to read it that way (either way would involve some soldering).

The ca.crt, ASC16 are the same for all devices, the files you need are tuya_user.db and tuya_enckey.db under /home/cfg (which should be unique to each camera). If you don't have a backup of those, you could still use the device 'offline' (assuming we can get RTSP working), by copying the whole flash from the other device and either disabling internet access, removing the tuya_enckey.db and tuya_user.db files or just making an offline patch.

It sounds like tuya probably knows that there's an issue with updating firmware on these 4.0.0 devices and that's likely the reason they don't offer any updates to it -- probably some bug or missing tool in the existing firmware required to perform the firmware update correctly.

Did you try to get a firmware copy of your working camera for comparison ? the address should be 81C08000.