omniparker commented 5 years ago

I was wondering if the Tuya Security Camera's may be possible. They work within the same app and I am able to get id and key in the normal manner. I tried to get the signature but don't see it in my logs. I bought the Mercury Security Camera from Walmart. It adds to the Tuya App like everything else. Would it be possible? What can I provide to help if it would be possible.

TimelessNL commented 3 years ago

Any other idea how to get the RTSP to work?

@EliasKotlyar have you tried opening the camera? I've seen some pictures of tuya based cameras that had a serial port at 57600 baud. Maybe thats your way in. Then you can browse on the filesystem and probably find something usefull.

guino commented 3 years ago

https://github.com/da-ha3ker/Merkury-Smart_cam-720p-work I uploaded the extracted bin. I am not super good at extracting data from these types of files and I am sure there is more that I have not found. I had to compress the folder named _7373C.extracted to upload it to GitHub, but if you use 7zip or WinRar you can extract it again. The hard part of aligning the partitions was already done so they are just the files. Please dig into these files. The hash is available in the _7373C.extracted/etc/passwd file. There is only one user, that being root. I think there are more jffs2 files we don't have access to though, including JSON files and web configuration information.

From the extracted bin file I was able to find a telnet toggle in the ppsapp application:

$ curl http://admin:056565099@10.10.10.7/sys/telnetd/switch
<html><body>Telnetd service started ok</body></html>
$ curl http://admin:056565099@10.10.10.7/sys/telnetd/switch
<html><body>Telnetd service stopped ok</body></html>

Unfortunately on my camera (doorbell) the commands show the above but it seems the telnetd service/file is actually missing from the image, so it doesn't actually do anything. Chances are the above will work on some cameras (and/or likely earlier firmware) like in the bin file you extracted. On my case I've already gone thru the PCB/UART route and u-boot is password protected -- I even tried the bomb to uboot method (ground SO pin of the flash chip) without success. The only thing left for me is now is to read/write the flash chip directly (will have to buy an adapter).

CoooWeee commented 3 years ago

I also have a Bell 5S (called Orion Smart Video Doorbell sold by Bunnings/AU):

{
"devname":"Smart Home Camera",
"model":"Bell 5S",
"softwareversion":"2.9.2",
"hardwareversion":"BE5S_H1_V10_433",
"firmwareversion":"ppstrong-c51-tuya2_arlec-2.9.2.20191111"
}

@vinstech Your post was really helpful.

My camera works with an Android App which is called Grid Connect. During streaming the app is connected to the camera via TCP/6668 and the stream come on a random UDP port > 4XXXX.

This app has following settings:

    public static final int FRAME_CONTENT_OFFSET = 12;
    public static final int HEART_BEAT_PERIOD = 10000;
    public static final String STR_VERSION_1_1 = "1.1";
    public static final int TCP_PORT = 6668;
    public static final int TCP_TIMEOUT = 30;
    public static final String TUYA_SMART_SERVICE_TCP = "tuya.intent.action.tcp";
    public static final String TUYA_SMART_SERVICE_UDP = "tuya.intent.action.udp";
    public static final int UDP_CLIENT_PORT = 6670;
    public static final int UDP_LOG_PORT = 7000;
    public static final int UDP_PORT = 6666;
    public static final int UDP_PORT_NEW = 6667;
    public static final int UDP_SERVER_PORT = 6669;

I could not spot anything helpful yet. They set TuyaNetworkInterface.setSecurityContent via the byes of a BMP image: fixed_key.bmp.zip

Although there is a fallback where they use "soisiwoejre".getBytes() or "woeijrweir".getBytes()

mearitek stated that the "Bell 5S" does support RTSP their support said my model doesn't.

TopdRob commented 3 years ago

Could this help someone? http://cdn-meari-us-oss-us-west-1.meari.com.cn/firmware/gray/ppstrong-b5-ctv-3.2.1.20200708-upgrade.bin

guino commented 3 years ago

Could this help someone? http://cdn-meari-us-oss-us-west-1.meari.com.cn/firmware/gray/ppstrong-b5-ctv-3.2.1.20200708-upgrade.bin

what device is that from -- it could be helpful for someone with the same hardware cause I know there is a way to upgrade the firmware from SD card and we may be able to 'customize' the bin file before upgrading.

b1ndm4n commented 3 years ago

Could this help someone? http://cdn-meari-us-oss-us-west-1.meari.com.cn/firmware/gray/ppstrong-b5-ctv-3.2.1.20200708-upgrade.bin

what device is that from -- it could be helpful for someone with the same hardware cause I know there is a way to upgrade the firmware from SD card and we may be able to 'customize' the bin file before upgrading.

im going to assume it is either a Snap 5s or a Bell 5s from https://www.mearitek.com/products/

TopdRob commented 3 years ago

I've found another one which is from a Merkury Innovations Smart Wi-Fi Camera (MI-CW007- 199W http://s3-us-west-2.amazonaws.com/airtake-public-data/smart/firmware/upgrade/201807/1530687241-ppstrong-c4-tuya2-geeni-1.10.2.bin

I've tried to change the last part to the firmware version of my device however I don't have the timestamp.

dfsx1 commented 3 years ago

Yeah, if you power the write enable pin you can flash using this programmer, it is called a ch341a programmer. That is how I got the dump file. The hard part is editing the hash and re-compiling the bin file to be the exact size and page size with the boot instructions put in the right place. I don't know how to do that due to aligning partitions and other things that can go wrong super easily. The flash chip is designed for multiple writes, but it wears out after about 30 full flashes so I want to do it sparingly. I will give it a whack though. Set the password to something like 123 and flash it back. It is probably similar to the ddwrt custom firmware stuff. I will check it out. Thanks for helping with the hash cracking by the way! Let us know if you make a breakthrough? Also, I am a bit busy this week, but I still plan on working on this. I want to be able to play with facial recognition from a WiFi camera as a senior project.

I failed to read anything from the (XMC QH64AHIG) flash chip with a SOP8 test clip 🥺. Only after desoldering from the board I could successfully read it with CH341A (modified for 3.3v).

I see certain high/low settings for also CS#, HOLD#/RESET# pins specified in the datasheet: https://datasheet.lcsc.com/szlcsc/1811072025_XMC-XM25QH64AHIG_C328461.pdf

@Jordan-Jarvis you remember doing anything with these other pins (except WP# for writing) to just succesfully read/verify? Or maybe you have a other flash chip?

guino commented 3 years ago

I failed to read anything from the (XMC QH64AHIG) flash chip with a SOP8 test clip pleading_face. Only after desoldering from the board I could successfully read it with CH341A (modified for 3.3v).

I see certain high/low settings for also CS#, HOLD#/RESET# pins specified in the datasheet: https://datasheet.lcsc.com/szlcsc/1811072025_XMC-XM25QH64AHIG_C328461.pdf

@Jordan-Jarvis you remember doing anything with these other pins (except WP# for writing) to just succesfully read/verify? Or maybe you have a other flash chip?

I also have the same chip (XMC QH64AHIG) on a 'bazz doorbell' (I highly believe it's same hardware as merkury/geeni/meari doorbell "5S"). I finally made some progress with this today as I received my CH341a programmer with the same clip on your picture (to which promptly applied the 3.3v fix). It also failed to read the flash using the clip while on the board BUT I figured I'd try to disconnect as few pins as possible to see if the programmer would work and got lucky: after a few tries it was only required to disconnect pin 6 (CLK) from the board and I was able to both READ and WRITE using the clip. After review with binwalk I confirmed telnet is not installed in this image (labeled version 2.9.6), so I rebuilt the cramfs partition with a few extra lines in the startup script to check/wait and run a custom script from the SD card -- merged that into the firmware bin, flashed it and got my custom script to execute. Last thing I did tonight was to copy the static binary 'telnetd' from a camera I already had (of similar OS/Chip) and adjusted the script to run telnet in passwordless mode, result:

# telnet 10.10.10.7
Trying 10.10.10.7...
Connected to 10.10.10.7.
Escape character is '^]'.

BusyBox v1.26.2 (2019-11-03 17:33:40 PST) built-in shell (ash)

/ #

So now I can close this up and tinker a bit more (remotely) to see if I can get onvif working and hopefully add the modules to maybe write the videos straight to my NAS (bypassing SD card). I will always need a SD card in this device to run my custom stuff (there's only 100Kb free space on this thing - used for config), but I never liked the idea that someone could rip the device off my door and just take it along with the video evidence of it. At the very least I'll make something to copy the files to my NAS as they are recorded on the SD card.

n0ggi3 commented 3 years ago

I was messing around with setting up a pi-hole tonight and started wondering. Dns poisoning... Is it possible to setup our own Mqtt servers and setup dns to resolve the Tuya address to our own server?

On Sun, Nov 22, 2020, 10:30 PM Wagner notifications@github.com wrote:

I failed to read anything from the (XMC QH64AHIG) flash chip with a SOP8 test clip pleading_face. Only after desoldering from the board I could successfully read it with CH341A (modified for 3.3v).

I see certain high/low settings for also CS#, HOLD#/RESET# pins specified in the datasheet: https://datasheet.lcsc.com/szlcsc/1811072025_XMC-XM25QH64AHIG_C328461.pdf

@Jordan-Jarvis https://github.com/Jordan-Jarvis you remember doing anything with these other pins (except WP# for writing) to just succesfully read/verify? Or maybe you have a other flash chip?

I also have the same chip (XMC QH64AHIG) on a 'bazz doorbell' (I highly believe it's same hardware as merkury/geeni/meari doorbell "5S"). I finally made some progress with this today as I received my CH341a programmer with the same clip on your picture (to which promptly applied the 3.3v fix). It also failed to read the flash using the clip while on the board BUT I figured I'd try to disconnect as few pins as possible to see if the programmer would work and got lucky: after a few tries it was only required to disconnect pin 6 (CLK) from the board and I was able to both READ and WRITE using the clip. After review with binwalk I confirmed telnet is not installed in this image (labeled version 2.9.6), so I rebuilt the cramfs partition with a few extra lines in the startup script to check/wait and run a custom script from the SD card -- merged that into the firmware bin, flashed it and got my custom script to execute. Last thing I did tonight was to copy the static binary 'telnetd' from a camera I already had (of similar OS/Chip) and adjusted the script to run telnet in passwordless mode, result:

telnet 10.10.10.7

Trying 10.10.10.7... Connected to 10.10.10.7. Escape character is '^]'.

BusyBox v1.26.2 (2019-11-03 17:33:40 PST) built-in shell (ash)

/ #

So now I can close this up and tinker a bit more (remotely) to see if I can get onvif working and hopefully add the modules to maybe write the videos straight to my NAS (bypassing SD card). I will always need a SD card in this device to run my custom stuff (there's only 100Kb free space on this thing - used for config), but I never liked the idea that someone could rip the device off my door and just take it along with the video evidence of it. At the very least I'll make something to copy the files to my NAS as they are recorded on the SD card.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-731920209, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEC6WBRDEXLHNLMULPXH3ATSRHQOXANCNFSM4GMY7FQA .

cbytestech commented 3 years ago

Oooh maybe?

On Mon, Nov 23, 2020, 12:52 AM n0ggi3 notifications@github.com wrote:

I was messing around with setting up a pi-hole tonight and started wondering. Dns poisoning... Is it possible to setup our own Mqtt servers and setup dns to resolve the Tuya address to our own server?

On Sun, Nov 22, 2020, 10:30 PM Wagner notifications@github.com wrote:

I failed to read anything from the (XMC QH64AHIG) flash chip with a SOP8 test clip pleading_face. Only after desoldering from the board I could successfully read it with CH341A (modified for 3.3v).

I see certain high/low settings for also CS#, HOLD#/RESET# pins specified in the datasheet:

https://datasheet.lcsc.com/szlcsc/1811072025_XMC-XM25QH64AHIG_C328461.pdf

@Jordan-Jarvis https://github.com/Jordan-Jarvis you remember doing anything with these other pins (except WP# for writing) to just succesfully read/verify? Or maybe you have a other flash chip?

I also have the same chip (XMC QH64AHIG) on a 'bazz doorbell' (I highly believe it's same hardware as merkury/geeni/meari doorbell "5S"). I finally made some progress with this today as I received my CH341a programmer with the same clip on your picture (to which promptly applied the 3.3v fix). It also failed to read the flash using the clip while on the board BUT I figured I'd try to disconnect as few pins as possible to see if the programmer would work and got lucky: after a few tries it was only required to disconnect pin 6 (CLK) from the board and I was able to both READ and WRITE using the clip. After review with binwalk I confirmed telnet is not installed in this image (labeled version 2.9.6), so I rebuilt the cramfs partition with a few extra lines in the startup script to check/wait and run a custom script from the SD card -- merged that into the firmware bin, flashed it and got my custom script to execute. Last thing I did tonight was to copy the static binary 'telnetd' from a camera I already had (of similar OS/Chip) and adjusted the script to run telnet in passwordless mode, result:

telnet 10.10.10.7

Trying 10.10.10.7... Connected to 10.10.10.7. Escape character is '^]'.

BusyBox v1.26.2 (2019-11-03 17:33:40 PST) built-in shell (ash)

/ #

So now I can close this up and tinker a bit more (remotely) to see if I can get onvif working and hopefully add the modules to maybe write the videos straight to my NAS (bypassing SD card). I will always need a SD card in this device to run my custom stuff (there's only 100Kb free space on this thing - used for config), but I never liked the idea that someone could rip the device off my door and just take it along with the video evidence of it. At the very least I'll make something to copy the files to my NAS as they are recorded on the SD card.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-731920209 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AEC6WBRDEXLHNLMULPXH3ATSRHQOXANCNFSM4GMY7FQA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-731942313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFZMEGVJ3EBZCVYXXK66F3DSRH2AVANCNFSM4GMY7FQA .

n0ggi3 commented 3 years ago

I would think we could force OTA updates at the very minimum. The next few weeks I am cramming for finals for a few classes but I will see if I can work something out. I know very little of mqtt but from what I understand was designed without security in mind.

jilleb commented 3 years ago

Could this help someone? http://cdn-meari-us-oss-us-west-1.meari.com.cn/firmware/gray/ppstrong-b5-ctv-3.2.1.20200708-upgrade.bin

what device is that from -- it could be helpful for someone with the same hardware cause I know there is a way to upgrade the firmware from SD card and we may be able to 'customize' the bin file before upgrading.

Found a lot of interesting URLs inside this firmware, most of which lead to some kind of output:

/search
/flash/upgrade/release_package
/flash/upgrade/percent
/sys/reboot
/sys/console
/log/open
/log/close
/log/upload
/devices/update
/devices/reboot
/sys/info
/sys/active
/sys/sleep
/flash/encryption
/flash/identity
/flash/upgrade/all
/flash/upgrade/ppstrong
/flash/iperf3
/sys/factory_reset
/dsp
/media/audio
/dsp/debug
/dsp/debug/cmd__ 
/dsp/debug/setstreamfile/

/media/audio/output/volume
/media/audio/input/volume
/devices/wifi 
/devices/default 
/default 

/dsp/debug/infodisplay/

and some possible username/password combinations:

admin 056565099
PpStRoNg #%%&wL1@*tU123zv
WeEyE &$ChuTian_91

guino commented 3 years ago

I've read something about hardware encryption chip from GPIO pins in the datasheet: https://datasheetspdf.com/pdf-file/853432/Hisilicon/Hi3518/1 So I think it's possible to store video encrypted on SD card.

I'm pretty sure they advertised the video recordings to be encrypted but they are not (at least on the SD card) -- they're just the usual H264 camera recordings (non-standard format) which you can convert/play with ffmpeg/mplayer/vlc/etc. But my main concern is not having the videos if someone takes the device/card away.

However, I believe you have (newer?) Anyka chip instead of Hi3518E? Looking at Meari's recent FCC applications from latest months it seems they changed everything from HiSilicon(Huawei) to Anyka chips.

The board on my doorbell boots up with a bootloader labeled anyka_c2, but when the OS loads there are a ton of Hi3516ev200 modules loaded so I'm not really sure and I'd have to bend out some huge capacitors to physically look at the chip, I would be willing to bet it's the anyka chip with some adjusted modules for the kernel (with the same name/devices).

see if I can get onvif working

@guino do you have any ideas for non-Tuya firmware?

If you have just a camera (not a doorbell) I'm sure you could download the hisilicon SDK and write whatever you want using their samples (RTSP server etc), it's just a matter of how much work you want to put into it. I do have another camera (PTZ) which has hi3516ev200 (for sure) and it came with RTSP/ONVIF right out the box, but I customized it to write to my NAS drive directly instead of using SD cards (you can check it on one repos in github). When I saw the same kernel version and similar modules on the doorbell I was hoping I could use the modules from the camera on the doorbell but the OS differences seem to be substantial, so I didn't make a lot of progress on my board today, quickly tried NFS and ONVIF without success -- NFS modules wouldn't load and the ONVIF tools I have required the web-server appliaction used by the camera I copied it from. From looking at the ppsapp code I am positive that no outside application can read the video feed while it's running. I'm sure if I ditch the tuya/ppsapp crap (which requires finding/disabling their watchdog or replicating its function) I could probably use standard hisilicon SDK code to get the video feed but I'm pretty sure I want to go that route. Right now I'm thinking of just downloading a full busybox into the SD card and using that to transfer the video files as they're recorded in the SD card into my NAS drive (probably by FTP or httpd).

I started poking around the ppsapp code with ghidra but again I don't want to spend a whole lot of time on it -- it would be far cheaper (if you consider the time spent on it) to just buy a cheap $40 POE camera with RTSP and put it right beside the doorbell, but it's a challenge, right ?

Suspect-byte commented 3 years ago

My doorbell has the Hi version. I have the bell 5S and the Bullet 2S. I am not a programmer. I have a bit of understanding of command. So if I can help in any case let me know!

guino commented 3 years ago

@Suspect-byte: So I bent the capacitors on my board and looked at the SOC I have on my doorbell and to my surprise it is exactly the same as yours (HI3518ERNCV300):

HI3518ERNCV300

It seems your board has the holes for the capacitors but they're just not populated.

Anyway, I made some progress today... got a full busybox on mmc card and adjusted my custom start script to set my user/password in /etc/passwd, start telnet daemon (password protected now) and the httpd daenon so I can list/download the SD card files from a web browser. Next I did a dump of the ppsapp process memory and was able to find/extract the JPEG of the motion trigger event prepared by the camera (sent to the cloud with an alert) -- this was just a blind search but it may be possible to find a buffer where the camera may storing an image every so often (which would allow using it as a MJPEG server), back burner for now. Next I reviewed the disassembly of ppsapp some more and found the function that initializes the buffers for video capture, found the function that allocates the memory for each channel and where it saves the buffer address (I renamed some things): ghidra ppsapp

With that I dumped the memory location of the buffer address (from running application) then dumped the buffer itself. Using my httpd daemon I was able to playback the last few seconds of video from the camera (though out of order because it's a circular buffer). I was able to play it with VLC and with an iOS app (IP Cam Soft Lie), but did not try anything else at this time (those are the two viewers I will likely be using). So what I am thinking is I can write an application that will do the process above to find the buffer and monitor it for changes to 'sync' with the ppsapp (filling its buffer). Then it can wait for an incoming connection request when the application will start sending/streaming the data at the appropriate frame rate so the remote side can view it. It will probably take a lot of tweaking but it should work (for me). Now to the bad part: I am not sure how easy it would be to 'fully automate' the buffer finding process so it could be used by other applications (i.e non ppsapp and/or different versions of ppsapp for which I don't have the disassembly code), I think the trickiest part is to define the fps and buffer size -- I know I can look at my ppsapp disassembly and find it for my camera but there are different channels and buffers which could make it harder to make it generic. Lastly, there's no 'audio' on this approach. I can't play the audio even on the saved files to the SD card because they're not saved in a 'standard' format and I'm pretty sure the app multiplexes the video+audio when it makes a stream for the tuya based app.

It's progress nonetheless, now I'll have to download/setup the tool chain for armv7l uclib and start coding away.

jilleb commented 3 years ago

Nice, great work!

To which pins are you connecting?

I've got the 8S (according to the API-responses it's sending) , but according to the board it's a 5S

I read there's a new firmware update available for my model (8S), I will try to see if I can MITM to obtain the firmware and disassamble it.

guino commented 3 years ago

Mine is also labeled as "8S" in the software but the board also says 5S and my board has a label 'MEARI' right in thethe middle almost between the springs for the doorbell wire. I'm not sure what 'pins' you're referring to: For UART I use the first 3 pins/wholes on the bottom left of your pic. For flash chip I suppose I use all pins on the chip to the top-left of the SD card slot on your pic. If you're talking video output 'pin' I can read both channels (0 & 1) which are HD and SD respectively. I wouldn't update the firmware to a newer version unless I had a backup of my current firmware/flash to restore -- one of the newer firmware versions I saw didn't seem like they were using linux/busybox anymore -- it seemed like they were just running a combined app direct from the kernel (which would make it more difficult to customize), but I didn't dive a lot into it deep to be certain of it.

miblo69 commented 3 years ago

Has anyone successfully converted the videos stored on the SD Card to mp4/avi or similar? I am able to convert the Video to MP4 - but not the Audio.

The command...

ffmpeg -f h264 -i 0?0000.data -bsf:v h264_mp4toannexb -c copy -an test.mp4

...produces a Video file that's playable on basically any player - but the Audio track is always silent.

The ffmpeg output after the conversion also indicates no Audio: frame=54011 fps=0.0 q=-1.0 Lsize= 275348kB time=00:35:56.86 bitrate=1045.8kbits/s speed=2.33e+03x video:275038kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.112723%

Any tips would be very helpful!

jilleb commented 3 years ago

I wonder if the audio is actually recorded on the video, or that the audio is just a seperate communication channel which isn't saved to the video feed.

I'm not sure what 'pins' you're referring to: For UART I use the first 3 pins/wholes on the bottom left of your pic. For flash chip I suppose I use all pins on the chip to the top-left of the SD card slot on your pic. If you're talking video output 'pin' I can read both channels (0 & 1) which are HD and SD respectively.

Allright, I meant the UART interface. with bottom left, do you mean the red or green section here:

Suspect-byte commented 3 years ago

@guino @jilleb

I saw on my board a separate mic and a video input. I think you are right that you can record only the video and the audio is on other pins

miblo69 commented 3 years ago

I'm assuming that the Audio is in the video file since I can replay older files via the Smart LIfe App with Audio. And there are no other files on the SD Card other than all the .data files and a .index. So presumably there is Audio in the .data file - I just need to figure out how to 'decode' it.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, November 26th, 2020 at 12:06 PM, Chillout notifications@github.com wrote:

I wonder if the audio is actually recorded on the video, or that the audio is just a seperate communication channel which isn't saved to the video feed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

guino commented 3 years ago

Allright, I meant the UART interface. with bottom left, do you mean the red or green section here:

UART is on the pins you marked with the red square -> left to right you have GND, TX, RX and 3.3V (I don't connect 3.3V) and it's all TTL 3.3V, so be warned not to use anything with higher voltage or you might burn it.

guino commented 3 years ago

Regarding Audio -- I know for a fact all cameras that support SD card (that I have seen) save both audio and video to the files (.data/.h264/.h265/.avi formats), but it's saved in a way that is not easily detected by standard tools (VLC/mplayer/ffmpeg, etc). I have seen the camera manufacturers provide some tools that support audio: For .h264 there's a player tool (windows) and file converter tool (windows and linux) For .h265 and .data there's a player tool (windows) and no converter tool For .avi (it's a 'fake' avi format similar to the formats above) there's a player tool (windows) and file converter tool (windows and linux) For most formats you can can play them with VLC/mplayer (no audio) or convert them (ffmpeg) with no audio -- to convert them with audio you can do it with the Android/iOS app (ie CAMHI etc). If you copy the file from the SD card (so it doesn't get deleted) and want to convert it later you can just overwrite one of the existing files on the SD card then download it with the app as mp4 (with audio). In all the above cases my experience is that the audio is often out of sync by a few seconds. But if audio is important you'll have to look for the tools specific to your camera/format -- most of the ones I have seen are called 'Smart Player' or 'Smart Viewer' or 'IPC Manager' or 'Device Manager' or 'H264 Converter' or 'HiPlayer'.

I can see the audio buffers on the memory along with the video buffers, there's a buffer for 8Khz and another for 16Khz (SD/HD), but it would be tricky to put them together for streaming or anything else. I am definitely not planning on spending time coding audio support but doesn't mean it can't be done.

voltprinter commented 3 years ago

Allright, I meant the UART interface. with bottom left, do you mean the red or green section here:

UART is on the pins you marked with the red square -> left to right you have GND, TX, RX and 3.3V (I don't connect 3.3V) and it's all TTL 3.3V, so be warned not to use anything with higher voltage or you might burn it.

I have the same camera-ish as jilleb. I'm prompted for a PW I can't get past. https://github.com/DanTLehman/orion_sc008ha has some writeup on it.

guino commented 3 years ago

I also could not find the boot password for UART access (some cameras/firmware have no password). I briefly looked for it with ghidra but I think it’s saved on an encrypted section of the flash and I didn’t feel like spending the time on that considering that the app partition was easily accessible (with programmer). I did play with that ppsMmcTool.txt (and commented on that github page you mentioned) but the programmer was the quickest access.

voltprinter commented 3 years ago

I can't find it for the life of me. There was another page/post on github which listed a lot of things you can enable with a file on the SD card. I forget what the filename was called, and all of it's parameters, but it was for similar cameras. I remember using it for an older t20 camera, I was able to enable RTSP (other posters on that page were able to enable SSH etc), do you by chance know what I am talking about?

guino commented 3 years ago

I remember trying some INI files on my doorbell camera and other hacks without success. From what I have seen in most recent “tuya” cameras there’s hardly anything that can be done using the SD card.

I have spent a reasonable amount of time on making a streaming application and concluded that it will need a full copy of the cameras circular buffer for it to work well (about 1.2mb for 1080p or 400kb for SD on my camera). Without NFS and without wearing the SD card I have to use RAM which I should have enough but not sure it’s worth the ‘cost’. So I went back to the jpeg option and found the location where the hardware encodes the frames as JPEG realtime. So I whipped up a cgi script for httpd and was able to create a URL which serves a snapshot of the camera view. Then I extended it a little bit and made another script which serves a mjpeg ‘stream’. This works really well (vlc, firefox, ios app, domoticz, etc) and requires virtually no memory as there’s no buffering and it doesn’t use much resources (script only runs when a connection comes in).

I will post everything I did with information soon but I still may work on the streaming application despite the buffering requirements (a challenge right?).

EDIT: write up: https://github.com/guino/BazzDoorbell

jilleb commented 3 years ago

Great progress @guino !!

guino commented 3 years ago

Final progress (from me at least): Got FULL HD RTSP stream working on my doorbell camera. The ppsapp has tbuilt-in support for this feature and it was just disabled (hard coded) by default so I changed 1 byte in the file and now it runs with RTSP in 1080P with audio. I suppose anyone that has a tuya camera with ppsapp similar enough can just use my posted 'rtsp' version and stream away. See final update/details/notes/files on the project page: https://github.com/guino/BazzDoorbell

Suspect-byte commented 3 years ago

@guino You dude, you are a absolute legend!! Thank you so much for this!

LuCiLuna commented 3 years ago

How do we flash to our devices? I have 4 1080p (Walmart Geeni) cams using the Tuya cloud stuff, I would love an rtsp stream to integrate with Agent

On Wed, Dec 2, 2020 at 5:29 PM Suspect-byte notifications@github.com wrote:

@guino https://github.com/guino You dude, you are a absolute legend!! Thank you so much for this!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-737558197, or unsubscribe https://github.com/notifications/unsubscribe-auth/APGGPIIWYKR5RGLGEYYHTULSS3EWTANCNFSM4GMY7FQA .

Jordan-Jarvis commented 3 years ago

@guino I have been lurking this thread occasionally but have not been able to give much time lately due to many life circumstances. I started seeing a lot of activity in my email notifications so I decided to check back in. I can follow the process you used for extracting the partitions and I think I follow what you did to re-create the partition after modifications. The part where I get confused is how you found the bit to flip to enable the RTSP in the ppsapp. Did you just use a hex editor? If so, how did you find the right bit to flip using Ghidra? does Ghidra have the ability to tell you where in the executable the code you are looking at is located? I have only used Ghidra a handful of times. The reason I ask is because I feel like avoiding cross camera versions of the ppsapp if I can avoid it to increase the compatibility. My camera is the Wal-Mart special merkury 720p camera. Also, we did find that in some of the cameras there is a way to upload firmware over the network so it would not require having a programmer to make the change if the firmware is deemed stable. I also would imagine that automatic updates would have to be broken or redirected in some way to make sure the changes stay. Good job with all of the stuff you did!

guino commented 3 years ago

How do we flash to our devices? I have 4 1080p (Walmart Geeni) cams using the Tuya cloud stuff, I would love an rtsp stream to integrate with Agent

There’s no way I could find to do it without opening the device and reading/modifying the built-in flash. If your device has the SD card slot you can probably make all changes as I posted in my write up. If there’s no SD card slot you would have to replace the ppsapp in the flash and write it back (assuming it is similar enough it should work with the one I provided). You can always restore the original data in the flash if it doesn’t work we would have to make the change to tour version of ppsapp. Now that I am a little familiar with it I could probably make the change fairly quickly if you provide me a dump of your flash (using a programmer).

LuCiLuna commented 3 years ago

I’ll have to obtain a programmer and get back to you.

On Wed, Dec 2, 2020 at 8:31 PM Wagner notifications@github.com wrote:

How do we flash to our devices? I have 4 1080p (Walmart Geeni) cams using the Tuya cloud stuff, I would love an rtsp stream to integrate with Agent

There’s no way I could find to do it without opening the device and reading/modifying the built-in flash. If your device has the SD card slot you can probably make all changes as I posted in my write up. If there’s no SD card slot you would have to replace the ppsapp in the flash and write it back (assuming it is similar enough it should work with the one I provided). You can always restore the original data in the flash if it doesn’t work we would have to make the change to tour version of ppsapp. Now that I am a little familiar with it I could probably make the change fairly quickly if you provide me a dump of your flash (using a programmer).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-737621822, or unsubscribe https://github.com/notifications/unsubscribe-auth/APGGPIJS6WJMBQUQU3LEHQLSS3Z6XANCNFSM4GMY7FQA .

guino commented 3 years ago

@Jordan-Jarvis to find what to change in ppsapp you need to load it in ghidra, analyze the code, find any references to anything related to rtsp/echo show and basically follow the code back to where it is initialized. On my version of firmware (2.9.2) it was initialized from the main/startup sub of the app. Once I found where it decided if it should start the RTSP server or not I just edited the instruction (arm assembly), found the bytes from the code in the file, modified what I needed with a hex editor (1 byte) and copied it to my SD card to run from my script after I killed the one from the original flash. It does take knowing a little bit of arm assembly code to make the change unless you track down the setting it reads (which should not be too bad either since it’s hard coded value). I can look at the ppsapp from your bin file if you like, just let me know.

In my app (tuya), there’s a setting to disable automatic updates so I am not worried about it (plus I can flash a backup if anything or just do the same on the new version).

LuCiLuna commented 3 years ago

How could I run the firmware from sd? Would this save me having to get a programmer?

On Wed, Dec 2, 2020 at 8:45 PM Wagner notifications@github.com wrote:

@Jordan-Jarvis https://github.com/Jordan-Jarvis to find what to change in ppsapp you need to load it in ghidra, analyze the code, find any references to anything related to rtsp/echo show and basically follow the code back to where it is initialized. On my version of firmware (2.9.2) it was initialized from the main/startup sub of the app. Once I found where it decided if it should start the RTSP server or not I just edited the instruction (arm assembly), found the bytes from the code in the file, modified what I needed with a hex editor (1 byte) and copied it to my SD card to run from my script after I killed the one from the original flash. It does take knowing a little bit of arm assembly code to make the change unless you track down the setting it reads (which should not be too bad either since it’s hard coded value). I can look at the ppsapp from your bin file if you like, just let me know.

In my app (tuya), there’s a setting to disable automatic updates so I am not worried about it (plus I can flash a backup if anything or just do the same on the new version).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-737627044, or unsubscribe https://github.com/notifications/unsubscribe-auth/APGGPIO3MQN4YZXY6TE6AITSS33VTANCNFSM4GMY7FQA .

guino commented 3 years ago

How could I run the firmware from sd? Would this save me having to get a programmer? …

I could not find a way without a programmer (for my hardware/firmware) - the programmer is $15 but you may want to review my write up as it involves opening the device and likely will require disconnecting a pin (with soldering iron) so you can read/write the flash. And you would have to repeat it for every camera, so if you’re not comfortable with that I would not recommend it.

Suspect-byte commented 3 years ago

@guino I got a question. I have little knowledge of ARM etc. Can I just use your ppstrong file and upload it with this command /flash/upgrade/ppstrong. Or what you told above here that you just should hard code it? Which software are you using to do that? Do have a step by step guide how to do this? Anyway thanks for everything what you have done! I am really grateful for all the work you putted in!

guino commented 3 years ago

@guino I got a question. I have little knowledge of ARM etc. Can I just use your ppstrong file and upload it with this command /flash/upgrade/ppstrong. Or what you told above here that you just should hard code it? Which software are you using to do that? Do have a step by step guide how to do this? Anyway thanks for everything what you have done! I am really grateful for all the work you putted in!

To anyone thinking about doing this you should keep in mind you will need: -programmer -soldering iron -multimeter/tester -linux machine/VM with required tools (unless you have everything in windows which I don’t know if it’s available). -you need to be comfortable with lifting/soldering chip pins. The programmer may need to be modified to work with 3.3V (lift a pin and solder 2 wires) and you may have to lift a pin on the flash chip to read/write it then solder it back in place.

Now @Suspect-byte to answer your questions: if you patch your start script (flash) you can just copy custom.sh and my rtsp enabled ppsapp to the SD card and use it - if they’re not too different I would expect it to work fine. Otherwise you can remove the files and just continue using what you have OR you can send me your firmware so I can patch your version of ppsapp. I am using just linux tools (flashrom, binwalk, cramfs, etc), I don’t know what’s available in Windows besides the flash tool itself. I thought my write up was a “step by step” but if you need more details feel free to ask.

I am not discouraging anyone from doing it — just being up front with the requirements. I’d hate to hear someone bricked their device because they used a 5v programmer or busted a chip pin while lifting/soldering it.

jilleb commented 3 years ago

@guino, I could look into the UART connections and gaining solder free access through that way. And my device has a USB port..I haven't yet looked into that.

solidssss commented 3 years ago

Wow, great progress! I'll try to follow this guide on my tuya wifi camera. Thanks for making this work locally.

It would be great if you could write the steps more clearer for noobs like me lol

guino commented 3 years ago

@solidssss The only way I can see any success without opening the device is to use the ppsMmcTool.txt file from the SD card. That file gets loaded/executed when you boot pressing the reset button and it seems to be just raw code being executed (wasn't a uboot script as far as I tried it). It may be possible to load a custom u-boot from the SD card that way which would provide options: 1-load the kernel from SPI-flash with a parameter to run the start script and ppsapp also from SD card (I know for a fact that parameter exists) OR 2-Read the SPI flash saving it to SD card, then modify it and write the SPI flash (like I did with the programmer).

It would probably take a lot of time to figure out all the details to make this work but I would would go something like this: -Download compatible u-boot sources to the hiSilicon chips (hi3518 is the one I have) -Modify the uboot code to force-load from SD card -Prepare SD card with uboot code in it (before data partition starts) -Build ppsMmcTool.txt using mkimage like I did here: https://github.com/DanTLehman/orion_sc008ha/issues/1 with code that would load the uboot from SD card -- it is possible that the first 4096 bytes of the uboot may do the trick, if not code would have to be written for this purpose -Once/If you get uboot to load (which would be a monumental progress figuring out all addresses/format of file/etc), then we would have options forward: 1-you could load the kernel from flash with the boot parameter ppsAppParts=0 to load the scripts+ppsapp from SD card (the default is ppsAppParts=5 which loads the app from the flash memory) OR 2-You could use uboot to possibly read the SPI flash and save it to the SD card, then modify and write it without a programmer (to apply similar changes like I did with the programmer).

I don't have a lot of spare time to play with the ppsMmcTool.txt route (and the programmer route is way faster). If there was enough people interested in this (I would think millions of users) could be worth spending the time on it.

There's always the possibility of looking into the boot loader of the flash (as pointed out by @jilleb to figure out the password and hopefully get into uboot that way (which would probably provide the same options as the ppsMmcTool.txt route).

The USB port as far as I could tell only provided power to the device (there was no USB connection of any kind when I connected to the computer).

jilleb commented 3 years ago

Good points. In my device manual, it states that the micro usb is only for use by the factory. Maybe it's not actually meant for usb, but to be used as a hardware key of some sort. Wouldn't be too weird.

LouDnl commented 3 years ago

@guino I managed to find the complete hi3815ev300 sdk and might have some pointers there. Only took me a day to download 🤭 What should I look for?

itkfilelor commented 3 years ago

Good points. In my device manual, it states that the micro usb is only for use by the factory. Maybe it's not actually meant for usb, but to be used as a hardware key of some sort. Wouldn't be too weird.

Try cutting a micro USB open and crossing the white and green. They may have reversed the data pins to obfuscate. And old otg adapter may even do the trick

LordVlkodlak commented 3 years ago

Man! This is like standing at the finish line, just starting at it. Of all the cameras I could have purchased, this is the one I got, and all I wanted was a live stream.

grodlor commented 3 years ago

I noticed that tuya-flash auto-saves the camera firmware in the backup folder as .bin.Tuya-flash can also write to a new firmware file to the device. Can this .bin file be modified to use the camera locally? edit:Sorry, I had a tuya siren also in "search mode" and I thought that tuya-convert took the camera, but it took the siren...my bad

jilleb commented 3 years ago

I would assume the firmware is signed. but it's worth trying.

LouDnl commented 3 years ago

I noticed that tuya-flash auto-saves the camera firmware in the backup folder as .bin.Tuya-flash can also write to a new firmware file to the device. Can this .bin file be modified to use the camera locally?

Mind sharing the bin file?

AMoo-Miki / homebridge-tuya-lan

Security Cameras? #4

telnet 10.10.10.7

telnet 10.10.10.7

ffmpeg -f h264 -i 0?0000.data -bsf:v h264_mp4toannexb -c copy -an test.mp4