View the Video

Learn how to remotely enable RDP Terminal Services on remote computers using VNCScan!

Twitter This

UserName: Password:

This is the second release in a week from Bozteck.  Here’s what’s in this one:

Twitter This

UserName: Password:

From the release notes:

• Interface updates

  • Updated the Outlook styke group box for the Managed Groups so that you can collaps and expand it using the << button.  This allows for more screen real estate.
  • Speaking of real estate, you now have a new (default) sizing option for new RDP connections. You can now choose to automatically size the remote screen resolution to match the size of the tab window.
  • You can now select multiple items in the list window and RDP to them in mass.
• Fixed a bug that made the vncmanxp.exe bomb out on some XP boxes
• Many other smaller interface enhancements and bug fixes.

Here are some screen shots of the interface changes:

You can grab the latest release HERE.

Twitter This

UserName: Password:

In the early years of VNCScan, all of the data was stored in a Microsoft Access database and the settings were stored in INI files.  This worked well but required that I distributed a lot of additional runtime files to access the database(pardon the pun).

In late 2003, I decided to move away from Access in favor of flat XML.  To this day, I still debate with myself which was better because each have their issues.  The XML file format for data made it possible to ship a smaller product with less dependencies but it severely limited the multi-user capabilities for sharing data.

The XML format is just plain text files. When one console reads the data and then writes a change, there’s a chance that another console that is also reading from that same textual XML file can write back what it thinks is accurate data and overwrite the first consoles changes.  It can get messy real fast.

At least with the Access database, you could have a few users adding and reading data at the same time without overwriting the whole file just for one change to a single field. 

I realize that Microsoft is steering its developers to their mini desktop SQL server instead of Access but it just seems like a lot of overhead for the type of data being stored. 

Today, all of the routines needed to read and write to an Access database is built into the existing DotNet Runtime.  What drove me to this XML format is no longer a problem. 

So, what do you think?  Should we make the move back to the Access database to facilitate a better multi-user experience or stick with the XML?

Twitter This

UserName: Password:

There are currently a number of websites that are hosting cracks for the latest version of this software. I want to put out an alert to anyone who may try it out that their “crack” contains a pretty nasty trojan that lets them spy on your computer and use it as a zombie. I guess that’s the risk that you always take when using keygens and cracks. This one in particular is really nasty, though.

With that being said, I also want to let everyone know that Bozteck isn’t some huge company that the Pirates are “sticking it to”. Every license purchase puts food on my family’s table and every theft of the software is felt by the entire family.

I work as hard as I can to support this software even better than those huge companies that compete with Bozteck. VNCScan costs a tiny fraction of what theirs does, too! While I don’t believe that all software should be free, I believe that it should be affordable by all. That is why the price is only $59 for the per-admin license. I also refuse to charge for each managed computer. With that one per-admin license, you can manage thousands of computers at no added costs.

If my hard work has made your life easier in any way, please consider buying a very inexpensive license for this software. My whole family thanks you.

Steve Bostedor
VNCscan Author

Twitter This

UserName: Password:

We put out an update to the VNCScan Enterprise Network Manager tool yesterday.  This is considered a refresher update with some bug fixes wrapped in.  There is significant development happening in the beta builds but it’s not ready for public consumption yet.

The biggest news with this update is the new release of UltraVNC server and viewer.  We’ve seen a very nice increase in screen performance and stability in this release of UltraVNC.

The deployment tool had been upgraded to deploy this new version seamlessly.  There is no need to recreate your deployment profiles that were configured to deploy the previous 1.0.5 release.

Twitter This

UserName: Password:

We’ve had a lot of request for the ability to automatically reconnect to computers when they are rebooted.  A majority of the requests were resolved with the implementation of the background scanner and the actions that can be performed when the scanner detects that the computer is alive.

To take this a step further, we’ve modified the ping window that happens when you right-click a computer and choose “Ping Computer”.  Instead of just opening a command window with the standard ping command running, we’ve designed our own.  We’ve done this in order to bring you an exciting new feature – automatically running commands or connecting when a computer responds for X number of consecutive pings.

Here’s a quick video showing how: http://screencast.com/t/CqJI7YhE

Download the latest version here!

Twitter This

UserName: Password:

Introduction

Bozteck VENM Console can deploy UltraVNC with session level encryption enabled. This is recommended in network environments where you fear that your VNC session may be “sniffed” from the network and replayed back without your knowledge. The risk of someone successfully doing this on your LAN is very low as it does require a moderately high level of “hacker skill”. Some networks, however, need extra protection even against low risk attacks such as this.

This document will explain the principles behind the VENM supported UltraVNC encryption as well as how to deploy and enable it from the console. The skill level to use this information successful varies. If you simply accept the safe defaults, the skill level required is low. If you choose to make modifications such as creating a custom rc4.key file, the skill level required is much higher.

This document is for Admins who want to customize the encryption, get to know how it works at a lower level, or are having DSM errors when connecting to an encrypted server. Anyone else can skim through or read this document as they wish.

Basic Principles

vncviewer.exe –> {RC4.KEY} ===> (Network) ===> {RC4.KEY} ==> [msrc4plugin_noreg.dsm] –> winvnc.exe

There are two key files that are fundamental to UltraVNC session level encryption and they are “msrc4plugin_noreg.dsm” and “rc4.key”. These will be refered to as the DSM and KEY files respectively through the rest of this document.

When a vncviewer.exe file wants to talk to an UltraVNC server that is set to use encryption, it starts by looking for it’s copy of the KEY file. If found, it encrypts it’s connection attempt using the data in the KEY file. It, then, sends a connection request to the remote server using this encrypted mode of communication that would seem like garbage to anything else on the network.

On the other end, the server hears a connection being requested. Because it is also configured to require encryption, it consults it’s copy of the KEY file and uses the data in the KEY file to decrypt the communication request coming from the viewer. If the keys match up, the data is correctly deciphered and the two commence communication in this encrypted tunnel.

If the keys do not match, the connection attempt is rejected and the viewer presents an error to the user stating that possible reasons could include the failure to find a DSM file and a few other suggestions. The error message is vague but it pretty much just means that either:

• The remote server is not configured for encryption but you are sending an encrypted request
• The server is configured to require encryption but you are sending an unencrypted request
• Both ends are configured for encryption but the KEY files do not match

More About the KEY and DSM Files (Server End)

The DSM file is a plug-in to the winvnc.exe service file. For reference, the winvnc.exe is the actual server executable for UltraVNC that is deployed to the remote computers and installed as a service. The DSM file must reside in the same folder as the winvnc.exe file. Don’t worry too much about that because the Bozteck VNC Deployment Tool does that work for you. When the DSM file is in the same folder as the winvnc.exe file and the configuration for the server has been properly set, the server will attempt to encrypt communication for any client that attempts to connect to it.

The KEY file also must reside in the same folder as the winvnc.exe file. The Deployment Tool also make sure that this happens as long as you do not modify things too much. If you simply tell the Profile Editor to enable encryption, it takes the KEY file that is located in c:\fastpush\vnc7\ultra and copies it to your Deployment Profile’s folder for easy deployment every time that you push that profile out to a computer.

Because this KEY file must match the KEY file on the Viewer end, it is best practice to only use one KEY file for your entire network. You do not gain sufficient security advantage by using multiple KEY files to make up for the headache required to keep them all straight and matched up. If you choose to generate a new KEY file, you must push that new KEY file out to each and every computer on your network that has encryption enabled to ensure proper connectivity.

By default, the UltraVNC Server is installed to either “C:\Program Files\orl\vnc” or “C:\Program Files\ultravnc” depending on the version of UltraVNC you are using. If you choose to distribute the KEY file using some method other than a VNC Push from VENM, it must in somehow make it’s way into that path on the remote computer end. Again, the VNC Push from VENM does this for you.

More About the KEY and DSM Files (Viewer End)

The KEY file is required to be in the same folder as the vncviewer.exe file. This KEY file must be an exact copy of the KEY file that is located at the server end as described above. By default, VENM uses the vncviewer.exe located in “C:\Program Files\Bozteck\VNCScan Console .NET” or whatever location you have installed VENM to.

You have the ability to customize the location of your vncviewer.exe file using either the main preferences (Support Files section), group properties (VNC Settings section), or the computer properties (VNC Settings section). If you choose to modify the location of the vncviewer.exe file, you need to make sure that a copy of your RC4.KEY file is moved with it.

Creating Custom KEYs

The Profile Editor has a button in the “Customs” section that allows you to generate a new key. This is an advanced level function and should never really need to be done in normal circumstances. To my knowledge, there has never been a tool released that allows someone to decrypt an encrypted UltraVNC stream for later playback. You should only need to generate a custom key if this is ever done. The KEY file does not control who can access you server. It only controls the way that the session is encrypted. You will still need to authenticate with the remote server using your password even if the KEY files match up.

If you do choose to create a custom KEY file, pressing this button is the easiest way to make sure that everything is placed in the correct locations for easy deployment. You may need to manually copy the new KEY file to the location where your vncviewer.exe resides, however. The newly generated key is always placed in c:\fastpush\vnc7\ultra.

Conclusion

I hope that this was a good in-depth overview of how the UltraVNC encryption works and how it interacts within the Bozteck VNCScan Enterprise Network Manager (VENM).

Twitter This

UserName: Password:

I just wanted to put out a quick blog post to let you know about a couple of new updates.

First, the VNCScan 2009.2.10 package has been updated to deploy the UltraVNC version 1.0.5.3 server and contains the latest 1.0.5.4 version of their viewer. You can download it here.

I also wanted to point out that we’ve updated the link for the recommended TCPIP.SYS patcher for Vista. The link is on the download page or you can just click here.

Twitter This

UserName: Password:

Important Information

There has been a serious integer overflow vulnerability found in the UltraVNC viewer with versions 1.0.5.3 and earlier. There is more information about this vulnerability at Core Security.

Notice that this is for the viewer only. The server is not affected by this bug.

Solution

The easiest way to upgrade the viewer is to upgrade to the latest release of VENM Console. This version uses the patched viewer and is safe.

Alternatively, you can manually update your vncviewer.exe by performing the following steps:

1. Download the zipped viewer here
2. Unzip the vncviewer.exe into the following places:

• “C:\Program Files\Bozteck\VNCScan Console .Net”
• “C:\fastpush\vnc7\ultra”

Thank You,

Steve Bostedor
Bozteck VENM Support

http://www.vncscan.com

Twitter This

UserName: Password: