It works when I change the filename to 1854-03.10.16.tar.gz…I can upload it, but then the processing of the uploaded firmware stays on 0% forever. When I rename the file to 1854-03.10.16.fw.pkg, I can upload it, but then it says Upgrade Failed, wrong firmware.
So I’m still no step further
The tar.gz probably won’t work because it ain’t signed and they are not keeping the latest releases anymore on their website. So you should find the fw.pkg on their website. I discovered it by sniffing the traffic from their app I believe.
I’ll try to downgrade once more at home and create a video about it.
Are you able to find my fw.pkg file maybe by sniffing? I need the 03.10.16 firmware for the 1854. Thx!
Just as an aside, I contacted Hubble on Facebook and got the following response. The wording is slightly different from what @benm received and now explicitly mentions RTSP streaming not being something they support. Frustrating.
Please know that Hubble cameras can only be used with the Hubble for Motorola Monitors app and we do not provide support for any third party apps or streaming via RTSP.
No I can’t because I don’t have that camera 
I can only sniff my own camera.
Anyway, it’s clear that Hubble won’t bring back what they removed. So either we have to bring it back, find a work around or accept the fact that it’s no longer possible what we want.
Downgrading the MBP855Connect in steps:
Getting the current version:
Uploading the firmware file to the upgrade page (took about 15 minutes):
Upgrade started:
Upgrade completed (took about 5 minutes):
Checking the version again:
Seeing the video:
After about 5 minutes it upgraded itself to the latest version.
Greetings all! Like others on this thread, I’m in the same boat with a MBP855 Connect. Shame on Motorola for taking this capability away. I’ve spent a good bit of time on this in the last couple days and have found some things that may be of interest. No final solution yet, but I’m hoping it helps towards one.
I used Nmap (https://nmap.org/) to scan my camera’s IP for any RTSP URL’s. Some info on doing this can be found here: https://blog.victormendonca.com/2018/02/09/how-to-scan-for-rtsp-urls/
I scanned using the following command in Nmap to catch all the ports:
nmap -p 1-65535 --script rtsp-url-brute 192.168.xxx.xxx
It returned the following results:
Nmap scan report for 192.168.xxx.xxx
Host is up (0.057s latency).
Not shown: 65325 closed ports, 204 filtered ports
PORT STATE SERVICE
80/tcp open http
4434/tcp open unknown
8080/tcp open http-proxy
51108/tcp open unknown
60000/tcp open unknown
60001/tcp open unknown
No hits on an exact URL, but given the port information, I started to plug each port number into the existing RTSP URL (using VLC) as a replacement to 6667. All but one seem to fail immediately. 51108 tries to connect for a couple seconds than fails.
rtsp://user:[email protected]:51108/blinkhd
If I had to guess, maybe this (or one of the others) is the port they are using now? If it is, the user:pass credentials do not seem to be working. I would image they too were changed.
4434 is a good possibility too as it falls under the category of register-able ports by IANA (not actually listed though). 51108, 60000 and 60001 would be considered private or dynamic ports (maybe a moving target??)
Hope this helps towards a solution! Regards
@TechMuchBro Thanks for the input! Unable to do anything with it though
Since you have the same device as mine, can you confirm within the hubble app that you also have Camera ID 2855?
I am thinking of sniffing the traffic somehow from the camera to the internet, or perhaps try to download the aes_decrypt file as within the blog earlier. Maybe with the directory traversal I can also change files on the device (guess not). Problem is that the camera stays for 5 minutes on the old version and then I am back on the “broken” version.
Camera/Model ID says 1855 in the app. I just tried taking a trace (using wireshark) today from inside my network. I’m getting some hits from the camera, but all of the packets are DHCP/ARP requests. Nothing really useful in them. I tried tracing again while the camera was in pairing mode and re-paired it to my phone, but got more of the same.
Thanks for the intel. Then I downgraded to the wrong version. Will try again tomorrow and inspect the packages of 1855. Decompiling 2855 didn’t bring me a lot though.
Alright, for 1855, there are no .fw.pkg files to download from the OTA server. Only .tar.gz.
That is good, because it allows us to unpack the file without having to decrypt it.
I still assume the .11 is the right one, since that was also the case for 2855.
I made a difference between all the changes in .11 and .18, but unfortunately, all changes seem to be in binary files, which probably doesn’t allow us to change anything back:
https://github.com/peternijssen/motorola-1855-test/compare/03.10.11...03.10.18
The solutions I had in mind so far were:
So far it seems none of them is possible since all changes seem to be within the binary files
Edit: Found this PDF on the internet:
It’s 4 years old, but it’s about adding telnet access to the camera with a tiny change in the firmware. That would perhaps allow us to kill the auto update process from running.
And the final problem; My fwupgrade page doesn’t accept a tar.gz. It needs a fw.pkg
Update:
I’ve downgraded again. Afterwards I downloaded as much files as I could, based on the firmware files I had so far and looking which files they use. Therefor I was capable of downloading the auth.conf file, which looks like this:
name = "Configures of user";
system :
{
ir_mode = 0;
master_key = "WWWW";
orbwebUrl = "XXX";
sid = "";
password = "";
mqtt_server_uri = "{\"status\":200,\"message\":\"Success\",\"data\":{\"mqtt_uri\":\"ssl://YYYY-mqtt.hubble.in:8883\"}}";
publish_topic = "/v1/server/devices/ZZZ";
subscribe_topic = "/v1/devices/ZZZ";
};
WWW = master key to the camera.
XXX = IP address which I don’t understand yet.
YYY = URL to a MQTT topic
ZZZ = Unique device token
From the code, I also noticed that I needed 3 certificate files: ca.crt, client.crt and client.key. The combination of these files, together with the MQTT URL allowed me to put a listener on the topic.
I’ve also noticed you can get the unique device token from: http://localaddress/?action=command&command=get_udid
When connecting with the Hubble app, I’ve noticed that a message is being written on that topic, containing the master key, the version and some sort of GUID, which changes frequently.
I’ve also noticed that I can now do a request to https://cs.hubble.in/v1/devices/config_details.json?device_token=ZZZ which gives me back some config details like urls, ports etc.
I’ve also noticed that I get some attributes to the following URL:
https://cs.hubble.in/v2/cameraservice?action=command&command=get_attribute&key=brightness&auth_token=WWW
I’ll update this message as I discover more.
I tried messing with some of the information on ptnijssen’s last post and also tried some other things by looking at the server calls from the hubble.com website but no luck.
I then tried downgrading my cameras (1667) from 03.10.20 to 03.10.11 and, weirdly, this time it worked even though previous attempts failed. I downgraded both my cameras and was then able to see them as generic cameras in HA with the usual rtsp URL: rtsp://user:pass@<IP_ADDRESS>:6667/blinkhd
Then at router level, I permanently blocked those cameras from accessing the internet altogether which means I can see their streams locally but they can no longer call home and self-update. This also means the Hubble app and website are no longer usable for me – can’t complain about that 
Am I just missing something really obvious here? This seems almost too simple and I can’t see any downsides.
The standalone monitoring device still pairs with the cameras and works normally. RTSP feeds are HD and have audio, and all of the other fluff these cameras do (play melodies, be a temperature sensor, etc) can be replicated in HA as well via the commands API in them (available commands here: https://github.com/Erliz/hubble-sniffer/blob/ba2212b398230210f264534d977b934566ac5747/README.md).
So far the only big downside is that I can’t get audio to play when viewing the stream via a HA stream component, but looks like this is an issue on HA’s side as the audio works fine when viewing the stream via VLC.
Hi @marcelod, can you explain in steps what you did to downgrade? Indeed strange that it suddently works for you. Hope we can make this work for others also.
To start off, I got my current firmware from here, it was 03.10.20:
http://<IP_ADDRESS>/?action=command&command=get_version
Then got my camera’s model from here, it was 1667:
http://<IP_ADDRESS>/?action=command&command=get_model
These were consistent with what the Hubble app showed.
Then trialled and errored my way to the previous firmware number and downloaded it via this URL structure. You’ll have to change the values for your case:
https://ota.hubble.in/ota1/1667_patch/1667-03.10.11.fw.pkg
I then went to this page on the camera:
http://<IP_ADDRESS>:8080/fwupgrade.html
From here I took the steps outlined in this post:
Then in my router, I blocked the IPs I reserved for my cameras from connecting to the internet and set them as a camera entity on HA by using the rtsp URL:
rtsp://user:pass@<IP_ADDRESS>:6667/blinkhd
Are you unable to try with a fw.pkg instead of a tar.gz?
I checked https://ota.hubble.in/ota1/1854_patch/
I can download the tar.gz file for the 1854, but cannot find a fw.pkg file. Maybe you can try?
I’ve tried but no luck. I can download 03.10.32, 03.10.20 and 03.10.16 tar.gz but no fw.pkg
Have you tried the firmware process through this app instead?
There’s an Android version too.
