Skip to main content

No love for SOAP

1 min read

So I had to do some SOAPy work this week and since it is some pre-war tech I had to dive in again. Here is the essence of what I got (from other ppl) :)

Well, SOAP isn't a "modern" specification, so it's only (somewhat) well supported by the technology stacks that were mainstream when the big vendors were pushing WS-Deathstar (Java, .NET) - so all that technology is already in place. (via)

Ohh death star you say? That gives me ...

I have PTSD from my experience with SOAP/WSDL. I'm even having problems typing these words. [...] (via)

No, it could not be that hard. No. Let's ask s/o who actually has build a library around this death star:

Detergent helps make SOAP interactions in Erlang uhh... cleaner (pun totally intended)! (via)


Sainsmart 1.8 display + Rasperry Pi

1 min read

Recently I bougt one of those tiny Sainsmart 1.8 inch displays to use it as a secondary monitor for my Kodi-based (raspian) media center in the living room.

The setup was pretty easy and fbi showed up pictures on the display five minutes after I got the wiring done. \o/

The problems started when I tried to run some demo pygame code on it. All I got was an error I did not understand because everything was setup correctly.

Traceback (most recent call last):
  File "", line 19, in 
pygame.error: No video mode large enough for 128x160

After fiddling around for a while, I created the file /etc/fbmodes with the following content:

mode "128×160"
geometry 128 160 128 160 16
timings 0 0 0 0 0 0 0

Works for me. Errors gone. =)

Plug love

1 min read

So I just finished Ch. 5 "Authenticating Users" in the Programming Phoenix book and after coding along the examples of ten pages, on the last page of this chapter I was like "Wait a sec, where do they persist the session data?!" and then I discovered this gem:


My little sons first VIM session ...

1 min read

I am ... very impressed by his skills, but does anybody know which language this could be?


1 min read

Fefe bloggte gerade über ein Problem von dem ich bisher eigentlich dachte, dass es so gut wie jedem halbwegs profesionellen Softwareentwickler bekannt wäre, aber es ist immer schön wenn auch einer der Großen nochmal ein Wörtchen darüber verliert.


Jetzt müsste die Erkenntnis nur noch im Management ankommen ... .


Sieht so aus als hätten wir einen Gewinner - TypeScript

1 min read

Angular 2 setzt auf TypeScript (statt AtScript), Google baut SoundScript (Typsystem für JS in der VM) in V8 ein und auch Micrsoft forscht scheinbar an einem ähnlichen Konzept. Dort heisst es allerdings Safe TypeScript.

Das könnte echt endlich was werden mit dem Versuch das Minenfeld Javascript-Programmierung zu räumen.


View your hubble camera stream whereever you want

6 min read


Do you own a hubble/blink/monitoreverywhere device and want to view the camera stream bypassing the proprietary software? Point your multimedia player to rtsp://user:pass@CAMERA-IP:6667/blinkhd/track1.

Update 26.11.2016

Since I got a log of comments saying it does not work any longer ... here is the stream URL for the latest firmware (change the IP to your camera's):

$ mplayer rtsp://user:pass@


Some time ago I bought this little and neat network attached camera baby monitor from Motorola called the FOCUS66-W.
It is advertised as being integrated to the cloud service that allows you to control your cam via smartphone and to watch and record your streams from any internet capable device (Browser + App).

Despite the shitty Android app and the Adobe Flash driven website, it really is a cool device with some nice feature for such a small device and price tag:

  • Good infrared night vision
  • Motion triggered video snapshots and notification
  • Two way audio communication
  • Temperature sensors + alarms
  • Playing lullabies

But as you might know from other embedded hardware projects, this kind of toys always suffer from security problems. At least that was what I hoped for when I asked myself how to obtain the video stream and directly play it on any device. So I started investigating.

Before I started to investigate I wrote an email to their support asking why they use this securtiy nightmare called Adobe Flash to view the videos on Their answers was support bullshit - even though it came from the dev department - and so they left me no choice. :)

Having a look around

So, what is our starting point?

  1. we got a camera connected to the local wifi
  2. an app used for controlling the camera device and viewing the stream
  3. a cloudy space somewhere at Motorola as a possible synchronization point

So for 1. you guessed right ... we fire up nmap:

    $ nmap

    Starting Nmap 6.47 ( ) at 2015-02-20 12:51 CET
    Nmap scan report for
    Host is up (0.058s latency).
    Not shown: 997 closed ports
    80/tcp   open  http
    6667/tcp open  irc
    8080/tcp open  http-proxy

    Nmap done: 1 IP address (1 host up) scanned in 2.20 seconds

Well, I expected to see 80, but what is up with 6667 and 8080. We will - maybe - see in a minute.

Let's step back and think about how the communication between the cam and app is done. There are two possibilities, with or w/o signalling done by the cloud:

  1. App Cloud Cam
  2. App Cam

To this point we don't know and we need to investigate a bit further.

Uncovering communication

There is an pretty easy way to intercept all network traffic produced by your smartphone by creating a monitored wifi using hostapd, a bridge to your LAN and Wireshark. The actual setup depends on your specific settings but you may use this as a good starting point.

After we setup the bridged wifi and connected the smartphone to it, we fire up Wireshark on the interceptor and start the hubble app on our smartphone.

(Next step: pull out the interesting bits from the wireshark log.)

The app startup leads to three interesting communication streams as seen from the log file.

  1. The app calls some (unencrypted) RPC methods on port 80 on the camera device, such as:
    • /?action=command&command=get_mac_address
    • /?action=command&command=set_brightness&value=5
    • /?action=command&command=recording_cooloff_duration&value=60
    • ...
    This looks like initialization of the camera stream.
  2. In parallel it makes some encrypted calls to the hubble API (?) that I have not looked into yet.
  3. After the initialization is done the app opens up an RTSP Session to port 6667 on the camera device in the local network. If you do not share the same network it will fetch the vids out of the cloud.

    And yupp ... that stream is what we are looking for! <:o>
  4. Not so interesting for our investrigation to obtain the camera stream but it says quite a lot about coding standards at the manufacture: the app also makes a call to
    . Yupp right ... nodeapp ... naming things ... hard.
  5. The app also fetches the camera event history pictures that are shown on the dashboard unencrypted from

Obtaining the video stream

In the last paragraph we found out where the video stream is hosted and that we could access it from the local area network. But the moment you fire up VLC to access the stream you will get prompted with a username and password input.

A second look at the Wireshark log tells us that they implemented a digest authentication, so no simple sniffing possible - as for eg. basic auth. To bad. :(

So what you could try next if you live outside of germany is to get you a copy of John the Ripper with activated hdda plugin and try to crack the username and password right of the data you obtained from your wireshark log.

But that is illegal in germany. What about reverse engineering the app to extract the username and password? Naah, that may be illegal too.

Ok, ok what about brute forcing the shit out of your cam? Nope illegal too and they will never ever have used a trivial password as found in any dictionary!!

And that is the moment when you remember your good old friend strings. Simply apply it to the unzipped APK and look what happens:

$ strings -a -t x classes.dex |grep -C2 rtsp
2b1831 rtsp://user:pass@%s:%d/blinkhd


Oh yes, that's a complex password ... not.

Now point VLC to rtsp://user:pass@CAMERA-IP:6667/blinkhd/track1 and you are ready to go.

Other observations

After I got all the nfo that I needed to view the camera stream I played a little more with the APK and the wireshark logs.


The camera seems to be Nuvoton N329 as indicated by the RPC repsonses from the camera device.

The App

Although the camera is labeled with the Motorola logo and managed by you find a lot of reference to a second similar service called

The app itself is developed by Hong Kong based company called CVISION. They also provide some links to test videos in their app. Say hello to one of their devs (^^):

There are also a lot more commmands that can be triggered by the RPC web interface. Just check classes.dex with the strings command.