Modified repeater (Source code)

[vcka]

Thanks, i was using older version. Now every thing lucks good.
PS. One more problem on linux:
32242 root 20 0 52396 1020 800 R 100 0.0 8:42.25 repeater

repeater is using 100% of cpu, it doesn't matter if its empty or is used by someone.


HERE WE GO!
Two servers and two viewers connected, then one viewer disconnects i got this error:
ERROR: do_repeater(): Writting ClientInit error.
*** glibc detected *** ./repeater: double free or corruption (fasttop): 0x0804d158 ***
======= Backtrace: =========
/lib32/libc.so.6[0xf7d2b04c]
/lib32/libc.so.6(cfree+0x85)[0xf7d2d085]
./repeater(__gxx_personality_v0+0x297)[0x8048e7b]
./repeater[0x804a38e]
/lib32/libpthread.so.0[0xf7f36195]
/lib32/libc.so.6(clone+0x5e)[0xf7d9aefe]
======= Memory map: ========
08048000-0804c000 r-xp 00000000 09:02 4777118 /home/vcka/1/repeater
0804c000-0804d000 rw-p 00004000 09:02 4777118 /home/vcka/1/repeater
0804d000-080b0000 rw-p 0804d000 00:00 0 [heap]
f4b00000-f4b21000 rw-p f4b00000 00:00 0
f4b21000-f4c00000 ---p f4b21000 00:00 0
f4cbd000-f4cbe000 ---p f4cbd000 00:00 0
f4cbe000-f54bd000 rw-p f4cbe000 00:00 0
f54bd000-f54be000 ---p f54bd000 00:00 0
f54be000-f5cbd000 rw-p f54be000 00:00 0
f5cbd000-f5cbe000 ---p f5cbd000 00:00 0
f5cbe000-f64bd000 rw-p f5cbe000 00:00 0
f64bd000-f64be000 ---p f64bd000 00:00 0
f64be000-f6cbd000 rw-p f64be000 00:00 0
f6cbd000-f6cbe000 ---p f6cbd000 00:00 0
f6cbe000-f74bd000 rw-p f6cbe000 00:00 0
f74bd000-f74be000 ---p f74bd000 00:00 0
f74be000-f7cbe000 rw-p f74be000 00:00 0
f7cbe000-f7e0a000 r-xp 00000000 09:02 18235413 /emul/ia32-linux/lib/libc-2.7.so
f7e0a000-f7e0b000 r--p 0014b000 09:02 18235413 /emul/ia32-linux/lib/libc-2.7.so
f7e0b000-f7e0d000 rw-p 0014c000 09:02 18235413 /emul/ia32-linux/lib/libc-2.7.so
f7e0d000-f7e11000 rw-p f7e0d000 00:00 0
f7e11000-f7e1d000 r-xp 00000000 09:02 18235690 /emul/ia32-linux/usr/lib/libgcc_s.so.1
f7e1d000-f7e1e000 rw-p 0000b000 09:02 18235690 /emul/ia32-linux/usr/lib/libgcc_s.so.1
f7e1e000-f7e40000 r-xp 00000000 09:02 18235418 /emul/ia32-linux/lib/libm-2.7.so
f7e40000-f7e42000 rw-p 00022000 09:02 18235418 /emul/ia32-linux/lib/libm-2.7.so
f7e42000-f7f25000 r-xp 00000000 09:02 18235693 /emul/ia32-linux/usr/lib/libstdc++.so.6.0.10
f7f25000-f7f28000 r--p 000e2000 09:02 18235693 /emul/ia32-linux/usr/lib/libstdc++.so.6.0.10
f7f28000-f7f2a000 rw-p 000e5000 09:02 18235693 /emul/ia32-linux/usr/lib/libstdc++.so.6.0.10
f7f2a000-f7f30000 rw-p f7f2a000 00:00 0
f7f30000-f7f43000 r-xp 00000000 09:02 18235416 /emul/ia32-linux/lib/libpthread-2.7.so
f7f43000-f7f45000 rw-p 00012000 09:02 18235416 /emul/ia32-linux/lib/libpthread-2.7.so
f7f45000-f7f47000 rw-p f7f45000 00:00 0
f7f54000-f7f58000 rw-p f7f54000 00:00 0
f7f58000-f7f59000 r-xp f7f58000 00:00 0 [vdso]
f7f59000-f7f76000 r-xp 00000000 09:02 18235407 /emul/ia32-linux/lib/ld-2.7.so
f7f76000-f7f78000 rw-p 0001c000 09:02 18235407 /emul/ia32-linux/lib/ld-2.7.so
fffe9000-ffffe000 rw-p 7ffffffea000 00:00 0 [stack]
Aborted

[shadowfax]

Thank you vcka. Since I was only testing with a single connection I didn't notice that huge memory leak (double free or corruption). The slots where messing thing up. I think this error has finally been fixed.

The CPU usage is due to the main application loop, shich is empty. I don't know which way to go right now. There are several options:

• Make one of the listening threads the application loop.
• Adding the timer method here. It would keep the application skeleton clean but it would delay the application exit.
• Make the main application loop check if one of the threads (Listening sockets) has exited although no exit signal was submited. In this case it would restart the closed thread. This shouldn't happen, but maybe it would be nice to make sure.

New features

• Configuration file. The file is named "vncrepeater.conf" and should be located on the application path under Windows or inside /etc/ under Linux.
• You may disable the Nagle Algorithm inside the configuration file.
• Fixed the memory bug reported by vcka. (Thanks again)
• Reports the connection IP when a server/viewer connects to the repeater.

[vcka]

Testing new one under linux. The problem - then i start vncserver and viewer for the first time, i got this log on repeater:
UltraVNC> do_repeater(): connection closed by server.
UltraVNC> Repeater thread closed.
And the server doesn't reconnect automaticaly.

[shadowfax]

Sorry about that...

I made some further changes and the issue has been fixed. Thank you again vcka for reporting this bug. Hope the new version works as expected.

I've also changed to non-blocking sockets (Making internals closer to the VNC Server). I've also changed some socket options, and made some changes to attains better compatibility between Winsock and Berkley Sockets.

[vcka]

Thanks, but linux archive is somehow corrupted
It is zero length.
I compiled by my self. But ...
UltraVNC> Server connection accepted from 1x.2x.2x.x6
ERROR: zero bytes read
UltraVNC> server_listen(): Reading authentication type error.
UltraVNC> Viewer connection accepted from 127.0.0.1.
In previous version every thing was ok. It would be very nice if there where a posibility for more verbosity.
If i close viewer every thing is ok : UltraVNC> do_repeater(): connection closed by viewer.
But then closing server the socket is not released.

[shadowfax]

That's weird, could not reproduce this error on Windows (The virtual machine's network interface has gone mad and I can't debug the LINUX version). What steps did you follow to get this error?

I tried to connect a server, then connect a Viewer, closed the server... and everything seems running ok.

I've made a new release with more verbosity and a new Makefile. Nothing new apart from this two modifications. In order to get more verbosity the application should be compiled with _DEBUG defined. To do so, just add an argument to make:

Code: Select all

make CFG=debug

It should be more verbose.

Hope we can trap this error soon. Thanks again for your support.

[vcka]

After building new version, uvnc viewer after entering password: Unknown VNC authentication result! repeater log : UltraVNC> Viewer connection accepted from x.x.x.x.
ERROR: zero bytes read
UltraVNC> viewer_listen(): Reading ClientInit message error.

Here is original uvnc repeater log after i close uvnc server:
UltraVnc Tue Jun 1 16:02:45 2010 > routeConnections(): starting select() loop, terminate with ctrl+c
UltraVnc Tue Jun 1 16:03:00 2010 > routeConnections(): new server connecting, accepting...
UltraVnc Tue Jun 1 16:03:00 2010 > acceptConnection(): connection accepted ok from ip: 193.227.102.26
UltraVnc Tue Jun 1 16:03:00 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): returning normally
UltraVnc Tue Jun 1 16:03:01 2010 > parseId(): IdCode = ID:87654321
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): Server sent code 87654321
UltraVnc Tue Jun 1 16:03:01 2010 > findDuplicateIdIndex(): similar ID not found
UltraVnc Tue Jun 1 16:03:01 2010 > addServerList(): Server added to list: code = 87654321, index = 0
UltraVnc Tue Jun 1 16:03:01 2010 > findViewerList(): Warning, viewer not found (code = 87654321)
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): respective viewer has not connected yet
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:06 2010 > nonBlockingRead(): returning 12 bytes
UltraVnc Tue Jun 1 16:03:06 2010 > readPeerHandShake(): len = 12
UltraVnc Tue Jun 1 16:03:30 2010 > isPeerDisconnected: recv() returned 0 (peer has disconnected orderly)
UltraVnc Tue Jun 1 16:03:30 2010 > connectionRemover(): Removing server 87654321 at index 0 (peer has disconnected)
UltraVnc Tue Jun 1 16:03:30 2010 > removeServerList(): Server Removed from list: code = 87654321, index = 0

Here is log from Your older bild when i close uvnc server (wich is much informative ;]):

UltraVNC> Add_server_list(): Server added with ID 5774425abc1fcbe5d749aed648ad83d2.
As you can see nothing happened. Then my server is disconnected and i start viewer session with same password, log:

UltraVNC> Add_viewer_list(): Viewer added with ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_reapeater(): Starting repeater for ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_repeater(): connection closed by server.
UltraVNC> Remove_server_list(): Server Removed from list 5774425abc1fcbe5d749aed648ad83d2
UltraVNC> Remove_viewer_list(): Viewer Removed from list 5774425abc1fcbe5d749aed648ad83d2

[shadowfax]

vcka: Is the new repeater version working on Linux?

Ok, let's see the log messages. I have to make them easier to read in my version...

After building new version, uvnc viewer after entering password: Unknown VNC authentication result! repeater log : UltraVNC> Viewer connection accepted from x.x.x.x.
ERROR: zero bytes read
UltraVNC> viewer_listen(): Reading ClientInit message error.

"Zero bytes read" usually means there is a closed socket. In order to take the password as a repeater ID the repeater has to act as a real VNC server until the ClientInit is sent. Therefore, the last step while connecting a viewer is retrieving the ClientInit message. At this stage the Viewer is talking directlly with the repeater and that certainly worries me. However I've been unable to reproduce this error on the Windows version and got the network adapter problems on the virtual machine. Does this happen each time you connect the viewer? Even with no server connected?

Here is original uvnc repeater log after i close uvnc server:
UltraVnc Tue Jun 1 16:02:45 2010 > routeConnections(): starting select() loop, terminate with ctrl+c
UltraVnc Tue Jun 1 16:03:00 2010 > routeConnections(): new server connecting, accepting...
UltraVnc Tue Jun 1 16:03:00 2010 > acceptConnection(): connection accepted ok from ip: 193.227.102.26
UltraVnc Tue Jun 1 16:03:00 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): returning normally
UltraVnc Tue Jun 1 16:03:01 2010 > parseId(): IdCode = ID:87654321
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): Server sent code 87654321
UltraVnc Tue Jun 1 16:03:01 2010 > findDuplicateIdIndex(): similar ID not found
UltraVnc Tue Jun 1 16:03:01 2010 > addServerList(): Server added to list: code = 87654321, index = 0
UltraVnc Tue Jun 1 16:03:01 2010 > findViewerList(): Warning, viewer not found (code = 87654321)
UltraVnc Tue Jun 1 16:03:01 2010 > acceptConnection(): respective viewer has not connected yet
UltraVnc Tue Jun 1 16:03:01 2010 > nonBlockingRead(): start
UltraVnc Tue Jun 1 16:03:06 2010 > nonBlockingRead(): returning 12 bytes
UltraVnc Tue Jun 1 16:03:06 2010 > readPeerHandShake(): len = 12
UltraVnc Tue Jun 1 16:03:30 2010 > isPeerDisconnected: recv() returned 0 (peer has disconnected orderly)
UltraVnc Tue Jun 1 16:03:30 2010 > connectionRemover(): Removing server 87654321 at index 0 (peer has disconnected)
UltraVnc Tue Jun 1 16:03:30 2010 > removeServerList(): Server Removed from list: code = 87654321, index = 0

Here is log from Your older bild when i close uvnc server (wich is much informative ;]):

UltraVNC> Add_server_list(): Server added with ID 5774425abc1fcbe5d749aed648ad83d2.
As you can see nothing happened. Then my server is disconnected and i start viewer session with same password, log:

UltraVNC> Add_viewer_list(): Viewer added with ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_reapeater(): Starting repeater for ID 5774425abc1fcbe5d749aed648ad83d2.
UltraVNC> do_repeater(): connection closed by server.
UltraVNC> Remove_server_list(): Server Removed from list 5774425abc1fcbe5d749aed648ad83d2
UltraVNC> Remove_viewer_list(): Viewer Removed from list 5774425abc1fcbe5d749aed648ad83d2

I guess you are referring to the list removals... Why does mine remove viewer and server while the other one just removes the server?

I think the older Linux version of the VNC repeater keeps the handshaking process in memory in order for the viewer to stay connected. This could be done in my version (since most of the handshake is produced by the repeater itself). The eaiest way would be for the repeater to keep in memory the ServerInit message and check it matches with the ServerInit stored in memory. I wanted to implent this kind of thing. One of the ideas I had was caching the images sent by the server on the repeater. This allows for the next features:

• If the server disconnects the images could be transformed to greyscale and the viewer would see the screen in greyscale until the server reconnects. Still have no clue on how to work with images, but I guess it would be learning how jpeg lib works.
• Caching images would make it possible for a http server to point towards that directory, making it possible to show the desktop through an HTTP browser. It would be a start towards opening an AJAX viewer for the repeater.

However, this are just some thoughts as first thing is first... and that is getting the repeater to do it's work correctly. That's why I'm really concerned about that error while reading the ClientInit message. Hope I can get the virtual machine fixed to track this error, but any description on how this error was produced would be great.

[vcka]

1.Starting repeater
2.Connecting vncserver with id 123
3.Connecting viewer with same password.
repeater console log:
UltraVNC> UltraVNC> Listening for incoming server connections on port 5500.
Listening for incoming viewer connections on port 5900.
UltraVNC> Nagle Algoritmh has been disabled.
UltraVNC> Server connection accepted from x.x.x.x.
UltraVNC> Nagle Algoritmh has been disabled.
UltraVNC> Viewer connection accepted from x.x.y.y.
ERROR: zero bytes read
UltraVNC> viewer_listen(): Reading ClientInit message error.
ERROR: zero bytes read
UltraVNC> server_listen(): Reading authentication type error.
I'm using debian 64bit

[shadowfax]

New version uploaded.

New Features

• Added the methods to free slots with broken connections awaiting for the other side to connect.
• Lowered CPU usage.
• More verbosity for the DEBUG version.
• Some messages are clearer.

Binary files uploaded to: http://code.google.com/p/vncrepeater

[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