De-ActiveX-ifying an ActiveX Component

Some ActiveX components add “enhancement” to the browser by dropping in custom controls for forms or other fanciness. Those types of components require the browser, because they augment the user’s experience within the browser. Other ActiveX components are little more than a standalone executable that can get it’s command line arguments from the web page that serves it. This article is about my experience separating out such an executable from it’s ActiveX constructs and using it without Internet Explorer.

I have an old APC AP5456 IP Gateway for Analog KVM, it’s a neat little device other than it’s insistence that I use Internet Explorer. It uses an ActiveX component to view the remote consoles. It’s based on VNC, and has some encryption of the RFB data added in. The device listens on port 80 (http) and 5900 (VNC). If I had any doubt after seeing the port number, it was cleared up in the “About…” dialog.

Unfortunately, I couldn’t just use a regular VNC client to connect. The authentication process has been removed from the VNC-side of things and moved to the web page. When you authenticate to the web page of the IP KVM, it gives the ActiveX component an authentication token which is used to view the console of the computer it’s connected to.

When you first login using a web browser you’re shown several options. The one we’re interested in is “Connect Video”

After clicking “Connect Video” we’re taken to another screen where the ActiveX component should normally be launched. I’m using Firefox in this screenshot so it fails. Most browsers other than Internet Explorer have no idea what to do with ActiveX (and rightfully so).

This page will meta refresh back to the previous page, so quickly select the option to view the source (Control+u in Firefox).

I searched the page for the <OBJECT> tag that normally holds the ActiveX details. Here is the relevant portion.

<OBJECT CODEBASE="vpclient4187.cab" width=0 height=0  CLASSID="clsid:09D6F55E-F235-4187-9C60-1D09CFD9FAFF">
  <PARAM NAME="ipaddr" VALUE="172.20.10.171">
  <PARAM NAME="sessionkey" VALUE="0688565E0688565EFA72032A87995D28" >
  <PARAM NAME="encryptionkey" VALUE="68F0585E68F0585E6BBA4AE3E6EF95FA">
</OJBECT>

The first thing to notice is the vpclient4187.cab cabinet file. Unpacking the cab file gives us AvocentHTTP.dll, vpfilexfer.dll, launchEXE.dll, vpclient.inf, vpclient.exe, and vpclient.dll. Awesome! It’s probably just that vpclient.exe I need to run right?

Well, no, unfortunately typing in the IP address of our IP KVM appliance into the dialog doesn’t result in a connection. We need that authentication token and encryption key to be included in the picture. It still seems very likely that vpclient.exe is what we want, but there’s more configuration that it clearly needs. Since there are no other settings in the dialog of vpclient.exe to adjust, we’ll optimistic assume those missing requirements are passed to it by the command line. The information could be passed to it by Windows messages, after all it’s not the first thing that gets called from the web browser. Looking at the contents of the INF file shows that launchEXE.dll matches the CLASSID of our object codebase. That dll probably gets all the details and hands it off to vpclient.exe. Before we freak out, lets try to keep it simple.

I wrote a little program to display a message box with the contents of any command line arguments it receives. From a Windows XP computer with Internet Explorer I connect to the IP KVM as normal, and then close the KVM application and Internet Explorer. This causes the ActiveX object to get downloaded and cached. Cached in %WINDIR%\Downloaded Program Files to be specific. I replaced the vpclient.exe with my own application (keeping the name the same). You will need to do this from the command line however, as Windows treats the %WINDIR%\Downloaded Program Files directory in a special way, which blocks you from seeing the actual files contained in it.

When I reopen Internet Explorer and attempt to connect with the IP KVM again, I see that my speculation was correct.

The Session Key and the Encryption Key change frequently, and require the vpclient.exe connection to come from the same IP address that authenticated to the web browser, but if we act quickly we can start a session using the information available in view source as command line arguments to vpclient.exe.

C:\Documents and Settings\Administrator\Desktop>vpclient.exe -k [Session Key] -e [Encryption Key]  [IP Address]

Of course the reasonable thing to do at this point is to make a front-end client to connect to the IP KVM web page, parse out the required content, and launch vpclient.exe with our argument. I’ll leave that up to you, but if you’re interested in doing it under Linux I’ve got you covered.


Posted

in

,

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.