VNC protocol analysis

VNCProtocol Analysis

VNC (Virtual Network Computing) is a super thin customer System Based on the RFB (remote frame buffer) protocol,

Designed and developed by Cambridge's at&t lab.

The default VNC ports are main: 5900 (C/S) and http: 5800 (B/S.

RFB (remote frame cache) is a simple protocol for remote graphics users. Because it works at the frame cache level, it can be applied to all window systems, such as X11, windows and Mac systems.

A remote terminal user uses an RFB client (such as a display, keyboard, or mouse) to provide frame cache changes.

RFB is an application layer protocol based on TCP.

RFB is a "thin aircraft" protocol in the true sense. The focus of RFB Protocol design is to reduce the hardware requirements for the client. In this way, the client can run on many different hardware, and the task implementation of the client will be as simple as possible.

RFB Protocol is stateless for clients. That is to say, if the client is disconnected from the server, if it reconnects to the same server, the status of the client will be saved. Even a different client can be used to connect to the same RFB server. The new client can obtain the same user status as the previous client. Therefore, the user's application interface becomes very convenient.

As long as a suitable network connection exists, users can use their own applications, and these applications will be kept, even at different access points. In this way, the system will provide users with a familiar and unique computing environment.

Display Protocol

The display protocol is based on a single figure of "Placing pixel data in a box located by X and Y.

At first glance, it seems very inefficient to draw so many user interface components. However, different pixel data encoding methods are allowed, which gives us great flexibility in processing different parameters (such as network bandwidth, client rendering speed, and server processing speed.

Update the frame cache through the sequence of rectangles. An update changes the cache status from one available frame to another, which is a bit similar to that of a video clip. Although the update of the rectangle is generally separated, it is not necessary.

The update part of the display protocol is driven by the client through commands. That is to say, the update only occurs when the server responds to the client request. In this way, the Protocol update quality is variable. The slower the client/network, the slower the update speed. For some applications, updates in the same region are continuous. If a slow client is used, the cache status of the frame cache can be ignored. This can also reduce the client network speed and draw speed requirements.

Input Protocol

The input protocol is a connection protocol based on the keyboard, mouse, and other devices of the standard workstation.

The input event is sent to the server by sending the client input.

These input events can also be integrated through non-standard I/O devices.

For example, the pen writing engine may generate a keyboard event.

Representation of pixel data

The initial interaction involves the coordination of pixel data formats and encoding methods transmitted between the RFB client and the server. This coordination is designed to make the client work as simple as possible. The bottom line of the design is that the server must provide pixel data in the format required by the client. If the client can process multiple data formats or encoding formats in the same way, it generally selects a format that is easy to generate on the server side.

The pixel format involves how to reproduce different colors by pixel values. The most common pixel format is a 24-or 16-bit "true color". It directly converts pixel values to red, green, and blue brightness through bits. The 8-bit "color ing" can map any pixel value to the RGB brightness conversion.

Encoding refers to how pixel data of a rectangle is transmitted over a network cable. A header is added to the rectangle of each pixel data. The X, Y coordinates of the rectangle on the screen, the width and height of the rectangle, and the specified encoding type are given. Then the data itself adopts this specific encoding method.

The data itself follows a specific encoding. Currently, the encoding methods include raw, copyrect, RRE, hextile, and zrle. in practical applications, zrle, hextile, and copyrect are generally used because they provide the best compression for typical desktops. Other possible encoding methods include jpeg for static images and MPEG for effective transmission of dynamic images.

The protocol can be extended by adding a new encoding method.

Protocol Extension

The protocol can be expanded in the following ways:

New encoding method

A new protocol can be compatible with existing clients and servers. Because the existing servers will ignore the new encoding methods they do not support. Therefore, no results will be returned when the client sends a request using the new encoding method.

Pseudo-encoding method

In addition to the real encoding method, the client can also request the "pseudo-encoding" Notification Server, which supports extension of a certain protocol. If the server does not support this extension, it will ignore it. It is worth noting that the client must first assume that the server does not support this extension until it receives confirmation from the server.

New security methods

Adding a new security method will bring unlimited flexibility. It modifies some protocol behaviors, but does not sacrifice the compatibility between the existing client and the server. The client and the server can communicate with each other through a secure protocol, which is not necessarily the same as the RFB Protocol.

You should not use different versions in any case.

The RFB Protocol version is developed by RealVNC. If you use a different protocol version that may be incompatible with RFB/VNC, to ensure protocol compatibility, contact RealVNC. This reduces the conflict between the encoding method and the security type.

Protocol Message

RFB can be reliably transmitted, such as byte streams or message-based. Like most protocols, it is also connected through a TCP/IP protocol cluster. The Protocol is connected in three steps. The first is the handshake message, which is used to negotiate the Protocol version and encryption method. The second step is to initialize the message, which is mainly used for the initialization message of the customer and the server. The last step is normal protocol interaction. The client can send messages as needed, and then obtain responses from the server.

All messages start with the message type, followed by specific message data.

The basic types of message descriptions are: u8, u32, S8, S16, and s32.

A utable shows an unsigned integer, and s indicates a signed integer.

All byte integers (except the pixel value itself) follow the big endian order.

Big endian or little endian is related to the CPU, thus affecting the order of integers in the memory. Big endian is the top byte, little endian is the top byte, and the network byte order is generally big-Endian.

Pixel represents a pixel value bytesperpixel byte, 8 xbytesperpixel = bits-per-pixel.

Protocol process

Message description

Handshake message

1. The VNC server sends the maximum supported RFB Protocol version number to the client, for example, "RFB 003.006 \ n", that is, the version number is 3.6, and the fixed version number format is ×××. ×××. Fill in the front of the deficiency part with zero.

2. The client replies to the version number to be used, in the above format. The client version must be smaller than or equal to the server version number. In this way, the server can be backward compatible.

3. Currently, major protocol versions released include 3.3, 3.7, and 3.8 (3.5 was reported to have problems). The maximum version is 4.0.

Negotiated security type

(1) v3.7 and later versions

List of security types supported by server sending

If the client supports a certain security type of the server, the client sends a byte to confirm the connection.

Security type:

If the number of security types is 0, the connection fails (for example, the server does not support the client request version number ).

There will be strings to describe the cause of failure:

After the server sends the reason string, the connection is closed.

(2) versions earlier than 3.7 (taking VNC certification as an example)

1. the server sends an unsigned 32-bit integer to identify a security type (related to authentication ).

Security type:

Other authentication types:

Note:

① 0. The connection fails (for example, the server does not support the client request version number), so there will be a string to describe the cause of the failure:

After the server sends a reason-string message, the connection is closed.

② None. authentication is not required (password is not required). protocol data will be sent in plaintext.

V3.8 or later versions also contain messages with security results.

The v3.3 and 3.7 protocols directly enter the initial packet.

③ For VNC authentication, protocol data will be sent in plain text, and the server will send a 16-byte random number.

The client uses des to encrypt the authentication and uses the user password as the key to return a 16-byte response to the server.

The security result message is followed.

2. the server sends a 16-bit random number.

3. The client uses des to encrypt the authentication, and uses the user password as the key to return the 16-byte encrypted data to the server.

4. The server confirms the security authentication. The returned value is a 32-bit unsigned integer. If the returned value is 0, the authentication succeeds. If the returned value is 1, the authentication fails. If the connection fails, the server closes the connection directly.

If v3.8 or a later version fails, a string is provided to describe the cause of the failure and close the connection.

If the connection fails under v3.8, the server closes the connection directly.

Initialize message

1. The client sends a byte initialization message.

If other customers on the server are allowed to continue the connection, the sharing flag should be non-zero (true ). Otherwise, the server

Disconnect other customers.

2. the server sends initialization messages to inform the client server of the height, width, pixel format, and desktop-related names of the frame cache.

This is related to implementation. Some implementations send 24 bytes before sending the desktop name string. The name string format is sh-Yinghua-1 (192.168.70.69 ).

The frame cache width is generally the size of the horizontal resolution, and the frame cache height is generally the size of the vertical resolution, such as 1024 × 768.

The pixel format mainly includes the following sections:

The server pixel defines the server's original pixel format, which will be used all the time unless the client enables

Sets a message in pixel format to request another pixel format. Bits-per-pixel indicates the number of digits required for each pixel value. This number must be greater than or equal to depth, and depth is used to indicate the number of useful digits in the pixel value. Currently, each bit must be 8 to 16 or 32 pixels. Smaller than 8 pixels are not supported. If multi-byte pixels are regarded as big-Endian, the big-Endian mark is non-zero. Of course, this does not make sense for 8 bits per pixel.

If the true color mark is non-zero, the last six items specify how to determine the brightness of red, green, and blue Based on the pixel value. Redmost

Limit is the maximum value in red (= 2 ^ n-1, n indicates the number of digits used in red ). Note that this value is generally in the big endian

. Red-replace indicates the number of replicas required to obtain the lowest obvious bit. The green maximum, green-replace, and blue maximum, blue-replace, and red are similar. To find a red value between 0 and the maximum Red value, follow these steps:

• Follow the big-Endian sign for pixel values. (For example, if the big-Endian flag is 0, the host's byte order is big endian, and then exchanges it ).

• Use red-replace to replace the right.

• Logic and red maximum values (in the byte order of the host ).

If the true color mark is zero, the pixel value used by the server is not directly composed of red, green, and blue brightness,

The service is indexed to the color graph. The items in the color chart are set by the server using the fixcolourmapentries message.

Note: bits/pixels are generally the digits of the color quality set for display.

Currently, no server supports fixcolourmapentries messages. Only X-based servers support color ing. In fact, to fully support color ing, the client must be able to specify special pixel values that are not used by the server. This may be added to future protocol versions.

Messages sent from the client to the server

The first byte of all client-to-server messages is the message type, data type u8.

The customer-to-Server Message is defined as follows in this article:

Other types of registered messages include:

It is worth noting that if you want to send a message not defined in this article, you must receive a message from the server.

Set messages in pixel format

In the "frame cache Update" message, how does one set the format of pixel values.

If the client does not send a "set pixel format" message, the pixel value sent by the server will follow the pixel format included in the server initialization message.

If the true color mark is zero, it means that the "Color panel" is used, as long as the client sends a message indicating that the color panel is empty, or the Panel item is reset by the server, the server can use the set Color panel item to set the Color panel.

Note: The pixel format is described in the preceding section.

Set encoding format

You can set the encoding method to determine the type of pixel data sent by the server. In the message, the encoding order is client.

Sort by priority (the first has the highest priority ). This sequence may or may not be selected for the server.

Pixel data can also use "original encoding" if not specified.

In addition to the basic encoding method, the client can also request "pseudo-encoding" to notify the server that it supports a certain extension protocol. If the server does not support this extension, it will ignore this pseudo-encoding. Note: this means that the client assumes that the server does not support its extension before obtaining confirmation from the server.

The next step is to repeat the number of encoding types.

The encoding format is determined by the encoding type.

Request frame cache update

Notification Server: the customer is interested in a region in the frame buffer. This region is limited by the X coordinate, Y coordinate, width, and height parameters.

The server usually sends a framebufferupdate message in response to the framebufferupdaterequest message.

Note: you can send a framebufferupdate message to reply to several framebufferupdaterequest messages.

The server assumes that the customer retains copies of all the parts of the frame server that it is interested in. This means that the server generally only needs to send incremental updates to the customer.

However, if, for some reason, the customer loses the content of a specific region, it will send a framebufferupdaterequest message and set incremental in the message to 0 (false ). This requires the server to send all the content in the specified region as quickly as possible. The copy rectangle encoding method is not used for updates in this region.

If the customer does not lose any content in the region of interest, it will send a framebufferupdaterequest message and set incremental in the message to non-zero (true ). When the specified region in the frame buffer changes, the server sends a framebufferupdate message.

Note that there may be an uncertain interval between framebufferupdaterequest and framebufferupdate.

For fast customers, it may want to send incremental framebufferupdaterequests messages at a fixed frequency to avoid occupying network resources.

When the increment flag is 0, it indicates that the complete content must be sent.

Key event

Press and release a key. If a key is pressed, the flag is not zero. It is released to zero.

In the X Window System, the key itself is assigned "keysym ".

For most keys, "keysym" corresponds to the ASCII Code. For more information, see the xlib referencemanual or reference. In Linux, It is/usr/include/X11/keysymdef. h.

For most common keys, the value of "keysym" is the same as that of the ASCII code (the first three bytes are 0, and the last one is ASCII code ). Other command keys are:

Mouse (pointer) event

Checks whether the pointer is moved or a key is pressed or released. The pointer is currently in the (X and Y coordinates). The keys of the mouse buttons are marked with a mask of 1 to 8 bits. 0 indicates release, and 1 indicates press.

For a normal mouse, "0" indicates that the mouse is moved. The numbers 1, 2, and 3 correspond to the left, center, and right-click buttons respectively. For the pulley mouse, the scroll wheel corresponds to 4th bits and the scroll wheel corresponds to 5th bits.

The drag operation continuously sends the left-click message and changes the coordinates of the mouse.

Client Text cut

The client has a new iso8859-1 (Latin-1) text in its cut cache, and the end of the line is represented by a new line character (value: 10. Do not press enter (value: 13 ). Currently, no method has been found for transferring non-Latin-1 character sets.

Server-to-customer message

Server-to-customer messages are defined as follows:

Other registered message types:

Note: before sending a message to the server, you must confirm that the client supports related extensions.

.

Frame cache update

Frame cache update is composed of a series of pixel data rectangles, which are sent to the frame cache by the client.

It is a response to the client's frame cache update request. There may be periods of uncertainty between requests and responses.

With the number of pixels, each rectangle includes the following:

The following is the specific encoded data.

Set Color panel entries

When the pixel format uses the "Color panel", the message tells the client how the corresponding pixel value is mapped to the RGB brightness.

The following are repeated colors.

Currently, color ing is rarely or even not supported. Some preliminary work has been done in this regard, but it has not been completed yet.

Currently, onlyX The server can fully support color ing.

Ring tones

If there is a bell event, it will ring on the client.

Server cut text

If the server Clipboard contains new content, the server sends the message to the client.

Encoding format

Encoding type in this article

Other encoding types

Original encoding (RawEncoding)

That is, raw pixel data is used without any processing. In this case, for a rectangle whose width is multiplied by the height (that is, the area) to N, the data is composed of N pixel values, these values represent each pixel arranged from left to right in the scanning line order. Obviously, this encoding method is the simplest and the most efficient.

RFB requires all customers to be able to process the original encoding data, and the RFB server generates the original encoding by default when the customer does not specify a certain encoding method.

Copy the rectangle encoding (CopyrectEncoding)

The copyrect encoding method is very simple and effective for clients that already have the same pixel data. This encoding method is represented by the X and Y coordinates in the network. Let the client know to copy the pixel data of that rectangle. It can be applied in many cases. The most obvious thing is that when a user moves a window on the screen, there is also a scrolling window content. It is not obvious when optimizing the image. A smart server may only send the image once, because it knows that the image already exists in the client's frame cache.

Copying the rectangle encoding does not send all the data rectangles completely independently, but only sends all the data of the first rectangle for a group of rectangles with identical pixel values, the subsequent rectangle only needs to send the X and Y coordinates in the upper left corner. In fact, copying a rectangle mainly refers to the subsequent X and Y coordinates, but there is no limit on the encoding Type Used for the first rectangle, you only need to know the position of the first rectangle in the frame buffer to complete the copy operation. Therefore, it is often used to combine the copy rectangle encoding with other encoding types for a rectangle.

Next, use the copyrect encoding method to send the same style.

Two-Dimensional travel encoding (Rise-and-run-length,RRE)

RRE indicates the length of lift and run. as its name implies, RRE indicates the code of Run Length of two-dimensional vectors. RRE encodes the rectangle into a format that can be translated by the client's graphics engine. RRE is not suitable for complex desktops, but it is useful in some cases.

The RRE idea is to divide the data of the pixel rectangle into subareas and the units that compress the original areas. The latest best partitioning method is generally easier to calculate.

Encoding is composed of pixel values. VB (basically the most common pixel values in a rectangle) and a list of subrectangles that count n followed by N, which are composed of arrays, (X, Y) is the coordinate of the Child rectangle. It indicates the coordinate value of-left on the Child rectangle, and (w, h) indicates the width and height of the Child rectangle. The client can use the background pixel data value to draw and then draw the original rectangle Based on the Child rectangle.

Two-Dimensional travel encoding is essentially a two-dimensional simulation of travel encoding, and Its compression degree can ensure the same or even better as the Travel encoding. More importantly, the RRE-encoded rectangle is immediately restored by the simplest graphics engine after being transmitted to the client.

During transmission, the data is described in the following header:

The child rectangle structure follows the repetition below:

Corre Encoding

Corre is a variant of RRE. It limits the maximum size of the rectangle to 255x255 pixels, and represents the dimension of the Child rectangle in one byte. If the server wants to send a rectangle that exceeds the limit, you just need to divide it into several smaller RFB rectangles. "For a common desktop, this method has a better degree of compression than RRE ".

In fact, if we further limit the size of the rectangle, we can get the best degree of compression. "The smaller the maximum value of a rectangle, the better the decision scale ". However, if the maximum value of a rectangle is too small, the number of rectangles is increased. Because each RFB rectangle has a certain overhead, the computation will deteriorate. Select an appropriate number. In the current implementation, the maximum value is 48 × 48.

Hextile Encoding

Hextile is a variant of RRE encoding. The rectangle is divided into 16 × 16 small pieces, and the dimension of each small part is 4 digits,

A total of 16 bits.

It is predefined to divide the original rectangle into small blocks, which means that the position and size of each block do not need to be explicitly specified.

The left-to-right and top-down order of the small parts separated by the rectangle starts from top to bottom. The small part of the encoding content is encoded in a predetermined order. If the width of the entire rectangle is not an integer multiple of 16, the last small part of each line is also reduced accordingly. The height is similar.

Each small part can use raw encoding or RRE encoding variants. Use a byte type to describe it. Each small part has a background pixel value. However, if the background pixel value of a small part is the same as that of the previous one, you do not need to define it clearly. If the child rectangle of a small part has the same pixel value, the foreground pixel value can be defined only once. Like the background pixel value, the foreground pixel value can also be obtained through the previous small part.

Therefore, data composed of small pieces is encoded in sequence. Each small part starts with a byte of the subencoding type. It is composed of digits of the mask.

If the raw bit is set, the remaining bit is invalid; then the width x height pixel value (width and height are the width of a small part)

High ). Otherwise, other bits are valid.

Background definition-if set, the pixel value follows the background color of a small part:

This must be set for the first non-raw part in the rectangle. If this parameter is not set, the background of the non-raw part is

One piece is the same.

Foreground definition-if set, the pixel value defines the foreground color of all the child rectangles in the small part.

If this bit is set, the color bit of the Child rectangle must be 0.

Any child rectangle-if set, a byte contains the number of child rectangles.

If this bit is not set, there will be no child rectangle. (For example, the entire small part is the background color)

Child rectangle coloring-if this parameter is set, the pixel value of any child rectangle takes precedence over the color definition of the child rectangle,

Therefore, the child rectangle is:

If this parameter is not set, all child rectangles are the color of the foreground color. If the foreground definition is not set, the foreground color and

The first slice is the same. The child rectangle is:

The position and size of each sub-rectangle are defined by two digits, X-and-y-position and width-

And-height. The most important four-digit X-an d-y-posi tion defines the position of X, and the N position is not important. Most

The important four-digit width-and-height defines the width-1, and the unimportant four-digit width-and-height defines the height-1.

Zrle Encoding

Zrle (zlib run-length encoding), which combines zlib compression, chip technology, palette, and running Length

Encoding. During transmission, the rectangle starts in a 4-byte area, followed by zlib compressed data, a single

Zlib "stream" objects are used for RFB Protocol connections. Therefore, zrle rectangles must be strictly encoded and

Decoding.

Before zlibdata is compressed, it indicates the order of 64x64 pixels from left to right, from high to low.

And hextile encoding. If the width of the entire rectangle is not an integer multiple of 64

Small pieces are also reduced accordingly. The height is similar.

Zrle encoding utilizes a New Compressed pixel cpixel (compres se d pixel ). This is consistent with pixel.

In the same pixel format, except that the true color mark is non-zero, the bit size per pixel is 32, and the color depth is not greater than 24. All digits are red,

Fill in the least or most important three bytes of green and blue brightness. If cpixel is only 3 bytes long and contains

The most unimportant or important 3 bytes. Bytespercpixel is the number of bytes of cpixel.

Each part starts with a sub-encoding byte. If the part is run length encoding, the highest bit of this byte

It will be set. The remaining 7 digits indicate that the drawing style-0 indicates that there is no style, 1 indicates that the slice is monochrome, and 2-127 indicates that the corresponding

. Possible sub-encoding values are as follows:

0-raw pixel data width x high pixel value (width and height correspond to the width and height of the corresponding piece, the corresponding pixel value is as follows:

2-16-packaged style type. The corresponding pixel values are grouped by The Palet tesize (= sub-encoding) pixel values.

Each packaged pixel value is represented as a region subject to the style index (0 indicates the first entry), corresponding

Palet tesize 2, 1 bit is used, Palet tesize 3, 4 two are used, 4 are used from 5-16

. The bit area is packed into bytes, and the most important bit indicates the leftmost pixel. Because the slice is not 8, 4, and 2 pixels wide

Therefore, fill bits are used to sort each row by the number of bytes.

M indicates the number of bytes of packed pixels. For Palet tesize 2, it is floor (width + 7)/8) x height,

3, 4 is floor (width + 3)/4) x height, and 5-16 is floor (width + 1)/2) x

Height.

17-127 not used (there is no advantage for Palet te RLE ).

128-a simple RLE consists of repeated executions until the end of the film. The execution may start from the end of one row to the start of another row. Each operation is represented by a pixel value and the length of the pixel value. The length is generally 1 or multiple bytes. After calculation, more than the sum of all bytes + 1 is used as the length. All values except 255 indicate the last byte. For example, 1 indicates [0], 255 indicates [254], 256 indicates [257], 510 indicates [255,254], and indicates []. 511 indicates [255,255, 0], and so on.

129-unused

130-255 color Rle. The color is followed by The Palet tesize = (subencoding-128) pixel value:

Next we will combine the simple RLE similarity, some repeated execution components until the end of the piece. Execution length passed

Color Palette index.

If the execution length is greater than one bit, it indicates the palette index and the maximum bit is set. The execution length will be included.

Pseudo-Encoding

Pointer/mouse pseudo-Encoding

If the client requests pointer/mouse pseudo encoding, it is capable of drawing the mouse locally. In this way, the transmission performance can be significantly improved. The server sends a pseudo rectangle with a pseudo-mouse code to set the Mouse shape as part of the update. The X and Y values of the pseudo rectangle represent the hotspot of the mouse, and the width and height represent the width and height of the mouse with pixels. Data with a width x height pixel value carries a bit mask. The bit mask consists of scanning lines from left to right, from top to bottom, and each scanning line is filled with floor (width + 7)/8 ). The most important bit of each byte indicates the leftmost pixel, and the corresponding 1 bit indicates that the pixel of the corresponding pointer is correct.

Desktop size pseudo-Encoding

If the client requests a pseudo-encoding of the desktop size, it can handle the change of the frame cache width/height. The server sends a pseudo-rectangle with the desktop size pseudo-Encoding as the previous rectangle to complete an update. The X and Y of the pseudo rectangle are ignored, while the width and height indicate the new width and height of the frame cache. No other data is related to the pseudo rectangle.

Protocol vulnerabilities and Solutions

The RFB (remote frame buffer) protocol used by the RealVNC VNC Server allows the client to negotiate with the server about an appropriate authentication method. design errors exist in the implementation of the Protocol, remote attackers can bypass authentication without a password to access the server.

The procedure is as follows:

1) the server sends its version "RFB 003.008 \ n"

2) The client replies to its version "RFB 003.008 \ n"

3) the server sends one byte, which is equal to the number of security types provided.

3A) the server sends byte arrays to describe the Security type provided.

4) The client replies one byte and selects the Security type from the 3A array.

5) execute a handshake if needed, and then "0000" of the server"

When implementing the RFB 003.008 protocol in RealVNC 4.1.1 or earlier versions, the system does not check whether the byte sent by the client in step 3 is provided by the server, therefore, authentication is transferred from the server to the client. Attackers can force the client to request "type 1-none" as the security type and access the server without the password field.

Hazard: remote attackers can bypass authentication without a password to access the server.

Solution: Check whether the security type of the client request is one of the types supported by the server. Otherwise, the connection is closed or the unauthenticated security type is prohibited.