At work we have a KVM over IP switch from Inter-Tech, a KVM IP-KVM101. It is really a small and versatile device that, in combination with 16-port KVM switches, allows us to control a complete rack with test hardware.

The KVM switch provides a web interface with a Java Web Start application for remote access. But the latest browser security updates disabled and removed the Java Web Start support . This move was announced quite some time ago (Oracle White Paper). Still, the vendor of the KVM switch, Inter-Tech, was not able to provide a valuable solution to cope with this problem.

After a bit of Googling I found an Amazon review about this particular KVM switch where the reviewer stated to have installed the firmware from another brand, the LINDY KVM over IP Switch. The LINDY switch looks identical (besides a different sticker) and – even better – their latest firmware provides a VNC server. This would allow us a browser and even operating system independent access to the KVM.

LINDY did not directly provide a download link for its firmware but I was able to find an adequate firmware on their Australian ftp server: LINDY_39432_39636_FW_0216.zip (8.3 MB)
I gave it a try; but uploading the LINDY firmware failed with an error message:

Firmware Upload
Error: OEM version is not matching.

Already having downloaded the LINDY firmware, I took a look at it with binwalk and a few commands later I had an extracted firmware image in front of me.

$ binwalk -e Step1_2_fw_ipkm03lindy_ipkvmstdCE50658B_+NOTRANS_FR_+COMPAT_2016-01-28_22-53_043105_67545_3MB.bin

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
320 0x140 uImage header, header size: 64 bytes, header CRC: 0xC5FCD671, created: 2016-01-28 22:02:49, image size: 3127675 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xC61254FC, OS: Linux, CPU: ARM, image type: RAMDisk Image, compression type: gzip, image name: "Ramdisk Image"
384 0x180 gzip compressed data, maximum compression, from Unix, last modified: 2016-01-28 22:02:47
3128123 0x2FBB3B uImage header, header size: 64 bytes, header CRC: 0xF5630930, created: 2016-01-28 21:55:34, image size: 915584 bytes, Data Address: 0xF00000, Entry Point: 0xF00000, data CRC: 0xB8B11697, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-2.6.13.1"
3140495 0x2FEB8F gzip compressed data, maximum compression, from Unix, last modified: 2016-01-28 21:55:33
4120231 0x3EDEA7 U-Boot version string, "U-Boot 1.0.0 (Jan 28 2016 - 22:54:03)"

$ cd _Step1_2_fw_ipkm03lindy_ipkvmstdCE50658B_+NOTRANS_FR_+COMPAT_2016-01-28_22-53_043105_67545_3MB.bin.extracted/

$ file *
180: Linux rev 1.0 ext2 filesystem data, UUID=ee9f8abb-cf9d-4943-8de7-d28dba7fb687
2FEB8F: data

$ sudo mount 180 /mnt -o loop

$ ll /mnt
insgesamt 43
drwxr-xr-x. 2 501 501 3072 Jan 28 2016 bin/
drwxr-xr-x. 2 501 501 1024 Okt 20 2008 dev/
drwxr-xr-x. 11 501 501 1024 Jan 28 2016 etc/
drwxr-xr-x. 2 501 501 1024 Nov 28 2007 flashdisk/
drwxr-xr-x. 6 501 501 5120 Jan 28 2016 lib/
drwx------ 2 root root 12288 Jan 28 2016 lost+found/
drwxr-xr-x. 5 501 501 1024 Nov 28 2007 mnt/
drwxr-xr-x. 2 501 501 1024 Nov 28 2007 proc/
drwxr-xr-x. 2 501 501 1024 Nov 28 2007 root/
lrwxrwxrwx. 1 501 501 3 Jan 28 2016 sbin -> bin/
drwxr-xr-x. 2 501 501 1024 Nov 28 2007 smb/
drwxr-xr-x. 2 501 501 1024 Nov 28 2007 tmp/
drwxr-xr-x. 3 501 501 1024 Jan 28 2016 usr/
drwxr-xr-x. 6 501 501 1024 Nov 28 2007 var/

One of the first things I’ve noticed was that core of the firmware seems to be produced/maintained by Raritan (or at least by one of its subsidiaries, Peppercon AG).

After locating the web server files and binaries, I grepped for the error string, or simply for ‘oem‘. Sometimes you have luck and applying ‘grep’ and ‘string’ on files is enough to find the right location for further analysis. (In the following snippet I’ve already narrowed down the results.)

$ cd /mnt

$ grep 'crossoem' * -R
[...]
lib/webpages/fwupdate.asp: <% if (!(crossoem == "yes")) { skipStart(); } %>
lib/webpages/fwupdate.asp: <input type="hidden" name="crossoem" value="<% writeEsc(crossoem); %>">
lib/webpages/fwupdate.asp: <% if (!(crossoem == "yes")) { skipEnd(); } %>
lib/webpages/fwupdate_bak.asp: <% if (!(crossoem == "yes")) { skipStart(); } %>
lib/webpages/fwupdate_bak.asp: <input type="hidden" name="crossoem" value="<% writeEsc(crossoem); %>">
lib/webpages/fwupdate_bak.asp: <% if (!(crossoem == "yes")) { skipEnd(); } %>
[...]

The string “crossoem” suspiciously looked just like a hidden html option. As a quick test, I wrote a minimalistic version of the firmware update form which included the additional (hidden) parameter. (It can be further reduced but the one shown below does the trick.) The page reloaded and now provided the firmware update option — and in this case also the OEM change I was looking for.

Warning: The following code might brick your device! Proceed at your own risk!

<html>
<head>
<base href="https://10.10.10.10" />
<title>Experimental IP-KVM Firmware Upload Form</title>
</head>
<body>
<form action="fwupdate.asp" method="POST" enctype="multipart/form-data">
<fieldset class="group">
<legend class="groupCaption">Firmware Upload</legend>
<br/>
<input type="file" name="firmware_file">
<br/>
<input type="submit" class="button" name="action_firmware_upload" value="Upload" align="left" style="vertical-align:middle">
</fieldset>
<input type="hidden" name="__templates__" value=" firmwareupload firmwareupdate">
<input type="hidden" name="crossoem" value="yes">
</form>
</body>
</html>

Side notes: The firmware update consisted of two firmware files that had to be uploaded consecutively. Also, you will need to adapt the base reference URL according to the IP of your switch.

After the update succeeded we were greeted with the new logo in the interface, and more important, with a VNC option:

Addendum

The only catch we’ve so far experienced after the update was that the two USB/LAN interfaces seemed to have switched positions.

Besides the hidden option “crossoem” there is a second one “crosshwid” which seems to disable cross hardware id checks. I consider this option dangerous and in our case it wasn’t necessary to set it as the hardware was identical.