Acknowledgements

I here place on record my deep sense of Gratitude to our beloved Chairman Thiru T.R. Pachamuthu for providing us with the requisite infrastructure throughout the course. I take this opportunity to extend my hearty thanks to our Director Thiru V.N. Pattabhiraman, Easwari Engineering College, for his constant encouragement. I convey my sincere thanks to Dr. S. Balasubramaniam, Principal, Easwari Engineering College for his interests and support. I take the privilege to extend my hearty thanks to Dr. C.Jayakumar, M.E, PhD, and Head of the Department, Department of Computer Science & Engineering, and Easwari Engineering College for his commendable support and encouragement towards the Completion of the project. I deem it a privilege to thank my Project Coordinator and Guide Dr. K.Kathiravan, M.Tech, PhD, Professor, Department of Computer Science & Engg, for being the guiding light and the driving force for the overall process of completing the project. I also wish to convey my sincere thanks to all the teaching and non teachingstaff of the department of CSE, Easwari Engineering College without whose co-operation this venture would not have been a success.

ABSTRACT
Knowledge, like freshwater is available in plenty, but the problem lies in distribution, in shipping, & in sharing. For years now VNC has only been seen as a branch of internet computing. Interestingly the open source communities have over a period of time been developing a powerful variant and Microsoft has gone a step further in implementing a separate Remote Desktop Protocol as a standard for its platform and developing a RDP terminal service for the same called Remote Desktop Connection. The sad part is that the Terminal Services Client has in itself contained several bugs and ultimately was rendered useless due to the already prevalent security flaws in the design of the Operating System as a whole. This has ultimately resulted in a rift between the technology and its potentially powerful applications such as in the field of Remote assistance, monitoring and mentoring.This Project aims on rebuilding the entire system integrating the powerful OpenVNC idea of SCREEN SHARING with the remote desktop protocol standards and integrate/implement this setup in the field of Technical Assistance, Remote expert assistance ,Education/tutoring & most

importantly providing the end user with enhanced accessibility.

TABLE OF CONTENTS
CHAPTER NO. TITLE PAGE NO. ABSTRACT v LIST OF TABLES viii LIST OF FIGURES ix LIST OF SYMBOLS x

1. INTRODUCTION
1.1. Background 1.2. Motivation 1.3. Problems to be solved and Goals of Thesis 1.4. Outline of the Report 1.5. Target Audience 2. REVERSE ENGINEERING A NETWORK PROTOCOL 2.1. Introduction 2.1.1. Concepts 2.1.2. Need for Reverse Engineering 2.2. Basis of Keeping a Network Protocol Secret 2.3. Methods for Reverse Engineering 2.3.1. Common Reverse-Engineering Methods 2.3.2. My Approach for Reverse Engineering RDP 9 2.3.3. Reverse Engineering Tools Used and Developed 3. PROTOCOLS INVOLVED IN TERMINAL SERVICES 3.1. The RDP Network Stack 3.2. Changes in RDP5 3.3. Cryptographic Protocols 3.3.1. A Brief Introduction to Cryptography 3.3.2. Encryption in RDP 3.4. Security Issues 3.4.1. Plaintext over Closed Secure Networks 3.4.2. Encrypted Plaintext over Public Insecure Networks 3.4.3. Encrypted Plaintext over Public Insecure Networks 3.4.4. Secure Networks 4. IMPLEMENTATION OF THE PROJECT 4.1. Understanding Existing Software 4.1.1. About Software Maintenance in General 4.2. Structure of the Software 4.2.1. The Service 4.2.2. Data Flow 4.2.3. Data Compression 4.2.4. TCP/IP connectivity 4.2.5. Building and Running the System

4.2.6. Compression Ratios 4.2.7. Mirror Driver 4.2.8. Screenshots of the output 5. PERFORMANCE ANALYSIS 5.1. Performance analysis based on number of packets transmitted 5.2. Performance analysis based on packet loss 6. DISCUSSION AND CONCLUSION 6.1. Discussion 6.2. Conclusion 6.3. Future work 6.4. Concluding Remarks

LIST OF FIGURES
Fig 1.1 Abstract View of a VNC System Fig 2.1 Man in the Middle Attack Fig 2.2 Iterative reverse-engineering process Fig 3.1 RDP protocol stack Fig 4.1 Win32 programming involved remote Desktop

LIST OF SYMBOLS
y y y y y y y y y y y y y y y y y y y RDP Remote Desktop Protocol VNC Virtual Network Computing RFB Remote Frame-Buffer DIB Device Independent Bitmap TCP/IP Transmission Control Protocol/Internet Protocol MFC Microsoft Foundation Classes OSI Open Standard Interconnect CPU Central Processing Unit commonly refers to a Computer VPN Virtual Private Network HTTP Hypertext Transfer Protocol SMTP Simple Mail Transfer Protocol RC4 Rivest Cipher 4 MCS Multipoint Communication Service MITM Man in The Middle Attack GPL General Public License ATM Asynchronous Transfer Mechanism VOIP Voice Over IP

INTRODUCTION
1.1 Background

Remote desktop is one of those wildly creative computer terms that means exactly what it sounds like. Remote desktop allows you to control the desktop and, indeed, the entire contents of a computer from another machine entirely. You do this using a sort of remote control, except that this remote control is not a magic wand but a software application. Remote desktop is a software application that turns one computer into the boss of another or a series of others. Remote desktop is sometimes found as part of a suite of other administrative applications; other times, remote desktop is its own entity, doing nothing but what it s supposed to do. Remote desktop software is available for all computer platforms.

WHAT IS REMOTE DESKTOP

With the Remote Desktop feature in Windows XP, you can remotely control a computer from another office, from home, or while traveling. This allows you to use the data, applications, and network resources that are on your office computer, without being in your office. In the Illustration below, you can see that an Systems Administrator can quickly (and securely) get into their corporate offices and do that, system down, no problem, you can fix from anywhere you can find an Internet connection that is stable enough to let you work.

Remote Desktop is the new name for the older Windows based Terminal Services Client that (like with Windows 2000), would allow you to connect

to and manage a server remotely for up to two connections, allowing you to do maintenance on the server and so on. Remote Desktop (Windows Server 2003 / XP), allows the same functionality, except it's enhanced and easier to use.

TOOLS USED
CORE JAVA JAVA NET JAVA - REMOTE METHOD INVOCATION (RMI) Jdk1.6.0/Window XP/NetBeans IDE

SYSTEM REQUIRMENT
HARWARE SPECIFICATIONS It is recommended that the minimum configuration for clients is as appended below:Suggested Configuration of Windows clients: Microprocessor Ram Hard Disk CD ROM Drive : Pentium-2 class processor, 450 megahertz MHz) : 128 MB of RAM : 2.5 gigabytes (GB) on installation drive, which Includes 500 MB on system drive. : 52 X CD ROM Drive

Functional Requirements
Host
1. 2. 3. 4. 5. 6. 7. Ability to approve or reject a request to remotely connect to the desktop. Ability to request assistance from a pre-defined source. Ability to request assistance from a colleague. Ability to allow/dis-allow remote connections to the desktop. Ability to allow/dis-allow interactive connections. Ability to restrict access to the desktop in some way (e.g. assign a password) Ability to give, to another user, enough details for that user to connect to your desktop. 8. A list of currently open connections, including details of the other endpoint of the connection and whether or not the connection is interactive. 9. Ability to close a connection. 10. Ability to toggle a connection between interactive and non-interactive.

Client

1. Ability to view a desktop remotely. 2. Ability to interact with a desktop remotely. 3. Ability (for a user with sufficient priviledges) to connect to a given user's desktop on a given host. 4. Ability to browse the network for hosts which you can then connect to. 5. Ability (for a system administrator) to connect to a given user's desktop without the user being aware of the connection. 6. Ability to view the remote desktop in fullscreen mode. 7. Ability to connect to a desktop given a remote assitance request. 8. Ability to connect to a desktop given some details from the host user.

Remote Desktop Client:

This component will be run on a machine from where the user wants to control the remote machine. It also consists of two parts a. Image Updater- Gets the images of the servers desktop and displays it to the user. b. Desktop Events Handler This entity records the keyboard and mouse actions performed by the user on the displayed image(of the servers desktop) and send these events to the server. The architecture of remote desktop application is quite simple and only consists of transmitting desktop images from the server to the client and transmitting keyboard and mouse events from the client to the server.

Remote Desktop Server:

This component will be running on the machine that is to be controlled remotely from another machine. It consists mainly of two parts a. Image Server - This is a thread that will periodically take screen shots of the desktop and send it to the client over the network. b. Events Server This entity will reserve the keyboard and mouse events sent by the client and emulate the same on the server.

Review of Existing Technologies:

Existing Products - VNC/RFB Existing Protocols - Remote Desktop/RDP Existing Protocols - Sun Ray

System Design
The host side is to be implemented as a server using the libvncserver library. The server will act as an X client and poll the local X display for the contents of the framebuffer and notify the clients if there have been any changes. Input events coming from the clients will be injected into the X display using the XTEST extension. The client we will most likely be a modified version of an existing Java client. The advantage of having a Java client is that it may be used to connect to the host from any platform.
Monitoring The Local Display

To implement a server you need to know the contents of the local framebuffer in order to pass this information onto the VNC clients. Currently, as an X client, there is only one way to do this and that is by doing a GetImage on the root window which basically copies the entire framebuffer from the X server to the X client. The main problem with this approach is that without knowing what parts of the framebuffer has actually changed since the last time you updated, you are wasting an enormous amount of resources copying the entire framebuffer each time.
Cursor Handling

Here is how to allow the client to see the cursor. There are several possible approaches: 1. Draw the cursor directly to the server's copy of the framebuffer and send framebuffer updates as the cursor is moved around. The client will see the cursor being moved in all cases. 2. Provide the cursor image to the client using the RichCursor or XCursor psuedo encoding and let the client draw the cursor locally. The client only sees cursor movement when that client is the one moving the cursor. 3. Again provide the cursor image to the client, but also send the client updates on the pointer position using the PointerPos pseudo-encoding which the client can use to update the position of its locally drawn cursor. Again, the client will see the cursor movement no matter who is moving it.

SLS of Remote Desktop

Interface
Host User Interface

Menu Entry:
Name = Remote Desktop Comment = Set your remote desktop access preferences Categories = GNOME; Application; Settings;

Connection Query Dialog

This dialog appears when the "Prompt me before allowing access" preference is set and a remote user connects to the server and is authenticated.

Outline of the Report The concepts behind reverse-engineering network protocols, and the methods used to find the information and need in order to implement RDP and screen share in remote desktop will be discussed in the following chapter. The information found using these techniques and also by reading various specification documents are documented in chapter 3, where the working of Remote Desktop Protocol will be covered. Chapter 4 covers implementation of RDP with respect to providing screen share support, including interoperability problems between the different paradigms used by the two platforms involved. Finally, conclusions and discussions for possible extensions are elucidated in Target Audience This report assumes the basic knowledge of computer network protocols, computer security and software implementation issues. Some understanding of how Windows Terminal Services work will also help for full comprehension of the report.

REVERSE-ENGINEERING A NETWORK PROTOCOL

The reverse-engineering of network protocols (ie) RDP is discussed in the following chapter. The problems of planning reverse-engineering activities are also briefly mentioned.
Introduction

2.1.1 Concepts

The concepts used in the reverse-engineering field seem not to be standardized. Therefore, some definitions are as follows.
Reverse Engineering

The term Reverse Engineering is used for different things. In the academic world, the term is used to describe the problem of getting information out of large amounts of source code, as a prelude to some software maintenance activity (see section 4.1.1). One example of this use of the term can be found in However, in other parts of the computer industry, the term is used in a more general way, describing activities that in some way are used to find unpublished information.
Network Analysis Network analysis is another term used in technical network communities. It describes methods and tools for analyzing raw network data in order to find problems with a network, for example bottlenecks and intrusions. Another related term is Retro engineering , which is used when there is a need to rewrite a standard in order to comply with already existing and marketleading incorrect implementations. Basis of Keeping a Network Protocol Secret

The protocols used in remote desktop are only partially documented. If a company has a truly superior protocol for a specific task, they may choose to keep it secret in order to gain market shares while not leaking the results of their research and development to their competitors. However, the problem with this approach is that you completely lose compatibility with existing products, something that is becoming more and more important with time, as the computing environments grow in complexity. Also, it is very seldom possible to keep the protocol secret for a long time, since reverse-engineering methods do exist. See section 2.3 for more information. Another reason for keeping the protocol secret, even though it is not superior in any way, is as part of a larger plan to actually increase the incompatibility with other products. By creating a set of products that only communicate with each other, a large company can create it is own market where the customer is forced to buy more products from the same vendor when a certain functionality is needed, since the functionality will not integrate as well if another vendors 7 products are used. The plan may not always work, since by using reverse engineering, other companies, organizations or individuals can create products that do communicate with the large company s products, even though the protocols were secret.

Methods for Reverse Engineering

A number of common methods for reverse-engineering exist. During the course of the project several implementation of those reverse engineering techniques were studied for the knowledge on how to incorporate a screen share in the windows operating system.

Common Reverse-Engineering Methods

Disassembler and Debugger

One way of finding out exactly what a piece of software is doing is to examine the binary executable machine code. Given the machine instructions of a certain hardware platform it is possible to decode the machine code into assembler instructions using a so called disassembler. However, since the assembler instructions are most often generated by a compiler from some higher level language, you will get a very hard-to-read representation of what the program does. It is often possible to debug the program at an assembler code level in order to find the correct lines of code in the program for my specific task. However, this method is very timeconsuming and tedious. It is not practical for larger projects, but for small well-defined tasks it can be an effective method. An example would be the task to find out. how a certain image format is encoded by running an image decoding program to see what it is doing for a certain image that has a known content. Man in the Middle Attack When doing reverse-engineering of network protocols, a method known as Man in the Middle attack , hereafter referred to as MITM attack, can be very useful. In the MITM attack, the network path between two communicating computers is by some method altered in order to route the network packets through a third computer where a specially written piece of software handles the packets. In figure 2.1, the normal path for packets that travel between the client and the server is Network path In order to use the MITM attack, I tell the client it should connect to the

computer running the MITM software instead of connecting to the real server. That is, the packets will travel Network path C. When the packets arrive to the MITM computer, they are processed by the MITM software and then sent via

Network path B to the server. Packets from the server are handled the same way, but in the opposite direction. The MITM software can either just listen to the packets (although a network packet sniffer (see section 2.3.1) can do that job just as well or even better) or process them in a more advanced fashion, for example by replacing some part of the packet in order to instruct either the client or the server to behave in a certain way. There are several different types of MITM software. Either the software is very simple and does nothing else Fig 2.1 Man in the Middle Attack 9 than listening for packets, presenting them without modification to the party operating the MITM software. For this purpose, a network packet sniffer, as described below, can probably do the job just as well. The MITM software can also do more advanced processing of the packages. It can, for example, replace parts of the packet on its way, in order to instruct either the client or the server to behave in a certain way. A real-world example of this was when the Samba project reverse-engineered part of the authorization protocols by using MITM software that replaced parts of the network packet stream in order to force the native servers to talk to each other in a different way.
Network Packet Sniffer

Another very useful tool when reverse-engineering network protocols are a packet sniffer. A packet sniffer works by listening to the traffic of a network interface and presenting the packets in a partially or fully parsed fashion. Examples of such software are tcpdump and Ethereal . Depending on the network architecture, the packet sniffer can only listen to packets where the host it is running on is the destination or source, or on all hosts on the same broadcast domain.

THE PROTOCOLS INVOLVED IN TERMINAL SERVICES

In this chapter, the working of RDP as a network protocol is discussed beginning by describing the protocol in general, to give an overview for newcomers to RDP. Apart from discussing and describing RDP, the various network security and security-related protocols will also be discussed.
The RDP Network Stack

Similarly to most network protocols, RDP consists of several layers. Figure 3.1 give an overview of how RDP is built. For an in-depth reference of the different packets involved in RDP, see appendix A. Beginning from the bottom of the stack, there is a standard TCP connection from the client to port 3389 on the server. On top of TCP, ISO DP 8073 packetsare sent. This is a standard defined, meant to provide a way for ISO network standards (built on the well-known OSI model) to run on top of the more commonly implemented TCP. This protocol is also referred to as TPKT , for example in the network analysis program Ethereal. On top of ISO DP 8073 lies Multipoint Communication Services (MCS). This is a standard providing domain management, channel management, data transfer, and token management. The latter is not used in RDP. The domain management is sparsely used too, since it is meant for protocols where more than two entities are communicating with each other. In RDP, more channels are used for example for sending clipboard and sound data. The data transfer capability is used to send the data between client and server. 15 The

Generic Conference Control is almost invisible in the protocol implementation. There is a minor exchange of GCC data in each direction in the protocol setup phase, but its role is so small I will not mention it further. Remote desktop implements GCC by sending a hard coded string to the server and by skipping 21 bytes when reading one of the setup packets from the server. The security layer provides encryption of the data sent over the MCS. On top of the protocol stack, the RDP application layer is the protocol that defines how the graphic data is sent to the client, and how mouse and keyboard in RDP.

Security Issues
In the network world of today, a lot of information is sent using insecure networks such as the public parts of Internet. At the same time, we are becoming increasingly dependent on computers. A lot of sensitive data are carried through today s network, for example medical journals, financial data,and military information. The implications of information leaks are often veryserious.There are basically three ways of dealing with the need for privacy, integrity and authentication: plaintext over closed secure network, plaintext over public and possibly insecure networks, and encrypted data transfer over insecure public networks. Previously closed networks such as Frame Relay and X.25 are replaced with data transfer over the Internet, protected by encryption. This change of network techniques is done because of both financial reasons Internet 19 connections have become much cheaper lately and for flexibility reasons. It is much easier to find an Internet connection when you are on the road than an X.25 connection.
Secure Networks

A relevant question here is whether there is such a thing as a secure network. Some people tend to believe that the network inside their firewall is secure, so there is no need to update the computers on the network and all traffic can safely be plaintext. The danger with this assumption is that in order for it to be correct, all parts on the internal network must be trusted. It is a fact that a lot of attacks originate from for example employees who are unhappy with their employer for some reason. Also, if one single computer on the internal network is compromised, it can be used as a gateway to attack all the poorly protected computers on the internal network. Using plaintext protocols for sensitive data on internal networks is also a bad idea since there are always some methods for gaining access to the network path between two computers given access to the same broadcast domain as one of them. Such a method is ARP- spoofing. During the investigations of RDP it is found that none of the available RDP clients from Microsoft verified the public key of the server. This is a rather serious security flaw as it opens up for MITM attacks such as the one described above.

IMPLEMENTATION OF THE PROJECT

In this chapter software maintenance in general and the support for RDP in the software is discussed.
Understanding Existing Software

Part of the challenge in this final report is to understand and modify an existing piece of software, remote desktop. Some of this activity is traditional software maintenance, an area where there is academic research.
About Software Maintenance in General A standard definition adopted by the IEEE in 1983 of Software maintenance Follows: Software maintenance is the modification of a software product after Delivery to correct faults, to improve performance or other attributes, or to adapt The product to a changed environment. Structure of the Software

The main aim of the system is to remotely monitor desktop activity which is better and adaptive than the existing software. Additionally allow both parties to interact simultaneously as an extension to the existing system of remotedesktop. 1. Quick Compress - A compression COM object 2. RemoteDesktopService
The Service The service itself is its own installer and uninstaller. 1. To install the service issue the following command: RemoteDesktopService -i 2. To uninstall the service issue the following command: 1. RemoteDesktopService u Data Flow

Data flows from the client to the server and back. Fig 4.1 win32 programming involved remote desktop 1. Client initiates a connection to the server on the server IP or name. DNS or host entries are required for name resolution. 2. Client sends the password, or 1 byte null character for no password. 3. Server receives the connection and spawns a thread for handling the connection. 4. Server sends the bit depth, the width, and the height of its desktop. 5. Client receives the bit depth, the width, and the height. 6. Server captures and sends the desktop to the client. 7. Client receives the desktop and acknowledges receipt. 8. Repeat steps 6-7 until the client closes the connection. 9. Server ends the thread that handles the client's connection.

Screenshots of the output

Remote Desktop on Sudden disconnection

Screen share over Remote Desktop Server:

Client:

DISCUSSION AND CONCLUSION

Discussion

Beginning the work on this project, a quite well-defined problem to solve was the need for improved user environment and screen share support in remote desktop. This problem proved to contain a large set of sub problems, many of them impossible to anticipate in the beginning. The sub problems ranged from large questions such as what method to use for the reengineering needed, to small questions, such as what datatype was hidden in a small part of the datastream.
Conclusion

The motivations of this project are to: Enhance remote desktop in terms of screen sharing, security and adapting it to the current Indian networks scenario Provide documentation in order to ease further development of remote desktop Regarding the first item, this project has succeeded in adding adaptability and security, including generic code for virtual channel handling. We have also succeeded in adding basic screen share for the proposed future of the same. About 2000 lines of code are in use as of now. Regarding the second item, new and current developers of remote desktop will find this report helpful as a reference. The parser used also will be of use in further remote desktop development, and the structure of it might be of interest for other people in need of writing packet parsers.
Future work

As of March 2008, there are a number of things to be done on remote desktop to Support all of RDP. Among them are: VOIP (virtual channel) over RDP for remote tutoring Support for more clipboard formats when transferring data between the Window System and Microsoft Windows. Dynamic compression of the data packets. Also, the security layer should be able to verify the peer when connecting in order to prevent man in the middle attacks, and it should also verify the signature of data packets. This functionality is missing at the time of writing. Another area of interest is to develop software that can connect to servers running other versions of VNC. It might be possible to use remote desktop for this purpose since the protocols are related.

Concluding Remarks
During the work some rather serious security flaws in Microsoft s client Implementations have been reported. Such theory behind the flaws, and some of the ethics behind reporting such flaws in a responsible manner are discussed. To the best of effort, a successful implementation and more robust version of existing remote desktop and as well as propose a practical implementation of screen sharing technique which can be implemented into the remote desktop package for better accessibility and extension of remote desktop to the field of remote mentoring has been implemented with a focus at prospective future developments.

Reference
1. Tristan Richardson, Quentin Stafford Fraser, Kenneth R Wood, and Andy Hopper. 2 Kevin Lano and Howard Haughton. Reverse Engineering and software maintenance: A practical approach. McGraw Hill, 3 Microsoft Corporation. Clipboard. Website, Accessed January2008. http://msdn.microsoft.com/library/.
http://www.ethereal.com/. http://www.tcpdump.org/. http://support.microsoft.com. http://www.microsoft.com/terminalservices. http://www.latexproject.org http://www.securityfocus.org/. http://en.wikipedia.org/wiki/Disassembler.

CET-IILM-ACADEMY OF HIGHER LEARNING

COLLEGE OF ENGINEERING
PROJECT ON Remote Desktop
IN PARTIAL TO FULLFILLMENT THE AWARD OF BACHELOR OF ENGINEERING DEGREE OF THE GAUTAM BUDHA TECHNICAL UNIVERSITY LUCKNOW

Submitted to:

Project Guide:

Submitted By: Kuldeep Singh Branch CSE Roll no-0715010059

CET-IILM-ACADEMY OF HIGHER LEARNING, GREATER NOIDA GB NAGAR (U.P)201301 JAN 2010