I have been using UltraVNC for connecting to client computers for a couple of years now, and I've been using a single rc4.key for all sites. It's bugged me, but I haven't had time to deal with it until today.
This is my "Beta" release (v0.9) of my script for using a unique (and renamed) rc4.key for each server to which I connect. I use it the following way: I put the same key on all of a unique client's computer to which I have access, and I use ONLY that key when connecting to those computers.
I've attached the script (which does not have to be modified for use) and documentation. Please try it out and let me know how it could be improved.
(Of course, since this BB doesn't allow attachments--Version 3 does--I can't append them here. Drop me an eMail if you want them.)
Here's the "ReadMe:"
ReadMe.txt file for Connect.cmd
Version 0.9 Sept. 28, 2009
Copyright 2007, 2009 Carol Anne Ogdin (firstname.lastname@example.org)
Released under GNU General Public License v3; see
http://www.gnu.org/copyleft/gpl.html for a copy.
This script is designed for those who cannot use a single encryption
key for all situations. For example, in early rollouts of UltraVNC,
we used a single rc4.key for all clients, which leaves a potential
security "hole," in that employees of one client could, theoretically,
use that key to gain access to another client's computer system(s)
(with only the UltraVNC and Windows logon passwords keeping them out).
Most experienced UltraVNC users rely on uniquely-named *.vnc files
to make each connection. Everything UltraVNC needs to connect is in that
For most users, these *.vnc files all depend on the MSRC4plugin.dsm for
security, using a unique encryption key named rc4.key.
What isn't clear (and Sean Covel was kind enough to gently point out) is
that you can rename rc4.key to any name, and create an environment var-
iable that points to it. If, for example, you have clients Alice, Bob
and Celine, you can creat three unique keys, Alice.key, Bob.key and
Celine.key, respectively. The keys must be the same (albeit with dif-
ferent names) at both the Server and Viewer ends of the connection.
Of course, you could put all the *.vnc and *.key files, all together in
the UltraVNC installation directory, but that seems clumsy. What this
script supposes is that you have a FOLDER for each client, with three
1. Alice.vnc (or, whatever you choose to name it),
2. Alice.key (or, whatever you choose to name it), and
3. Connect.cmd (this script).
You must make sure there is exactly one *.vnc and one *.key, and one
copy of Connect.cmd in the folder. I choose to name the folder with
the client's name.
Before You Begin
1. At the UltraVNC server, select the MSRC4plugin.dsm as your encryption
model, then click on the adjacent [Config] button.
2. The first time you try, it will report you have no key. Create one.
That creates a unique new_rc4.key for this server.
3. Rename new_rc4.key to rc4.key, and restart the winvnc.exe service.
4. Make a copy of the rc4.key (to another medium; i use a USB memory
stick), and rename it to <client>.key (e.g., Alice.key)
5. That the new key back to the place from which remote access via
UltraVNC will be conducted.
Test the Connection
1. Temporarily rename an rc4.key in your UltraVNC execution folder
(if any) to something else (e.g., rc4.key.original).
2. Copy the new key, created above, to the UltraVNC execution folder.
3. Temporarily rename that key to rc4.key.
4. Launch winviewer.exe, configure the connection, and check the
option "Save connection settings as default."
5. Click the [Connect] button and confirm that you can connect to the
UltraVNC Server at the remote location.
Saving the Connection Configuration
1. While you're connected, right-click on the vncviewer icon in the
task bar (if it's not visible, you may have to minimize the con-
nection window to see it), and select "Save connection info as..."
2. Rename and save the connection file at a convenient place.
(You'll be offered the opportunity to save the password for the
UltraVNC server, which you may or may not choose to save in the
file, depending on your security requirements.)
3. Disconnect from the remote Server.
4. Clean up the environment by taking these steps:
a. Remove the rc4.key you temporarily created, above
b. Restore the rc4.key (if any) you may have saved before you
tested the connection.
How To Configure
Decide where you're going to store your connection information for
each Server you contact; I'll assume that folder is simply D:\ for
At that folder, create a unique folder for the name of the Server or
entity which whom you connect (e.g., Alice uVNC).
Now, copy three files that that folder (D:\Alice uVNC):
The (renamed) *.key that you copied from the remote Server, earlier.
The (renamed) *.vnc you saved while connected to the Server, above.
The Connect.cmd file (that this file documents).
How To Connect
Navigate to the unique folder you created, and click on the Connect.cmd
file. It will open the connection with the appropriate encryption option
This version of the script acknowledges ONLY the MSRC4plugin.dsm.
The script could easily be expanded to use other plugins, or even to
use any of the allowable three DSM methods defined at
http://msrc4plugin.home.comcast.net/~ms ... index.html
The Connect.cmd script writes output to a cumulative log, named Connect.log,
in the same folder as the command. If things go awry, this is the best
place to start to figure out what's happened.
There are two lines at the beginning of each script (after the configura-
REM set Assert=echo ***Assert:
set Assert=REM Assert:
If the first is marked with "REM", you'll only see a couple of lines in
each log file; if you move the "REM" to the second line, the first will
be enabled, and progress reporting (in the form of "assertions" that are
demonstrably true) will appear in the log.
If you would like to use a script in debugging mode, find the line that
contains "set debug="... and remove the REM in front. That will force
major actions that will change data to be reported, but not run.
The "set debug=" option inserts "echo WILL" before certain commands
that are then reported, but not executed. Only those commands that
would take significant time or make changes to your hard drive(s)
are changed to "debugging mode."
To run a script (say, "Connect.cmd") in debugging mode:
Open one window showing the script in an editor, and another window
running the command-line interpreter ("cmd"), type the following line
in the "cmd" window:
cmd /c Connect.cmd >testout.log
That will run the script, return to the current "cmd" window, and
show the history of execution in the "testout.log" file. You can
then read "testout.log" and "Connect.log" to understand what
happened (or would have) during execution of that script.
Return to the editing window, make changes, and rerun the command
until you're satisfied with the results
Be sure to undo your debugging changes after you're done, so they don't
interfere with proper operation.
The Version number is provided at the top of each script, and this ReadMe
For minor revisions, changes are noted here:
0.9 (090928) Initial release