LSC Smart Outdoor (IP) Camera - Hack not working

EpicLPer commented 1 year ago

Heya!

Bought a LSC Smart Outdoor (IP) Camera yesterday and tried this hack, but sadly it didn't seem to work. I added the camera to Tuya and had to update it before being able to use it (which probably was a mistake in hindsight).

The Firmware version on it right now is 2.10.36, and the only open ports I see are 53 and 6668.

If you need anything, I'm willing to open the camera up and do have soldering skills, I've also helped to dump the Sonoff cam a few years back and then figuring some things out :)

Thanks already for your help!

guino commented 1 year ago

@jonesMeUp well, the OS and file structure is totally different on these devices -- so no more boot parameters, scripts, etc. It'll be just placing some files in the SD card and booting up. I don't want to 'host' device files in github so I'm trying to find the right tools to extract the files from their update. From what I can tell they're only updating devices to 2.10.36 if your account is in the European servers, but being on 2.10.36 would only require a patch file like we've done in the past. I am still debating if there's any 'benefit' in not updating to 2.10.36 (other than not having to enroll the device on Europe's server).

guino commented 1 year ago

I was able to get the phone app and RTSP working together after a whole lot of trying and re-writing the video call back function by hand. What's left to do now is:

make a cgi script to enable/disable telnet on demand (because there will not be a telnet password on this device)
adjust logparser for motion detection/notification
documentation/write up

guino commented 1 year ago

For anyone waiting on this: https://github.com/guino/LSCOutdoor1080P

EpicLPer commented 1 year ago

Awesome! Does audio work already for it?

guino commented 1 year ago

@EpicLPer yes! audio works already! Thanks for the coffee (and the help)!

McPrapor commented 1 year ago

I have interesting issue, it doesn't offer me upgrade from 2.10.28 anymore, says the latest version installed. Is it only me?

UPD. Anyway second option with binwalk works well, got rtsp on two devices, works great. Btw I admitted hat after reboot camera turns it's lens to its bottom, so doesn't really translate any picture, as lens is closed. Could that be because I'm using 2.10.28? Anyone else having same issue? Any advice howto tune the point where it should be directed during startup?

guino commented 1 year ago

@McPrapor I thought I saw that on first boot - does it happen every boot? It could be because you are on 2.10.28.

The update to 2.10.36 will only show up if your account is on the European server, and may only show up on the LSC app (I dispense try it on the tuya app itself), I do know that using the LSC app with North American account it will not prompt to update.

McPrapor commented 1 year ago

Thanks for quick answer. I was able to connect the third device as well, so the fix is really working great.

Every time I'm rebooting the camera, the lens stays directed to the bottom unfortunately.

I have European account and using LSC app. The app stopped to offer me an upgrade 3 weeks ago. I believe that here is a problem with this upgrade, maybe they just temporary stopped to offer it. Here is the topic, where people complain about problems during the firmware upgrade: https://gathering.tweakers.net/forum/list_messages/2154532

Anyway I'm pretty happy about possibility to use cameras with frigate to know, that noone will mess with my bicycle, thank you so much for your work!

guino commented 1 year ago

@McPrapor It is odd that you don't get the 2.10.36 update notice on the LSC app with Europe servers -- I tested just now and I still get the prompt to update the outdoor camera, so I'd expect the same with the rotating camera (basically same firmware).

To be clear you WILL NOT get the update prompt while using the files to enable RTSP (because that's already 2.10.36), so if you wish to update your device you should remove the SD card, make sure you're using the LSC app with an European account and hopefully that should be enough.

I can confirm that running 2.10.36 (patched application) on my 2.10.22 firmware seems to cause the up/down movement of the camera to move more than it does with the 2.10.22, I believe this is what's causing the camera to point almost all the way down at start up. At a quick look I was not able to find any quick setting to change that behavior.

guino commented 1 year ago

If any one here has a rotating camera on 2.10.36 I'd like to get the output from this telnet command:

cat /etc/config/_ht_sw_settings.ini

That may give us a hint as to fix the issue with older firmware.

jonesMeUp commented 1 year ago

first things first: thanks for your time and energy!

~~After guino was on it, i asked santa for a camera... so my mother bought one for me to get it to work before christmas. I know, i talk too much when i am frustrated and filled up with beer... sorry now some facts: I put my camera online today. In the smartlife app, i don't get any info because when i deny the "update SDK version to V4.8.8" it takes me out of the configuration. Then i tried to get the camera of my colleague into my network, but after the pairing sound (i can see the device in my router), the app counts from 2:00 to 0:00 ignoring that the pairing was done. I don't know what version i have, but my colleague told me his device was 2.10.36 and he got the same update info like me. He said he had denied all tuya update wishes, so i think i have the same version (both of us have the device without movement). so, our 2.10.36 seems to be different from your versions?! our anyka_ipc size: 4187428 your anyka_ipc size: 4258888 After i had nothing to lose, i used guinos guide to get (your) 2.10.16 patched and put it over the colleague version accepting the fact that it may brick the device. Same result: pairing sound, visible in the router - but smartlife counts to 0. So the Hardware seems to be the same, no brick at all. but still a non working device. I am willing to do all your crazy wishes on the device of my colleague - its already unusable, at least with tuya app, and it has still warranty left for some time... Would be nice if you have an idea of getting the device to work without the fu*§"§% smartlife app, but no problem if the device will be declared as doorstop.~~

Solved My tablet has some cracks in the display which costs me usually more time to scan barcodes. So i thought it was mayby a problem with the barcode, but why then a few times it makes the pairing sound witout going any step further? But then it happend - I saw the stream in the app. Not for long then it throws an error message and said "offline". Tried a few times and got a steady online/offline status. So it was the WLAN chip! Went to Action and got a new one. Its online now for 10 minutes without any strange effects. I leave this message here for anyone with the same problem.

Btw, i looked on "our 2.10.36" -> Build is from Dec 30 2021 11:33:37, while downloaded file is from Aug 5 2022 10:43:25. Perhaps my colleague was wrong on 2.10.36, because the downloded version is much newer. So now i can finally start with some testing, after i lost a whole day on a broken WLAN chip.

McPrapor commented 1 year ago

I took unpacked camera yesterday, created a new LSC account as Belgium, installed LSC smart app on a new devices and left camera run on stock for a day after activated it via app and no update proposed. In the forum topic I posted people complained that some cameras are updated well(withj white phone on the box) and some cannot be updated (with black phone on the box). I can buy only cams with black phone, so guess its my luck that I didn't apply the update. And in the middle of that forum thread people write, that update is no more proposed, 2.10.28 is now an oficially the last version available.

guino commented 1 year ago

@jonesMeUp glad you got it working. I have seen issues with chinese cameras having poor quality wifi chips, I have a camera where the wifi causes the device to freeze frequently and disabling wifi and using Ethernet (which thankfully is present) makes the device very stable. So I am not surprised you had issues with it.

@McPrapor I will add my rotating camera to my LSC app to see if I am offered the update, but it is surprising that possibly slightly different version of the device had no update available - maybe they removed it specifically because of that initial position issue we’re seeing on 2.10.36

guino commented 1 year ago

@McPrapor I am not being offered to update my rotating camera either. It obviously works with 2.10.36 with that start position being the only ‘noticeable’ glitch. I can tell you that 2.10.36 has a number of new settings not present on 2.10.28 so I would hope they could allow it to work correctly, but without sample settings it would be a guessing game which can take a long time to figure out.

guino commented 1 year ago

@McPrapor and anyone else with the rotating camera: I spent quite a bit of time (as expected) trying different values for settings (and even did some patching attempts) and was finally able to get the rotating camera to start in the correct position. I have updated the repository so it should be ready to go -- if you already have it all setup you only need to update hack.sh in the SD card. So really there should be no reason to try and get 2.10.36 on these cameras.

McPrapor commented 1 year ago

Oh what a wonderful news! Updated and checked my cams, looks great!

UPD. Oh after some more testing I found , that axis Y position after reboot gets different angle. First I thought it inverts the angle before reboot, but now I'm not really sure, will do more tests. Anyway it's a great job, thank you again!

jonesMeUp commented 1 year ago

@guino Captain we have a problem: motion event. Tried to make my "single file offline" solution for this device. When the device is online, all worked well. when i cut inet - all went working. But when i cut inet and then boot the outdoor - no motion event is detected anymore. I hope thats, not again, only hitting me (after talking, again, bad about tuya devices). I tried to find the problem in ghidra, but i was lost in hex. Motion event must be handled in anyka_ipc_rtsp, else it wouldn't work after switching off inet.

And another think i don't understand:

The reason why we're using a passwordless telnet is to prevent writing to the flash memory on every boot.

Where can i see when something is written to the flash? I thought /tmp is always in RAM.

I think i am too old for this :(

guino commented 1 year ago

I have just updated the repo's readme with how you can update the outdoor camera to 2.10.36 if it isn't being offered in the app.

@jonesMeUp I'll have to try it out and check the code to see why it isn't working -- likely the tuya code is 'waiting' for connection with the server before it fully starts its own functions. In these devices the RTSP code is separate from the tuya code so it should start up right away without internet (but the motion detection is a tuya function).

Regarding the flash issue: The start scripts mount a read-write partition under /etc/config and copies some things in there every boot if they're present in the SD card, then deletes them and it happens every boot, so if we wanted to do a telnet with password we'd have to accept that we'd be writing to the flash every boot for no good reason. While working on the rotating camera I also found that even without telnet a file gets copied from read-only flash to /etc/config on every boot so I made an 'override' to prevent that in my latest hack.sh. We can take care of all those things by writing a custom partition to the flash but I generally like to leave the device's flash untouched whener possible.

guino commented 1 year ago

@McPrapor with my rotating camera, no matter what position I left the camera before reboot it always boots up to the normal front-facing position (same angle). So I'm not sure why you're getting a different behavior.

jonesMeUp commented 1 year ago

@guino If i understand you correctly the problem is the etc folder (not the tmp?). but we used it also on the doorbell for passwd/shadow, TZ, dropbear. Is this because it was handled another way on the doorbell? And if so, can't we just place the config files also in the ram? You used the mount bind (i never ever heard off it until you placed it in your git) - can't it be used for "all configs to ram"?) Might sounds all a bit silly, but since you crashed into my life... I must learn so much in so less time...

guino commented 1 year ago

@jonesMeUp in this firmware there’s a symbolic link from /etc/shadow to /etc/config/shadow — that symbolic link is read only. /etc/config is where they mount a read-write settings partition. When the device stars it always tries to delete the /etc/config/shadow file, so if we copy one in place we write the flash and it will be erased on next boot so we would have to copy it again. We could remove that behavior by modifying the application partition (custom flash) to leave the shadow file alone so it would just stay configured. A custom flash change would most definitely be removed by future updates.

jonesMeUp commented 1 year ago

@guino thank you really much, that you try to hammer your wisdom into my head. I am really trying to understand your info and i read more linux guides for this project than in my whole life before... What i think i have learned from your postings:

doorbell doesn't make such symbolic links to read-write partiton, so we are not in panic about /etc
we could make a warkaround for the /etc folder that would be destroyed by an update (but we don't want updates?!)
the problem of the motion detection can be fixed by ghidra (but not by me)

what i don't understand:

how can I see if its written to ram or to flash.
where to find such stuff like motion detection in ghidra.
why the bard's tale was more important to me than linux.

Perhaps it looks like i take a short look and then give up, but thats not true! before i post here, i have invested at least a day of trying. I am a poor pensioner, so i have the time.

guino commented 1 year ago

@jonesMeUp you are right about the symbolic link, I always worry about updates being done without express authorization and it may be possible to remove it the motion detection limitation in ghidra — haven’t looked for that specifically yet.

You can execute the mount command in telnet to see what is mounted — anything that is not read only and not in the SD card (/dev/mmcblk*) would be flash storage so it is ideal to be mindful of anything copied/modified in these locations.

The tuya code usually has a connection wait which is usually a while loop checking a variable or calling a function to check if the device is online (with a wait/sleep inside) before running other tuya functions (like motion detection) — most likely 3-4 lines of code that would have to be modified to bypass the wait.

I have played my fair share of video games, in fact the only reason I learned coding and OS stuff was so I could play games on the computer. If you have time and want to learn I praise your efforts and will try to answer when I have time but ghidra is basically reverse engineering which is a step further out from coding, so don’t feel bad if it takes time - I spent half a day myself yesterday to figure out 1 setting, so it takes a lot of time even experienced people to do this stuff.

jonesMeUp commented 1 year ago

@guino thx for your support! Meanwhile i have found some places with MQTT, NTP and Network_connection loops. e.g: 0009c4b0 f8 ff ff 1a bne LAB_0009c498 replaced by 0009c4b0 00 f0 20 e3 nop But there seems to be many more. I will try the next time to get it done.

If i am able to fix the buggy tuya online code, i will go on with my 1 file solution and i will have many questions about the flash writings. (If i see it correctly, tuya overwrites /etc/TZ also at every boot!?)

guino commented 1 year ago

@jonesMeUp I had a quick look and it seems very different than previous code I've seen (though the code has the same effect) -- I haven't tested anything but you can try changing this

00088c94 02 00 00 0a         beq    LAB_00088ca4

to

00088c94 02 00 00 ea         b      LAB_00088ca4

I would expect it to initialize the tuya functions even if it can't reach the tuya servers.

jonesMeUp commented 1 year ago

@guino thx, this one i found also, but i made the mistake to just look into the offline mode. so i ended 9 loops - and, of course, one too much. After i tried the cam online, i realized that even putting the cam online didn't show an event anymore. But i don't dare to give you a "offline only" version, so i started from scratch and found that only 2 loops must be ended to get the motion event offline. grafik If you can confirm it on your device, i would be pleased to see it in your repo. Next i will start the single file version of hack.sh - with more annoying questions.

And i found 2 interesting subs:

factory mode where you can give uuid and paswd in a file (lost the address, but can be found again - if needed)
param_1 = ht_audio_codec_play_audio_file("/usr/share/<filename>.mp3"); can't this be used for your creapy voice to send a message to all visitors? ;)

icecream4all commented 1 year ago

forgive my ignorance but I'm wondering how to download video files remotely.

jonesMeUp commented 1 year ago

welcome icecream4all, the video files are saved in a non standard format to the sd-card. If you are running a raspi as smarthome central (like me) is the best to let ffmpeg do the job. When you tell us more about your environment we can give some more info.

guino commented 1 year ago

@jonesMeUp I will take a look at the code, not sure when I can actually test it offline. There's a built in function to play mp3 files, but unless we have a way to call the function 'on-demand' (from linux command line) there's no way to make it play what we want (I can't directly 'call' a function inside their code from linux command line).

@icecream4all Using the files I provided you can 'download' the video files by browsing to http://user:password@IP:8080/ (user and password configured in httpd.conf) then browsing into the DCIM folder and clicking on one of the .media files -- you should be able to download the file directly from a script with curl/wget or similar too. The files are (as mentioned above) in non-standard format but you can play them without audio with mplayer or VLC (if you select H264 demuxer).

jonesMeUp commented 1 year ago

@guino still so much left to learn. i thought your play.cgi jumps directly into the tuya binary to play the mp3. sometimes i feel like a stoneage warrior in a raspi world. when i was in school, the zx81 was not invented. but we had already the pyramids!

I will take a look at the code, not sure when I can actually test it offline

No problem, i have my offline version and can test my onefile. I don't care how much time it will need. Its only a try to give something back to your wonderfull project. btw, would be nice if you could drop me a line to understand why play.cgi works on doorbell, but not on outdoor (like you would tell it a 5 year old child)

guino commented 1 year ago

@jonesMeUp on older firmware they had a loop checking to see if anything needed to be played — it was just checking variables in the memory. So play.cgi simply set the variables in memory and the loop would detect and play it.

At a quick check I did not find anything similar for these newer devices, so if we can’t find it we would have to find some loop that is running but isn’t being used and basically change it out to monitor some memory location and call the mp3 playback function when we need it. The closest thing I found was the thread to play the siren alarm — we could trade that for play.cgi (which would make the siren function no longer work correctly).

It is not impossible, just a pain and time consuming to modify each individual instruction to write a whole new function without braking whatever is there.

jonesMeUp commented 1 year ago

@guino ok, that sounds to me like a real good idea. Have you ever tried the siren? its a bad joke! is not a siren, its just a mp3 playing. I have a fire alarm here... thats something i would call siren, but that %$%&$ outdoor whisper is called a "siren"??? so it would nice to have it replaced by a usefull function. sorry that you have to invest so much time in me, but i hope to give it back twice into the project.

guino commented 1 year ago

@jonesMeUp Your changes seem ok, I'll have to do some testing when I have a chance and include them in the main patch. Meanwhile we can make an 'offline patch' with these 2 changes so anyone else can try if they want.

McPrapor commented 1 year ago

@guino I dumped today fw from one similar cameras sold in local stores, where no card tricks worked. I wanted to enable telnet for beginning, as uart pins being disabled most probably in uboot. So far I was able to disassemble it only with binwalk, but apart of rootfs, there are zlib files and not all of them could be unpacked with gzip and some jffs2 files. Could you please share some tricks how to disassemble those?

icecream4all commented 1 year ago

@jonesMeUp I run homeassistant. My wifi is crappy at the moment which sucks cause I'm building a timelapse. The Tuya app keeps telling me there are no vids recorded (end of video) but now I can manually access the clips thanks @guino . I take some screenshots from the clips to fill the holes in my timelapse.

guino commented 1 year ago

@McPrapor jffs2 in a firmware dump sometimes is tricky. Basically you have to extract the jffs2 partition as a separate file, then on a linux machine you can mount it with something like on this script: https://elinux.org/Mount_jffs2 -- you may need to adjust the mtdblock0 to something else depending on what already may be present on your OS.

Basically (all on the linux machine): -use dd to 'extract' the entire JFFS2 from the firmware dump into a separate file (because binwalk will try to extract separate jffs2 pieces and anything in between i.e. zlib files) -check to see if you have any mtd modules and devices loaded: lsmod | grep mtd and ls -la /dev/mtd* -if you already have /dev/mtdblock0 you may need to see what's using it and/or adjust the script to use a different number not in use like mtdblock1. -execute the script (perhaps with different mtdblock value), passing the extracted JFFS2 from the firmware -- it may throw some errors for some drivers that you don't have like mtdram, mtdchar) -- that should be ok, hopefully you'll be able to mount it to view/edit the files.

I will tell you advance jffs2 is usually for settings, so you may go thru all this and not find anything useful to gain access to the device, but you could be lucky and find a setting to turn on telnet, etc -- but you'd have to flash your changes back to use it.

jonesMeUp commented 1 year ago

OFFLINE Version This version works without the tuya cloud.

Update:

OSD-Time fixed

Todo:

Extern: Make a ffmpeg script for the raspi to show live stream in the browser [high priority]
Make record duration [very low priority]

MQTT Output: Fhem IODev comes from my Smarthome, all _SIZE is SD-Card data, Lumi is the lumination and can be used for day/night topics in your Smarthome.

Preconditions:

You need to patch the original app https://github.com/guino/LSCOutdoor1080P
Patch guinos anyka_ipc_rtsp with the unpacked ips file fromGuinoToJones.zip
Copy the patched anyka_ipc_rtspand the hack.sh to the root folder of the SD-Card.
Prevent inet connection in your router

[hack.sh]

#!/bin/sh

TZ="GMT+01:00"            # Greenwich Mean Time    (edit me)
NTPD_IP="192.168.178.100" # local NTPD Server IP   (edit me)
MQTT_IP="192.168.178.100" # local MQTT Server IP   (edit me)
MQTT_PORT="1883"          # local MQTT Server Port (edit me)
MQTT_DEVICE="DVES_CAM01"  # local MQTT Device Name (edit me)
PATH_VIDEO="/mnt/DCIM/"; PATH_DEPTH=4 # /DCIM/YYYY/MM/DD/TIMESTAMP_X/
BB="/tmp/sd/busybox"      # Busybox shortcut
REC_TIME=30               # Atm: No change possible
DEBUG=0

####################################################################################
# FUNCTION: Set variable and send it as MQTT command
####################################################################################
sendMQTT() { 
  eval $1="$2" # Set Variable ($1: Variable-Name, $2:Variable-Value)
  /tmp/sd/mosquitto_pub -h $MQTT_IP -p $MQTT_PORT -t $MQTT_DEVICE/$1 -m "$2"
}
####################################################################################
# Mount SD-Card
####################################################################################
mkdir -p /tmp/sd
mount /dev/mmcblk0p1 /tmp/sd
rm -f /tmp/_ht_ap_mode.conf # If this exist, flash will be written
####################################################################################
# Reset wifi to client mode (same as it wifi_driver would have done)
####################################################################################
killall udhcpd
ifconfig wlan0 0.0.0.0
touch /tmp/wifi_is_8188
####################################################################################
# Set the local time and bind /tmp/ over /etc/ (no flash write)
####################################################################################
echo "$TZ" > /tmp/TZ
mount --bind /tmp/TZ /etc/TZ
####################################################################################
# Modify ini file for Y-Movement and bind /tmp/ over /etc/config/ (no flash write)
####################################################################################
cp /usr/local/_ht_hw_settings.ini /tmp/_ht_hw_settings.ini
echo 'tilt_total_steps = 2200' >> /tmp/_ht_hw_settings.ini
mount --bind /tmp/_ht_hw_settings.ini /etc/config/_ht_hw_settings.ini
####################################################################################
# Start telnet and httpd
####################################################################################
telnetd -p 24 -l /bin/sh
$BB httpd -c /tmp/sd/httpd.conf -h /tmp/sd -p 8080
####################################################################################
# Event loop 
####################################################################################
(
  [ $DEBUG -eq 1 ] && (> /tmp/sd/dmesg.log; > /tmp/sd/delete.log)
  ##################################################################################
  # Wait for anyka_ipc_rtsp to connect to WLAN and sync localtime
  ##################################################################################
  while [ $(date +%s) -lt 1645543474 ]
    do ntpclient -s -c 1 -i 5 -h $NTPD_IP &
  done
  (hwclock -w; hwclock --systz) &
  ##################################################################################
  # Set status variables in the binary to online
  ##################################################################################
  PID=$(ps | grep -v grep | grep anyka_ipc_rtsp | awk '{print $1}');
  # Copy timestamp into app (when online, it comes as json from tuya server)
  HEX=$(printf '%.08x' $(date +%s)); 
  echo -en "\x${HEX:6:2}\x${HEX:4:2}\x${HEX:2:2}\x${HEX:0:2}" \
      | dd of=/proc/$PID/mem bs=1 count=4 seek=$((0x9648c));
  # Fake MQTT is online (set statusMQTT to 1)
  echo -en '\x01' | dd of=/proc/$PID/mem bs=1 count=1 seek=$((0x434d1c));
  # Streaming duration [ TODO ]
  #echo -en '\x0a' | dd of=/proc/$PID/mem bs=1 count=1 seek=$((0x189a04));
  #echo -en '\x3c' | dd of=/proc/$PID/mem bs=1 count=1 seek=$((0x8f50c));
  sleep 2 # Some sleep to prevent reboot
  ##################################################################################
  # 
  ##################################################################################
  REC_STOP=0 # Time when recording will stop (0: Recording has already ended)
  sendMQTT MMC_SIZE $(df -m /dev/mmcblk0p1 | grep dev/ | awk '{print $2}') #    [MB]
  sendMQTT MAX_SIZE $(($MMC_SIZE / 2)) # Max allowed space for streaming videos [MB]
  sendMQTT ACT_SIZE $($BB du -ms $PATH_VIDEO | awk '{print $1}')
  sendMQTT VERSION  $(cat /usr/share/VERSION | awk '{print $1}')
  while true; do
    BUF=$(dmesg -c); if [ -z "$BUF" ]; then continue; fi
    [ $DEBUG -eq 1 ] && echo "$BUF" | grep -v RTW | grep -v '^$' >> /tmp/sd/dmesg.log;
    #################################################################################
    # Motion event has ended, now its paused for the rest of "shield time"
    #################################################################################
    if [ $REC_STOP -gt 0 ] && [ $(date +%s) -gt $REC_STOP ]; then
      REC_STOP=0; sendMQTT RECORDING 0
      # Delete oldest streaming folder(s) until ACT_SIZE < MAX_SIZE
      while [ $($BB du -ms $PATH_VIDEO | awk '{print $1}') -gt $MAX_SIZE ]
      do 
        OLDEST=$($BB find $PATH_VIDEO -type d -mindepth $PATH_DEPTH \
                -maxdepth $PATH_DEPTH | $BB sort | $BB head -n 1)
        rm -rf $OLDEST
        [ $DEBUG -eq 1 ] && echo "SIZE: $($BB du -ms $PATH_VIDEO)" >> /tmp/sd/delete.log
        [ $DEBUG -eq 1 ] && echo "$OLDEST was deleted" >> /tmp/sd/delete.log
      done
      sendMQTT ACT_SIZE $($BB du -ms $PATH_VIDEO | awk '{print $1}')
      [ $DEBUG -eq 1 ] && echo "Act folder size: $ACT_SIZE" >> /tmp/sd/delete.log
      # Delete empty parent folders (for devices with YYYY/MM/DD/HH folder format)
      $BB find $PATH_VIDEO -type d | $BB sort -r \
        | xargs $BB rmdir --ignore-fail-on-non-empty
    fi
    #################################################################################
    # Motion event
    #################################################################################
    case $BUF in *"motion detect"*)
      sendMQTT RECORDING 1
      REC_STOP=$((`date +%s` + REC_TIME))  ;; 
    esac
    #################################################################################
    # Lumi event
    #################################################################################
    case $BUF in *"ent lumi"*)
      sendMQTT LUMI $(echo ${BUF#*current lumi:} | $BB cut -d "[" -f1) ;;
    esac
  done;
) &
####################################################################################
# Now start anyka_ipc
####################################################################################
export LD_LIBRARY_PATH=/lib:/usr/lib:/tmp/sd
cp /usr/bin/daemon /tmp/
/tmp/daemon &
/tmp/sd/anyka_ipc_rtsp 2>&1 | {
  while true; do
    read -r BUF
    case $BUF in ''|\#*) sleep 1; continue ;; esac
    echo "<1> $BUF" > /dev/kmsg
  done
}

EpicLPer commented 1 year ago

@jonesMeUp I'd love for those cams to somehow become "dumb RTSP/ONVIF cams", and this is the closest approach yet!
There's also the OpenIPC project, but sadly Anyka is not supported properly yet.

jonesMeUp commented 1 year ago

@EpicLPer yep, i have no interrest in an AI spy. Just a dump camera would be nice.

EpicLPer commented 1 year ago

@EpicLPer yep, i have no interrest in an AI spy. Just a dump camera would be nice.

If someone is skilled enough to try and port OpenIPC to these specific Anyka chips we may have a chance :)

jonesMeUp commented 1 year ago

@guino I could need an advice. When i set the "wait for ntpd sync" in the background loop:

####################################################################################
# Event loop 
####################################################################################
(
  while [ $(date +%s) -lt 1645543474 ]; do :; done; # Wait for synced localtime

The streaming folder didn't get the actual time, because the app starts before the time is synced.

When i set it in front of the loop, the camera seems to be in an endless loop (perhaps a wathdog restarts it) I set a sleep() within the app in _tuyamain(), it doesn't change the date of the streaming folder.

          sleep(0x20);
          IPC_APP_Sync_Utc_Time();

On the device date shows the correct time, but stream-time is always 1h wrong and stream-folder date is always 1970. The timestamp on the stream will be corrected after ~10s when using the timesync-wait in the background and comes up with the "correct" time (1h wrong) as soon the stream is shown in vlc

jonesMeUp commented 1 year ago

@EpicLPer i don't think someone will do it. But as long as we have guino... i am very happy to get the 24/7 service here. Of course we must have an eye on guino and prevent holiday/marriage/kids/joing a cult/drugs/netflix/gambling/...

McPrapor commented 1 year ago

Hey, folks. Any chance to get a patch to make it start offline?

guino commented 1 year ago

@jonesMeUp

WRONG (I thought you had usleep) The sleep(0x20) you added is really just 32 milliseconds -- if you want to sleep for 20 seconds you should do sleep(20000) you may need to put that 20000 into a memory location and load the parameter from it because you probably can't load 20000 into a register directly

Another approach could be to leave the code unchanged (which tuya uses to wait for it to be 'online' with their servers) and set the variable/memory in the process directly (so it thinks it's online), that is: once your NTP service syncs. On 2.10.36 the variable that tells if mqtt is online seems to be at 0x434d1c -- so something like this could work (untested): echo -en '\x01\x00\x00\x00' | dd of=/proc/$PID/mem bs=1 count=4 seek=$((0x434d1c)) (you have to set PID= the process id of anyka_ipc_rtsp in the command)

So basically you could try (without your offline patch) to just run the command above when your NTP service syncs the time to see if the device starts 'acting' like it's online (motion notifications, recording, etc).

guino commented 1 year ago

@EpicLPer I just updated the repo with a feature to control the PTZ of the camera -- I think I recall you wanted that too?

jonesMeUp commented 1 year ago

@guino Well, thats a very cool idea! I will try this in the evening. [edit] It worked, but solved only 1/2 endless loops. Next one is in ht_tuya_service_start() ->IPC_APP_Sync_Utc_Time() When i ended this loop i get the same result as with my patch (rtsp & motion event working, but wrong times). So i think it must be within there. I will test tomorrow some more. As bruce s. said "We learned more from a three-minute guino, baby Than we ever learned in school"

@McPrapor Above your post is an offline solution. But if i were you, i would wait until the localtime is fixed.

jonesMeUp commented 1 year ago

@guino After many hours of ghidra surfing, i found that it looks like the app reads the hwclock, so i copied the time from system to hardware clock hwclock -w. In telnet it looks good, the 1h differ is gone. So its the right direction, but the app refuses to update the change. Tomorrow i will dig into it again.

guino commented 1 year ago

@jonesMeUp Looking at the code you can try this one (together with my first command): echo -en '\x01\x00\x00\x00' | dd of=/proc/$PID/mem bs=1 count=4 seek=$((0x47b7a0)) -- this seems to be what gets that other loop to stop, and it does some stuff with Time zone and system clock, so patching it may not be a good idea (but this should allow the normal code to execute).

jonesMeUp commented 1 year ago

@guino well, that fix breaks the motion event. The only problem i have ist that the streamingfolder thinks its 1970. I wasted again much time on this topic. I switched the internal logging of the cam on to get a little more info. I will look tomorrow if i find something there to explain it.

I think its a timing problem, because the stream neeeds also a few seconds to sync the date. The app is starting to fast for ntpd to end this job and the streaming folder doesn't sync the date after init.

guino commented 1 year ago

@jonesMeUp for these devices, have you tried to sync the time in hack.sh (and wait) instead of running the event loop in the background ? you will have to adjust the code that changes the memory directly (so that waits for the main application to be running), but I would expect the main application to start with the correct date. The only question is 'how long' we can wait to run the daemon and anyka_ipc before any type of watchdog restarts the device.

guino / Merkury1080P

LSC Smart Outdoor (IP) Camera - Hack not working #42