LSC Smart Outdoor (IP) Camera - Hack not working

[EpicLPer]

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]

@EpicLPer If it has 2.10x firmware you need to try this one: guino/BazzDoorbell#13 -- did you try that one already ?

[EpicLPer]

@EpicLPer If it has 2.10x firmware you need to try this one: guino/BazzDoorbell#13 -- did you try that one already ?

Not exactly sure what I should try there from that issue? Or do you mean instructions from the repo itself?

[guino]

@EpicLPer there's a 'Process' section on that issue, just follow it and see if it works -- that's the process that has worked for 2.9.x and 2.10.x firmware to root the device and get a ppsapp file we can patch for RTSP.

[EpicLPer]

When doing the above via the URL http://admin:[email protected]/proc/cmdline it simply says "Connection Refused".

[guino]

@EpicLPer did you do it after creating a ppsFactoryTool.txt file? 2.10 firmware is know to require that file before URLs work.

[EpicLPer]

Is it possible to just leave it empty? Afaik I have one on the SD Card right now yes, but I'm not entirely sure what to do or what to put in it sorry ^^"
Those cams seem very different from other cameras so far.

[guino]

@EpicLPer this is the information regarding ppsFactoryTool.txt : if you don’t do it correctly it wont work. It may be worth trying port 8090 as well (from 4.x firmware) - it’s always a surprise with tuya firmware.

Special note for 2.10.0 firmwae: This firmware (and newer) have port 80 closed by default -- so to use the http://admin:05656... links below you have to RIGHT CLICK this link: https://github.com/guino/Merkury720/raw/main/ppsFactoryTool.txt select "Save as.." and save this file to the root of the SD card. EDIT the file (avoid copy/paste the contents of it) and modify only the ssid and password as the file requires specific format to work. When the device detects the file (in the right format) it will disconnect and re-connect the wifi (to the ssid specified) and will OPEN port 80 so the http://admin:05656... links work.

Special note for 4.0.x firmwae: This firmware (and newer) have port 80 closed by default -- so to use the http://admin:05656... links below you have to RIGHT CLICK this link: https://github.com/guino/Merkury720/raw/main/ppsFactoryTool.txt select "Save as.." and save this file to the root of the SD card. EDIT the file (avoid copy/paste the contents of it) and modify only the ssid and password as the file requires specific format to work. When the device detects the file (in the right format) it will disconnect and re-connect the wifi (to the ssid specified) and will OPEN port 8090 so the http://admin:05656... links work but you have to add :8090 to every URL, for instance: http://admin:[email protected]:8090/devices/deviceinfo. Depending on the device you have you may need to use the information and files from https://github.com/guino/Merkury1080P#conclusion

[EpicLPer]

Will try this once I'm home, thanks! :)

[EpicLPer]

@EpicLPer this is the information regarding ppsFactoryTool.txt : if you don’t do it correctly it wont work. It may be worth trying port 8090 as well (from 4.x firmware) - it’s always a surprise with tuya firmware.

Special note for 2.10.0 firmwae: This firmware (and newer) have port 80 closed by default -- so to use the http://admin:05656... links below you have to RIGHT CLICK this link: https://github.com/guino/Merkury720/raw/main/ppsFactoryTool.txt select "Save as.." and save this file to the root of the SD card. EDIT the file (avoid copy/paste the contents of it) and modify only the ssid and password as the file requires specific format to work. When the device detects the file (in the right format) it will disconnect and re-connect the wifi (to the ssid specified) and will OPEN port 80 so the http://admin:05656... links work.

Special note for 4.0.x firmwae: This firmware (and newer) have port 80 closed by default -- so to use the http://admin:05656... links below you have to RIGHT CLICK this link: https://github.com/guino/Merkury720/raw/main/ppsFactoryTool.txt select "Save as.." and save this file to the root of the SD card. EDIT the file (avoid copy/paste the contents of it) and modify only the ssid and password as the file requires specific format to work. When the device detects the file (in the right format) it will disconnect and re-connect the wifi (to the ssid specified) and will OPEN port 8090 so the http://admin:05656... links work but you have to add :8090 to every URL, for instance: http://admin:[email protected]:8090/devices/deviceinfo. Depending on the device you have you may need to use the information and files from https://github.com/guino/Merkury1080P#conclusion

Sadly this didn't seem to work :( The Camera still connects to my IOT WiFi instead of the normal one, despite me putting my normal one into the config to check if it even seems to read the file.
The SD Card is properly detected in Tuya tho and shows up just fine, so I doubt it's an incompatible SD Card.

[EpicLPer]

Tried a different SD Card now too, sadly same result.

[guino]

@EpicLPer sorry you had no success, every now and then we have reports of issues like this where multiple SD cards and multiple attempts don't work. Many people have reported success after repartitioning/reformatting the SD Card (trying windows/linux/etc). In any case you're welcome to post the SD card contents (from your attempt) so I can review to check if there's anything wrong.

[EpicLPer]

The SD Card contents are just the ppsFactory file and nothing else. Or do I need more? And of course also the files and folders the camera puts on it when turning the cam on.

[guino]

@EpicLPer for 2.10.x firmware the ppsFactoryTool.txt file is all you need to enable URLs like (adjust IP accordingly):
http://admin:[email protected]/proc/cmdline (port 80 -- most devices)
http://admin:[email protected]:8090/proc/cmdline (port 8090 -- some devices)

If you can get one of the two above working then we can try adding more files to see if it can be rooted. If neither above works then there's no way to move forward (other than opening the device).

I still would recommend you post a ZIP of your ppsFactoryTool.txt file (from the SD card) so I can review it -- a lot of times people make mistakes because windows hides file extensions, etc.

[EpicLPer]

Will try one more time, I don't have to hold the Reset button or anything right?

[EpicLPer]

Just tried again holding no buttons or anything, and it still doesn't connect to my normal WiFi and instead stays on the IoT one.

Here's the ZIP (with changed credentials): cam_sd.zip

[guino]

@EpicLPer your ppsFactoryTool.txt file is fine -- are you sure the SD card if FAT32 formatted ? maybe try to use the phone app to format it then copy the ppsFactoryTool.txt file to it. If the SD card isn't formatted in a compatible format the device will simply ignore it.

[EpicLPer]

Did format via the app yeah, but sadly still doesn't seem to work.

[guino]

@EpicLPer it looks like 2.10.6 is the last 2.10.x version we had rooted, They may have made more changes in this 2.10.36 to block more things -- there's no way of knowing for sure unless someone gets a firmware dump (which requires opening device + removing the flash chip to read it).

[EpicLPer]

@guino I'm "okay" when it comes to hot air soldering, but I'd have to buy some hardware to read the flash then, but would be willing to :) Always love some challenges!

If you tell me what hardware to get to read the flash and all I'll try so.

[guino]

@EpicLPer if you get the firmware I can definitely look at it. Just be careful when selecting/using a flash programmer to make sure it doesn't have 5V on 3.3V pins (many CH341a programmers out there have this issue -- and there's a mod to fix them).

[EpicLPer]

Would something like this work then?

https://www.amazon.de/DollaTek-Programmierer-ch341a-Adapter-Buchse/dp/B08HP4X326/ref=sr_1_4?keywords=CH341a&qu=eyJxc2MiOiI0LjgwIiwicXNhIjoiNC4zNyIsInFzcCI6IjQuMjQifQ%3D%3D

[guino]

@EpicLPer that is basically what I have and I did have to fix the programmer like this: https://www.youtube.com/watch?v=-ln3VIZKKaE

[EpicLPer]

I also have a ST-LINK and JR Programmer 2 still laying around from other projects but doubt I can reuse them here? I'm quite a beginner with these kind of things

[EpicLPer]

Took the camera apart now, already ordered the flasher :)

Noticed it has TX and RX on it tho, is there no possibility to connect vis serial and dump it?

[EpicLPer]

I've read up on this a bit and apparently it's also able to dump such chips via an Arduino? If so could try that, or wait on proper hardware and be less likely to damage things ^^"

[guino]

@EpicLPer great pictures. The XMC chip beside the RX/TX pads is the flash chip you need to read. The RX/TX pads (along with GND at the bottom would be for TTL-UART access which can sometimes be helpful, but you would need a TTL-UART 3.3V adapter (USB or serial), or a board with serial TTL connections (i.e. Raspberry Pi, etc).

[EpicLPer]

Do have that :)

Do you have Discord or Telegram by any chance to maybe easier talk there for a bit until I have some results I can post here again? Normal conversation always bloats issues up a bit.

[guino]

@EpicLPer if you have a Pi and you're willing to solder some wires to the board we can try to dump the flash to a SD card using the bootloader. Send me an email directly (my email is on my github profile) and we can exchange contacts.

[mrwiwi]

Exact same results with LSC Smart Doorbell ! Will follow your progress with attention :)

[EpicLPer]

Exact same results with LSC Smart Doorbell ! Will follow your progress with attention :)

We already got RTSP with Audio working, but it's via a test-mode of that camera.
You can test and see if yours is the same as mine (which we used to test this on) by creating a file called _ak39_factory.ini with nothing inside it on the root of the SD, and see if it screams at you in Chinese then which means it entered "Factory Test Mode".

Nothing will work tho and it won't connect to WiFi, this is literally only to see if your camera is similarly built than mine is, so then chances are high once we release a working version yours will work with it too! Please do report your results :)

[jonesMeUp]

@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 tuya_main(), 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]

@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]

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

[guino]

@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]

@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]

@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]

@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]

@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]

@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]

@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.

[jonesMeUp]

@guino yep, long before i put the waiting into the bg which seems to trigger a watchdog. there is no chance to wait for so long.
For a test i put iirc 8 * nop instruction at the start of void ht_log_init(void) the first sub in main().
It worked without killing the log function, but we could live without the logging...
My problem is the ldr part. i don't understand how to load the statusMQTT variable into r3 in assembler code.
i "copied" the code block from tuya_main()

          while (statusMQTT != 1) {
            sleep(1);
          }

        0009c498 01 00 a0 e3     mov        r0,#0x1
        0009c49c 18 de fe eb     bl         <EXTERNAL>::sleep
        0009c4a0 a0 30 9f e5     ldr        r3,[PTR_DAT_0009c548]
        0009c4a4 03 30 8f e0     add        r3,pc,r3
        0009c4a8 00 30 93 e5     ldr        r3,[r3,#0x0]=>statusMQTT
        0009c4ac 01 00 53 e3     cmp        r3,#0x1
        0009c4b0 f8 ff ff 1a     bne        LAB_0009c498

into the free part of void ht_log_init(void) but i didn't get ldr to point to the statusMQTT.

[guino]

@jonesMeUp here's what I'd try (this will SET the statusMQTT and at the same time skip the loop):

  0009c4a0 a0 00 9f e5         ldr    r0,[0x9c548]
  0009c4a4 01 30 a0 e3         mov    r3,#0x1
  0009c4a8 00 30 00 e5         str    r3,[r0,#0x0]
  0009c4ac 01 00 53 e3         cmp    r3,#0x1
  0009c4b0 f8 ff ff 1a         bne    LAB_0009c498

YOU MUST ALSO modify the bytes on address 0x9c548 to be: 1c 4d 43 00

If that's not what you want to do you may give me some more detail... in any case, if you want to load the contents of statusMqtt (0x434dc1) into r3 the instruction should be:
ldr r3,[0x9c548] along with modifying the bytes in 0x9c548 to be 1c 4d 43 00 (as I did with r0 above).

If you wanted to just set the variable from an outside script I assume that trick with echo+dd would work (as you previously confirmed):
echo -en '\x01\x00\x00\x00' | dd of=/proc/$PID/mem bs=1 count=4 seek=$((0x434d1c))

[guino]

@jonesMeUp some other piece of information which can help.. apparently this can prevent the watchdog from resetting the device:
(while true; do sleep 5; echo -n 1 > /dev/watchdog; done ) < /dev/null >& /dev/null &
(basically sending 1 to /dev/watchdog every 5 seconds)

I kept my device running for a few minutes without a reboot and without anyka_ipc running that way -- however: the biggest problem is that anyka_ipc is what configures/connects the wifi on the device (so you can sync the time) so you'd have to start and configure the wifi by hand in order to get the time before running anyka_ipc. Still could be an option if all else fails.

[jonesMeUp]

@guino thx for your support!
You misunderstood me. I used your hint to set statusMQTT in hack.sh as soon as ntpd has done its job.

What i want ito do:

Step 1:

while (statusMQTT != 1) {
   sleep(1);
 }

Place this loop at 0x00065bc8 in void ht_log_init(void) thats in main() NOT in tuya_main()
There is enough "empty" space for this loop and i want to test it for sideeffects.

Step 2:

If this will work, i want to overwrite the loop in tuya_main() with a call to ht_log_init(void)
(The original caller function to ht_log_init(void) will be NOP out for the testing, later it can be "repaired")
At this position the wlan should be working and the time sync shouldn't be started.
This should work on both versions: your online and mine offline version.

while (statusMQTT != 1) {
   sleep(1);
 }

But i don't get the ldr to work. I now it holds a reference to an address, but i don't have a clue how
to calculate the offset. I asked the Duck, but got only topics where you must know already assembler to understand it.

[McPrapor]

I thought 2.10.36 is available again, but looks like it's just the hack makes it believe it's running 2.10.36.

[guino]

@jonesMeUp there's not a lot to it:

READ data from any address (into r3):

ldr r0,[0xPOINTER_ADDRESS]
ldr r3,[r0,#0x0]

WRITE data to any address (from r3):

ldr r0,[0xPOINTER_ADDRESS]
str r3,[r0,#0x0]

In both cases POINTER_ADDRESS will be an address containing the address to read/write, so if you wanted to read/write to 0x434d1c you would have to place the bytes 1c 4d 43 00 somewhere (near the code) and call that 'somewhere' POINTER_ADDRESS. You could even take out part of a string to write those bytes. In my example above #42 (comment) I used 0x9c548 because it was already storing some address used by code I overwrote. There's no 'offset calculation' required for this method, just requires the 8 bytes (for the 2 instructions) + 4 bytes to store the absolute address to read/write (but has to be near the code).

So you'll need to copy all the bytes from the loop code to 0x065bc8 (assuming you have space) then you'll need some other 4 bytes (near that code) to put the address bytes 1c 4d 43 00. It could look like this:

LOOP:   01 00 a0 e3     mov        r0,#0x1
        18 de fe eb     bl         <EXTERNAL>::sleep
        a0 30 9f e5     ldr        r3,[POINTER_ADDRESS]
        00 30 93 e5     ldr        r3,[r3,#0x0]
        01 00 53 e3     cmp        r3,#0x1
        f8 ff ff 1a     bne        LOOP
        ?? ?? ?? ea     b          EXIT_LOOP
POINTER_ADDRESS:
        1c 4d 43 00
EXIT_LOOP:
       <existing code>

(notice the 'missing' add instruction since I'm using absolute address defined in the POINTER_ADDRESS memory location)

You also have the option to use a few more instructions to build the address directly:

LOOP:   01 00 a0 e3     mov    r0,#0x1
        18 de fe eb     bl     <EXTERNAL>::sleep
        1c 30 a0 e3     mov    r3,#0x1c
        4d 3c 83 e3     orr    r3,r3,#0x4d00
        43 38 83 e3     orr    r3,r3,#0x430000
        00 30 13 e5     ldr    r3,[r3,#0x0]
        01 00 53 e3     cmp    r3,#0x1
        f9 ff ff 1a     bne    LOOP

Either one should work as long as you have enough space -- chances are whatever code you're overwriting/deleting (to put your code in place) already uses some address nearby that you can use for a pointer_address making it simpler to write without adding jumps or multiple instructions (seems like 0x65ca8 is the perfect POINTER_ADDRESS for you).

[guino]

I thought 2.10.36 is available again, but looks like it's just the hack makes it believe it's running 2.10.36.

Yes, the hack uses a main application 2.10.36 so it reports that version to the server. I never did look into changing that since it works fine, but it could prevent us from knowing when a 2.10.36 is actually available for that device. Chances are it may come out as a different version than 2.10.36 anyway.

[jonesMeUp]

@guino i used your build the address directly version for my testings, worked well. I also added much nop instructions for you to give us more nice functions ;)
Still no success on localtime, but added current lumi: x to the event loop. I want to use the camera to switch on a light when its dark on movement event. Currently i use a Sun_RiseSet_Timer calculation for this, but its not very accurate.
I hope to find more time for my testings, now that the holidays are nearly over.

[jonesMeUp]

date and hwclock now shows the correct date/time, so no more 1970 as root of the streaming folder.
But the video-stream still differs 1h. I will spend some more time on it, but if it tooks to much time - i will give up and live with it.

I will post my actual hack.sh and the patch file as soon as the 1h problem is fixed (or if i get lost in the fix).

[guino]

@jonesMeUp Nice to hear you've made progress. I recommend you try a normal boot (i.e. no SD card) to verify the video time is correct -- if it's off by 1h without the SD card then the issue isn't related to your changes (likely just some other setting).

[jonesMeUp]

@guino of course the problem is related to the offline patch. There are many functions that are only called when the device is online.
To get the date fixed for the streaming folder i had to rewrite the IPC_APP_Sync_Utc_Time() funtion (which didn't make any sense in the offline version).
The timestamp was coming from tuya server as a json string, now dd writes the timestamp into the new funtion after the time was synced.

I have already seen a possible location for the 1h problem:

[01-10 04:55:36-- TUYA Debug][gw_intf.c:4405] timezone:+01:00

The lines of the logfile are crying in my head, so i have to spend some time there.

[jonesMeUp]

@guino after searching for endless hours in the code, without any success, i think they are cheating.
Can you please check if date and hwclock differ, on your online cam, also to the vlc time display?

[guino]

@jonesMeUp sorry it's been a busy few days here.

This is my doorbell (2.9.6 fw):

~ # date
Tue Jan 17 14:24:31 CST 2023
~ # hwclock
-sh: hwclock: not found
~ # /mnt/mmc01/busybox hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
~ # ls -la /etc/TZ
-rwxr-xr-x    1 wagner   root            12 Jan 17 02:07 /etc/TZ
~ # cat /etc/TZ
CST05:00:00

This is my indoor dumb camera (2.7.6 fw):

~ # date
Tue Jan 17 14:26:38 CST 2023
~ # hwclock
-sh: hwclock: not found
~ # /mnt/mmc01/busybox hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
~ # ls -la /etc/TZ
-rwxr-xr-x    1 wagner   root            12 Jan 17 01:04 /etc/TZ
~ # cat /etc/TZ
CST05:00:00

This is my rotating camera (2.10.36):

~ # date
Tue Jan 17 09:29:56 GMT 2023
~ # hwclock
Tue Jan 17 09:29:57 2023  0.000000 seconds
~ # ls -la /etc/TZ 
lrwxrwxrwx    1 1000     1000             7 Aug 24  2021 /etc/TZ -> /tmp/TZ
~ # ls -la /tmp/TZ
-rw-rw-rw-    1 root     root            10 Jan 17 09:27 /tmp/TZ
~ # cat /tmp/TZ
GMT+05:00

My local time was 14:24-29 when testing the above -- please notice I am on Eastern US timezone (despite it showing CST), but all my devices show the correct time on the video.

[jonesMeUp]

@guino so i searched many hours in my patches, but the gmt/date/hwclock "glitch" was in the original app already.
After you confirmed my suspicion, i updated my post to my actual version, showing the correct time only in OSD (like the original version). #42 (comment)

[usernamepaul]

Cyberduck
ftp
Server (192.168.xxx.xx)
port 21
user: root
pass:telnet

[der3b]

I will use the above information to leverage our options if it works on 2.10.36 and/or newer.

Hello Guino, works on fw 3.167.94.14. just got telnet access:
[root@anyka /usr/share]$ cat VERSION
3.167.94.14
[root@anyka /usr/share]$ cat BUNDLE
HT_IPC167KM_TUYA_AK3918EV330