3

I am in the process of reverse engineering an existing system in an attempt to replace their existing TightVNC applet with something else (hopefully NoVNC if at all possible).

So far, here is what I know...

  • Debian server
  • OpenVZ linux VMs inside of it that runs apps on-demand for users
  • Users connect to OpenVZ VMs via generated parameters (TightVNC uses these)

I've been able to connect using the TightVNC Java jar using connection params like this:

java -jar VncViewer-20070502-01.jar
    HOST myhost.com
    PORT 443
    ENCPASSWORD 234f92c02c3b128e
    CONNECT vncsession:0c5a727371e5d10e3147566e389b28c3
    DisableSSL No

I believe that this connects to the server using an HTTPS proxy and then reroutes to a specific OpenVZ session, but I cannot be 100% sure of the process. I am unable to ping vncsession from the Debian server or the OpenVZ instances, so I'm not exactly sure what it even is.

Some of these parameters are covered in the TightVNC README - but not all of them.

Right now I am facing two problems...

  1. ENCPASSWORD is a non-standard parameter as far as I can tell. Through decompiling the TightVNC jar I can tell that this is simply decrypted back into plain text, so I have no idea what the purpose of this is... The passwords are randomly generated in the first place.
  2. I have no idea how CONNECT works, or how to use it on any VNC client besides TightVNC. I believe it has something to do with the proxy routing.

Can anyone help me understand these parameters, especially the CONNECT parameter? Any additional help with using another VNC client in place of TightVNC would be appreciated as well. Thank you!

jocull
  • 211
  • 2
  • 8
  • After some additional digging into the TightVNC source I'm seeing that this may have been modified and recompiled... making this entire VNC viewer setup non-standard. This could explain my difficulty in figuring out how it works. – jocull Mar 21 '12 at 20:04

0 Answers0