Injecting Your Own SSL Certs Into The Uniclass Prima IP-16

I’m presently contemplating a project to build a small DC/storage outbuilding down the side of my garage, basically to relocate all the random servers and such which are currently located in my study to somewhere else, ideally with proper climate control.

Now of course I don’t want the inconvenience of actually having to go out there to yutz with things when I need to so I went digging around on eBait for an IP KVM, turned up a “Prima IP-16 Uniclass” for $140, seemed like a reasonable price, unfortunately it’s one of the ones that uses an oddball cable that feeds PS2/USB and VGA via an HD15 connector. But I digress.

When I got it home, I started poking around if of course. First thing I wanted to do was to upload my own SSL certs to it, via the vendor-supplied web interface you can upload *SOME* certs but not others, one of the ones you can’t upload is the SSL cert for the web server, no biggie, let’s make that happen.

First things first, these guys have a non-password-protected root console available on Serial port 1, w00t! What an awesome start, fire up realterm, connect to port, determine that we’re talking 115200-8-n-1, reboot box. Surprise surprise it’s running Linux (on some flavour of Intel XScale processor);

Prima IP-16 Bootloader

Prima IP-16 Bootloader

Having a sniff around we find that we’ve got one linux user, and that’s root, not sure what the default password is, but since it’s just crypt’d I could feed it to cudahashcat, or since I’ve got a root shell I could just change it…

Prima IP-16 Password Reset

Prima IP-16 Password Reset

Let’s have a look at inittab;

/> cat /etc/inittab
#slog:unknown:/bin/syslogd -n
#klog:unknown:/bin/klogd -n

Hmm, we’ve an inetd but it’s disabled, I wonder what runs out of that?

/> cat /etc/inetd.conf
discard dgram udp wait root /bin/discard
discard stream tcp nowait root /bin/discard
telnet stream tcp nowait root /sbin/telnetd
ftp stream tcp nowait root /bin/ftpd -l

Woo, telnet and ftp, just what I always wanted, let’s run it up and see if she works

/> /bin/inetd&

Sure enough, now we can telnet over and login using the root password we set;

Prima IP-16 Telnet Access

Prima IP-16 Telnet Access

Now that we have a fully functional terminal we can actually use “vi” so let’s make that inetd change stick;

/> cat /etc/inittab
#slog:unknown:/bin/syslogd -n
#klog:unknown:/bin/klogd -n
/> reboot

Next step, find the certificates, a bit more nosing around turned up /etc/config/certs;

/> cd /etc/config/certs
/etc/config/certs> ls
dh1024.pem        dserverkey.pem    server.crt        webserverkey.pem
dh512.pem         ldapcert.crt      serverkey.pem
droot.crt         ldapkey.pem       webroot.crt
dserver.crt       root.crt          webserver.crt

OK, so here are all the certs, not just the ones the web UI will let us update, I reckon that “webserver.crt” and “webserverkey.pem” are probably what we’re looking for, so we can just drop in our own certs and we’re golden, right? Not quite so fast there, there’s a problem;

/etc/config/certs> cat webserverkey.pem
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,D0C717240CAC789F

That’s a fly in the ointment, the private key is encrypted, probably with some hard-coded password. Time for some reverse engineering, by the wonders of FTP we download /bin/webs and feed it to our old friend IDA, have a sniff around in the “Strings” sub-view to find ourselves a starting point;

Prima IP-16 webs IDA "Strings"

Prima IP-16 webs IDA “Strings”

A bit of digging around leads to;

Prima IP-16 webs Code

Prima IP-16 webs Code

Oh, look “dserverpass” that sounds suspiciously like a really un-creative private key password, let’s grab the keys from the KVM and see what we can see;

$ openssl rsa -in webserverkey.pem -out webserver.key
Enter pass phrase for webserverkey.pem: dserverpass
writing RSA key

Awesome, so the password is, in fact “dserverpass”, so let’s go encrypt our private key with that password;

$ openssl rsa -in privkey.pem -out webserverkey.pem -des3
writing RSA key
Enter PEM pass phrase: dserverpass
Verifying - Enter PEM pass phrase: dserverpass

FTP the cert and key up, reboot the device and no webserver…

/> cat /var/log/webs.log
SSL: Unable to set certificate file </etc/config/certs/webserver.crt>

Bugger… The cert which was there to begin with used a 1024-bit RSA key, maybe it doesn’t like 2048-bit keys…

$ openssl req -newkey rsa:1024 -keyout -nodes test.key -x509 -days 365 -out test.crt
Generating a 1024 bit RSA private key
writing new private key to 'test.key'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

$ openssl pkey -in test.key -out test.pem -des3
Enter PEM pass phrase: dserverpass
Verifying - Enter PEM pass phrase: dserverpass

Upload, rename, reboot, et. viola, it’s presenting our new cert… That’s rather a kick in the teeth.

At least we got our own cert into it, but I’d prefer something a bit more than 1024-bit…

Not sure whether it’s a limitation to how they’ve compiled the openssl libs for it, or if it’s a limitation of their implementation, I’ll have to do some digging and figure out which it is, if it’s a limitation in their code it might be possible to patch it (and fix the crappy hard-coded key passphrase while I’m at it…) if it’s a limitation in the libs it may well have to go in the “too hard” basket, because I don’t particularly fancy building a cross-compile toolchain for an unknown platform, time will tell.

In the meantime I’ll leave it as is and disable inetd again.

Morgan / 2016-11-25 / Uncategorized / 0 Comments

Installing NUT on ESXi 4.1

The final battle in my quest for properly integrated UPS Monitoring was to get my ESXi 4.1 box into the mix.

Some rummaging around online turned up a NUT Client for ESXi 5 (french) which doesn’t work for ESXi 4, fortunately the same guy has also done a NUT Client for ESXi 4 (french) which will work, but takes some effort.

The tricky part is that it seems that the only way to customise an ESXi 4 install is via oem.tgz, whereas in ESXi 5 we have the concept of “packages”, I broke my ESXi box several times figuring out how to actually do this properly so I figure I might as well write it up for others (also it’s probably good to have a native English version rather than having to go through the peril of Google Translate.)

    Enable SSH access on your ESXi box;

  • Login to vSphere
  • Select host
  • Configuration -> Security Profile
  • Firewall -> Properties…
  • Remote Tech Support (SSH) -> Options…
  • Click Start

SSH into your ESXi box and do the following;

~ # cp /bootbank/* /altbootbank/ # not necessary but recommended, backs up your bootbank
~ # cp /bootbank/oem.tgz /bootbank/oem.tgz.orig
~ # cd /tmp
/tmp # mkdir oem
/tmp # cd oem
/tmp/oem # tar -zxf /bootbank/oem.tgz
/tmp/oem # cd ..
/tmp # wget
Connecting to (
oem.tgz              100% |*******************************| 40871  00:00:00 ETA
/tmp # cd oem/
/tmp/oem # tar -zxf ../oem.tgz

Once that’s done you’ve got a “merged” tree of the existing oem.tgz and the NUT oem.tgz, next step is to go edit etc/ups/upsmon.conf to add a MONITOR clause for your UPS, and then update etc/ups/ if you want email notifications (If you don’t want notifications, just comment out the NOTIFYCMD line in upsmon.conf).

Once you’re happy with the config you need to re-pack the oem.tgz, the trick here (took several attempts and one ESXi rebuild to get this right…) is that your .tgz must NOT have leading ./ in the paths, the way to do this is pretty simple;

/tmp/oem # tar -zcf /bootbank/oem.tgz bin/ etc/ lib/ oem.txt sbin/ usr/ var

Now reboot, and if all’s well ESXi will boot up happily, if it doesn’t consult the troubleshooting section below.

Once ESXi has booted up, SSH back in and run;

 ~ # upsmon
Network UPS Tools upsmon 2.4.3
UPS: compaq3kva@lodestone (slave) (power value 1)
Using power down flag file /etc/killpower

It you’re seeing that then it looks like you’re all good, now to test the shutdown script issue the following;

 ~ # upsmon -c fsd

ESXi should shut itself down shortly thereafter.

If that all works then you’re done.

If your ESXi box pink screens, you probably cocked up the oem.tgz, at the loading screen do a “Shift+O” and give the additional option “noOem”, this will prevent ESXi from loading the oem.tgz, then you can SSH back in and try again.

If the above doesn’t work then you’ve REALLY screwed something up (like say, when I DELETED the oem.tgz file… Protip: DON’T DO THAT) for that “Shift+R” will switch you over to the “altbootbank” (actually it swaps the contents of bootbank and altbootbank), which will revert you to the original state (assuming you did the backup as suggested in the above code), SSH in and try again.

If that doesn’t work you can boot the install CD, switch to a console with “Alt-F1” and copy the oem.tgz.orig file back to oem.tgz.

If that doesn’t work then you’ve done something REALLY special and I can’t help 😉

Morgan / 2016-11-09 / Uncategorized / 0 Comments

Creating the DropBot9k (AKA; ESP8266 throwies) Part 3

Part 3 – The tools which Espressif hath provided

So we’re still chasing power savings at this point, the next logical step is to reduce the TX power of the ESP8266 because we don’t need much range in this application, unfortunately NodeMCU does not expose the TXPower API…

Looks like we need to write a patch against NodeMCU… Or not…

Something of a diversion;

Around about this time I decided I needed the rtc API for the software which necessitated a new build, off to the NodeMCU Build service we go; build a new image, flash to ESP8266, ESP8266 crashes…

Turns out some time between when I initially started playing with NodeMCU and now, there’d been several SDK updates, and with new versions of the ESP8266 SDK it is frequently necessary to flash a new “init data block” to the ESP, so I dug up the appropriate “init data block” (in the latest SDK package) and attempted to flash it using and also NodeMCU Flasher, but in no case was I able to get a working ESP at the end.

Further research lead me to the Espressif “Flash Download Tool v3.3.6” which can be downloaded from Espressif’s Other Tools page, with that and the latest SDK package I was able to get the updated init data block installed (I also reinstalled the “AT” firmware, probably wasn’t necessary to flash that as well, but I was being paranoid).

Espressif Flash Download Tool

Espressif Flash Download Tool

Then flashed the new NodeMCU image using the normal process.

End diversion.

The upshot of having to go through this process was the discovery of the RFConfig tab in the Flash Download Tool.

Flash Download Tool RFConfig tab

Flash Download Tool RFConfig tab

The “LowPowerEn” checkbox here piqued my interest, turns out, it does pretty much what it says on the box, it hard-codes a limitation on the TX Power. Checked the “LowPowerEn” checkbox, dialed it down to 0dBm (1mW), generated a new init data block, flashed it to the ESP, and re-tested.

Now, on a 5 min wake/1 min sleep cycle (I think, might have been 3 min wake/2 min sleep), I was seeing in excess of 48 hours of battery life, which was “good enough”. Out of interest I ran it up with NO sleep, and it was still good for 8+ hours, so a pretty good outcome all in all.

Turns out, the way we built the scenario for the competition meant that the ESP only needed to be (and indeed COULD ONLY be) deployed for about 6 hours, so I tweaked things to switch it to a 10min wake/10sec sleep cycle, just to give it the occasional kick in the head to make sure all ran smoothly, I also dropped two separate units in the alleyway for extra redundancy.

I’ll write another quick post in this series around “packaging” and that will cover the hardware, I’ll write up another post or maybe two about the software for it as well.

But for now, that’s your lot.

Morgan / 2016-11-09 / Uncategorized / 0 Comments

NUT for Windows – Gracefully Shutting Down VMWare Guests

After I got NUT sorted out on my *nix fleet it was time to bring my Windows box into the mix, I frequently run VM Guests on my workstation for various different tasks, basically unless it’s something that’s going to be providing an active service for an extended period I run it up in VMWare Player, any “servers” go on the ESXi box.

Because VMWare doesn’t gracefully shut down or suspend VM Guests when the host gets shut down there was the possibility of badness as a result of an abrupt windows shutdown in the event of a power failure, as such I wanted any Guests which happened to be running on my workstation to be gracefully shutdown (or rather suspended).

Initially I’d planned to do this with the VMWare VIX API, but in doing some digging into it and trying a few things I decided it was too much bother for the moment (it’s also, frankly, a pretty damn ugly interface), so we went to Plan B which was to screenscrape the output of vmrun to determine what VMs were active, then issue a suspend to each of them prior to shutting down the host.

This is what I ended up with (It’s called from a batch file which is called by upsmon), I’m kinda new to this PowerShell stuff, so this is pretty horrific, but it does the job.

cd "C:\Program Files (x86)\VMware\VMware VIX"
$vms = .\vmrun.exe -T player list
foreach($v in $vms)
	if ($v -like "*.vmx") {
		$stat = "Suspending " + $v;
		echo $stat;
		$vm = '"' + $v + '"';
		echo $vm;
		.\vmrun -T player suspend $vm

The only other minor hitch was that in order to be able to see the active VMs I needed to switch the Network UPS Tools service over to using my account rather than LocalSystem, but I figure that’s probably better anyway, least (or rather lesser) privilege and all of that.

Morgan / 2016-11-08 / Uncategorized / 0 Comments

Adventures in UPS Management

Always one for “if it’s worth doing, it’s worth overdoing”, I use a rather oldschool 2RU rackmount 3kVA Compaq UPS (R3000h, OEM badged PowerWare 5119) for my network core, NAS, ESXi and workstation.

It was a cheap buy at ~$100 sans batteries, I just threw 4 7.2AH SLA batteries into it and called it good (I also have a much larger UPS, but it’s in need of a new battery pack, and being that it’s internal pack is *20* 7.2AH SLAs, it’s rather $$$ to replace).

For the first time in two and a half years since we bought this place we had a blackout yesterday morning…

The “pleasure” of having to go and manually shutdown all my machines at 05:30 was enough to FINALLY spur me into getting off my arse and actually setting up monitoring for the UPS.

The first challenge was building a cable that ACTUALLY BLOODY WORKED with this UPS (pro-tip; DO NOT plug a straight-through serial cable into a Compaq R3000h, the UPS will IMMEDIATELY and without warning power down…)

After various false starts, I FINALLY got a working cable up and running (found several different pinouts floating around online), the UPS speaks UPSCode2 and the cable to talk to it is as follows;


Oddball comms parameters too 1200 8-n-1 software flow control (Xon/Xoff), if you’re interested check out the UPSCode2 Concept Description which includes all of the protocol info.

Spent some time arguing with Powerware LanSafe trying to get it to play ball, eventually gave up and spent some time digging around for other solutions. Initially I looked at apcupsd because I knew it existed, but that doesn’t support upscode2, some further digging turned up Network UPS Tools which fit the bill, as a bonus there are clients available for *nix, Windows and ESXi.

Now to choose a UPS server, decided the best option was my NAS which is a FreeBSD box, and as an added bonus it has a real, legit, serial port onboard, hooked the UPS up there, installed NUT from ports.





Added a couple of LISTEN clauses to upsd.conf;


Added a couple of users to upsd.users.
Et viola;

# upsc compaq3kva@lodestone
battery.capacity.nominal: 17.00
battery.charge: 95.0
battery.runtime: 2280
battery.voltage: 55.20
battery.voltage.maximum: 56.00
battery.voltage.minimum: 40.00
battery.voltage.nominal: 48.00
device.mfr: Compaq
device.model: UPS 3000 VA FW -0033
ups.mfr: Compaq
ups.model: UPS 3000 VA FW -0033
ups.power.nominal: 3000.00
ups.status: OL

So we’re all good there.

A few tweaks to upsmon.conf (mainly switching out -h for -p in SHUTDOWNCMD), and a quick test, and we’re golden.
Also enabled CGI on the webserver on that box to allow me to monitor the UPS;

UPS Stats from NUT

UPS Stats from NUT

I’ll probably enable SSL at some point but for the moment it works.

For my firewall box (pfSense) it was very straightforward to integrate, basically just installed the nut package and pointed it back at the NAS box.

Getting the ESXi integration to work was a bit of a pain in the arse, so I’ll write that up separately.

Next cab off the rank will be integrating my Windows box, which will be a little more involved because I also want to suspend any VMWare VMs which happen to be running on it at the time, prior to shutdown (either some PowerShell + VMWare vmrun voodoo, or I might write a quick’n’dirty app to do that), so that’ll get a separate write up too.

Oh, and one more thing, had to add the following to /etc/devfs.conf to ensure that NUT had access to the serial port;

own    ttyu0    root:uucp
perm   ttyu0    0660

All in all it was a relatively painless process, the biggest issue being getting the right damn cable made…

Morgan / 2016-11-08 / Uncategorized / 0 Comments

Creating the DropBot9k (AKA; ESP8266 throwies) Part 2

Part 2 – ESP8266’s do HORRIBLE things to batteries

So initially I went with the naive approach, I stuck a pair of CR2032’s in parallel and strapped them to the ESP8266, I was rather disappointed to discover that that only got me about 20 mins of life, repeated the test with a pair of AAA’s for interests sake, I think I got about an hour out of them, time to do some ACTUAL research…

In doing some fishing around online I found some YouTube video around powering ESP8266’s from batteries or somesuch, which alerted me to the horrific power draw behaviours of the ESP8266, turns out a bare module pulls bugger all current, EXCEPT every 100ms or so where when it’s in AP mode, where it suddenly draws 400+mA to beacon, which the CR2032’s (being that their nominal rated current draw is 15mA) were VERY unhappy with, I did a quick lash up on my electronics bench to validate that that was, in fact, what was happening here, the scope confirmed the findings.

Fortunately there exists a simple solution for this, “strap a big-ass capacitor across the power rails”, 1000uF is a good choice, it doesn’t completely eliminate the spikes, but it reduces them to manageable levels and doesn’t add excessive bulk.

So I went and strapped a 1000uF cap across the module and repeated the test with a fresh pair of AAA’s, sadly that was still only good for 6 hours or so (even after I dropped the beacon interval back to 2 sec).

Back down the rabbit hole then.

The ESP8266 supports various “sleep” modes, reading the doco, the only thing that would really work for me is “deep sleep”, next problem, the way deep sleep works is;

  • GPIO16 is connected to RESET.
  • Sets a timer to fire GPIO16.
  • Powers down everything except the timer.
  • Timer expires, GPIO16 fires, chip is reset.

Problem is that the ESP-01 doesn’t have GPIO16 broken out… Time for some microsurgery!

ESP-01 Modified for Deep Sleep

ESP-01 Modified for Deep Sleep

Note the jumper wire between the Reset pin and pin 8 on the ESP8266, also note that the power LED has been removed, that alone pulls ~10mA.

Bada bing, bada boom, deep sleep, did some testing managed to get 60 hours out of a 5min sleep 1min wake cycle, this was less than optimal but at least it showed that there was a way forward.

More in part 3 whence we dig into the tools Espressif hath provided.

Morgan / 2016-11-04 / Uncategorized / 0 Comments

Creating the DropBot9k (AKA; ESP8266 throwies) Part 1

Part 1 – The Inspiration

For Ruxcon 12 this year it was decided to expand the Black Bag competition into two phases, the first being on the Saturday which was the “standard” Black Bag fare, get into a hotel room, acquire intel, don’t set off alarms and such, Sunday however was a bit different.

We decided to send the top three teams on something of a “scavenger hunt”, basically we’d send them to a few locations across the Melbourne CBD to find clues which would eventually lead them back to the conference venue where they would find a (blatantly fake) “bomb” (I’ll write up another post on the construction of that some time later), which they’d have to “disarm” for extra points.

The first stop for this “scavenger hunt” was to be a Wireless hotspot stashed in one of Melbourne’s many alleyways, to which they would connect for instructions for the next step.

Because things were very much “up in the air” as far as how we were actually going to achieve this one of the design goals was that the hotspot should be capable of being deployed on the Friday night and collected on the Sunday, necessitating at least 48 hours of battery life.

WRT703N with Internal LiPo battery

WRT703N with Internal LiPo battery

I did some testing of a Linksys WRT703N platform I’d modified with an internal battery pack, unfortunately the battery life was rather woeful, next attempt was to just strap the WRT to a USB Power Bank and use that, turns out the 703N is actually really power hungry, the ~4000mAh power bank I tested with gave only a bit over 2 hours of life, even with TX Power down at 0dBm (1mW), and obviously the equation around the amount of battery capacity required just wasn’t going to work out.

Clearly it was time to go back to the drawing board, at some point on Slack somebody had suggested we might be able to do it with an ESP8266, I’d initially discarded the suggestion because I didn’t want to have to deal with building webservers and suchlike on a platform like that. But needs must, so I dug in, more on that in part 2.

Morgan / 2016-11-03 / Uncategorized / 0 Comments

Ruxcon 2016 Hardware Hacking Village

Thanks to all who visited us at the Ruxcon 2016 HHV, hopefully you got some value out of my presentations and such (I’m sure you got value out of the other presenters at least).

I’ve uploaded new Gerbers/Drill file for the SimpleSolder kit to my Ruxcon 2016 HHV page, these have the assorted cock ups from the original design corrected, just in case anybody wants to go make their own.

I’ve also included a DigiKey basket link, though for one-off quantities you’re probably better off going elsewhere if you’re AU based.

The RuxBadge build instructions, firmware and firmware source are also up there, if you want to write your own firmware (or modify mine) you’ll need to get a hold of the appropriate STM32 Standard Peripheral Libraries and dump them in an appropriate place (if you attempt to make it before you do that it’ll bitch at you) but other than that it should be pretty straight forward, I think there’s a README in there which has some details about what’s what and build targets and such.

dnz is going to write a tutorials on how to load firmware onto the badge using the UART bootloader, he’s also got a tutorial from last year covering how to do the same with BusPirate (though you’ll need to figure out the connections yourself) and perhaps how to find the flag in the badge firmware so keep an eye out on his site

When I get around to grabbing them off my burner lappy I’ll also throw the slide decks from my presentations up there.

Morgan / 2016-10-28 / Uncategorized / 0 Comments

So, Who The Hell Is This Guy Anyway?

I’m a random Australian geek/maker/hacker/whatever the hell you want to call me.

In order to keep myself sane (well, sane-ish…) I basically do whatever is interesting me at any given time; but I suppose you’d say my “core competencies” are electronics, software development/reverse engineering, information security, forensics, systems/network admin. I also do wood and metal work, general engineering, chemistry, car stuff and I’m a halfway decent amateur tailor.

I’ve had this domain lying around for a while (i.e. years), decided it was probably about I actually did something with it, this was mainly catalysed by needing somewhere to stuff the bits and pieces I developed for the Ruxcon 2016 Hardware Hacking Village.

I’ve no idea how often I’ll actually bother to post anything here, but I suspect it’s going to come in fits and starts, initially I’ll post some stuff from the work I did at/for Ruxcon this year, but other than that it’s liable to be a matter of when I’m doing something that I think is sufficiently interesting/worth documenting and whether or not I have time to actually write it up.

Morgan / 2016-10-28 / Uncategorized / 0 Comments