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...
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.- 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!
0 Answers