How to generate a Zookeeper root password (superDigest) using standard unix tools

You may want to generate a Zookeeper superDigest without making use of the built-in


class if, for example, you’re using configuration management tools such as Puppet or Chef and normally generate authentication values outside of the environment where they’ll be used.

The Zookeeper documentation on this is vague at best, and I eventually had to resort to reading the source code for this function, which for some reason includes the “super:” prefix in the digest. This can be seen in the source code responsible for the generation of the digest:

 static public String generateDigest(String idPassword)
         throws NoSuchAlgorithmException {
     String parts[] = idPassword.split(":", 2);
     byte digest[] = MessageDigest.getInstance("SHA1").digest(
     return parts[0] + ":" + base64Encode(digest);

The function clearly splits the input (in the format “super:password”) into two sections, then promptly ignores that array and uses the full input for the digest directly following that.

For example, if your password is “hunter2”, you need to do the following to generate a functioning digest:

$ echo -n "super:hunter2" | openssl sha1 -binary | base64

And then when you lauch Zookeeper, you would use the following in addition to the standard command line:


Took me a while to figure out that my original attempts weren’t working because I didn’t include “super:” in the password.


How to export your Runtastic “Sleep Better” data on Android

Sleep Better with Runtastic is a well-polished sleep tracking app for Android and iOS that I’ve been using for the past year or so without issue. Unfortunately I found out a few days ago that Runtastic does not sync your sleep session data with their servers, which means that you lose everything if you uninstall the app or get a new phone. Having no export function also means that you are limited to the app’s visualisation and statistics features.

I started digging for a solution and soon found that the app stores its database at the following location (access to this directory requires root):


This turns out to be a sqlite database that you can view with any compatble program (I used DB Browser for SQLite) and from there you can easily export the data in each table as a CSV file.


As an example of what you can do with the data, I made a scatterplot of the number of hours I slept against my sleep efficiency:


If only companies would make it easier to access your own data.

Netgear DGN2200 stores credentials as plain text – allows full access in local subnet

In my previous post I made the remark that the telnet interface for my Netgear router does not require credentials. As such, you already have full root access the moment you connect.

After some digging I found that the web interface credentials are not encrypted at all. The contents of the /etc/passwd file are readable by the (Telnet) “nobody” user, with full access. Example output:

~ # whoami
~ # cat /etc/passwd

There is no /etc/shadow file.

This means that anyone on the local subnet (connected via Wifi at a coffee shop for example) can enable Telnet, and get the password for the web interface.

This is the latest firmware (version V1.0.0.37_1.0.21WW) available for this router.

How I fixed my Netgear router’s broken webserver

A couple of nights ago we had some stormy weather that resulted in a power outage. The night was filled with lightning strikes and the following morning I found myself unable to connect to the internet.

After attempting to log into the web interface of my router (and failing) I pinged it and realised that it was still running fine. Numerous reboots followed during which I discovered that the web interface actually worked, but only for about 30 seconds after booting, after which it stopped responding to requests entirely.

It was in these 30 second moments of insight that I found that my DNS settings were erased (I assume this was due to the bad weather), so I quickly fixed it. I finally had a working internet connection again, and set about fixing the web interface.

After a bit of research it became clear that the only other option of connecting was via Telnet, but telnet was disable by default. Further digging lead me to this tool used by Netgear technicians to temporarily enable Telnet access while connected in the router’s subnet. Oddly enough, after connecting I found that it didn’t require any authentication. This came as quite a surprise and I suspect that there is no easy way to fix this.

Anyway, I now had full root access to my router’s (somewhat outdated) Linux OS. I checked top and noticed that httpd was still running, and yet it was not responding to requests. Shortly after restarting the daemon manually I found that the web interface was working fine once again, and for longer than 30 seconds. I used it to run a firmware upgrade which solved the problem entirely. The web interface was fine once again, and I didn’t notice any permanent lightning damage.

A quick how-to for the Telnet tool:
It must be run on the router’s local subnet, otherwise it won’t respond and you need to use the following command:
telnetEnable.exe <Router’s IP> <Router’s MAC Address with all separators such as colons removed, and all letters in caps> Gearguy Geardog
For example:
telnetEnable.exe 30469A24067F Gearguy Geardog

That should enable Telnet on your router until the next reboot.