thirtythreeforty / neolink

An RTSP bridge to Reolink IP cameras
https://www.thirtythreeforty.net/posts/2020/05/hacking-reolink-cameras-for-fun-and-profit/
GNU Affero General Public License v3.0
890 stars 149 forks source link

Argus 2 and other battery camera #91

Open surfzoid opened 3 years ago

surfzoid commented 3 years ago

Hi I would like to find an solution to watch the video of my reolink argus 2 camera under linux, wath i know is , those came use only an uid , send to an amazon p2p server whose send back video and info to the oficialy reolink windows or android client. Can you implement an function of connect with only uid ? If needed, i can provide an wireshark file packet . thank

Lanwalker commented 3 years ago

Thank you for that information. Yes, security from packet capture can be a serious problem and our networks need to be aware of it.

Do the battery powered units have the ability to use https ? I thought browsers were not supported on those ( possibly for that reason )...

I have actually debugged access database issues across the WAN with packet capture years ago... somebody moved a database on a Dearborn server but many users and routines were still trying to use them and when they hit those routines, their forms either hung up or gave an error but for some reason ( possibly database security or Novell network issues ), it didn't really give the correct reason.

Lanwalker commented 3 years ago

Thank you. Troubleshooting network connectivity issues as we brought different technology into our international automotive assembly locations ( Vax, Novell, HPUX, WinNT, mainframe, printer servers, video information systems,... etc ) is how I was pulled from building and or assisting many of our test and control programming projects... too much time needed invested tracking those issues down for me to dedicate some of my time helping out our new system designers and maintenance groups. I sure miss those challenges... damn this physical disability crap and the companies that infringe on us by keeping us out of the job markets for that reason but will not admit to it.

Lanwalker commented 3 years ago

I am not sure who wanted updates on this but Reolink support finally replied.

Dear Robert Gamble, Thank you very much for your reply. In that case, you cannot access the cameras via UID if there is no internet access. You can only access the cameras via IP address, instead of UID. Anything we can help you, please do not hesitate to keep us informed. Have a nice day! Best Regards Reolink Support Team – Ivy

QuantumEntangledAndy commented 3 years ago

I think their reply is technically incorrect because you can do discovery using the uuid on the local net to learn the IP with broadcasts. It's what jdillenkofer does in his program. My I ask what you wrote to them? It would help with the context of their reply. But I suppose I shouldn't be surprised with this sort of answer

twistedddx commented 3 years ago

I would not regard UID as something you can connect to. UID is simply used as a method for a client to automatically learn the IP path to the device.

The UID function has a different method of informing a client the IP path if the client is local or remote to the device.

UID exists in OSI layer 5 and 7. I would consider you connect to things in Layer 1, 2 or 3. Layers 4 or higher no longer connect devices, they manage data and offer functions.

Lanwalker commented 3 years ago

This is the scenario I gave them... loss of internet connectivity ( just like if the wire is cut, power outages, etc.. ). We had to have multiple routes for communications ( in case ) for our systems backup when dealing with our automotive customers ( Ford, Honda, Toyota, etc ) with the use of internal and external servers and databases as our systems matured in the automotive industry. I had to install modems and 800 numbers as a possibility could shut down our production and our clients production ( and Ford charged us about a million a day if we shut them down )

Sally,      Thank you. We are trying to work on local applications inside a LAN with no internet access to the outside world and wondering how these will work in that environment ? Can our computers still access these cameras thru our isolated local area network ? This is a security concern since there will not be any routers connecting to a path for the cameras to reach outside and the clients ( cell phones and PCs ) will be trying to watch the cameras from our isolated LAN.

twistedddx commented 3 years ago

"will be trying to watch the cameras from our isolated LAN." The Reolink support agent answered wrongly. The UID method of informing a local client of the devices IP would continue without internet access. That method for local devices is via broadcast discovery and has no dependency on the internet.

Lanwalker commented 3 years ago

Thank you.

See, this is the type of information you have to dig out of people. When I leave Florida for my doctors in Ohio, I want the cameras watching this place and I'll be remote for possibly 2 months ( or longer.. last trip was an unplanned 14 months due to vehicles and the Chinese Virus crap ) at times. My neighbor has access to my additional WiFi router and can access my network if my AT&T router stops working for some reason ( or his ). I want him to be able to watch over the place while I am gone too ( he can use the cameras to watch his back entrances ). I use TeamViewer for remote control of my network(s) either here in Florida or at my girlfriend's Ohio location ( where I am going to install the next batch of cameras when I return this spring )... a neighbor in Ohio also has access to my additional WiFi router so they can do things up there also and may even get a few of these cameras for their place as another viewpoint.

I am one of a very few national admins for the United States Minutemen ( we used to have a structure on facebook with nearly 4000 groups and pages that was destroyed on August 19, 2020 at about 4:30 PM EST... it took me and a few others about 7 months to create that in 2011-2012 and with no previous notification, FB destroyed all of our data that was not backed up to our private web server we used as a common point for all the groups and pages ) so I have a lot of friends and members looking for security solutions right now with all the destruction and violence going on. We now have spread our internet presence among a lot of the alternate social media sites to prevent that total destruction of our structure(s) in the future ( We call MeWe.com our 'new' home.

I am physically disabled ( got smashed by a drunk in a F150 4x4 ( 45 mph ) from the left side while coming home from work on my motorcycle ( 25 mph ) ), 82nd Airborne Artillery ( 1977 ), Test and Control Systems Engineer / IT Analyst now on Social Security Disability because no company would hire me after our company sold out and the buying company sold our assembly lines to Mexico, South Korea and China... so this is what I do as support for the US Minutemen since I can not physically do much else for our country in my condition. I am now trying to get back into the programming I used to do ( along with everything else in my free time ) so I can implement these cameras into our systems as well. We have members in RVs, out in the deep boondocks and many other places so I get asked questions and I hunt the answers down and hopefully solutions as I can... and some just can not be resolved with canned software like the Reolink clients used with these cameras. ( the reason I am reviewing all these different conversations on Github and other places ) as I pull my software development system(s) together.

http://iii.thruhere.net/Social-Media-Sites/united_states_minutemen.html

twistedddx commented 3 years ago

Wireshark is good for showing the layers. layers

Lanwalker commented 3 years ago

I had the Novell version called Lanalyzer and often told our corporate network management where some of our network problems were... even debugged a stupid access database with an excell part and found out somebody had moved one of the linked databases and had not updated the remote plant clients setup... our Dearborn offices tried but many did not even know what you were talking about. When Lear bought that place and tied their WindowsNT network in thru our routers their broadcast storms of print servers they placed across that link about killed our network and I went and pulled the damn cord from the router until they fixed it since they wouldn't give me access to it to fix it myself.

surfzoid commented 3 years ago

Wireshark is good for showing the layers. layers

For Light think i use Sometime the gnome network analyser https://etherape.sourceforge.io/

cyberjom commented 3 years ago

To grab video or frame from Reolink battery camera is my wish. If contributor need argust2 or some other model I am willing to send him.

surfzoid commented 3 years ago

Hi, here it s some info i found on the net : an unluky windows dll https://www.wasteofcash.com/BCConvert/ an good description of the BC protocol https://www.wasteofcash.com/BCConvert/BC_fileformat.txt there is an generic android client for all BC camera : steamview : https://wasteofcash.com/BCConvert/Downloadlinks.html and more an question, is ispy can acces on our cam ? : https://www.ispyconnect.com/download.aspx

twistedddx commented 3 years ago

Hi, here it s some info i found on the net : an unluky windows dll https://www.wasteofcash.com/BCConvert/ an good description of the BC protocol https://www.wasteofcash.com/BCConvert/BC_fileformat.txt there is an generic android client for all BC camera : steamview : https://wasteofcash.com/BCConvert/Downloadlinks.html and more an question, is ispy can acces on our cam ? : https://www.ispyconnect.com/download.aspx

wasteofcash is my website and Neolinks active developers are well aware of the content I have written.

surfzoid commented 3 years ago

Hi, here it s some info i found on the net : an unluky windows dll https://www.wasteofcash.com/BCConvert/ an good description of the BC protocol https://www.wasteofcash.com/BCConvert/BC_fileformat.txt there is an generic android client for all BC camera : steamview : https://wasteofcash.com/BCConvert/Downloadlinks.html and more an question, is ispy can acces on our cam ? : https://www.ispyconnect.com/download.aspx

wasteofcash is my website and Neolinks active developers are well aware of the content I have written.

haha i made an good joke then :-)

QuantumEntangledAndy commented 3 years ago

Definitely well aware of it :) Thank you for all your good work @twistedddx !!

From the logs on ispy it seems it cannot access BC camera directly, it works on generic rtsp cameras and ONVIF, so it should work if neolink does the translation for it as the middle man. Personally though I prefer to setup mine with something like homeassistant or zoneminder or some other nice and free and open source software to manage the cameras.

thirtythreeforty commented 3 years ago

@QuantumEntangledAndy and/or @twistedddx: are y'all interested in trying development for Argus? If so would you like for me to set up my Argus on a VLAN and get you access to it? (You can have a VM on the network too)

surfzoid commented 3 years ago

@QuantumEntangledAndy and/or @twistedddx: are y'all interested in trying development for Argus? If so would you like for me to set up my Argus on a VLAN and get you access to it? (You can have a VM on the network too)

idea is good, but vlan will block broadcast.

thirtythreeforty commented 3 years ago

@surfzoid how do you mean? Neither the VM nor camera will be aware they're on a VLAN. (They can have internet access.)

surfzoid commented 3 years ago

@QuantumEntangledAndy and @twistedddx i trying the folowing very interesting basic test : first get the two soft here : https://medium.com/level-up-programming/how-to-reverse-engineering-an-android-app-be5835f6fa1e and test them on this apk (the oldest i found) : https://apkpure.com/reolink/com.mcu.reolink/download/217-APK?from=versions%2Fversion We can see BC work, P2P ect :-)

surfzoid commented 3 years ago

@surfzoid how do you mean? Neither the VM nor camera will be aware they're on a VLAN. (They can have internet access.)

i spent lot of hours to have argus 2 and jdillenkofer prog work through vlan (vpn) because the cam conect with broadcast and random port but why not

surfzoid commented 3 years ago

More simply, don't you have icq, discord or other chanel where to discuss?

mplogas commented 3 years ago

@QuantumEntangledAndy and @twistedddx i trying the folowing very interesting basic test : first get the two soft here : medium.com/level-up-programming/how-to-reverse-engineering-an-android-app-be5835f6fa1e and test them on this apk (the oldest i found) : apkpure.com/reolink/com.mcu.reolink/download/217-APK?from=versions%2Fversion We can see BC work, P2P ect :-)

I have disassembled their app multiple times but apart from poking around in their aws buckets and finding the endpoints i wasn't able to do much. point is, you can't just hijack the endpoints, something else seems to be missing.

//edit: what i mean by that is they're doing lots of JNI stuff. So unless someone can decompile .so files the app isn't really any help. Same goes for the desktop app btw.

thirtythreeforty commented 3 years ago

If you tell me exactly what you're looking for, I have decompiled their .so's before 😎. A spelunking adventure of "how does it work?" is probably too broad, but "I can't figure out how they're validating the endpoint" might be feasible to answer.

thirtythreeforty commented 3 years ago

More simply, don't you have icq, discord or other chanel where to discuss?

We could make a Discord if everyone agrees it would be better, but I don't want to split the discussion between GitHub and Discord - empirically, GitHub is working pretty well so far. It's difficult for users to find info if you spread it out in too many platforms. I like the fact that GitHub discussions are easily searched by anyone.

mplogas commented 3 years ago

The android.bc.api namespace sets up callback and commands. I assume the libBCP2P_API.so is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would be libIOTCAPIs.so libRDTAPIs.so and libp2pc.so

Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)

surfzoid commented 3 years ago

More simply, don't you have icq, discord or other chanel where to discuss?

We could make a Discord if everyone agrees it would be better, but I don't want to split the discussion between GitHub and Discord - empirically, GitHub is working pretty well so far. It's difficult for users to find info if you spread it out in too many platforms. I like the fact that GitHub discussions are easily searched by anyone.

yes your are right, i don't really no if in hacking and reverse everything can be public :-)

surfzoid commented 3 years ago

The android.bc.api namespace sets up callback and commands. I assume the libBCP2P_API.so is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would be libIOTCAPIs.so libRDTAPIs.so and libp2pc.so

Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)

i like .so file, i'm linux user and really would like to have an linux reolink client also, a way to handle motion detection and save video on pc rather reolink cloud :-)

mplogas commented 3 years ago

The android.bc.api namespace sets up callback and commands. I assume the libBCP2P_API.so is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would be libIOTCAPIs.so libRDTAPIs.so and libp2pc.so Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)

i like .so file, i'm linux user and really would like to have an linux reolink client also, a way to handle motion detection and save video on pc rather reolink cloud :-)

well unless your linux is running on an armeabi/arm64-v8 device you won't be very happy with the .so files ;)

surfzoid commented 3 years ago

yes, need to recompil source of course

QuantumEntangledAndy commented 3 years ago

Vlan for the camera sounds fun to play with.

With regards to getting broadcasts to work it's not about the internet access that's important but the type of adapter. I belive the tap adapter supports multicasts but the tun adapter does not (possibly the other way round but it definitely works on one and not the other as I've had to use broadcasts over VPN in a previous project)

thirtythreeforty commented 3 years ago

Yup, you'd need layer 2 bridging to make everything truly seamless. I'm using ZeroTier as the "virtual Ethernet" tap adapter. I'll shoot you an email with the details.

surfzoid commented 3 years ago

Yup, you'd need layer 2 bridging to make everything truly seamless. I'm using ZeroTier as the "virtual Ethernet" tap adapter. I'll shoot you an email with the details.

I'm interested by this détails because i switched ftom open vpn routed to bridge and broadcast don't work

QuantumEntangledAndy commented 3 years ago

I belive for broadcasts to work on openvpn all participants need to be using the tap interface. Is this the case? You'll probably also need things like client-to-client turned on as well but I don't have a setup to test this.

surfzoid commented 3 years ago

I belive for broadcasts to work on openvpn all participants need to be using the tap interface. Is this the case? You'll probably also need things like client-to-client turned on as well but I don't have a setup to test this.

yes i did, i don't have lot of option on server side, because, openvpn is component of my isp box (french freebox one)

twistedddx commented 3 years ago

I thought the idea was a VM and camera within the same VLAN. There is no VPN between the VM and camera from what I read.

Connection method for access to the VM were not given yet but assuming ssh access to Linux or Team Viewer to Windows or VPN or whatever. The VM will see a broadcast, the connection to the VM will not prevent extracting dumps of broadcasts etc.

I don't think broadcasts will even play any significant role in getting an Argus to connect locally. jdillenkofer already did the hardwork in adapting Neolinks code to support BC UDP protocol, Neolink needs a port of jdillenkofer's code. The access to an Argus will be great for testing that the ported code actually works correctly.

PS. I am not the man for the job of writing Neolink code relating to Argus.

QuantumEntangledAndy commented 3 years ago

Yes I think that's our setup too SSH in or maybe SSH + VPN (mostly for the NAT transversal if done this way) and then play.. I mean reverse engineer... from the VM. I'm not sure if UDP uses a fixed port though maybe the UDP discovery will be nessecary to get the ports. Will need investigating.

surfzoid commented 3 years ago

Yes I think that's our setup too SSH in or maybe SSH + VPN (mostly for the NAT transversal if done this way) and then play.. I mean reverse engineer... from the VM. I'm not sure if UDP uses a fixed port though maybe the UDP discovery will be nessecary to get the ports. Will need investigating.

for the argus 2, the udp port is random

surfzoid commented 3 years ago

soudnlike to save battery life, the cam canot be pinged, have no port open, but, when i'm conect to it with the jd prog, the cam become pingable, so is, the udp broadcast the only way to wake up the cam ?

thirtythreeforty commented 3 years ago

More simply, don't you have icq, discord or other chanel where to discuss?

We could make a Discord if everyone agrees it would be better, but I don't want to split the discussion between GitHub and Discord - empirically, GitHub is working pretty well so far. It's difficult for users to find info if you spread it out in too many platforms. I like the fact that GitHub discussions are easily searched by anyone.

re: chat, GitHub just launched a new feature called Discussions that might be more in line with this. I think I'll start to direct support requests over to Discussions. Features and bug reports (such as this ticket) can remain Issues.

surfzoid commented 3 years ago

Very Nice idea @thirtythreeforty, i would be glade to be include in the Discussions.

mplogas commented 3 years ago

The android.bc.api namespace sets up callback and commands. I assume the libBCP2P_API.so is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would be libIOTCAPIs.so libRDTAPIs.so and libp2pc.so

Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)

@thirtythreeforty please let me know if you think it's worth pursuing the reverse engineering approach and need the binaries and/or the decompiled android code. Unfortunately I don't have the tools/licenses to decompile ARM-based .so binaries, so I would need your help here to proceed further.

thirtythreeforty commented 3 years ago

Appreciate the offer - you can shoot me an email: thirtythreeforty@gmail.com.

I don't think we have a hard requirement on them, since jdillenkofer's tool is able to establish comms. But it would definitely be a good thing to have if you've already done some work.

twistedddx commented 3 years ago

I think how local connection works is known but I believe some Argus users are keen for remote connection. The VPN issue mentioned I think is a concern they will not be able to wake their device remotely via some VPN due to lack of broadcasts.

Reolink connection with UID via AWS servers is not known.

There is 2 distinct feature requests. Only the first is actively being worked on. The second still requires a willing dev to take on reverse engineering and implementation. 1)Local network support of devices that use BC UDP such as Argus - jdillenkofer has working code already 2)Remote network support via Reolink UID/AWS system - I don't believe much work has occurred.

thirtythreeforty commented 3 years ago

There is 2 distinct feature requests. Only the first is actively being worked on. The second still requires a willing dev to take on reverse engineering and implementation.

  1. Local network support of devices that use BC UDP such as Argus - jdillenkofer has working code already
  2. Remote network support via Reolink UID/AWS system - I don't believe much work has occurred.

Great point. I had not really considered (2) because from my point of view the phone-home stuff is an antifeature that I firewall off. But I can see how some people might like it.

We'd have to be really careful with such an implementation. While Reolink would hardly care if users are streaming via their LAN, if Neolink were to start using their cloud, they might very much care about increased load, since Argus cams typically do not stream 24/7. How does this get reconciled with RTSP clients/NVRs that do expect to stream 24/7?

To summarize - I'm completely game for (1). (2) we will have to approach carefully, with a clear description of how it ought to work. At any rate, (1) is a prerequisite of (2).

thirtythreeforty commented 3 years ago

In fact, the impedance mismatch of Argus cams' periodic streaming with NVRs' expectations of 24/7 streaming will need to be solved for LAN-only traffic, or else Neolink will drain cameras' batteries pretty quickly. So I think it would be good to discuss how that ought to work.

Lanwalker commented 3 years ago

The new Reolink E1 Pro firmware update now has the cameras using ' wlan0 ' as their preferred names in the ROUTER... every one of them has the same ' name ' appended to their address in my AT&T ROUTER... the Argus units at least append their MAC address so every one of them are a different name in the DNS generated when the DHCP assigns the IP address to the cameras DHCP client. I just sent that piece of information to REOLINK SUPPORT.

I had a Reolink E1 Pro I bought from the Reolink site that would not eject the MicroSD card and had to return it... I purchased 2 other E1 Pro cameras from Amazon since the Amazon price was lower at the time.

The 2 cameras from Amazon showed the same name ( Wlan0 ) in the DHCP of my router but the camera from Reolink showed ( E1 ) appended to the address. Pinging the ' name ' ( Wlan0 ) would return one address the first time and the 2nd address the next time I pinged them... ( I noticed this because somebody was talking about using the DNS names of the cameras and this would cause confusion with the names being the same in the local DNS table of the ROUTER.

When I received the replacement E1 Pro camera from Reolink it must have had the older firmware revision and showed ( E1 ) appended. AFTER UPGRADING THE FIRMWARE, all 3 cameras now show ( Wlan0 ) and pinging the name ( Wlan0 ) gives me the different addresses ( and how the ROUTER selects which local IP address to use is unknown but it did not repeat the address but used the next ( Wlan0 ) in the ROUTER DHCP table ?? )

Most devices append their MAC to the preferred name the DHCP client acquires and helps identify the device for troubleshooting and also keeps it as a unique identifier in the local DNS system. I am not sure if the local ROUTER sends the local DNS names when the router tables are updated but this would cause some confusion since 3 devices on the local LAN DNS would have the same name if we only used their DNS NAMES in addressing them.

Just some interesting facts I found out in the last few days trying to figure out why the ' new ' E1 Pro camera quit responding to the network ( but still recorded to the local MicroSD memory card after pulling it and looking at the dates and times of the file names ) and Reolink support telling me to check the latest firmware and I updated the camera to the latest firmware on their site.

To the members 'testing ' the application and collecting network traffic... try isolating the Argus battery powered cameras on their own WiFi router with a workstation running Wireshark as the cameras are powered up. That may be a way of isolating the process used by the UID for those cameras. I'm not sure what you will see but at least you should have some fairly isolated traffic to sort thru. All the cameras have an IP address assigned to them, even with the UID being used for remote access thru the Amazon servers.

Too bad we can not get some cooperation from Reolink Support for the software routines of the newer battery powered cameras ( Yet )... I've asked and get the run-around and an older PDF file about accessing the older cameras thru IP.

Lanwalker commented 3 years ago

Parts of the Argus cameras electronics must ' stay alive ' for motion detection and network responses... maybe some type of network request / query for a camera status would not drain the batteries too much ??

Reolink seems to have gutted some of the code compared to their other camera systems... just like the recent ' updated clients ' for the PCs and the Android phones took the ' zoom / magnify ' function from them ( and put in a stupid ' clip ' that MAGNIFIES an area in the picture ).

Lanwalker commented 3 years ago

I quit using the Reolink ' cloud ' due to costs and limitations of 1 camera free ( for a month trial period )... I have 2 outside Argus battery powered cameras ( on stationary, the other a PT unit ) and 3 inside E1 Pro units. I am on a fixed income ( SSD if you want to call below survival as any type of income )

thirtythreeforty commented 3 years ago

@Lanwalker you say:

trying to figure out why the ' new ' E1 Pro camera quit responding to the network ( but still recorded to the local MicroSD memory card after pulling it and looking at the dates and times of the file names ) and Reolink support telling me to check the latest firmware and I updated the camera to the latest firmware on their site.

Did updating the firmware improve its behavior on the network?