Motorola Camera's

Hardware
21

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

22

@TechMuchBro Thanks for the input! Unable to do anything with it though :frowning:
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.

23

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.

24

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.

25

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:

  • Change the version number of the old package to make the camera think it’s on the latest version
  • Remove the auto update function so it doesn’t update unless we want it
  • Bring back the removed changes

So far it seems none of them is possible since all changes seem to be within the binary files :frowning:

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 :frowning:

26

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.

1 Like
27

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 :wink:

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.

28

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.

29

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

30

image
image994×453 9.48 KB

For mine it still stays at 0% here forever…:frowning:

31

Are you unable to try with a fw.pkg instead of a tar.gz?

32

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?

33

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.

34

Maybe this helps: https://www.contextis.com/en/blog/push-hack-reverse-engineering-ip-camera

35

Or https://github.com/Erliz/hubble-sniffer

36

@basboers thanks for the tips. I was already aware of those articles.

@marcelod it is indeed that simple. I just can’t block those addresses within my current router :frowning:
I think if you block ota.hubble.in on router level, it will not be able to download the latest version but allows you to use the app and website

@roel_hendr I also had a couple of cases that it didn’t want to downgrade. It just said that there was no file or something. I restarted the camera with the physical on/off switch or restarted my browser/laptop which I think resolved it. So perhaps give the physical on/off switch a go.

37

I downgraded for the Xth time yesterday and since then, it didn’t update automatically. Let’s hope it stays like this.

38

I finally solved it by downgrading and using opendns.org as my DNS servers. I blocked ota.hubble.in and ping.hubble.in within OpenDNS.

1 Like
39

Good to hear you solved it for your case. I still am not able to downgrade :frowning:. It still doesn’t process my 1854-03.10.16.tar.gz file. It stays at 0%

40

Sure you are waiting long enough? I have no clue otherwise :frowning: