Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Root without SD card (V2.10.45 and possibly others) #19

Open
isotherm opened this issue Jul 23, 2024 · 7 comments
Open

Root without SD card (V2.10.45 and possibly others) #19

isotherm opened this issue Jul 23, 2024 · 7 comments

Comments

@isotherm
Copy link

isotherm commented Jul 23, 2024

I have been working on this, trying to get root shell and possibly RTSP without permanently needing SD card.

Please note that I have firmware V2.10.45, but looking at the squashfs, it seems very similar to V2.10.30. I think the below might still work, modifying wifi_driver.sh instead of wifi_driver_new.sh.

Here's what I have so far:

  1. Follow instructions at LSC Smart Outdoor (IP) Camera - Hack not working Merkury1080P#42 (comment) to get a root shell.
  2. Log in to the camera via telnet.
  3. vi /etc/config/passwd and change the x between the colons to 20zVXVMtkhCxI. (This password is telnet. To do something else, run mkpasswd -m des, enter your desired password, and use that output instead.)
  4. vi /etc/config/wifi_driver_new.sh and add these two lines at the top of the driver_install() function, so it's like this:
    driver_install()                     
    {                                                                  
        tcpsvd 0 21 ftpd -w / -t 1800 &
        telnetd
        wifi_stop
    
  5. Upon rebooting even without the SD card, telnet and FTP are available.

I'm working on RTSP next.

@isotherm isotherm changed the title V2.10.45 Root without SD card (V2.10.45 and possibly others) Jul 23, 2024
@guino
Copy link
Owner

guino commented Jul 23, 2024

@isotherm this is cool. With RTSP the issue is that I had to write out a whole new function into the main application, and I only did that to the specific version I posted.
In theory it should be possible to do it with other versions of the main application, but it is just easier/faster to use the version I already patched.

In theory it is also possible to write a script/tool that loads the main application to memory, patches it, then executes it (so you can fit everything in the config partition), but again that requires a lot of extra time.

You could potentially just download the patched main application from somewhere on the network, but either you need to use the ram (which is limited), flash (which doesn't have enough space) or some network mount (which may be limited by kernel), so using the SD card is the simplest/easiest way to do it.

I understand the benefit of not needing SD cards (believe me I prefer that as well), but I also see the benefit in being able to just remove the SD card and running the device in 'stock' mode.

@isotherm
Copy link
Author

isotherm commented Jul 25, 2024

Thank you for this explanation. While experimenting, I did have a case of the device no longer connecting to wireless. Without UART, I had to build an update.tar to reflash the /etc/config partition to a known state. If modifying anything in that script on the config partition, adding a failsafe to uninstall the hack (e.g. if a certain file exists on SD card) would be a good idea.

The following works to enable RTSP server via SD card without patching, and also avoid connecting to Tuya cloud at all:

  1. On SD card, make empty file named _ht_ap_mode.conf.
  2. On SD card, make file named hostapd with the following contents:
    #!/bin/sh
    killall udhcpd
    ifconfig wlan0 up
    /usr/bin/wpa_supplicant -Dwext -i wlan0 -c /mnt/wpa_supplicant.conf -B
    /sbin/udhcpc -i wlan0 -t 10 -A 5 -q &
    grep -q "root:x:" /etc/config/passwd && sed -i "s/root:x:/root:20zVXVMtkhCxI:/" /etc/config/passwd
    
    (If you want a different root password than telnet, run mkpasswd -m des, enter your desired password, and use that output instead between the colons in the last line.)
  3. On SD card, make file named wpa_supplicant.conf with the following contents (adjusted for local network):
    network={
         ssid="SSID"
         psk="PASSWORD"
    }
    
  4. Reboot. Only open ports are 23 (telnet) and 554 (rtsp).

This could also be implemented, as above, to work without any SD card. The advantage is either not to need SD card at all, or not to worry about the hack being erased when the recorded video rolls over.

I'm still working on things like two way audio and the notifications. Also, I need to make sure wireless reconnects properly if the connection is lost.

@Marco15453
Copy link

Is there any update here?

@isotherm
Copy link
Author

Straight one-way RTSP works when following the instructions given at this comment.

In theory it's possible to run a process on the camera to record by receiving its own RTSP feed. I tried this and it seemed to work ok, but I figured I would just record on a computer/server that's receiving the feed.

I have everything in IDA and know where the functions are that need modifying, so if @guino could share what modifications he needed to make and what new function had to be made, then I could make those changes to this binary also.

@Marco15453
Copy link

Is it possible to still allow the camera to still connect to the cloud?

@isotherm
Copy link
Author

Is it possible to still allow the camera to still connect to the cloud?

If you only want root, the instructions in the first post should work. If you will keep the SD card in the camera, you can skip steps 4 and 5, though I suppose the files might get erased when the card fills up and it starts deleting old videos/files.

@guino
Copy link
Owner

guino commented Nov 20, 2024

I have everything in IDA and know where the functions are that need modifying, so if @guino could share what modifications he needed to make and what new function had to be made, then I could make those changes to this binary also.

I wouldn't remember the changes myself by now. I do remember having to write a new function from scratch to get RTSP working -- the easiest way to find out what changed is to look at the patch file: https://github.com/guino/LSCOutdoor1080P/raw/refs/heads/main/anyka_ipc_rtsp.zip -- this just has the addresses and bytes changed from the original file. What I can suggest (and what I would be doing) is: 1-Download the original anyka_ipc file from Option 3, make a backup, apply the patch, then look look at the decompiled code (on the addresses in the patch), comparing with the decompiled original code (backup file).

I would give you 'source code' if I had anything but I wrote the changes (ARM assembly) in Ghidra command by command and tested until it worked, so the only thing I have is the manually patched anyka_ipc file -- which is the same exact thing you get when you apply the patch to the original anyka_ipc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants