Tons of models, I wonder if there could be a breakthrough between them

[SirLouen]

I've seen that most of the projects revolve around Tuya ecosystem

I've downlaoded Tuya app to discover that the interface is almost the same as many others and the pairing system the same, like Smart Life, or CloudEdge to mention some

I currently have a cam ZS-GX1S which more or less follows the same principles I read (including most of the endponts, port 8090, for latest Tuya firmwares, etc...)

But I'm not able to extract with the files you provided in the MMC the ppsapp file (because, it seems to be a relatetively different model).

I would like to reverse engineer my ZS-GX1S to see if I can get to a similar end like you, but not sure how could you get all those files in MMC which provided the way to get that ppsapp file which helped to introduce the root in the system, and from there enable all the services like RTSP.

I hope you can give me some light, so I can continue in my research to unlock my cam which seems a clone of yours with only some extra features.

[guino]

@SirLouen if you tried the the methods/files from 720p, BazzDoorBell and 1080p (3 different repositories) then chances are you have a device with different boot loader address and the only way to find the address is to connect to the serial port or download the flash with a hardware programmer - both require opening the device and require having the hardware/knowledge to do it. There’s also a chance the device doesn’t run linux and even with the hardware you won’t be able to root it — if you post the reply to /proc/cmdline it may be a clue if it’s linux or not. There’s also a post in the wiki of bazz doorbell with lots of URLs that could give information to check if it’s linux or not, specially this one: http://admin:056565099@ip/proc/self/root/etc/init.d/S90PPStrong

[SirLouen]

if you post the reply to /proc/cmdline

I think this is the main problem in my progress: that url doesn't give any result.

Although many other commands do:

{
  "device": {
    "name": "Smart Home Snap",
    "longname": "Smart Home Snap",
    "model": "Snap B24S",
    "serialno": "",
    "tp": "",
    "hardware_version": "",
    "software_version": "1.4.0",
    "firmware_version": "ppstrong-b6-neutral_ntd-1.4.0.20211102",
    "mcu_version": "neutral-2.3.1.20211028"
  },

Firmware is not tuya but b6 based (not sure what is b6 though)

There are plenty of similar endpoints in between: https://github.com/SirLouen/zs-gx1s#other-endpoints

But particularly the proc/cmdline doesn't work :(

Did you find all that info by downloading flash through serial port? Do you know any guides to work on this?

[guino]

@SirLouen the lack of response for /proc/cmdline is usually an indication for non-linux firmware.

I tried everything to get root and had to use a hardware programmer in the end — details of my process are posted here: https://github.com/guino/BazzDoorbell

The only reason there’s a way to root similar devices without using as serial port or hardware programmer is because of the information I got from my device (after I extracted the firmware and reviewed it in more detail).

You can definitely extract your firmware and see what you got — that is the best way to confirm if you have a linux based firmware.

[SirLouen]

@guino I still have some kind of hope. I have opened the cam and I can spot almost the same two chips you mentioned in the Bazz DoorBell at least the SOC is the same and the flash is almost identical.

https://github.com/SirLouen/zs-gx1s#electronics-opening-the-camera

So, my faith is still up. Now trying to identify the UART pins location in that motherboard. Maybe I could follow the same steps to pick up the firmware.

[SirLouen]

I feel they could be these:

[guino]

@SirLouen could be the one you marked or the one at the bottom (probably more likely):

[SirLouen]

Problem: I'm not too savvy on electronic affairs :( But still willing to try.

I feel I could follow your same procedure with the pin 6 of XMC flash and go straight to pick up the firmware which is the important thing here.

Where are you sticking the second clip?

[SirLouen]

Anyway, I've been thinking that you could be running your scripts, because you found the /proc/ executable mechanism, straight from the beginning, right?

So despite I could find the firmware file I could not do much with it...

[guino]

@SirLouen The clip end you marked with "????" is not touching anything -- I was simply pointing out the pin that I had to disconnect to read the flash (the one you marked with the arrow). Some people have reported being able to read the flash without making changes (depends on the board) and other people have reported having to remove the whole chip to read the flash.

You have to be careful about the hardware programmer you use cause some report support for 3.3V and actually output 5V to some pins and could damage the chip or board. If you have a heat gun the best/easiest approach is to remove the chip. I don't recommend using a standard soldering iron to mess with the chip/pin because the board is very fragile and you need a lot of experience to avoid damaging the board -- it would be easier to cut the pin and solder it back later than to lift the pin without damaging the board. Obviously it's your call but you've been warned.

After exhausting options without making changes the way I got access was: -disconnect the flash chip pin -read firmware (hardware programmer) -review script files -modified script to run script from SD card during boot of the device -created a modified firmware -flashed modified firmware (hardware programmer) -connect flash chip pin back -created script on SD card to start telnet on the device <- at this point the device is rooted

Only after the above I was able to get a copy of ppsapp and review/modify it to enable RTSP, and build other scripts for other features (and later build the rooting processes I have posted).

[SirLouen]

it would be easier to cut the pin and solder it back

• How can you cut the CLK pin?

• Which were your schematics from the cam board to your hardware programmer? I see you used a CH341A USB programmer. I will try to see some YT videos to understand how to manage to make it working.

[guino]

@SirLouen I have cut pins on chips before and soldered back using electronics needle cutting pliers — whatever your plan is I highly recommend practicing on some old/junk board first.

The programmer is usually as simple as connecting pin 1 of the chip to pin 1 on the header. The one I got had to be modded cause it was giving out 5v on signal pins. There’s different software available (windows/linux/mac). Reading and writing firmware is usually the simple part.

[SirLouen]

Ok I think I have the firmware, which was the processor you used for GHidra?

[guino]

@SirLouen did you run it thru binwalk? It should be enough to know if it’s linux. The processor should be armv7 32 little.

[SirLouen]

This is what I've found:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
2036141       0x1F11AD        Certificate in DER format (x509 v3), header length: 4, sequence length: 1284
3327273       0x32C529        Certificate in DER format (x509 v3), header length: 4, sequence length: 5380
4353761       0x426EE1        Certificate in DER format (x509 v3), header length: 4, sequence length: 13692
4768532       0x48C314        Unix path: /home/sound/restart.wav
4768656       0x48C390        Unix path: /home/sound/dingdong.wav
4769712       0x48C7B0        Unix path: /home/sound/warning.wav
4769952       0x48C8A0        Unix path: /home/cfg/mp_config.db
4774112       0x48D8E0        Base64 standard index table
4785188       0x490424        Unix path: /home/sound/login.wav
4799759       0x493D0F        HTML document header
4800439       0x493FB7        HTML document footer
4801263       0x4942EF        HTML document header
4801296       0x494310        HTML document footer
4801659       0x49447B        HTML document header
4801783       0x4944F7        HTML document footer
4805567       0x4953BF        HTML document header
4805608       0x4953E8        HTML document footer
4805743       0x49546F        HTML document header
4805927       0x495527        HTML document footer
4816136       0x497D08        Unix path: /home/cfg/idcard.bin
4824596       0x499E14        XML document, version: "1.0"
4852372       0x4A0A94        PEM RSA private key
4852588       0x4A0B6C        SHA256 hash constants, little endian
4863144       0x4A34A8        PEM certificate
4901308       0x4AC9BC        Unix path: /usr/local/etc/zoneinfo
5107487       0x4DEF1F        Neighborly text, "Neighbor Cache Entries ||s %-10s"
5107516       0x4DEF3C        Neighborly text, "Neighbor"
5117392       0x4E15D0        Unix path: /home/hcq/share/code/meari/liteos_v5.0.1.3/platform/bsp/board/hi3518ev300/include/hisoc/i2c.h
5139976       0x4E6E08        SHA256 hash constants, little endian
5141848       0x4E7558        Unix path: /home/hcq/share/code/meari/liteos_v5.0.1.3/platform/bsp/board/hi3518ev300/include/hisoc/spi.h
5142648       0x4E7878        Unix path: /home/hcq/share/code/meari/liteos_v5.0.1.3/platform/bsp/board/hi3518ev300/include/hisoc/uart.h
5154276       0x4EA5E4        eCos RTOS string reference: "ECOST  CPUUSE   CPUUSE10s   CPUUSE1s   mode"
5301888       0x50E680        Unix path: /home/cfg/random_para.txt
5390412       0x52404C        CRC32 polynomial table, little endian
5413428       0x529A34        Unix path: /home/pub/himpp_git_hi3516ev200/himpp/board/mpp/./../mpp/cbb/audio/mpi/src/hi_mpi_ai.c
5418988       0x52AFEC        Unix path: /home/pub/himpp_git_hi3516ev200/himpp/board/mpp/./../mpp/cbb/audio/mpi/src/hi_mpi_ao.c
5714584       0x573298        Unix path: /home/pub/himpp_git_hi3516ev200/himpp/board/mpp/./../mpp/cbb/audio/mpi/src/hi_mpi_adec.c
5736120       0x5786B8        CRC32 polynomial table, little endian
5797458       0x587652        TIFF image data, big-endian, offset of first image directory: 8
5798916       0x587C04        TIFF image data, big-endian, offset of first image directory: 8
5824344       0x58DF58        CRC32 polynomial table, little endian
5863312       0x597790        Unix path: /home/nie/pro/v103/trunk/libAACenc/src/aacenc_lib.cpp
5866328       0x598358        Unix path: /home/nie/pro/v103/trunk/libMpegTPEnc/src/tpenc_lib.cpp
5866453       0x5983D5        Copyright string: "copyright law and international treaties."
5877116       0x59AD7C        Unix path: /home/nie/pro/v103/trunk/libFDK/include/fixpoint_math.h
5877880       0x59B078        Unix path: /home/nie/pro/v103/trunk/libAACenc/src/quantize.cpp
5880820       0x59BBF4        Unix path: /home/nie/pro/v103/trunk/libAACenc/src/transform.cpp
5892800       0x59EAC0        Unix path: /home/nie/pro/v103/trunk/libFDK/src/FDK_tools_rom.cpp
5905856       0x5A1DC0        Unix path: /sys/class/pwm/pwmchip0/
5906064       0x5A1E90        Unix path: /sys/class/pwm/pwmchip0/export
5906928       0x5A21F0        Unix path: /home/hcq/share/code/meari/meari_sdk/src/mp_ipc_api.c
5907348       0x5A2394        Unix path: /home/hcq/share/code/meari/meari_sdk/src/mp_ipc_msg.c
5907728       0x5A2510        Unix path: /home/hcq/share/code/meari/meari_sdk/src/mp_sub_device.c
5907896       0x5A25B8        Unix path: /home/hcq/share/code/meari/meari_sdk/src/mp_srv_info_manager.c
5907984       0x5A2610        Unix path: /home/hcq/share/code/meari/meari_sdk/net/pps_firmware_download.c
5909188       0x5A2AC4        Unix path: /home/hcq/share/code/meari/meari_sdk/components/common/mp_device_manager.c
5909308       0x5A2B3C        Unix path: /home/hcq/share/code/meari/meari_sdk/components/common/mp_stream_buf.c
5909520       0x5A2C10        Unix path: /home/hcq/share/code/meari/meari_sdk/components/common/mp_kv.c
5909768       0x5A2D08        Unix path: /home/hcq/share/code/meari/meari_sdk/components/iot_hub/mp_iot/mp_iot.c
5910600       0x5A3048        Unix path: /home/hcq/share/code/meari/meari_sdk/components/iot_hub/mp_iot/mp_iot_device_manager.c
5910724       0x5A30C4        Unix path: /home/hcq/share/code/meari/meari_sdk/components/iot_hub/mp_iot/mp_iot_message.c5911208       0x5A32A8        Unix path: /home/hcq/share/code/meari/meari_sdk/components/mp_ipc_client/mp_client_login.c5911768       0x5A34D8        Unix path: /home/hcq/share/code/meari/meari_sdk/components/mp_ipc_client/mp_client_http_info_exch.c
5915524       0x5A4384        Unix path: /home/hcq/share/code/meari/meari_sdk/components/mp_ipc_client/mp_client_event.c5917056       0x5A4980        Unix path: /home/hcq/share/code/meari/meari_sdk/components/mp_ipc_client/pps_aliyun_oss.c
5917600       0x5A4BA0        Unix path: /home/hcq/share/code/meari/meari_sdk/components/mp_ipc_client/mp_cloud_storage.c
5918112       0x5A4DA0        Unix path: /home/hcq/share/code/meari/meari_sdk/components/p2p/mp_p2p_client.c
5919796       0x5A5434        Unix path: /home/hcq/share/code/meari/meari_sdk/components/p2p/mp_p2p_cmd_process.c
5920452       0x5A56C4        Unix path: /home/hcq/share/code/meari/meari_sdk/components/p2p/mp_p2p_stream.c
5921424       0x5A5A90        Unix path: /home/hcq/share/code/meari/meari_sdk/components/p2p/ppcs.c
5922776       0x5A5FD8        Base64 standard index table
5924508       0x5A669C        Unix path: /home/hcq/share/code/meari/meari_sdk/components/mp_ipc_client/pps_aliyun_oss_stream.c
5925828       0x5A6BC4        SHA256 hash constants, little endian
5927024       0x5A7070        Unix path: /home/hcq/share/code/meari/meari_sdk/components/iot_hub/wrappers/HAL_linux/HAL_TLS_mbedtls.c
5932464       0x5A85B0        CRC32 polynomial table, little endian
5936560       0x5A95B0        CRC32 polynomial table, big endian
5943960       0x5AB298        CRC32 polynomial table, little endian

It's kind of weird that the MECO J5 doorbell also used CloudEdge app like my cam, and the firmware version he was using is almost thje same, but still I cannot access /proc things through my camera :(

I've uploaded the firmware image to my repository.

Also I've read that there was a little "hack" that if you inserted the sdcard, way before it loaded services for Cloud services were app + 8090 port was open. Maybe that could changes things a bit.

Tomorrow I will try to move it forward.

[guino]

@SirLouen that doesn’t look like that is standard linux as I don’t see it listing a kernel for the firmware. You may be able to find some setting or code to change and enable rtsp but it won’t be anything we have posted before.

[SirLouen]

From what I see there is another OS used for the same chipset we have in our cams (HI3518), called LiteOS https://gitee.com/LiteOS/LiteOS

So we are talking about a Unix based system as we clearly can say in the paths but I cannot confirm how it goes in terms of kernel

It seems that Tuya has also launched some LiteOS in the latest models, probably the ones you used, were older ones. https://github.com/tuya/tuya-iotos-embeded-sdk-multimedia

It seems that many of these chinese white label brands are moving towards LiteOS nowadays. I'll try to investigate a bit.

Maybe I can find something around here: /home/hcq/share/code/meari/meari_sdk/components/p2p/mp_p2p_stream.c

[SirLouen]

I've seen that you mentioned it before

So here is a dead end for this cam :(

I'll have to connect to the UART since I've seen that some people are able to run commands straight on that bootloader, but have not seen anyone achieving anything interesting so far :(

Let's see where this takes.

[guino]

@SirLouen I have seen at least one 5.x firmware running linux, but most 5.x firmware are RTOS/LiteOS and we haven't been able to make any changes to that. It is not 'impossible' -- if the code is there someone with enough time could potentially patch it to enable any feature not enabled by default. It would take a lot more effort than on the linux versions, would require hardware programmer and would be limited to whatever is already in the code. If it's just a camera (not doorbell) and the chip is compatible you could try OpenIPC firmware which supports some tuya devices for sure.

I unfortunately don't have the time to dig thru all the above , God knows I would love to just reverse engineer hardware+software as a job, but since that's not the case: it would be far cheaper/quicker/easier to just get cheap camera from china with everything I need out of the box, but some people do it as a challenge and have enough time & resources to play with it.

[SirLouen]

Interesting that OpenIPC I've never heard about But the documentation of that project is completely absent + all Telegram groups are 100% Russian. A very difficult access barrier :)

But they seem they are just starting (around 1 yr project). Let's see how it evolves.

[guino]

@SirLouen not sure where you're seeing stuff in Russian -- I see they have some docs in that but I never once was presented russian option without requesting it.. the firmware for your device should be this one: https://github.com/OpenIPC/firmware/releases/download/latest/openipc.hi3518ev300-br.tgz the documentation I'm seeing is this one: https://github.com/OpenIPC/wiki/blob/master/en/index.md which I got from this project: https://github.com/OpenIPC/firmware/blob/master/docs/index.md

[SirLouen]

I've talked with them, and this is a super challenge...

Basically, first I should be flashing that firmware, and soldering (and finding) if there is a USB connection for the cam (other than the battery charging one, one for data). That would be super-complex because my knowledge on SoC and boards is basically 0.

Maybe I would take it as a crash course in the future but it will require researching too much for what I can take right now. Wifi Chip will be completely disabled (because it's unlikely i could find the driver for that Open IPC kernel) and they assume I should do a DIY in the case opening to put the Wifi USB antenna that will give the connection feature to the cam.

Conclusion: the amount of work I should be doing is way beyond my capabilities. As you said, it will be 10 times cheaper to buy a perfect battery cam just ready to go to were I'm thinking to set this one. The only problem is that I need to use this cam for the following 3 months but I don't want it as a permanent solution as it is. So doing the holes in the wall to mount it and having to switch it in the near future is going to be a pain in the ass, so this is why I was willing to hack it and find something that let me keep it for at least 2 or 3 years.

The only option here, is to find a way to open RTSP straight on liteOs but seems unlikely Found this question in Stack which seems the same type of cam as mine:

https://reverseengineering.stackexchange.com/questions/25938/need-help-opening-a-img-file-from-a-camera-firmware-trying-to-get-out-of-the-m

[guino]

@SirLouen I thought you could flash the firmware with the programmer (like you used to read it), but without support for your wifi chip it is basically useless. Some cameras are just more trouble than they're worth. I have an ezviz camera/doorbell running RTOS and luckily there was a firmware version for it that has onvif+rtsp so that's what I flashed and how I use it -- so if you could find firmware for camera with similar enough hardware and rtsp function that could work but there's an ocean of hardware and firmware out there so again not worth the cost of the camera.

[SirLouen]

I've contacted all the white labels sites to see if someone could provide me such firmware but no luck

Lucky enough, today @jonwedell has replayed in another issue in the @youribonnaffe repo and found me a good alternative

https://github.com/youribonnaffe/iegeek-security-camera/issues/1

Basically there is a LowFi snapshot URL that works on my cam (/devices/snapshot/)

I'm starting to think that the cam operates this way (with snapshots), because I've set the Home Assistant internal Cam integration to 10 FPS and I can see the pseudo-stream at the same pace as the original CloudEdge app. Also considering how the UDP port works and how low-consumption they are, I seriously doubt this type of cams use any perma-stream by anymeans.

Maybe I'm wrong, but when they constantly say in their sites: "Be aware this cams are not ONVIF/RTSP compatible, I'm starting to think they are true: just take this JPG generation and they are happy to go).