Modified repeater (Source code)

[vcka]

After several time closing viewer i've got this log:
UltraVNC> Viewer connection accepted from 127.0.0.1.
ERROR: Trying to allocate an empty slot.
^C
Exiting VNC Repeater...
FATAL: Failed to free repeater slots.

[shadowfax]

You can ignore the fatal error while exiting the repeater since the slots are being freed but I missed to decrement the counter at one spot of the code. I'll be fixing it in the next release.

I'll look what could be throwing the "ERROR: Trying to allocate an empty slot".

In the next release I'll be adding mutex for the slots. This should solve some problems when more than one thread is accessing the repeater slots. I will also try to port a function working on Windows to Linux so they are 100% identical.

Now it's time to eat here at Spain, hope to get all the new version in a couple of hours.

Thanks again for reporting.

[shadowfax]

The latest version has been uploaded to subversion. However, once again, google code is blocking access to the uploads therefore the only upload I've managed so far is the LINUX binary (release version). I hope to get the rest of the binary files uploaded sortly.

Changes

• Thread functions have been defined on a separate file and some new methods have been declared.
• Mutex has been implemented to avoid multiple threads accessing the repeater slots simultaneously.
• Small fix to the repeater slot counter.
• Even more verbosity on the debug version.

[bigdessert]

well I finally got an Iphone today and this was the first thing I tried. I am using the latest linux release and tried using mocha vnc lite and ezdesktop and cannot get either to work with the linux repeater. Basically the server connects fine, it shows the viewer connect message but nothing happens on the iphone.....it just keeps trying to connect. Any Ideas?

[shadowfax]

Hi bigdessert,

Sorry for the delay. Have you solved the problem?

If both ends are connected but the viewer keeps trying to connect it is most likelly that the IDs from the server and the viewer are not matching. The server side is the same as a normal repeater connection where you specify the ID. The viewer side defines the ID through the password so:

• Check the password is set in the viewer.
• Check the password matches the Repeater ID.

Note: Remember that the password is the numeric part of the repeater id. That is, if you are connecting to the server "ID:1234", the password is only "1234".

In Mocha VNC Lite -the one I use for testing since it is free- I alway disable the "Save Password(s)" as the password shall be retyped to match the ID. This brings the connection preferences window when connecting.

Please, if it continues to fail, please tell me what ID you're using at the server side, and what you are typing as a password in order to recreate the error.

[bigdessert]

well just tried it again with iteleport or jadduu vnc. when I connect I can see both the view and the server, but my iphone viewer just sits at Authenticating. This is using the latest linux release. here is what the console looks like

Code: Select all

UltraVNC> Listening for incoming viewer connections on port 5900.
UltraVNC> Listening for incoming server connections on port 5500.
UltraVNC> Nagle Alorithm has been disabled.
UltraVNC> Server connection accepted from xxx.xxx.xxx.xxx.
UltraVNC> Server waiting for viewer to connect...
UltraVNC> Nagle Alorithm has been disabled.
UltraVNC> Viewer connection accepted from xxx.xxx.xxx.xxx.

[shadowfax]

There was a problem with the MutEx handling under GNU/Linux. This bug bloked the application.

New code uploaded to the repository.

Makefile has been changed under GNU/Linux. To make the release version type "make release", to make the debug version type "make debug".

UPDATE: Linux and Windows binaries uploaded.

[vcka]

Testing. Every thing looks fine

[bigdessert]

anyone else having trouble with the linux reapeater version crashing??

[shadowfax]

Outputting the raw binary "challenged" ID could cause troubles under Linux. I've done a small modification in order to store the original repeater ID sent by the server in order to display the clear text repeater ID for monitoring purposeses.

Hope you enjoy.

[B]

I understand the purpose of the project is "to build a VNC repeater that is compatible with standard VNC <i>viewers</i>".

But does anyone know if there are there any VNC <i>servers</i> other than UltraVNC that support repeater mode?

The "vncrepeater" by shadowfax is cool because it fools generic VNC viewers. Is there any hope of ever fooling generic VNC servers the same way?

[gs2010]

Hello,

I find it quite odd that when going through the repeater, there is a huge decrease in performance .. am I doing something wrong ?
In this modified version , the 'Nagle' algorithm is disabled, but the results are still slow ..
Does anyone have any suggestions ?

Thanks

[Mikegio73]

Hi all,
please, could you say how to have VERBOSE logging in Win version?
It is pretty easy in linux version, but no idea what to do for to have logging also in Windows.


Thanks

[Sainsuper]

have someone tested with ultavnc 1.0.9.6 ?
i have this message:

invalid authenticated scheme sent by server..

it works great with ultavnc 1.0.8.2 and single click.

[zorzy]

Any solutions about "invalid authenticated scheme sent by server.." with version 1.0.9.6?

As already Sainsuper said, work perfect with 1.0.8.2.

[shadowfax]

Hi zorzy,

It's been a long time since I wrote my last post.

The project of the modified repeater was basically a proof-of-concept on how you could hack a field such as the password field (present on all VNC clients) in order to send the repeater identifier to get any standard VNC client to get working with the repeater. This has a minor drawback: the server needs to be configured with no password as the password is used for other purposes (Sending the identifier). Right now this issue doesn't have a negative effect on how the repeater works as the server will never require authentication on a reverse connection.

IMHO this could lead to a insecure setup vulnerable to a brute-force attack. The reason I say this is because the repeater-ID is a numeric field and since the password is limited to 8 characters there are 100 million possible ids. For remote support purposes this could be somehow reasonable as it would be difficult for the attacker to fetch the ID of the remote party before we connect for remote support, however it could be quite hazard for a server that is permanently connected to the repeater. Once we have connected to the remote party the problem disappears as concurrent connections to a remote server is not possible and, if it was we could set the server to avoid it.

What I did to face this problem was to take over an outdated open source VNC client for iPhone (VNSea) and made it work with the new iOS SDK. Once it was working with iOS 4.x and 5.x I slightly modified COTVNC, used in the project, to get it working against the repeater (It is a really small change). Right now I've got a minimal VNC client running against the uVNC repeater. It looks alike the TeamViewer client (with no eye-candy) and the repeater is configured in iPhone's/iPad's settings. As you may expect due to the lack of eye-candy, I haven't uploaded the app to the app store.

I didn't have in mind updating the repeater as I have a working VNC client for my iPhone/iPad, however if you are willing to keep using it I could look over the code to get it fixed when I get some spare time.

Best regards

[B]

Hey shadowfax, welcome back! Were you ears burning? I was just mentioning your project a little earlier today or yesterday.

With use of a DSMPlugin, VPN, or similar encryption wrapper, doesn't your brute-force concern go away?

[shadowfax]

LOL so you are the one to blame for my burning ears!

In those cases my brute-force concerns go away... however, since the modified repeater is focused on standard clients and this may not be an option. If I'm not mistaken the DSMPlugin will come alive before the authentication phase so I guess this is not an option since we need to send the ID as a password and DSMPlugin would send it cyphered (The repeater should support DSMPLugin to allow this option); however not all standard clients support DSMPLugins.

VPN, SSH, etc... are a nice options, but once again, this may not be possible. For example, I tested the repeater with a JAVA VNC client for a simple [SPAM] mobile phone. This phone doesn't include VPN capabilities and you just can run a JAVA application at a time, therefore you would be limited to specific VNC clients which support a cypher mechanism that you can setup apart from the repeater; for example a VNC Client supporting SSH. This leads to the initial problem: Maybe that type of VNC client is not available for a device.

So, the real trouble is that if you want to be able to use any type of VNC client the repeater is left vulnerable to a brute-force attack. If you protect it you may need a more specific VNC client or a device that supports VPN or any other kind of password protection (Tunneling would be suggested).

The brute-force attack would affect any computer that is hooked to the repeater for a long time... for example if you hook permanently your home computer to the repeater to have permanent access to it. It wouldn't affect remote support, as the user would call us, we would tell them to open SC, ChunkVNC, or whatever... and we would connect to it immediately. Since the ID is no longer available once a viewer has connected to the server the attacker would have a really small amount of time to brute-force that ID. It is possible if the attacker is lucky enough to be testing that ID before we connect to it, but it is a one in a million chance and since we should have the remote end on the phone (voip or whatever) we could minimize the problem asking them to disconnect and try again. But when the computer is hooked for a long time with the same ID it becomes vulnerable.

Even if the repeater would support authentication between the viewer and the server I would suggest using some tunneling protocol... but it would be far more secure if this is not possible because we are using devices that wouldn't support it. On the other hand this would allow to share a VPN connections, or a SSH tunnel between users but some user's wouldn't be able to access all the computers as they won't know the VNC password. I think that authentication over the repeater has some features to offer and it's not possible through the modified repeater as the password is used for ID.

On the other hand I still find it useful for some situations... so if anyone is interested on using it I will modify it once again to make it work. Recently I bought a linux router and I will compile the VNC repeater for it, so there is a chance of merging the code with the modified repeater and take care about some protocol changes.

However, open source VNC viewers are easy to modify in order to make them work against the repeater (For example the JAVA viewer). For example, getting cotVNC to work against a repeater is about 5 lines of code (Excluding the GUI). So any open source VNC viewer should be easy to modify once you know where the handshaking process is taking place.

[B]

Oh really? I had no idea it was that easy to make a client repeater-compatible -- that really would be the preferred method, and we all like open source around here anyway. I would love to do that to TIghtVNC, for example. (I probably won't, as I'm just not a very good programmer and don't want to worry about having forked it, even for my own purposes.) Can you list or point to the relevant lines of code somewhere? I guess one could check how SSVNC does it.

There are other more exotic authentication methods you could try to use while leaving your regular password=ID mechanism intact. (I'm thinking of a variant of "port knocking", perhaps even done manually. For example, have the end user manually connect and disconnect from the repeater a set number of times within 120 seconds. That accomplishes a very primitive form of "pre shared key" on top of the open repeater.)

If you haven't, you might also take a look at Rudi's work with NAT2NAT; it makes for some interesting possibilities.

[shadowfax]

The first step on the handshake (First step when communicating with the VNC server) would be the version. A server would send something like:

Code: Select all

RFB 003.008

This states the server is using RFB protocol with version 3.8. The current repeater will reply with a non-existant version. The exact reply from the repeater is:

Code: Select all

RFB 000.000

Therefore we can detect we are talking to a repeater.

Once we know the other end is a repeater we shall send the ID for the server we want to connect to. The packet size shall have a fixed size of 250 bytes (Zero filled) and the format is "ID:" plus the server ID. For example if we are connecting to server with ID 1234, then the data on the packet would be:

Code: Select all

ID:1234

..and all leading zeros until we get 250 bytes of data. In C/C++

Code: Select all

char repeater_id[250];
memset(&repeater_id, 0, 250);
sprintf(repeater_id, "ID:%d", repeaterID);
// Send the data in repeater_id

Where repeaterID is the variable holding the number "1234" for the previous example. Why an integer? Because the repeater only allows numeric identifiers.

Then we start again looking for the initial handshake message, since the server will send once again it's RFB protocol version so the viewer can tell if it can talk to it. Therefore, from here on it is like a standar VNC connection and no further changes shall be made to the VNC client.

As you can see there is not too much code to make a VNC client work with the repeater, however it may take a greater amount of code to get the user interface to work. If it is a command line application we could just set the variable repeaterID to 0 and just skip the code above if repeaterID == 0.

The hard part is finding open source for the devices... currently there is no open source project I know off for an iPhone/iPad VNC client except VNSea and a fork called VNSee... however this projects have been abandoned a long time ago and they won't work out of the box so you must rewrite the project keeping this projects as a guide but there are many deprecated functions, and tons of lines of code that won't work with the current SDK. However if you find an open source project for your device that's about it

[B]

Thank you! That's so simple even I can understand it. Great description. I imagine the server side would be equally basic? We have someone trying to find a repeater-supported WinCE VNC server.

As to iOS, I thought Apple had a hard line stance against open source (for jailed iThings)?

[shadowfax]

The way the server connects to the repeater is also quite simple, however the code behind it can have several degrees of difficulty. This is so because the RFB protocol is focused on a client-to-server connections and not the other way around; therefore you may find servers that won't allow reverse connections and you'll have to make a client socket that will connect the server to the repeater.

The client is trivial as it sticks to what all VNC viewers do and you just have to worry on releasing memory if you happen to allocate it and the language you are using doesn't do that for you.

As for Apple I also thought they where not to kind with open source, however I'm now bit confused as I've been able to find several interesting open source projects on the web. For example, RouteMe is quite an interesting open source library for slippy maps and you can find several applications on the app store making use of this library. There are also some non-free applications on the app store which are open sourced. However I find there is not that much open sourced projects for the iPhone.

On iThings open source applications are never free of charge (unless you've got a jailbroken iThing) since you require a certificate to upload the application to the device and there are only two ways to do so: a developper certificate which is charged yearly, or a distribution certificate (That is you get the application from the app store).

I think the trouble with open sources application and Apple comes from the open source licesing. Latelly I've been trying to include a library that makes use of glib in a project and there seems to be much talk over the internet on LGPL and if Apple doesn't allow this kind of licesing on the apps submited to the app store... however open source apps are possible.

[zorzy]

Hey all,

I have a stable working solution with this repeater (updated version without CPU bug... https://github.com/XSoftBG/repeater ) and ultravnc server version 1.0.8.2. , since version 1.0.9.x solution doesn't work anymore.
Probably reason is in RFB 3.8 or some other changes in negotiation.

I'm looking for someone who would update this repeater to work with UVNC server up to version 1.1

Security is not a problem, all traffic goes trough VPN tunnel.

If you are interested, send me a PM with approx. price or additional questions.

Regards, Gregor

[zorzy]

Hey all,

I have a stable working solution with this repeater (updated version without CPU bug... https://github.com/XSoftBG/repeater ) and ultravnc server version 1.0.8.2. , since version 1.0.9.x solution doesn't work anymore.
Probably reason is in RFB 3.8 or some other changes in negotiation.

I'm looking for someone who would update this repeater to work with UVNC server up to version 1.1

Security is not a problem, all traffic goes trough VPN tunnel.

If you are interested, send me a PM with approx. price or additional questions.

Regards, Gregor

Rudi noticed, that problem was not in repeater but in UVNC code (when no password was set, as this repeater requires).
Sources are fixed and next server update will include this BUG fix.