Modified repeater (Source code)

[shadowfax]

Hello,

This is a fast modified version so don't expect nice code. ¿What does it do? Not much really...

When you connect from a VNC client (Not necesarelly UltraVNC Viewer) as if the repeater was a normal VNC Server, the repeater will ask for VNC Authentication. The password you must type to access the repeater is the repeater id. After entering the password/repeater id, the repeater will disconnect the session. If a VNC server was found with the repeater ID (Therefore the server must connect before the viewer connects), the ID is saved in a global variable. Now, when you connect again (same process) the repeater won't ask for a Password, since it will attempt to link to the server with the specified repeater ID.

If, on the second conection, you are asked for a pasword it could be due to the fact that the real VNC Server is asking for one, or the VNC server wasn't logged in when we supplied the repeater id.

For example, if I perform a reverse connection from the server using "ID:1234", when the repeater asks for a password I would type "1234" (NO "ID:" string). The viewer gets disconnected, I connect the viewer again... and I'm linked with the server with ID 1234.

This makes the repeater fully compatible with any VNC Viewer, including iPhone VNC viewers.

However, the code is just a proof of concept, since the global variable is only cleared after a succesfull second attempt. On the other hand, I don't really like it since multiple viewers could mess up (But could be suficient if there is only one viewer). However, code is not clean enough, and not very efficient since it has to compare performing a loop encrypting the available IDs and it even encrypts those with ID 0 (An IF could speed thing up a little)...

Oh well, if you wish to take a look, here it is:

A new project was started with more in-depth...
Please refer to: http://code.google.com/p/vncrepeater/

Compiles under Visual C++ 2008 (Under Window)
Compiles under G++ (Under Linux)

[shadowfax]

I've changed the link to the source code.

In this version the ID is stored in an array reusing a structure so the repeater ID is stored together with a timestamp and the IP address of the user who generated the Repeater ID. Therefore, the changes are as follows:

• Only a user from the same IP address as the one that inputed the Fake ID/Password will be linked to the VNC server.
• The repeater ID is deleted if it hasn't been used for 5 minutes.

You still have to login the VNC server into the repeater before the viewer can access the repeater. Hope it doesn't mess things up with ISP proxies.

[B]

Sounds like a great start. I hope to get a chance to test it.

[bigdessert]

has anyone tested this with Iphone VNC clients?

if this works I wish I knew how to port this to the linux repeater!

[shadowfax]

The repeater works with iPhone viewers.

Right now I'm working on another version in order to establish the connection directly (without the hazzle of disconnection after setting the ID through the password). I'll talk more about it when it is ready, but as an advance it is a re-write in console mode (No graphic interface), with some precompiler conditionals so it can be compiled for Windows or Linux.

As of the version that I've published so far and its use with an iPhone viewer. Let's say for example you are using Mocha VNC Lite. You would click on"menu" -> "Edit connections"... Add your server and in the setup make sure "Save password(s)" is disabled. Hit connect and the settings view will come back up... Type the repeater ID you wish to use, for example "1234" and make sure the server has already connected to the repeater using that ID (doesn't work if the server is not previousliy connected, that is going to be fixed in the next version)... hit connect and... you'll get disconnected. Hit connect again BUT this time leave the password blank (No authentication) or enter the password required by the "real" server and you'll get connected to the VNC server.

I hope to get thing easier on the next version.

[bigdessert]

wow this is all so far over my head. Cannot wait until the next version though then maybe I can talk the boss into getting me an iphone for doing remote support.

[shadowfax]

In order not to post new links every time, I've created a new google code project to host the source code. The new version is available at:

http://code.google.com/p/vncrepeater/

What's new
I've re-written the VNC repeater using code from UltraVNC's Repeater and Jariko's Linux port of the repeater. Although it still won't compile under LINUX, some precompiler conditionals have been set to make portability easier (Hope to have that ready as soon as the Windows version is fully implemented).

The repeater ID is fully implemented using the standard RFB Protocol. In order to do so, I've used the VNC password to set the repeater ID, so you have to type in the repeater ID as a password when connecting to the VNC Repeater. The repeater ID is, therefore, limited to 8 characters (VNC password limit). Right now it is only working with numeric IDs.

The server must NOT request VNC authentication to the viewer when connected through the VNC repeaeter as the authentication is used to set the repeater ID. However, when UltraVNC's server connects to the repeater it does it this way.

I've also included the latest binary on the downloads page of google code in case someone is interested on testing it without having to compile the source code.

Looking forward to hear your comments, suggestions,...

[shadowfax]

Bigdessert: I'm a freelance and one of the jobs I offer is remote support (Programming services as well, although most of the work I've done so far has been .NET and PHP). My goal with this project is being able to give remote support to the customer from my iPhone if I'm outside of the office. My first goal was being able to connect to the repeater from the iPhone... Right now I can manage to do so, although I need to make slight improvements over the actual version. My second goal is to be able to run the repeater from a Soekris or a WRT54GL router (Or any other router that supports open firmware)... That means it shall be ported to Linux.

Since I was writting this code from scratch (Although copy-pasting) chunks of code from UltraVNC's repeater and Jarko's Linux port, I've added some precompiler comments to keep things cleaner. Right now the code won't compile under Linux since I've reused UltraVNC's include files for VNC Authentication (It uses some API calls), however it may compile using libvncauth (I don't know yet how the functions are prototyped on this library).

I thought other people could be interested on a project of this kind so I decided to publish it... Source code has been published as well not only fue to the fact that it is based on GPL software, but also, since I'm not proficient on C/C++, so other people may contribute to make it better.

Best wishes

[bigdessert]

Bigdessert: I'm a freelance and one of the jobs I offer is remote support (Programming services as well, although most of the work I've done so far has been .NET and PHP). My goal with this project is being able to give remote support to the customer from my iPhone if I'm outside of the office. My first goal was being able to connect to the repeater from the iPhone... Right now I can manage to do so, although I need to make slight improvements over the actual version. My second goal is to be able to run the repeater from a Soekris or a WRT54GL router (Or any other router that supports open firmware)... That means it shall be ported to Linux.

Since I was writting this code from scratch (Although copy-pasting) chunks of code from UltraVNC's repeater and Jarko's Linux port, I've added some precompiler comments to keep things cleaner. Right now the code won't compile under Linux since I've reused UltraVNC's include files for VNC Authentication (It uses some API calls), however it may compile using libvncauth (I don't know yet how the functions are prototyped on this library).

I thought other people could be interested on a project of this kind so I decided to publish it... Source code has been published as well not only fue to the fact that it is based on GPL software, but also, since I'm not proficient on C/C++, so other people may contribute to make it better.

Best wishes

Well I can't contribute much other than some beer!

[shadowfax]

If you come over to spain beer is welcomed

[vcka]

Yes if linux version will come out, it would be perfect day in our lifes ;]

[shadowfax]

Although the repeater is working fine, it does not exit gracefully... I'm trying to fix this issue. While doing so, I've changed the VNC authentication files for those used in the Linux version of the VNC server, so I hope the next version -when ready- will compile under Linux.

When the next version is ready -probably next week) I'll tell you in this thread, hope it will compile under Linux as well.

[bigdessert]

now I just need to talk the boss into getting me an iphone for testing...

[shadowfax]

Hello

The LINUX version will still have to wait, I'm having a bit of trouble understanding how "fork()" works and if it would be better to use threads or processes under LINUX, and there are still a few things I would like to change in the code before finally preparing a LINUX release. I'm still running away form the Windows API to keep portability as easy as possible.

By the way, something I hadn't said before... The repaeater would just work on mode II, that is, with the "ID:xxxxxx"... I don't see how in would be possible to insert an IP Address in the 8 characters the VNC password allows. Maybe using HEX format? For example. 192.168.1.1 = "C0A80101"? I really think it would be complicated for the end user and I'm not really sure if people are using MODE I... I always use MODE II.

So... Anyone using mode I?

[bigdessert]

I only use the mode where you enter an ID number and the repeater matches it.

[B]

I'm still a bit mystified by the various repeater modes. I rely on ChunkVNC and SCPrompt as my "gateway drugs" in figuring out how best to use the repeater. They both expect a numeric repeater ID.

As to possible IP address encoding, (a) I think it would be valuable, and (b) there are several ways to do it. As you said, hex would be fine. But so would hashing of some kind, and so might a guess / brute force lopping of octets, in many circumstances.

Or how about this -- let's say you need to keep it numeric.

Just convert the dotted decimal IP address into straight DECIMAL, and truncate the two leading digits.

The LARGEST address is 255.255.255.255 (more or less) and that's represented as only a TEN digit decimal number, 4294967295. It's almost, almost always going to be okay to truncate the leading two digits.

Anyway, as noted, great idea to kludge it the way you describe.

[shadowfax]

Different modes:

MODE I The viewer connects to the repeater supplying an IP Address. The repeater then opens a connection to the specified IP address. This mode is used to open one port to the Internet giving access to multiple VNC Servers behind the router.

MODE II The mode where you supply a Repeater ID. Usually used for remote support.

I really don't find MODE I that usefull since I always use a VPN connection to acces the VNC servers inside a local network. But if someone REALLY finds it useful I could try to implement this on the repeater.

Yes, reapeater IDs are always numeric. The original repeater stores the ID as a numeric value. I guess it does so to save memory. On the other hand my version of the repeater stores IDs as "strings" (Although it will only match the numeric IDs due to the way the server identifies, it would require a MOD to allow the server to send alphabetic chars). There are two reasons why I do this:

• Less CPU cycles to match the server (since it would have to des encrypt the ID of each server until it finds a match).
• Since the DES cypher is not reversable (since the ID is the password to encrypt), it would be impossible to establish the viewer connection before the server has connected.

Right now I was searching for a way to lower memory usage... I'm looking at the possibility of using linked lists instead of fixed arrays... Also thinking of using a mutex or semaphore to keep only one list, instead of the server and the viewer list (duplicate list doubles memory usage).... The code I store right now is 33 bytes long (32 + NULL) while the original version stored the ID in 4 bytes. Using a single list would more or less make the same memory usage... Plus it support 8 character alphanumeric IDs (If the server gets modified).

In order to keep IDs known the challenge key sent on the challenge response, is always the same (It generates the random challenge key) when the repeater is started but then keeps the same ID. It shouldn't be a security threat compared to the original repeater as the same security threat exists if the repeater ID get's sniffed. That's the reason why I would suggest keeping the viewer port hidden behind a VPN.

I wanted to fix such issues before going for a LINUX port.

[shadowfax]

Got some bad news and some good news...

Bad news
Although the repeater is working, there are still some possible memory leaks. Some have been corrected by trpping CTRL-C, but still looking if there are any leaks left behind.

Good news
Now compiling under LINUX.

Download the latest source code... I would suggest downloading from the subversion repository as I don't update the snapshot every time. Hoever, if you downloaded the snapshot unzip it (Sorry about that, no gzipped tar right now). Go into the sub folder "repeater" and just type "make". You should now have an executable file named "repeater" inside that subfolder... so just type "./repeater" and it should start.

To compile under Windows, just the same way as before... Open the project in Visual C++ and compile.

Please, contact me if you find any bug, memory leak,...

[shadowfax]

New update...

The new version starts to differ from the original version. Compiles under Windows and Linux cleanlly. Binary files for Windows and Linux have been updated.

What's new?

• The repeater should close cleanlly when CTRL-C is pressed.
• The memory usage has been lowered (I'm using linked lists instead of fixed arrays).
• You may now define what ports the repeater will be listening to.

Usage: repeater [-server port] [-viewer port]

If no arguments are supplied, the repeater will listen at port 5500 for server connections and port 5900 for viewer connections. You can now change one of the ports or both of them, for example: "repeater -viewer 5901" would set the por listening for viewer connections on port 5901.


Hope you enjoy it. Comments and suggestions are welcomed.

[bigdessert]

am I correct in saying that the linux version does not support encryption?

By the way testing the linux version everything seems to be going great with it.

[vcka]

Does linux version supports auto reconect from server side?

[shadowfax]

That's right... If you wish to use encryption the easiest way to go is using an SSH tunnel. Let me explain...

In order to select the repeater ID through the password, the repeater acts as a standalone server during the hanshaking phase up to the last stage where the client and server exchange their initialization messages. Encryption takes place at an earlier phase. Precisely it takes place at the authentication phase used to exchange (In this case) the repeater ID.

Since the viewer can connect before the server has connected there is no way to know if the server will allow encryption. On the other hand the repeater authenticates to the server as "No authentication required", therefore the server sends unencrypted data. Since the authentication schemes are hidden through the repeater the only possible way to allow encryption is to implement the encryption at the repeater (for example, adding VeNCrypt support) BUT the repeater would slow down since one of the sides (Server-Repeter or Viewer-Repeater) could allow this authentication scheme but the other side wouldn't allow it; therefore the repeater should decrypt incoming data, look at the other point and reencrypt it or send it unencrypted depending on its capabilities. IMHO this would downgrade the repeater's performance and therefore I don't think it's worth implementing encryption... If someone thinks otherwise I'll take a look and I could add a precompiler condition to accept the most commonly used encryption scheme.

I think the best way to go would be adding a VPN tunnel for the viewers (Not exposing the viewer port to the internet as a security measure)... and the server connections can be tunneled through SSH if encription is desired.

Openminded to other suggestions or ideas on how to face this "problem".

[shadowfax]

vcka, not yet

When one of the connections closes (Server or viewer side) both ends get disconnected to free the repeater slot. Correct me if I'm wrong, but what you are looking for is: if the server get's disconnected from the repeater -maybe because of bad coverage when connected through a mobile network- that it will reconnect to the repeater but keeping alive the viewer. Is that correct?

If it is so, I'm planning to make this happen but I have to implement something like the "timer" of the original version to free idled connections. Once this is done, modify slightly the code so the viewer doesn't get disconnected if the server exits (Already made some code changes to make this easier to achieve once the timer has been implemented).

[YY]

Hi! shadowfax,

Very happy to discover your modified repeater. Your idea is great. (extend the listening port of the uvnc server with its mode II operation, so that overcome the limitation of a port-forward-not-allowed router)

New update...

The new version starts to differ from the original version.....

For your 1st released repeater, when a server connected, the repeater will log with a message of:
Add_server-list(): Server added with ID .............

(and so does the viewer)

For this new release, this feature is gone.
Why remove this feature, I think this message is very useful for monitor purpose of the operation of the repeater.

The repeater ID is deleted if it hasn't been used for 5 minutes.

In my test, the repeater will not remove a viewer/server after 5 minutes, even they never meet & connect their counter party with the matching ID, but some users may like this feature. It will be best if this timeout can be configurable.

[B]

Openminded to other suggestions or ideas on how to face this "problem".

Have you thought about opening a second door into the repeater, one that accepts registrations via https? I realize that what makes your idea so cool is that it works with all VNCs out of the box without additional layering, but a repeater ID reservation process via http or https would be convenient as an adjunct.

It would need its own logic and timeout, of course, but it would mean that some of the initial encryption worries would disappear (nothing would be in plain text) and viewer and server could themselves use any encryption or none at all.

[ Of course what I'm secretly wanting is full repeater management capability, viewing and picking from available attached targets by ID and name, etc. in GoToMyPC/LogMeIn style. I think the ChunkVNC dev is working on at least some of that, using the x11vnc Perl repeater. ]

[shadowfax]

First of all thanks for your suggestions and I'm glad you find the repeater usefull. Hope we all get the repeater working and stable enough. The only way to do this is by testing it so I really appreciate you are trying the repeater so it can be tested in a much more efficient way. The more people using it it will be easier to trap any possible bug.

For your 1st released repeater, when a server connected, the repeater will log with a message of:
Add_server-list(): Server added with ID .............

(and so does the viewer)

For this new release, this feature is gone.
Why remove this feature, I think this message is very useful for monitor purpose of the operation of the repeater.

The verbose output will be back, probablly defining the verbosity level. One of the reasons I didn't place them back in was a dessign error. On the first version I was converting the encrypted data to HEX in order to show the debug information and I kept the hexed string in memory. This took 32 bytes of memory per ID. Now I only store the encrypted string so the memory usage for repeater ID has been cut in half (Plus I only mantain one structure instead of two, so it is even lower). If the first character is a byte with value equal to 0. It won't show up, so I have to bring back the HEX value (Although it isn't stored). I hope to add even more verbosity to make sure everything is doing what it is supposed to do and giving the hability to the user to set how verbose the repeater should be.

In my test, the repeater will not remove a viewer/server after 5 minutes, even they never meet & connect their counter party with the matching ID, but some users may like this feature. It will be best if this timeout can be configurable.

That's right... That feature was implemented in a previous version where I sticked closelly to the original VNC repeater but, once started to focus it another way, I took away the "timer" thread. I want to bring the timer back into the application but I've been looking over for the main functionality to start working as it is suppoed to be before adding more code to the application. Right now the application is structured in different files and I think it is about time to get it back in... However, I'm still thinking on creating a new file called "Threading" and creating a WIN32 and a POSIX file for it (Loading one or the other depending on the platform)... Winsock vs BSD sockets is easilly managed through precompiler conditions but the differences between processes and threads between Linux an Windows are a bit more complex. So right now I'm a bit uncertain on which way to go first...

Have you thought about opening a second door into the repeater, one that accepts registrations via https?

Yes, I've been thinking about it but I keep bumping into problems. The only way this could be functional is by creating an HTTPS server that would bring up an interface whith the IDs and create an AJAX client for the different IDs. The AJAX client should take into consideration a mobile client probably doesn't have a keyboard and place a softkeyboard on screen when the images are shown. However I'm not proficient enough in C/C++ for image manipulation to make this work.

If you only reserve the ID through the HTTPS interface some new problems come to live. One comes up from the user experience as the user needs two connections to establish the VNC sessions... However, as you stated, it would solve some problems like the 8 character limit of the VNC password, the output of the connecting viewer would be clearer, there could be encryption (Although I think the VNC server should be modified to acomplish this as I think it always connects with no authentication), etc...

But there are also other considerations from the security point of view. One of the biggest threats I've considered is the Internet Service Provider Proxies. Some users, even mobile device users, are being routed through proxies which could lead to two people with the same IP address. If the ID is reserved to an IP address this could lead into collisions where two users reserve a diferent ID but one of them could a session that was not requested (Entering the other user's request). Further more, if the servers are connecting with no authentication (UltraVNC seems to be connecting with no authentication for example) it could make an attacker using your same proxy gain access to those servers. Right now this is harder since he could resend the repeater ID (if sniffed) but as the slot is in use he wouldn't gain access. I know there are ways to retrieve the "real" address in the HTTP protocol but I would have to stick to the public IP address as there is no way of retrieving the real ip address through the RFB protocol. Another problem is that some mobile networks change proxies and, therefore, the IP address could be changed between the HTTPS reservation and the VNC login (Haven't seen this so often but I've read of things like this happening with PHP sessions that store the public IP address for security). This is the main points why I always bumb against a closed door... Due to security concerns the VNC session should be established right away. Therefore the only reasonable way I've found to do it through HTTP is an AJAX VNC viewer.

However, if you wish encryption on the VNC connections, establishing an SSH tunnel would do the job and it wouldn't imply new security threats. There are quite a lot of document on SSH port forwarding to make the repeater stand behind SSH... And there is also quite a lot of documentation on how to make an application talk SSH. In fact, one of the projects I have in mind right now is making my own HelpDesk VNC Server stripping things away from the VNC Server and adding SSH capabilities for the reverse connection. What I'm really up to is compiling the repeater on an openfirmware router (Probably OpenWRT or DD-WRT) and implement StrongSwan and XL2TP (Don't know yet if this is possible without hardware hacks) that would allow me access to the private network and to the Viewer port of the repeater. On the other hand install OpenSSH and tunnel the reverse VNC server through SSH against the repeater.

[B]

Great response; thanks!

On those Linux-based routers, at least, couldn't you just run x11vnc, which <b>itself</b> can act as a repeater?

http://www.karlrunge.com/x11vnc/faq.html#faq-reflect

I may have more to add as I try to further digest what you've said.

[YY]

@shadowfax,

Thanks for your detail explanation.

Just another two suggestion:
1. Able to run the repeater as service.
2. Make sure no [topic=15187]Nagle Algorithm delay[/topic] issue.

[vcka]

vcka, not yet

When one of the connections closes (Server or viewer side) both ends get disconnected to free the repeater slot. Correct me if I'm wrong, but what you are looking for is: if the server get's disconnected from the repeater -maybe because of bad coverage when connected through a mobile network- that it will reconnect to the repeater but keeping alive the viewer. Is that correct?

If it is so, I'm planning to make this happen but I have to implement something like the "timer" of the original version to free idled connections. Once this is done, modify slightly the code so the viewer doesn't get disconnected if the server exits (Already made some code changes to make this easier to achieve once the timer has been implemented).

I mean, then session ends, both ends gets disconnected. But if server is running whit option -autoreconnect it must reconnect with same ID-password. In this case it doesn't. Maybe it's because server gets wrong disconnection string?

[shadowfax]

On those Linux-based routers, at least, couldn't you just run x11vnc, which <b>itself</b> can act as a repeater?

Disn't know it could run as a repeater... Does it allow MODE-II (ID based reapeating)? I guess, in case it allows it, it would still need to be modified in order to allow this kind of hack for a standard client such as iPhone clients and so on.

Just another two suggestion:
1. Able to run the repeater as service.
2. Make sure no Nagle Algorithm delay issue.

On the next version it will be possible to disable the Nagle Algorithm. Some sites say disableing the Nagle Algorithm could lead to some unexpected troubles therefor it will be optional.

In order to enable/disable the Nagle algorithm (and considering your request for the repeater to run as service), I've included a configuration file. I don't wish to work with the registry in order to keep most of the code platform independent. However, in order for the application to run as a service there should be changes to the output and the repeater should be able to write to a log file. Therefore don't expect this feaure on the next version, but I'll try to build it in a future.

By the way, since I find the encrypted ID not really usefull and I can't find a way to get the clear ID from the viewer, I've changed the string when a Viewer or a server connects to the repeater in order to show the IP address. Something like "Viewer connection accepted for 127.0.0.1". It will be released on the next update.

I mean, then session ends, both ends gets disconnected. But if server is running whit option -autoreconnect it must reconnect with same ID-password. In this case it doesn't. Maybe it's because server gets wrong disconnection string?

The "-autorecconnect" feature is implemented on the VNC Server. It should work with the repeater. My testing environment is as follows: Windows Vista running UltraVNC Server 1.0.8.2, UltraVNC Viewer 1.0.8.2, Repeater running on Windows Vista (or repeater running on a virtual machine with GNU/LINUX Debian 5)... Also testing from iPod Touch with a free, view only, VNC viewer. The "-autoreconnect" feature of VNC Server is working.

Maybe the problem arises from the VNC Server you are using or maybe it is a bug in a previous version of the repeater (Server socket not closing up cleanly). If it is a bug of the repeater it will be solved on the next version as I'm getting no trouble with it.