Support for Argus Pro

[Velines]

Thanks for the great piece of software as well as the interesting article on your blog!
I have a Reolink Argus Pro which unfortunately is not yet compatible with Neolink:

[2020-07-06T20:17:59Z INFO  neolink] Neolink 0.3.0 (unknown commit) release
[2020-07-06T20:17:59Z INFO  neolink] Terrasse: Connecting to camera at 192.168.50.194:9000
[2020-07-06T20:17:59Z INFO  neolink] Terrasse: Connecting to camera at 192.168.50.194:9000
[2020-07-06T20:18:00Z ERROR neolink] Error streaming from camera Terrasse, will retry in 1s: Connection error
[2020-07-06T20:18:00Z ERROR neolink] Error streaming from camera Terrasse, will retry in 1s: Connection error

NMap tells me port 9000 TCP is closed, so this is not surprising.

I am new to Wireshark, Lua and reverse engineering things, so please forgive me my lack of knowledge. I tried to capture the communication between Reolink's macOS client and the camera, and everything is done over UDP, so no TCP at all. However, I think the protocol works similar to what you described: In the packet capture I can see the magic bytes you described, legacy authentication using md5 hashes missing the last character, and later packets are potentially XML-based, as I see the same bytes in the data reoccurring.

I would be very happy if you would try to support the Argus Pro and please let me know if I can be of assistance.
Please find attached a short packet dump of connecting to the camera (user/pw = admin/123456), getting a few frames of video streams, and disconnecting.

Argus Pro dump.pcapng.zip

[Alessandrolosco]

Hello! I'm interested in this having some Reolink Argus 2/Reolink Eco solar-powered cameras. Not an expert in this particular field but I offer my basic help!

[thirtythreeforty]

Hey this is great thanks. Without access to hardware this may be a tricky proposition, but let me take a look at your packet captures and we'll go from there. It's good to hear that it's at least similar.

[Velines]

Thank you very much for looking into it :) Please let me know if you need further packet captures or want me to try something.
I had another look at the packet dump a few days ago and while I didn't make any progress in modifying your dissector, I have a feeling that one "Baichuan packet" might be split across multiple UDP packet.

[thirtythreeforty]

I've looked at this and it looks like there's an extra wrapper around the typical Baichuan packet that starts 0xf0debc0a. Probably related to the fact that it's a UDP transport - the unfamiliar header always starts with 0x10cf872a, or 0x20cf872a if it's the last in a series.

The good news is that I see D&6I in the ASCII dump - this is what the Charlie Scrambler turns <?xml into - so once the extra UDP layer is reversed, it would probably be straightforward.

But let me ask you (or anyone else interested in this ticket) before going too much further - how do you envision this working assuming the protocol is reverse engineered? A big part of the Argus camera's user experience is that it only records during a motion event. RTSP is a "streaming" protocol which would drain the battery pretty quickly.

(Not being critical here, I don't own any of these cameras so I don't know what you expect out of them.)

[Alessandrolosco]

Argus uses his PIR sensor or something to activate the video, notifies users and record on microSD. I suppose that the PIR could turn on and off the RTSP endpoint or the endpoint could be activated upon external request.

[Velines]

The good news is that I see D&6I in the ASCII dump - this is what the Charlie Scrambler turns <?xml into - so once the extra UDP layer is reversed, it would probably be straightforward.

Great, that's what I saw as well and what made me think it would be pretty similar to the regular protocol.
Some of the packets seem to have some kind of counter at byte 0x13 (which maybe includes the following bytes). You can see that especially well in the packets of size 70 (whatever their purpose is).

About the use-case, I might have a bit of a special thing here. We've built a cat-safe screened porch and I'd like to check/watch what our cats are doing out there. So far I haven't had time to do the wiring and that's why I bought the battery-powered one (actually I have the one with a solar panel), but at some point in time the camera will have continuous power. So currently we let the cats out every few days for a couple of hours, and in the meantime the camera will have re-charged via the solar panel.
So, one use-case is to watch the stream without having to use the proprietary Reolink client. This client cuts the connection after a few minutes to save battery power, but this would not be required anymore after proper wiring. Another one is that I have blocked the camera's internet access because I don't like to have my stream going over some Chinese servers, but I still would like to have a way to check the stream when I am not connected to my wifi, so I would proxy the RTSP stream over my own server.

[JPinSPACE]

I don't know if there is a significant difference between the Argus Pro and Argus 2, but if it's possible to also support Argus 2 it would be appreciated.

[richhalliwell]

I've looked at this and it looks like there's an extra wrapper around the typical Baichuan packet that starts 0xf0debc0a. Probably related to the fact that it's a UDP transport - the unfamiliar header always starts with 0x10cf872a, or 0x20cf872a if it's the last in a series.

The good news is that I see D&6I in the ASCII dump - this is what the Charlie Scrambler turns <?xml into - so once the extra UDP layer is reversed, it would probably be straightforward.

But let me ask you (or anyone else interested in this ticket) before going too much further - how do you envision this working assuming the protocol is reverse engineered? A big part of the Argus camera's user experience is that it only records during a motion event. RTSP is a "streaming" protocol which would drain the battery pretty quickly.

(Not being critical here, I don't own any of these cameras so I don't know what you expect out of them.)

Ideally - on attempting to open the stream it would request the camera start the RTSP stream. In a similar way that the app supports live viewing, it would be great to be able to request an on demand live stream, for the 15 minutes or so that the camera keeps the stream open.

I'm also super interested in support for the Argus 2 - thank you for the great work. Really enjoyable write up

[rwenz3l]

Another user with an argus2 joining in - if you need any captures or anything I'll do my best to provide them. My initial attempt at hacking these failed, but I'm curious now.

[bt]

Would also love to get an RTSP stream for my Argus 2!

I don't want my camera feed sending up to China, and also it's super laggy to watch it over their servers. Would be great to be able to get a local stream + connecting to my local Synology Surveilance for saving PIR.

[DavidAustin]

I had an interest in an Argus Eco - I was after a WiFi camera for time lapse.

However, my testing shows that it's impossible to connect to the camera (using the Argus windows client)
without connecting to the Argus servers. That's a deal-breaker for me - even with reverse-engineering,
there's no way to ensure security and privacy.

[bt]

@thirtythreeforty Just to continue this conversation, do you think it'll be the same UDP function (ie. _IOTC_thread_UDPrecv) that was pictured in one of the screenshots you posted during your disassembly?

I have an Argus 2 but I'm not very good with embedded electronics (or more like I'm not confident enough to desolder the flash)... Possible instead you could share your firmware dump so I could have a look around?

[thirtythreeforty]

No need to desolder the flash if you just want to look around (and don't want to modify anything). You can unpack the official firmware update with binwalk as well.

I suspect it is _IOTC_thread_UDPrecv, yes. Although if you can stare at the format in Wireshark and document what's going on (or write a plugin that can parse it), that's also a good starting point, and you wouldn't have to reverse engineer any firmware.

[DavidAustin]

This talk of disassembly inspired me to tear down my Argus Eco (a bit). Disassembly is quite easy. It has a SPI FLASH soldered on and is based on the CC3200 Wifi MCU.

I could read out the FLASH contents - but I'm personally in no huge rush with this one.

[thirtythreeforty]

@DavidAustin it's discouraging that you can't directly connect. Have you portscanned the Argus or otherwise tried to directly interrogate it? It's unusual for Reolink cams to be cloud-only.

Also very interesting that this cam isn't running Linux, if the CC3200 is really running the show.

[DavidAustin]

@thirtythreeforty I did port scan - and logged network activity when using the windows client -
I can share those captures if anyone wants.

It appears to be UDP mostly, with a range of ports used - 2015 for device discovery,
2018 for login, 60036 is used for streaming the image data.

There is a TCP port open - 54321 - which I think is debugging - I couldn't get it
to do anything aside from an initial few characters at connect.

The login message sent to port 2018 is sent after communication to 54.210.7.156 (AWS),
and the login data varies each time. I attempted replaying some samples of login data without
success. I also attempted to use the windows client whilst disconnected from
the internet and it wouldn't work - no communications to the camera IP at all.

I also decoded some of the later packets and there appears to be similar
scrambled XML as you thought.

[jlg89]

I had opened another issue, but I'd bet the Argus cameras are all the same.

Neolink throws an "Error streaming from camera" when attempting to connect to the Argus Eco.

Reolink camera model and firmware: Argus Eco, build 19120201, firmware 1202_491_352_19

Config.toml:

bind = "0.0.0.0"
# bind_port = 8554

[[cameras]]
name = "GateCam"
username = "admin"
password = "gAteCam12"
address = "192.168.77.12:9000"
format = "h264"

I've tried with/without h264.

Output:
$ ./neolink --config config.toml
[2020-07-31T11:45:41Z INFO neolink] Neolink 0.3.0 (unknown commit) release
[2020-07-31T11:45:41Z DEBUG neolink::gst] Permitting anonymous to access /GateCam, /GateCam/mainStream
[2020-07-31T11:45:41Z DEBUG neolink::gst] Permitting anonymous to access /GateCam/subStream
[2020-07-31T11:45:41Z INFO neolink] GateCam: Connecting to camera at 192.168.77.12:9000
[2020-07-31T11:45:41Z INFO neolink] GateCam: Connecting to camera at 192.168.77.12:9000
[2020-07-31T11:45:42Z ERROR neolink] Error streaming from camera GateCam, will retry in 1s: Connection error
[2020-07-31T11:45:42Z ERROR neolink] Error streaming from camera GateCam, will retry in 1s: Connection error

etc.

I've attached a WireShark packet dump from the macOS app to the camera. I connected, changed stream quality, ran through the configuration options (so the app would pull all the config data from the camera), and finally closed the connection, which presumably causes the camera to go back into power-save mode. Figured that might be useful, if you ever want neolink to be able to fully support the battery-powered cameras.

The UID on this camera is 95270001A7KVX76K. I suspect it may use that for part of the encryption.

GateCam.pcap.gz

[jlg89]

But let me ask you (or anyone else interested in this ticket) before going too much further - how do you envision this working assuming the protocol is reverse engineered? A big part of the Argus camera's user experience is that it only records during a motion event. RTSP is a "streaming" protocol which would drain the battery pretty quickly.

I can't speak for anyone else, but my hardware is powered by an existing solar power setup. I'm not really worried about draining the battery, but I do like the power-saving features. A good enhancement for neolink might be an option that tells neolink to only pull a stream from a camera when it's receiving RTSP requests for that camera, instead of full time.

The cameras support push & email notifications for motion detection, and I'm pushing Reolink to add MQTT support, so there are ways to get those notifications into HomeKit etc. You can join the camera to Google Home, but it uses Reolink's cloud service. It's obviously preferable to keep security camera data in-house.

I'll send you one of these cameras if you want it, and have the time to mess with it. Let me know. No pressure.

One thing that everyone else can do who has one of these Argus cameras is to open a ticket with Reolink support and tell them you want to be able to access these cameras with third-party apps. At the very least, they could throw some assistance thirtythreeforty's way.

[jlg89]

Without access to hardware this may be a tricky proposition

I really like the Argus Eco hardware and overall functionality, but the more I learn about the backend setup, the less I like the camera. Everything, and I mean everything, goes through their Chinese servers (well, Hong Kong, but...yeah. China). The camera can't even send local email notifications--those are proxied by their servers. Which means that my email credentials aren't really on the camera, they're on a Chinese server, so now they're reading my mail. Just because I'm paranoid doesn't mean they're not out to get me. Anyway, long story shorter, if you want this Argus Eco, I'll factory reset it and send it to you. I'm going to swap it out for a Dafang-hacked WyzeCam, which only talks to people I tell it to talk to.

[bt]

No need to desolder the flash if you just want to look around (and don't want to modify anything). You can unpack the official firmware update with binwalk as well.

I suspect it is _IOTC_thread_UDPrecv, yes. Although if you can stare at the format in Wireshark and document what's going on (or write a plugin that can parse it), that's also a good starting point, and you wouldn't have to reverse engineer any firmware.

I had a look around for the firmware but it seems that battery-powered device firmwares are not available for download Reolink's website... which is a PITA.

From here:

For the battery-powered cameras, we suggest using the auto-upgrade for them and they don't support upgrading in this way (download the file and upgrade via software).

[twistedddx]

I believe Reolink tends to use Amazon AWS for cloud services. So your device is likely not connected to China but that connection via AWS may allow full control by any authorised Reolink employee.

There is a good chance the waking of the device is via the connection to AWS. I imagine for power saving while hibernating all the camera keeps awake is the connection to the cloud server.
If true there may be very little hope for neolink to wake the device on demand.

[jlg89]

AWS makes sense. It's really frustrating that these cameras are completely unable to do anything local, not even SMTP. I guess the Argus product line is just begging for a firmware hack. Conceptually, it doesn't seem it would be too difficult to replicate the power-saving features, since they're mostly tied to either PIR motion detection or incoming network access. Keep the video & IR turned off otherwise, and bingo, you're saving battery. But firmware-fu is not my fu. I've suggested this as an option to the Dafang-hacks guys for those cameras, and if somebody gets motivated to hack Argus, I'm willing to help provide hardware.

[twistedddx]

You should see if wake on lan magic packets wake the device also.

[Morphy99]

Sucks we can't hack this one, I'd be happy with local notifications and accessing the SD recordings after the event. I can see it records without internet connection so might be able to fancy some way of removing the internet access block from the router for x amount of minutes after the notification. Is there a way to intercept notifications? Spoof a server locally?

[jdillenkofer]

Hello!
I found out how most of the argus 2 communication over udp works and wrote the following project:
https://github.com/jdillenkofer/camera_proxy

My usecase is a bit different:
I want to display the current live video on a FritzFon, when the door bell is ringing.
For this i wrote a small python webserver, which can communicate with the camera and translate the h264 video stream
into images that can be accessed via an url over http.
The camera stream is only started when someone calls the http api.

I got something that works, but the stream is often interrupted and then i need to reconnect to the camera (which can take up to 2 seconds).

I guess it has something to do with the udp reliability layer in the protocol.
I also tried to send regular ping messages to the camera to keep the stream alive. This helped, but the stream still often hangs.
Maybe i have to send these ping messages time-controlled.
I am currently sending them every x reply packets from the camera.

All communication works 100% in the local network. I never needed to communicate with any remote servers.

Thank you for this project and the blog post.

Feel free to use my project as a reference to integrate udp support into neolink.

[thirtythreeforty]

Hey that's great @jdillenkofer. The proof of concept for local network only is enough to get going.

@jlg89 if you're still offering I'll take you up on your Argus hardware offer.

[jlg89]

I have an Argus Eco I can reset & send to you. Do you think you want another Argus model as well (or instead of)?

Update: I've pulled the Eco from its perch and reset it. I'll box it up tomorrow and ship it to wherever you tell me. UPS, unless you prefer something else.

[thirtythreeforty]

Thanks @jlg89!

[surfzoid]

Hello!
I found out how most of the argus 2 communication over udp works and wrote the following project:
https://github.com/jdillenkofer/camera_proxy

My usecase is a bit different:
I want to display the current live video on a FritzFon, when the door bell is ringing.
For this i wrote a small python webserver, which can communicate with the camera and translate the h264 video stream
into images that can be accessed via an url over http.
The camera stream is only started when someone calls the http api.

I got something that works, but the stream is often interrupted and then i need to reconnect to the camera (which can take up to 2 seconds).

I guess it has something to do with the udp reliability layer in the protocol.
I also tried to send regular ping messages to the camera to keep the stream alive. This helped, but the stream still often hangs.
Maybe i have to send these ping messages time-controlled.
I am currently sending them every x reply packets from the camera.

All communication works 100% in the local network. I never needed to communicate with any remote servers.

Thank you for this project and the blog post.

Feel free to use my project as a reference to integrate udp support into neolink.

That's an very good new as an starting point to get an linux client, other point i requested to Reolink support but without real response, is the fact of the cam isn't really an security cam as they say, because i'm in france, which is not suported by their cloud, so at this time, the cam can only save video on the sd card and it is easy for an bad boy to take the cam and go away.
So, other save option aren't mandatory, like FTP, Samba or other.

[Lanwalker]

<G>.. getting anything from their support is a big joke, they can't even keep the email messages going to their support group straight.. I keep getting somebody new but still using the same support@reolink.com address and when I reply, I make sure I add their pr@reolink.com and sales @reolink.com to the recipients and I always send me a copy to my backup email accounts too. The first E1 Pro that came in had some problem with the MicroSD card after a few hours. It formatted and saved video to it but a few hours later when I tested the camera from remote, it said the card was not formatted and when I tried to format it again, it failed. When I got home and accessed it from my PC, it didn't even show a MicroSD card in there... when I tried to remove it, it refused to cycle out no matter what I tried, it didn't even feel like a spring was in it... and the slot is too thin to get a set of tweezers in to try to wiggle it to break it lose. I kept on their support people and they wanted me to take a video of how I was putting the card in ?? ( blooming idiots, if I can't get it out, I can't get another one back in... not my first rodeo ) and since they send email in the middle of the night ( on the other side of the world from the US on Eastern Standard Time ), I was getting up just to make sure I could get something back right away and it still took a few days before I had somebody send me a RMA number and address and it cost me about $14 just to mail it back with a tracking number ( they said they will refund that ). I got an email last night from a new support person asking when I was going to send it back and I had already sent the tracking number and a picture of the receipt days earlier ( their return guy's id name is  Yogurt <G> )... I pulled up the copy of the email I had in my backup account and sent it to all of them and told them to get their communication structure fixed with separate email addresses so they know what is going on. I think I had 4 or 5 different names with the same support@reolink.com come from them. I did get a PDF file from a Hillary in their support earlier on with some code and comments but when trying to extract it, there was routines that parenthesis did not match up when removing ( commenting out their added comments ) and when I asked about it, they said their battery powered units didn't use all the code the ac adapter inside units had to save battery power ( I even got the solar charger for the outside WiFi units since I would be gone for extended times and nobody would be able to swap battery packs ). I have a stationary Argus Pro and their Argus PT unit for outside and 1 of the E1 Pro from them ( $44 and I had to send it back for memory card stuck issues) and then bought 2 more E1 Pro from Amazon about a week ago for $36 each that got here in 2 days. I attached 2 PDf files... the cgi-jasonv1.1.pdf is the one their support sent me and the cgi_command.pdf file is one I found somewhere else in my search for information... I hope these may help somebody since I am just trying to get back up to speed programming since I've been out of the loop way too long ( since 2001 programming test and control systems in C <G> )

[thirtythreeforty]

Thanks all for the good discussion (and hardware :). I know this ticket is older, but its duplicate #91 has a lot more discussion, and indeed momentum, so I'm going to close this one just to keep the issue queue tidy.