Damn, I bricked my camera!

[wangxiaoming1986]

HELP !

So the story goes like this. I have a tuya " Mini 7s" camera from CALEX, with the details below:

"devname":"Smart Home Camera","model":"Mini 7S", "serialno":"074934231","softwareversion":"2.9.6"," hardwareversion":"M7S_H1_V11_F23","firmwareversion":"ppstrong-c51-tuya2_calex-2.9.6.20200522",...

I followed https://github.com/guino/BazzDoorbell/issues/13 and all went well, or partially well I might say. I got telnet access, I could play "snap.cgi" and "mjpeg.cgi" (after changing the address), but RTSP would not work for the life of me. I patched for the version of my firmware, following the instructions, made sure the patched ppsapp was on the root of the SD card, heard the double start-up sound (so the patched ppsapp was loaded), but RTSP would just not work. Everything else was fine though. One interesting bug I noticed was that if a custom password was set for telnet access, login would not work after the loading of the patched ppsapp. I tried and retried the hashed password that I set up, but it would not log me into telnet. However login would work if I had removed/renamed the ppsapp from the SD card's root so that it doesn't get loaded. To avoid this I configured for a passwordless login and telnet worked after loading the root ppsapp.

Seeing that RTSP still didn't work, I thought I should perhaps learn to patch it myself before asking for help. But even before that, I thought what if I re-root my camera with the instructions from https://github.com/guino/BazzDoorbell/issues/2, since it is mentioned that both versions work, just to see if that will make ppsapp work and give me an RTSP feed (I am no linux guru, I am trial-ing and error-ing without much clue as to what I am doing), or affect the behavior of the camera in any way. And affect it, it did! The camera was rooted, all the folder structure appeared on the SD card, the same as with the #13 method, but "snap.cgi" and "mjpeg.cgi" would not work, despite making sure the address was changed with the one specific to my firmware. RTSP didn't work either as the 2nd start-up sound was not heard even with the ppsapp file on the root of the SD card. So for some reason ppsapp wasn't loading.

Then I decided what if I replace the "initrun.sh" from "2" with the "initrun.sh" from "13". This is when I had a feeling that things might go south, but I nevertheless pushed ahead. Attempting this to see what may happen seemed a lot easier than learning to patch my ppsapp (or admit defeat and ask for help) and deal with memory addresses and things I don't quite understand well yet. Difficult endeavors are always dealt with last. Tackle the easy stuff first, my inner inspiration told me. And it was damn easy to replace the "initrun.sh" file.

BUT, upon reboot, the camera showed me an ugly solid red LED similar to that of HALL 9000 from 2001: A Space Odyssey, and it stays like that forever, red and menacing, it doesn't even blink at me to appear friendlier :P No matter if I remove the SD card or not, the red led light remains present. So my camera is currently unresponsive or bricked just because I messed with the "initrun.sh" files from different root approaches.

Now, dear reader, could you please help me get out of this rut? Is there any way to restore my camera to normal functionality, and then hopefully repatch/re-root it again with the right files so that the RSTP stream works? I am ready to embark on a difficult endeavour and learn what I must, as I've exhausted my "easy-to-go" options.

[guino]

@wangxiaoming1986

I have mentioned these a number of times: -NEVER mix ppsapp versions -- your ppsapp should be version 2.9.6 for your firmware 2.9.6 (if you run 2.9.7, etc it will likely brick your device) -NEVER mix scripts of different processes (i.e #2 with #13 and vice-verse) -- it just won't work and if you used #2 at all then you'll not be able to boot your device.

13 is the preferred process as it allows the device to boot normally without SD card (#2 will only boot with the correct files in the SD card).

Without knowing what your /proc/cmdline is currently setup, the only thing I can suggest is to follow the #2 troubleshooting steps to RESTORE your device to factory state (this requires you knowing your original cmdline information in env file and copying the ppsMmcTool.txt from #2).

If you follow the #2 troubleshoot steps and it doesn't boot then either your cmdline information is wrong or your device has some sort of hardware issue.

[wangxiaoming1986]

@guino

Indeed, I remember reading all those admonitions, and I took them very seriously the first time. When I saw that even doing so the RSTP stream still didn't work (I used #13 at first), I began fiddling with the settings. I never ran a different ppsapp file, but I did run the "initrun.sh" from #13 after having rooted the device with #2. That's when my camera froze. It was missing the "initrun.sh" file specific to method #2, without which the camera stops working. I panicked when I saw that even when attempting a restore the camera was still frozen. What I forgot to do is hold the reset button down while powering on the camera. Doing this returned my camera back to the correct factory /proc/cmdline, and all is well now, the camera works as it did when I first bought it.

You and others have contributed with so much work and info on these cameras (I appreciate that, of course, and am very happy to buy you a beer :) ), writing about what works and what doesn't, what to do and what not to do, and when to do it, that it is daunting and overwhelming to navigate through. Jumping from one link to the other and trying to follow the thread that guides you to root your specific camera feels, at times, quite confusing. There is useful stuff in every comment, but does it apply to me? Well, there is only one way to find out, by trying it, and then possibly breaking things, and then learning how to unbreak them, and then understanding everything a bit better.

Now I am back to square one. I have re-rooted the camera with #13, everything works except the RTSP stream. Wanting to know what happens, I also added the code for outputting the log file from the custom ppsapp, but nowhere can I see any RTSP request from VLC. But then again, I don't even know what I am looking for, there's so much stuff in that log file... So I need help making the RSTP stream work now. "mjpeg.cgi" and "snap.cgi" work without a flaw.

[guino]

@wangxiaoming1986 post a zip of your SD card without the SDT folder and I can take a look.

I assume you used the existing patch for your firmware and it didn't work ? usually people forget to copy the patched ppsapp file to the root of the SD card or the file is incorrectly named (i.e. have .txt on the filename, etc) -- in windows that's pretty common because it likes to 'hide' extensions for files.

[wangxiaoming1986]

Yep, that's correct, I have downloaded the patch from here, as I found it specific to my firmware. Mine is correctly copied to the root of the SD card, and it has the correct file name, no extension, no nothing. It is named exactly like the one from /home/app, and also the correct size and correct MD5 hash.

I was willing to try and patch the ppsapp myself following your instructions, though I am not very fond of addresses in hex and assembly instructions. That is why I fiddled with other root methods first as that seemed easier, but that got me into trouble.

Well now, I have only one option, learn to patch my own ppsapp. Or abuse your time and ask you to patch it for me. :)

[wangxiaoming1986]

I'd be happy for you to say NO, just so that I am forced to do it myself, and learn something new, step out of my comfort zone, etc. If after trying my best I still fail, then I am happy to ask for help :) Patching my own ppsapp, I mean!

[guino]

@wangxiaoming1986 just post a zip of your ppsapp and I'll take a look.

[wangxiaoming1986]

@guino ppsapp - xiaoming.zip

Thank you !

[guino]

@wangxiaoming1986 can you try this patch ? (same steps as original patch) ppsapp-rtsp.zip

[wangxiaoming1986]

@guino What a breath of fresh air after so much failed attempts (on my part) to make it work!!! I get a lovely stream from VLC and also telnet's netstat shows that port 8554 is open, whereas with the first patch it was not. IT WORKS ! I don't know how you did it, but it fascinates me that you managed to do that and you understand all that machine code that literally gives me a headache just to look at.

I'd wish to learn what you know, and play more with these cameras, learn how to make them completely offline forever and ever, how to send time/date info to them so that they don't get that from the TUYA servers, perhaps even find a way to send sound (in the sense that I speak live in a mic) to the integrated speaker, turn on and off the LEDs. This reverse engineering seems so magical!

Please accept many cans of beer from me, it's the least I can do to give something back as well, when you have given us so much more! And please don't get too drunk! :D

[guino]

@wangxiaoming1986 thanks for the beers! I am glad it works now! I think there was just something wrong with that patch file, I re-did it and it should be good.

Remember to backup your SD card files!

If you want to use it offline check out his wiki: https://github.com/guino/BazzDoorbell/wiki/%5BHow-to%5D-Use-the-device-OFFLINE-(disconnected-from-tuya-servers)-%3F

If you want to make it offline using a patch (option 2 from link above) I can make that patch for you but you'll then need to make a local NTP server (or at least allow an internet NTP server to be accessed by the device thru the filrewall). It is far easier to just use the offline script that requires no patching and no NTP server. Without the NTP server the date/time on the feed would be wrong.

For audio playback: without that tuya cloud stuff would definitely have a large delay (recording/copying/playback) -- even thru the tuya app I think it's already too slow but you can play pre-recorded audio easily: https://github.com/guino/BazzDoorbell/wiki/%5BHow-to%5D-Play-custom-sounds-trough-your-bell-speaker.

[wangxiaoming1986]

@guino You are welcome! It might be a good idea to have the old patch for my firmware replaced with the one you just made, so that other people with the same firmware like mine can download the one that works and not the one that gave me headaches for a few days. :)

My working SD card has been backed up and deployed to the rest of my 7 cameras that I have, which luckily have all got the exact same firmware. I confirm that all 7 work. And I am so glad I haven't updated when tuya prompted me to!

The reason why I am very much interested in a forever offline way to operate these cameras is because I want no strings attached to the tuya network once I bought the hardware. They are a chinese company (even the name TUYA is a pinyin transliteration of two Chinese characters), and having lived in China for many years, and seeing the attitude of the chinese companies to privacy and data theft, I want nothing to do with any technology coming from chinese initiative, at least not while communism rules their land anyways. While I like the offline script you wrote, which works well and which I have uncommented to see in action, I'd like a more permanent and forever patch. I would be happy to provide my own local NTP server for time sync (I am currently learning what an NTP is and how to make it work). But no connection to the Chinese, not even to get the time and date.

All of the above ties well into why I also want the ability to stream audio to the cameras from let's say a desk mic, or headset connected to my computer. It is because all these cameras are used for surveillance and assistance of a family member (grandma) that has dementia and doesn't even remember where she's placed the phone, or any number to ring to call for assistance, or how to dial it. There is somebody coming in every so often to check on her, but I also want to see what happens and be able to intervene when necessary. So I currently use all of my 7 cameras (and plan to buy more if I can find them with the same firmware, or firmware that I can patch) which are deployed in strategic locations around her abode. This allows me to hear and see everything that happens, to be the "voice from heaven" that speaks and guides.

Since grandma is also a bit hard of hearing due to advanced age, I had to desolder the speaker of every camera and connect them to an amp and then to large speakers. With this setup I can be heard even if you have no eardrums or you are deaf completely! I literally thunder down from the (tuya) cloud, and be the voice from heaven that guides and counsels grandma what to do and what not to do, what medicine to take, and what no to take and when to take it. I can even hear everything that happens, what she speaks, know where the cat is, hear the dog bark (hence somebody approaching the area) etc. I have even been told that God has spoken to grandma (as she says that she hears voices that guide her coming out of the black boxes - the speakers), and I am happy that she listens to God's guidance as it seems that God cares for her and loves her, she says. Our family has already had a very hard time convincing her to do anything, we only get grief if we try. One gets very stubborn with old age, especially if you don't even remember what you agreed to do 1 minute before and now you reject it saying that you never agreed to it. You never get anywhere this way. But these cameras really help. Since grandma was a devout christian all her life, she listens to God more than she listens to us her family. So God I am, for the time being :D

As you can imagine I did all this through the tuya app on my phone until recently. But it is tedious cycling through the stream of 7 cameras (and soon more), and very cumbersome overall. But it works, there is not much lag, my voice arrives at the camera in under a second from the moment I speak it in the tuya app (despite hundreds of miles apart geographically), and the reply of grandma has a similar delay. There are no wifi devices around the area, only what I set up myself, so I guess that explains the low latency, plus the good internet connection between me and her. The RTSP streams are literally flowing like rivers of fresh water unimpeded by any wifi saturation in the area. But I wanted to speak to her through my own cloud, not through the tuya cloud. With your help I have managed to seer her (the RSTP issue being solved), so now I sit in front of my desk, at a multiple monitor computer and can see all 7 streams rushing in from far away, through a properly configured router with zerotier network. The only thing I am missing is the possibility to stream audio to her. And when the stream doesn't contain my voice, I can play a radio station through all the black boxes in the house (the source of heaven in grandma's terms). Perhaps grandma will think a heavenly choir of angels are singing to her. Joke aside, it works, and it helps a lot my family managing her and also managing our sanity. And it's way cheaper than paying the exorbitant fees of a care home.

So audio streams, with RTSP offline forever (with a NTP server) are the next step in my endeavor to completely jailbreak these cameras.

If you could help with any of these issues I would very much appreciate it, but I don't want to make you feel that you must help. You've already done so much that no amount of beer will suffice to thank you. But I am thinking out loud here and learning more about these cameras, in the hopes that perhaps I could implement these changes I want myself. Don't they say that "be the change you want to see in the world" and not always expect to be spoon fed? :D Maybe I will accept to be spoon fed when reaching the age of grandma, I'll probably have no choice that time anyway, but while I still have neurons that still fire, I'd rather put them to work towards achieving my goals. Any help is appreciated along the way, of course, but I do not expect it. I only thank you for your effort and help thus far !

[guino]

@wangxiaoming1986 I already replaced the patch in the main list.

I'll work on the offline patch for you so you don't need the tuya cloud if you don't want to use it -- like I said you'll either need to setup a local ntp server OR allow access to an internet based ntp server then add /mnt/mmc01/busybox ntpd -d -q -n -p ntp.server.com to custom.sh to sync the time. There's some info on this post (and on this issue) for working offline: https://github.com/guino/BazzDoorbell/issues/4#issuecomment-1209748973 it's kind of long but useful information for working offline. If you don't care for the time displayed being correct then you don't have to do anything.

On the audio front this guy did some proof of concept using MQTT and said it worked: https://github.com/guino/BazzDoorbell/issues/4#issuecomment-797873986 but I personally have never tried it (not sure he posted his files either) -- maybe worth reaching out to him if you're interested on that. I don't think I have the bandwidth right now to do much research on that as I would probably try to approach this by making a java application to record and send the audio data, then have a native application on the camera receive and playback the audio. As of right now all you can do is have pre-recorded audio files (as many as you want on the SD card for instance) with multiple messages like, hello, yes, no, etc and use play.cgi to play them with url requests. In theory you could use something to record a .wav file locally (in the right format), use upload.cgi to upload it to the camera and then play.cgi to play it back -- this obviously would be very laggy right now.

[guino]

@wangxiaoming1986 you can try this patch for offline startuo -- you CAN and SHOULD use this patch over your RTSP patched ppsapp file (in the root of the SD card), that way you will have RTSP and offline startup.

Please use the same steps as before to patch it (ROM patcher): ppsapp-offline.zip

Let me know how that goes.

[wangxiaoming1986]

@guino I have checked /mnt/mmc01/busybox ntpd -d -q -n -p ntp.server.com with my local pfsense NTP server in preparation for running the cameras fully offline, and the command works. I will add it to the script later.

I have also studied in more depth the proof of concept using MQTT and I must admit that the method introduces a lot of delay, at least that is what I understood from reading it. Will try to implement later once I can confirm I am fully offline first.

However, patching my already patched ppsapp for offline operation did not work. I can still access the camera from the tuya app, as well as stream locally with VLC. Netstat also shows established connections to some amazon servers. It seems that it must be more tedious to create a patch for offline operation than it is to enable RSTP. While checking all this I noticed something peculiar. I was running a local RTSP steam with VLC and simultaneously accessing the tuya stream on the phone. When moving the camera to the left or to the right, the image on VLC would take longer to refresh than the image on the phone. I was surprised how can a local RTSP stream have longer delay than the same stream routed through the internet. How would one attempt to explain this peculiarity?

Trying to understand if the offline patch works at all, I also patched the original ppsapp (the one without the RTPS patch), just to see if there is any difference in the connections the cameras makes compared to not having the ppsapp at all on the root of the SD card. And there is no difference at all, the camera behaves like there was no patch applied or it was running the default firmware.

[guino]

@wangxiaoming1986 so a few things to notice: 1-The patch does not block internet traffic -- all it does is allow the device to boot up completely (to enable RTSP stream) if there's no access to the Tuya servers. You have to block access to the tuya servers yourself using firewall, hosts file or just disconnecting it from the internet altogether and having it only in an isolated network.

2-The phone app does not stream the video over the internet if it has access to the device on the local network, it finds the device locally and connects to it directly whenever possible. Only if you're accessing it from a different network is that it will then try to stream over the internet (and I'm not sure it will route the stream thru tuya servers either, I think it just uses the tuya servers to make the link between device and app, then lets the two talk directly to each other if at all possible).

If you want to block tuya servers using hosts file there's one you can use here: https://github.com/guino/BazzDoorbell/wiki/%5BHow-to%5D-Use-the-device-OFFLINE-(disconnected-from-tuya-servers)-%3F -- the problem is that you'll need to copy it to /etc on the device and that needs to be done on every boot, so blocking internet on a firewall is the only way to ensure you won't connect to tuya servers at all as the device may have time to connect to tuya servers before you copy the hosts file to /etc -- but you can try just adding cp /mnt/mmc01/hosts /etc before the /mnt/mmc01/ppsapp & line (in custom.sh).

[wangxiaoming1986]

@guino I like it that you really don't take no for an answer :)

I apologise for the confusion and thank you for clarifying. The offline patch works correctly, the cameras were placed on an isolated network, so they do not see the internet. I can stream them all successfully. I am happy to keep them this way for the time being. If in the future I want them to be accessible again through tuya (for whatever reason), then I only have to change the settings on the router, as opposed to having to take each individual SD card and do the modifications manually.

The peculiarity still persists. The local RSTP stream seems laggier than when the stream is routed through the internet (through a 4G connection) using the tuya app. I find that strange, don't you?

Now, another issue that I struggled a bit with today, and it is still unresolved, is the line /mnt/mmc01/busybox ntpd -d -q -n -p myNTPserver.com. Where do I place it in the "custom.sh" script? I already tried after /mnt/mmc01/busybox telnetd -l /bin/sh but it didn't work. I then tried after /mnt/mmc01/ppsapp & and it didn't work. Then I placed it before /mnt/mmc01/offline.sh & and it did not work either. But when I run the command through telnet, it finds my local NTP server and updates correctly. Or I should say, rather correctly... because there is an issue with the timezone not being right. I fixed that by editing echo 'PST-1' > /home/cfg/TZ and then added the line immediately after running the patched ppsapp. The command runs and works, I checked with telnet. But the command that gets the time from my NTP server doesn't work. I have even added sleep timers just in case the wifi connection was not up, but the time doesn't get updated. What else would you suggest me do?

[guino]

@wangxiaoming1986 I haven't checked deep enough in the ppsapp code to see if the tuya phone app uses RTSP or some other (custom) streaming service. If it does use RTSP I am 100% certain it is a different code than the RTSP code we use with VLC -- this is likely the source of any differences in streaming (lag) when using the same network.

The ntp command should work if you place it right after the telnetd command -- the time zone command can be placed right before (or right after) the ntp command as well. If the command is working on telnet and not on the custom.sh script likely it is quitting because there's no network available at the time it is executed, so a simple solution is to use this instead: /mnt/mmc01/busybox ntpd -d -q -p myNTPserver.com (notice the original command had -n and I removed it) -- this allows the ntp command to run on the background until it can sync the time and once it does it will exit (as it's no longer needed).

[wangxiaoming1986]

@guino Fascinating ! The ntpd command works with "-n" dropped. It never occurred to me to type "ntpd --help" to see what other parameters there are.

Regarding the audio stream, I will read and learn more, for now I am happy with how the cameras work.

Thank you one more time for you help!

More beer to you!

[guino]

@wangxiaoming1986 thanks for the beers! Glad you got the ntp thing working. I may try to research a little bit on the audio streaming when I have some time (which is hard to find).

[wangxiaoming1986]

I will also be looking at the audio stream. If I find anything before you do, I will post it here. It'd be interesting to find a way to make it work!