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
878 stars 143 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

twistedddx commented 3 years ago

Duplicate of #30

QuantumEntangledAndy commented 3 years ago

To summarise #30. Battery cameras use a different protocol (UDP) Which we do not currently support. Not because we can't do it but because none of the developers had a camera to reverse engineer. Someone has kindly sent @thirtythreeforty a camera so we can start work on it. Unfortunately we have yet to really have the time :(.

Lanwalker commented 3 years ago

Not sure where you got that info but my Reolink Argus Pro and Argus PT can be pinged on my local net. I can see they received a local network address from the DHCP of my router.

On Sunday, November 22, 2020, 3:45:32 PM EST, surfzoid <notifications@github.com> wrote:  

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

QuantumEntangledAndy commented 3 years ago

Lanwalker is quite right that there must be an ip address else messages will not be route-able in general.

I suspect surfzoid attached his client app via autoconnect, in which case the app only reports the uuid (from the front screen, see pic).

Screenshot 2020-11-23 at 13 13 28

However the ip is still assigned and viewable in the advance setting of the app (see other pic).

Screenshot 2020-11-23 at 13 13 43-masked

What I am not sure about is how the command and control works on the battery model. For example does it shutdown the network card periodically and only wake up to poll the amazon server for updates that have been cached into their server. Perhaps you (lanwalker) can tell me if you can connect a client over ip only maybe even with the camera blocked from accessing the outside network.

surfzoid commented 3 years ago

Hi, if i remember corectly, to connect my first argus 2 i used the sharing wifi of my Phone and then scan the qr code on the Cam with the Android app, but this is only setup for link app and cam, after Wath, the stream use the amazon p2p streaming server, aws

surfzoid commented 3 years ago

For me that's logical the fact of the Cam have ip, this need to have internet conection and send mail notification, but the main goal is video stream. If there is french People here, can we exchange technical info ? It should be more accurate

surfzoid commented 3 years ago

it isn't more easy to reverse the android application/apk?

QuantumEntangledAndy commented 3 years ago

At this point I am not sure reverse engineering the the android application will be any easier. We already have most of the protocol understood.

Regardless only one developer has a battery camera at the moment and they are busy at the moment with other things. If you are interested in helping with the addition of UDP based cameras pull requests and just general discussions are more than welcome. You said you could give us wireshark dumps? If you can connect an official client and give us the dumps during login and streaming that would be good. But please remember that these dumps contains password and things.

surfzoid commented 3 years ago

oki, so i could send the dump packet file to thirtythreeforty in private

QuantumEntangledAndy commented 3 years ago

If you want to not send passwords and make the dump public the best way would be to start the dump after the client has logged in and don't press any of the setting just stream and quit

QuantumEntangledAndy commented 3 years ago

I think we already have a few dumps provided in #30 anyway though so this is more to do with not enough time at the moment

surfzoid commented 3 years ago

yes the most important packet is the authenticate one, to get amazon acces, i also can set an tempory stupid passwaord, but there is already uuid who is the most important part when conecting to the aws author server https://support.reolink.com/hc/en-us/articles/360007010033-What-is-Reolink-P2P-Server

QuantumEntangledAndy commented 3 years ago

Do we have to connect to the aws server is there no way to connect directly over lan

surfzoid commented 3 years ago

Do we have to connect to the aws server is there no way to connect directly over lan

yep, my usage is cam at work and view at home, with an linux rpm based distro, mageia, so, no reolink client, after, argus2 don't permit to save video in an loacal pc via samba, ftp or other, reolink cloud don't aviable in europe (reolink don't care about the fact they say argus 2 as an security cam but not in fact)

in issue #30 jdillenkofer say is had sucess to view localy the camera

QuantumEntangledAndy commented 3 years ago

Right neolink works by exposing a camera on the local network to rtsp. It is effectively a reolink to rtsp translator. If you can connect to the camera locally at work then neolink can provide an rtsp link to it. You can then connect through normal rtsp client software. Does this setup satisfy your needs?

surfzoid commented 3 years ago

well if am i rigth, at this time, neolink don't work with argus 2 camera?

twistedddx commented 3 years ago

It appears jdillenkofer already has UDP BC cameras working. Under the UDP layer it just looks like standard BC modern protocol.

This python code would need to be re-implemented in Rust in Neolink. https://github.com/jdillenkofer/camera_proxy/blob/master/src/baichuan_udp_layer.py

QuantumEntangledAndy commented 3 years ago

Not at the moment no. I am looking over the dumps now actually:

Normal header for tcp is starts with f0 de bc 0a The udp one start like this:

10 cf 87 2a b0 02
00 00 00 00 00 00 00 00 00 00 32 05 00 00 f0 de
bc 0a 01 00 00 00 2c 07 00 00 00 00 00 01 01 dc

You can see the normal magic f0 de bc 0a start a little later. Currently we haven't worked out what these extra bytes do but it is on the todo list.

twistedddx commented 3 years ago

jdillenkofer also modified the dissector for UDP use: https://github.com/jdillenkofer/camera_proxy/blob/master/wireshark-dissector.lua

QuantumEntangledAndy commented 3 years ago

Oh cool I was just writing a dissector update. jdillenkofer's one needs updating to our new dissector format though so I'll try that

QuantumEntangledAndy commented 3 years ago

Interesting some of the udp packets have extra obsfucation... Will need more work sigh

QuantumEntangledAndy commented 3 years ago

Fortuantly jdillenkofer seems to have done most of the heavy lifting so can look into that :)

surfzoid commented 3 years ago

Fortuantly jdillenkofer seems to have done most of the heavy lifting so can look into that :)

jdillenkofer as say in his comment of issue #30 fell free to use his code in neolink add an option to conected bridge to cam through internet should be good, take also in consideration, the setting file of jdillenkofer don't need ip, uid is enought

Lanwalker commented 3 years ago

I have not tried to use these cameras just on my own LAN... it would defeat my purpose of even getting them if they couldn't get out of the local area network... but I do like the fact I do not have to mess with my router like I had to do with my web server both to receive and send information with the UID.

I do not use the Reolink ' cloud '... I did set it up initially to test it but they only let you use it for a month for 1 camera and I do not have the funds on my Social Security Disability to finance their operation.

I send emails out and have notifications turned on for my Microsoft system using their outlook client on the PC and on my dumb android ' smart phone ' and it is fairly quick surprisingly.

These cameras do record to a PC without the memory cards but need the memory cards when recording for the smart phones ?? Still a lot of questions I am digging for answers for yet... sure wish they would release interface code for their cameras like my interface system vendors did when I was programming, it would save us all a lot of headaches... I had to read and write to hardware memory locations when I first started working with that type equipment with assembly, pascal ( The Germans loved Pascal for some reason ) and C.

That would be an interesting test if somebody had a place like in a deep basement to shield the WiFi signals from the devices. I used to have access to that type of test hardware ( $60,000 HP Logic analyzer with multi-channel high speed oscilloscopes and dedicated packet capture devices for the networks ) many years ago and a very old warehouse building with 3 foot thick walls of lead glaze coated bricks that our maintenance guys hated me for when they had to run wire or fiber optics thru them so my network equipment could get access

QuantumEntangledAndy commented 3 years ago

I rather do not like the UUID, it works only because it phones home to the reolink server. The client connects to the server and then the server sets up the hole punched connection. I rather prefer to setup home assistant or similar software on my local network to at act as the gateway to the WAN with reolink cameras only able to talk to neolink. But to each their own method.

Anyways I shall try and get the udp working at some point jdillenkofer work will help for sure. But I have other commitments too.

Lanwalker commented 3 years ago

Are you sure about that ? I do not use the Reolink cloud and have had no problem with remote connections yet.

QuantumEntangledAndy commented 3 years ago

Yes, you do not need to subscribe or have cloud for this service. There is no magic way of bypassing a NAT/firewall with some UUID. Relink set up the hole punching and run it for free.

surfzoid commented 3 years ago

I rather do not like the UUID, it works only because it phones home to the reolink server. The client connects to the server and then the server sets up the hole punched connection. I rather prefer to setup home assistant or similar software on my local network to at act as the gateway to the WAN with reolink cameras only able to talk to neolink. But to each their own method.

Anyways I shall try and get the udp working at some point jdillenkofer work will help for sure. But I have other commitments too.

I don't know how, but he use only uuid and send broadcast to local network only, 255.255.255.255 see for that his udp layer code file

QuantumEntangledAndy commented 3 years ago

255.255.255.255 is broadcast to everything on the local network. It will work something like this:

Client broadcast 255.255.255.255 on some port: "Hello I am looking for UUID=AUUID please respond to me if its you" Camera: "Oh that's me I have this IP = MY.IP.IS.THIS please contact me there"

I'd have to look at the details of the code for its exact code but its usually a broadcast to learn the ip and then use that from then on

twistedddx commented 3 years ago

I rather do not like the UUID, it works only because it phones home to the reolink server. The client connects to the server and then the server sets up the hole punched connection. I rather prefer to setup home assistant or similar software on my local network to at act as the gateway to the WAN with reolink cameras only able to talk to neolink. But to each their own method. Anyways I shall try and get the udp working at some point jdillenkofer work will help for sure. But I have other commitments too.

I don't know how, but he use only uuid and send broadcast to local network only, 255.255.255.255 see for that his udp layer code file

It is in: def discover_device(self):

Sends a discovery packet and learns the IP just like the official client can.

QuantumEntangledAndy commented 3 years ago

Might be nice to add discovery to neolink but it will be local only since broadcast is restricted to local networks and we don't talk to the reolink servers for hole punching

twistedddx commented 3 years ago

Just static assign the IP on the camera or reserve an IP on their DHCP server. UID really doesn't serve much purpose on the local network, just use the LAN IP.

QuantumEntangledAndy commented 3 years ago

Yes static ip on local is more than enough. I just wanted to try and clear up this misconception about UUID... I think I didn't help though :( so sad

surfzoid commented 3 years ago

But argus2 on local network don't provide an standard stream, i never get vidéo with vlc, gstreamer or other, so there is something more

QuantumEntangledAndy commented 3 years ago

They provide a stream of BC formatted data you cannot get it to go to vlc without a translator like neolink. That's neolink purpose to transform a BC stream into a rtsp stream.

surfzoid commented 3 years ago

yes, bashuan protocol is the main job of yours hacking , it is nice, but, for battery cam they pass through aws whose seem to be more standard, so is there any chance of reolink encapsulate it in their protocol for the battery cams, or they "convert", so, for not local watching stream, but from my linux box through internet, do you think there is a way to get this "normal" stream not directly from the cam but from the amazon server by providing the uuid ?

QuantumEntangledAndy commented 3 years ago

Battery camera do not have to pass through aws. We already have dumps of them talking locally. Neolink talks locally to the camera translate to rtsp its then a standard stream you can read and send elsewhere.

twistedddx commented 3 years ago

yes, bashuan protocol is the main job of yours hacking , it is nice, but, for battery cam they pass through aws whose seem to be more standard, so is there any chance of reolink encapsulate it in their protocol for the battery cams, or they "convert", so, for not local watching stream, but from my linux box through internet, do you think there is a way to get this "normal" stream not directly from the cam but from the amazon server by providing the uuid ?

If your cam is at home/work you would want Neolink running on a device at home/work connecting to the cam on the LAN. You could then use VPN to access your LAN remotely.

Or you could port forward on your home router to get access, but BC device security is extremely weak and you should not expose them to the internet. Neolink security also may not be suitable for exposing to the internet.

I do not believe anyone has looked into the UID connection protocol. It almost certainly exposes the same weak security of BC devices and should simply be disabled. UID hole punch connection via Reolink servers(AWS) is available on almost all BC devices not just the battery ones. The battery cams do not appear to be significantly technically different to other BC products. They are just optimized UDP/TCP, packet loss resilience etc for internet data transfer instead of LAN data transfer.

Lanwalker commented 3 years ago

I just emailed Reolink support ( support@reolink.com, pr@reolink.com and sales@reolink.com ) asking about the ' UID ' and if it does go thru external servers and to explain the process if possible. It sometimes gets a quick return, sometimes it takes them a couple of days of bantering to get anything out of them

QuantumEntangledAndy commented 3 years ago

Let us know what they say. But the answer likely depends on the technical knowledge of the representative.

You should already be aware of the difficulty with NAT because I think you mentioned that you had to set up port forwarding on your router before. If getting through a router was as easy as a UUID why don't we all just use that for everything? The answer is we can't use this technique (hole punching) without a middle man to facilitate the connection.

Please do read up on NAT transverse and hole punching. It's used in a lot of locations like video calls and multiplayer video games.

QuantumEntangledAndy commented 3 years ago

Perhaps you could also look at the link posted before it mentions that the register UUID on the sever and RELAYs connections when what they call p2p fails. In all likelyness this p2p is a p2p setup through hole punching

Lanwalker commented 3 years ago

I guess the ' UUID ' just didn't register since it is called a ' UID ' in the user interfaces.

I am still hoping Reolink will ' explain ; it to make it clearer.

Lanwalker commented 3 years ago

http://www.internet-computer-security.com/VPN-Guide/NAT-T.html

Lanwalker commented 3 years ago

Thank you. Still getting myself back up to speed... a lot has changed in 20 years <G.

twistedddx commented 3 years ago

Regarding NVR RLN8-410 UID:

NVR init: NVR does DNS for p2p.reolink.com (in my case response was 54.210.7.156)

Data between NVR and Reolink 54.210.7.156 is UDP. NVR contacts Reolink at port 9999 from port 38991 Reolink respond to NVR at port 38991 from port 9999 NVR contacts Reolink at port 58200 from 38991 and continues to do this every 10 seconds from here Reolink contacts NVR at port 38991 from 58200 but only the first time and not every 10 seconds after.

Data payload appears to have a magic of 3a cf 87 2a (2a 87 cf 3a?). All data in both directions use this magic. After magic appears to be 4 byte payload size which is always 20 bytes short of payload size. This likely indicates a 20 byte BC header in the payload. 4 bytes, always 01 00 00 00 1 byte incrementing message handle. 1 byte always 03 2 bytes always 00 00 4 bytes no pattern noticed, all 4 bytes always different data. Payload looks encrypted with chunks of same data in multiple different messages, which to me indicates this is likely text/xml with a single scramble key run over it like other BC messaging.

UID connection from NVR side: Many messages between Reolink and NVR occur using the same ports, magic and format as before.

UID connections from client side: DNS lookup of apis.reolink.com (52.5.228.193 3.224.113.94) Establishes a very Brief TLS 1.2 connection with Reolink. Then soon enough my client has switched to a direct connection to the public IP 54.210.7.156 The data between the client and 54.210.7.156 uses same magic and format as before.

There appeared to be a terminate packet of 28 bytes: 20 cf 87 2a f8 00 00 00 00 00 00 00 00 00 ...

QuantumEntangledAndy commented 3 years ago

Don't suppose you could send a packet with the encrupted data. I want to see if it's the same encryption used for the UDP data or BC XML. (Will need header for the key too)

QuantumEntangledAndy commented 3 years ago

3a cf 87 2a is the exact same magic used for UDP connections. I've just finished my BC dissector for UDP that can decrypt those. Is this really public? Because it's not really encrypted again. I'll post my UDP dissector and you can check it out too.

QuantumEntangledAndy commented 3 years ago

UDP dissector is in #94

twistedddx commented 3 years ago

It is across the public internet. It is just the BC UDP protocol!

Adding these cleared up everything to all the servers and the XML is all readable. -- UID DissectorTable.get("udp.port"):add(2018, bc_protocol) DissectorTable.get("udp.port"):add(9996, bc_protocol) DissectorTable.get("udp.port"):add(9999, bc_protocol) DissectorTable.get("udp.port"):add(18430, bc_protocol) DissectorTable.get("udp.port"):add(18432, bc_protocol) DissectorTable.get("udp.port"):add(38991, bc_protocol) DissectorTable.get("udp.port"):add(58200, bc_protocol)

The TLS section that appears to prime the UID connection is maybe a harder hurdle to break in to random devices as it may be difficult.

But eavesdropping a connection is simple.

twistedddx commented 3 years ago

A user connecting to their BC device via IP vs UID gives near identical eavesdropping protection. In that both offer only the most basic protection that has been fully defeated by multiple projects now. The UID or IP, username and password is easily obtained from the messages.

For random attacks from those that can not eavesdrop. Direct IP does require a port forward which if not restricted does leave the BC device open to brute force and other exploits. UID would require brute force attacks to the p2p/AWS servers. I assume you would need UID, username and password before the p2p servers would give you the direct connection details.