guino / BazzDoorbell

128 stars 22 forks source link

Chacon FI02 #24

Open SamThing opened 3 years ago

SamThing commented 3 years ago

Hi. I recently bought this camera https://chacon.com/pt/camaras-ip/1238-camara-ip-wi-fi-interior-mini-1080p-5411478345268.html. Which is basically a smartlife(tuya) camera running firmware 2.9.5 Port 80 is open but when i try to http i get prompt to login with username and password which i was not able to find. I was able to gain access with #13 Now I have telnet and the hack file is done.

But I'm still getting prompted to login with username and password. (already tried all possible combinations, the serial number and etc) Also, snap and mjpeg don't work (tiny blank square image)

Some informations about the cam (I was able to get them running /tmp/PPStart ): name: Smart Home Camera factory: PPSTRONG device_type: 74 model: Mini 8S hardware_version: M8S_H1_V10_F23 software_version: 2.9.5 firmware_version: ppstrong-c51-s_chacon-2.9.5.20200205 sn: 059554188

I got UART to work (readonly it seems) and the hardware aspects are very similar to this one https://github.com/guino/BazzDoorbell/issues/2#issuecomment-774789777

Great work you've done! Thanks for your time and effort!

guino commented 3 years ago

I also see some references in the code to /etc/passwd which may indicate it's actually using that user/password list to allow/deny service to the device. I would check/set the contents cf /etc/passwd and try a user/password combination from there to see if it works (i.e. your user+password from telnet).

I also see some indications that it may have a RTSP server on port 554 (separate from 8554) so you may want to try to check if 554 is open with telnet IP 554 and if it's open try rtsp on that as well.

Finally I made another change to try and bypass password check on Digest (if the above doesn't work) -- I doubt it will allow 'everything' to work but I expect at least some stuff to work with Digest: --deleted--

SamThing commented 3 years ago

Hi

the 554 port is closed for TCP and UDP (even using the video feed on the android app) The patch works! Now I can use any user/pass on both basic auth and digest. But still no luck on rtsp

guino commented 3 years ago

@SamThing When you have a chance: can you try to make another log with the original ppsapp just trying to access rtsp on the camera from VLC to see if we can get any useful information? I understand the camera may crash but maybe tou can execute/mnt/mmc01/busybox sync right after trying to start rtsp so it records data to the SD card before it crashes/reboots - this could be very useful in defining where the change needs to be done.

I assume you tried using a user/password combination that works with telnet (from /etc/passwd) with no success. I also wanted to double check as there have been reports of VLC for mac having issues with RTSP from these cameras - you may want to try with something else like ffplay/ffmpeg or some phone app too.

The only other thing I think you could try is some onvif tool to see what it shows - this device may have basic onvif on port 80 (which should provide information on rtsp feeds available).

SamThing commented 3 years ago

Hi

fyi: I just updated the busybox with a newer version that has vi, wget and curl to make the things easier

This log file contains the log when trying to get the rtsp feed using vlc on a linux machine using the original ppsapp:

vlc --rtsp-tcp rtsp://admin:banana@192.168.1.226:8554

VLC media player 3.0.9.2 Vetinari (revision 3.0.9.2-0-gd4c1aefe4d)
[0000556212055be0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Created new TCP socket 19 for connection
Created new TCP socket 19 for connection
[00007fc230001170] live555 demux error: Failed to connect with rtsp://192.168.1.226:8554
[00007fc230004ad0] main stream error: connection failed: Connection refused
[00007fc230004ad0] satip stream error: Failed to connect to RTSP server 192.168.1.226:8554
[00007fc230004ad0] main stream error: connection failed: Connection refused
[00007fc230004ad0] access_realrtsp stream error: cannot connect to 192.168.1.226:8554
QObject::~QObject: Timers cannot be stopped from another thread

Also, tried to use some android apps that get the onvif configuration automatically, but no luck here, since all of them try to reach this invalid /onvif/device_service endpoint --deleted--

SamThing commented 3 years ago

As you can see, there's nothing on the log, the app just stoped. Please note that the file was appended, so start reading backwards 😄

guino commented 3 years ago

@SamThing I'm probably going to have to try making a few different changes for you to try when you have a chance.

guino commented 3 years ago

@SamThing Sorry I had a long day at work. Here are 2 ppsapp mods for you to try:

--deleted-- This one should try to open RTSP on port 8555 (not 8554) and should accept any password for RTSP.

--deleted-- This one is the same as above but using port 8554. I have a feeling that the port 8554 is being for some specific function for the app support and preventing the 'normal' (non-app) RTSP from being available on port 8554 so that's I made the change on the port on the first test above.

Please run the 1st one and do nmap to see if port 8555 opens -- then try to view the video with the app (to see if it still works or not), then try VLC (tcp/udp) using rtsp://admin:password@IP:8555/Streaming/Channels/101 to see if you get anything.

Regardless of it working or not, you can try the 2nd one using port 8554 (including app/VLC) using rtsp://admin:password@IP:8554/Streaming/Channels/101 -- I am expecting that any password other than 'admin' should work but let me know.

SamThing commented 3 years ago

Hi, good morning And thanks for keeping working on it!

Testing the first file shows that the port 8555 is indeed open, but using it causes the camera to reboot, same as the default behaviour of 8554. Just to nmap that port causes that. RTSP don't work either.

The second file behaves the same but on port 8554. 😢

guino commented 3 years ago

@SamThing does the app work (to view video) with the test1 file? I assume it doesn’t based on your response but want to be sure.

SamThing commented 3 years ago

no, don't work at all and causes the camera to reboot as it does on the original ppsapp file on port 8554 😢

guino commented 3 years ago

When I asked about the “app” I meant the original app that came with the camera - does that work with test1 or test2 above?

SamThing commented 3 years ago

Oh, yes both worked fine with the android app 😄

guino commented 3 years ago

@SamThing that's interesting -- that means that the android app isn't using port 8554 (it's probably using some other method). It is possible that this other method is preventing the RTSP server from working -- I'll do some digging in the code.

guino commented 3 years ago

@SamThing Can you try this one: --deleted--

This one should still be on port 8554 for RTSP but it will not start the app_server support -- it will stay in a 'factory mode holding' state without actually going into 'factory mode'. But I wanted to see if the app server code is interfering with the RTSP support code in any way. If this still reboots the device when you try to use RTSP on port 8554 then the app server is not the issue. Obviously the original app for the camera will not work with this version.

SamThing commented 3 years ago

hi @guino

About the 8554 port behaviour, no change. Even a simple nmap -p8554 is still enough to restart the camera.

In case if you doubt that is the right version running:

ps |grep pp
  925 root      0:00 ./ppsdsry
  953 root      0:04 /mnt/mmc01/ppsapp-test3
 1059 root      0:00 grep pp

The android app indeed didn't work. Even the funcions not related with the video feed like gathering camera's information. The rest of camera's built-in functions are working fine, like the http server with random user/pass

guino commented 3 years ago

@SamThing Just a wild guess from looking at the code -- it seems their server may not care which port you connect to and uses the request headers to determine how to process the request -- can you try (on original firmware): rtsp://admin:password@IP:80 to see if it works -- that is rtsp:// on port 80 with the correct password obtained from the log file (just like you did to get the /proc/cmdline working before.

guino commented 3 years ago

@SamThing forgot to ask you to try rtsp://admin:password@IP:80/Streaming/Channels/101 as well

SamThing commented 3 years ago

No luck too.

Tried with UDP/TCP with /Streaming/Channels/101 and without it..... When you say request header, which one are you referring to?

guino commented 3 years ago

@SamThing The request header is the combination of URL, parameters and protocol (ie http/rtsp, get/post, / or /Streaming/Channel/101 - there’s code in the firmware suggesting everything gets parsed bu the same function and based on the type (http/rtsp/https/rtsps) it goes to different functions.

At this point I am thinking that there is some sort of issue with the rtsp server on this device - suspecting it may not be setup correctly as the video feed is intended to be viewed from the app (and only from the app). There’s no other reason I see why simply opening the connection to the port would cause the device to reboot. I know I am looking at the right code because the reboot issue happened on the port 8555 when I changed it.

Just about the only thing I can offer now is to try and make an offline ppsapp based on some other firmware known to have RTSP working and that uses the same camera sensor. This would require a number of changes in the file to hopefully ensure that it would not modify your firmware/files and cause problems. Obviously this would mean no longer being able to use the original app from the manufacturer. There is the risk of not finding all the functions that modify the device and it could potentially make your device no longer boot correctly (and you would have to restore a firmware backup). It all depends on what you think is important for you - if jpeg/mjpeg+app is enough or if you rather have rtsp. Obviously there’s no guarantee it would work but it would be something to try.

SamThing commented 3 years ago

Hi @guino ,

Understood. I'd say that for my purposes the mjpeg endpoint is enough. But I'd love to see this RTSP feed working even with the chance that it would brick the device.

So it's your call to go ahed or not. If you choose to proceed, I'll help you with everything I can from my side.

Lets do some science! 😄

guino commented 3 years ago

@SamThing Did you use #11 to get the flash.bin file listed on 2nd post or did you use a programmer ? I just want to be sure we have a way of restoring the flash if anything goes wrong.

SamThing commented 3 years ago

I did the #11 procedure

guino commented 3 years ago

@SamThing so here's something 'wild' for you to try:

1-Download this file: https://github.com/guino/Merkury720/raw/main/ppsFactoryTool.txt to the SD card and set your wifi ssid+password in it -- then copy it to the root of the SD card. This is to ensure the ppsapp will connect to your wifi. 2-Edit your boot script so that you run umount /home/cfg right before executing ppsapp 3-Download ppsapp-offline.zip and place it on the SD card -- adjust your boot script so it runs this file instead of the other ppsapp files. 4-If you want to 'test' snap/mjpeg with this ppsapp you'll need to adjust the jpeg address to match this patch: https://github.com/guino/ppsapp-rtsp/issues/1#issuecomment-751521849 5-If it works, the time will possibly be wrong in the video -- in which case you'd have to use this to have it set correctly: https://github.com/guino/BazzDoorbell/issues/4#issuecomment-744084557

Give it a try with rtsp://IP@8554 after it boots up -- please notice the startup sound will likely not happen (as we are unmounting the /home/cfg as a precaution). I tried to remove most of what would write/erase things in /home/cfg but I rather unmount it to be sure. If the device doesn't boot up you can try it without the unmount /home/cfg command in the boot script. If it doesn't work either way I am at least hoping it won't cause any permanent changes that could affect your device (and you should be able to revert changes and run your own ppsapp ) -- the ppsapp I used as base is from another firmware of same board+camera sensor so it is the most likely to be compatible with it.

SamThing commented 3 years ago

hi @guino , I'm quite busy at work today, but I'll let you know once I have a chance to give it a try.

guino commented 3 years ago

@SamThing take your time and do it when you don't have to rush it.

SamThing commented 3 years ago

Hi @guino , sorry for the delay, a lot of things happened in my life. Just have time to give a try now.

The port 8554 is closed. snap/mjpeg didn't work, even with this address you suggested. The proc/cmdline endpoint now works with the default password (http://admin:056565099@ip/proc/cmdline) instead. Android don't recognise the camera as other apps too.

ps |grep pp

  924 root      0:00 ./ppsdsry
  953 root      0:00 /mnt/mmc01/ppsapp-offline
 1089 root      0:00 grep pp
mount

rootfs on / type rootfs (rw,size=15864k,nr_inodes=3966)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
/dev/mmc01 on /mnt/mmc01 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
guino commented 3 years ago

@SamThing can you provide a log output for this ppsapp? or at least the information from /devices/deviceinfo ?

I assume you didn’t try it with /home/cfg mounted? (Removing the unmount command from script)

we may need to create a file /mnt/mmc01/config.json to define some parameters in it — here’s a sample file you can use for that: https://github.com/guino/BazzDoorbell/issues/21#issuecomment-776432465

SamThing commented 3 years ago

Yeah, I tested with /home/cfg mounted, but same results as previous

from /devices/deviceinfo:

{
  "devname": "Smart Home Camera",
  "model": "Mini 8S",
  "serialno": "059554188",
  "softwareversion": "2.9.6",
  "hardwareversion": "M8S_H1_V10_F23",
  "firmwareversion": "ppstrong-c51-tuya2_kjell-2.9.6.20200417",
  "authkey": "",
  "deviceid": "",
  "identity": "MR2003210200102728",
  "pid": "aaa",
  "WiFi MAC": "ac:64:cf:ea:1d:3e"
}
cat config.json

{
        "version":      1,
        "sleep_mode":   0,
        "alarm_fun_onoff":      1,
        "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,
        "loudspeaker_vol_pct":  100,
        "onvif_enable": 0,
        "onvif_pwd":    "admin"
}

--deleted--

guino commented 3 years ago

@SamThing From a quick look at the log it doesn't seem like the ppsapp is able to start the camera sensor. I will take a closer look but differences in the OS/drivers may not allow this ppsapp to work correctly.

guino commented 3 years ago

@SamThing I took a closer look at the log/code and I believe the problem is really with the OS differences between your firmware and tuya firmware. The tuya version of ppsapp simply is unable to connect with the video device in the board. I highly doubt there's any change I can make in the ppsapp to allow it to work with the different OS drivers, so short of re-flashing the whole board with a new bootloader+kernel+file system this is not going anywhere.

SamThing commented 3 years ago

Well, I think it's the end of the road then. As I said, the actual hack is enough for my purposes and I'll happily be using it. Please let me know if you find anything or decide to continue working on it, or....anything actually Thank you for your work and time. You're very kind!

I'll absolutely buy some coffee to you! See you around!