At work, we use Citrix and Remote Desktop a lot. I mean too much. But that’s how the sysadmins have decreed it will be, and that’s how it is. Both systems have the facility to access files on the client system by representing them as drive letters on the server when you connect. However, this facility can be turned off by the system administrator, and (you’re probably ahead of me here) it is.
Of course, the systems in questions are also fairly bare with regard to tools for analysing log files, diagnosing database problems and the like. And they don’t have internet access. And the sysadmins are unresponsive. So the only thing we can do is open stuff on the server, copy sections of it to the clipboard (which is shared with the client) and paste it onto the client to do stuff with.
Enter the Clipboard File Transfer Protocol. This cunning ploy uses the shared clipboard as a means of implementing something very similar to TFTP. TFTP is reworked as a 7-bit text-based protocol to avoid any character encoding issues with using the clipboard in plain text mode, and each end polls the clipboard for changes. The essentials of TFTP remain unchanged—there is a read or write request and a series of data blocks, and each block sent is acknowledged by the other side. The only real change (other than the transport medium) is that the block sizes are not fixed, and the end is noted by a zero-sized block.
An example of a conversation follows:
[Client] TFTP WRQ file.txt
[Server] TFTP ACK 0
[Client] TFTP DATA 1
<~9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>Cj@.4Gp$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,
O<DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKY
i(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIa
l(DId<j@<?3r@:F%a+D58'ATD4$Bl@l3De:,-DJs`8ARoFb/0JMK@qB4^F!,R<AKZ&-DfTqBG%G
>uD.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c~>
[Server] TFTP ACK 1
[Client] TFTP DATA 2
[Server] TFTP ACK 2The data is encoded using Ascii85
encoding, which packs 4 source bytes into 5 characters, unless the 4 source bytes are zero in which case they are represented by the single character z. Each packet starts with TFTP and ends with a blank line, which means the clipboard-poller can recognise it.
Two big questions spring to mind:
I’ll answer the second question first: the basic server implementation is in VBScript, and is short. This means it can be copied using the clipboard into a new .vbs file on the server and run directly from the server’s command line using cscript. The VBScript gains access to the system clipboard through the InternetExplorer.Application COM object, and access to the filesystem through the Scripting.FileSystemObject COM Object. Note that the latter can only write to files in text mode, but for computers using single-byte-character code pages this is not a problem in practice.
The use of Internet Explorer for clipboard access means that security settings in IE must allow scripts access to the clipboard. The script uses about:blank as its starting point—so two possible solutions are to either lower the security level of IE as a whole, or to add about:blank to your Trusted Sites. If you can’t do either of these, change the script to use a site which is already trusted (it must be accessible though, so the default microsoft.com sites are no good for blocked-off servers like these. If you have no trusted sites, and no permissions to alter security levels, you are probably stuffed.
The client implementation is in Java for user-friendliness. Files can only uploaded from client to server at the moment (although you can upload the Java software and use it to send files the other way!).
Java client source code: http://homepage.mac.com/tapinacom/code/TFTP.java
Java client binary: http://homepage.mac.com/tapinacom/code/ClipboardTFTP.jar
VBScript server: http://homepage.mac.com/tapinacom/code/tftp.vbs