VNC协议分析

VNC基于RFB协议实现远程桌面控制,本文详细介绍了VNC的协议流程、显示与输入协议、像素数据表示、编码方式以及扩展机制。此外,还探讨了协议的安全类型协商、认证过程和存在的安全漏洞,特别是如何通过协议漏洞绕过认证。解决方法包括对客户端请求的安全类型进行检查和禁止无认证连接。
摘要由CSDN通过智能技术生成
简介

VNC(Virtual Network Computing)是基于RFB(Remote Frame Buffer)协议进行通信的,是一个基于平台无关的简单显示协议的超级瘦客户系统,

由Cambridge的AT&T实验室设计开发的。

vnc的缺省端口是main:5900(C/S)和http:5800(B/S)端口。

RFB (远程帧缓存) 是一个远程图形用户的简单协议,因为它工作在帧缓存级别上,所以它可以应用于所有的窗口系统,例如:X11,Windows和Mac系统。

远程终端用户使用机器(比如显示器、键盘、鼠标)的叫做RFB客户端,提供帧缓存变化的被称为RFB服务器。

RFB是基于tcp的一个应用层协议。

clip_image002

RFB 是真正意义上的“瘦客机”协议。RFB协议设计的重点在于减少对客户端的硬件需求。这样客户端就可以运行在许多不同的硬件上,客户机的任务实现上就会尽量的简单。

RFB协议对于客户端是无状态的。也就是说:如果客户端从服务器端断开,那么如果它重新连接相同的服务器,客户端的状态会被保存。甚至,一个不同的客户端可以用来连接相同的RFB服务器。而在新的客户端已经能够获得与前一个客户端相同的用户状态。因此,用户的应用接口变的非常便捷。

只要合适的网络连接存在,那么用户就可以使用自己的应用程序,并且这些应用会一直保存,即使在不同的接入点也不会变化。这样无论在哪,系统都会给用户提供一个熟悉、独特的计算环境。

显示协议

显示协议是建立在“把像素数据放在一个由x,y 定位的方框内”这单一图形基础之上的。

乍一看上去,把这么多的用户接口组件绘制出来是非常低效的方法。但是,允许不同的像素数据编码方式,使得我们在处理不同的参数(如:网络带宽,客户端的绘制速度,服务器处理速度)有了很大程度的灵活性。

通过矩形的序列来完成帧缓存的更新。一次更新代表着从一个可用帧缓存状态转换到另一个可用,因此有点和视频的桢类似。尽管矩形的更新一般是分开的,但是并不是必须的。

显示协议的更新部分是由客户端通过命令驱动的。也就是说,更新只是在服务器端响应客户端的请求时发生的。这样就让协议更新质量是可变的。客户端/网络越慢,更新速度也就越慢。对于一些应用来说,相同区域的更新是连续不断的。如果用一个慢的客户端,那么帧缓存的缓存状态是可以被忽略的。这样也可以减少对客户端网络速度和绘制速度的要求。

输入协议

输入协议是基于标准工作站的键盘和鼠标等设备的连接协议。

输入事件就是通过把客户端的输入发送到服务器端。

这些输入事件也可以通过非标准的I /O 设备来综合。

例如,手写笔引擎可能产生一个键盘事件。

像素数据的表示

初始的交互涉及到RFB客户端和服务器之间传输像素数据格式和编码方式的协调。这种协调被设计的让客户端的工作尽量简单。而设计的底线是:服务器必须按照客户端的要求格式来提供像素数据。如果客户端可以同样的处理多种数据格式或编码格式,那么一般会选择服务器端易于生成的格式。

像素格式涉及如何通过像素值来实现不同颜色的重现。最常用的一般像素格式是24 位或16 位的“真彩色”,它通过位来直接实现像素值到红、绿、蓝亮度的转换。8 位“颜色映射”可以任意映射像素值到RGB亮度的转换。

编码指一个矩形的像素数据如何通过网线传输。每个像素数据的矩形都加上了一个头,给定矩形在屏幕上的X、Y坐标、矩形的宽和高,以及指定的编码类型。而后数据本身就是采用这种特定的编码方式。

数据本身遵循特定的编码。目前的编码方式主要有Raw、CopyRect、RRE、Hextile 和ZRLE.在实际应用中我们一般使用ZRLE、Hextile 和CopyRect,因为它们提供了典型桌面的最好压缩。其他可能的编码方式还包括,用于静态图片的JPEG和用于动态图像有效传输的MPEG。

协议可以通过增加新的编码方式来进行扩展。

协议扩展

协议可以通过以下方式进行扩展:

新的编码方式

一种新的协议可以通过与现存的客户端和服务端进行相关兼容的添加。因为现存的服务器将会忽略它们所不支持的新编码方式。所以客户端通过新的编码方式进行请求也就不会有结果返回。

伪编码方式

除了真正的编码方式,客户端也可以请求“伪编码”通告服务器,它支持某一协议的扩展。服务器如果不支持这种扩展,那么它将忽略。值得注意的是:客户端必须先假设服务器端不支持这种扩展,直到它获得服务器端支持的确认。

新的安全方式

添加一个新型的安全方式会带来无限的灵活性,它通过修改协议的一些行为,但是并没有牺牲现存客户端和服务器端的兼容性。客户端和服务器端可以通过协议好的安全方式进行交流,当然并不一定与RFB协议类似。

无论如何你都不应使用不同的版本号。

RFB协议的版本是由RealVNC公司来制定的。如果你使用一个不同的协议版本可能与RFB/VNC不兼容,要保证协议的兼容性,请联系RealVNC公司。这样会减少在编码方式和安全类型上的冲突。

协议消息

RFB协议可以进行可靠的传输,如字节流或基于消息的。和大多数协议一样,它也是通过TCP /IP协议簇连接。协议由三步完成连接。首先是握手报文,目的是对协议版本和加密方式进行协商。第二步是初始化报文,主要用于客户和服务器的初始化消息。最后就是正常协议的交互,客户端可以按需发送消息,然后可以获得服务器的回复。

所有的消息以消息类型开始,接下来是特定的消息数据。

协议消息描述的基本类型有:U8、U16、U32、S8、S16、S32。

U表示无符号整数,S表示有符号整数。

所有字节整数(除了像素值本身)遵从big endian顺序。

big endian或者little endian跟cpu有关,从而影响整数在内存中的排列顺序。big endian是高字节在前,little endian是低字节在前,网络字节序一般是big-endian。

PIXEL代表一个像素值bytesPerPixel字节,8XbytesPerPixel = bits-per-pixel。

协议流程

clip_image004

消息说明
握手消息

1、vnc服务器发送所能够支持的最高RFB协议版本号给客户端,比如:“RFB 003.006/n”,即版本号为3.6,版本号固定格式为×××.×××,不足部分前面补零。

clip_image006

2、客户端回复将要使用的版本号,格式如上。客户端的版本号必须小于或等于服务器版本号。这样服务器可以实现向后兼容。

3、目前发布的协议版本主要有3.3、3.7、3.8(3.5版本被报告存在问题),最高版本号为4.0。

协商安全类型

(一)v3.7以上版本安全类型

服务器发送所支持的安全类型列表

如果客户端能支持服务器的某一安全类型,那么客户端就会发送一个字节来确认连接clip_image008

的安全类型:

clip_image010

如果安全类型数是0,那么连接失败(例如服务器不支持客户请求版本号),这样就

会有字符串来描述失败原因:

clip_image012

服务器在发送原因字串后,就会关闭连接。

(二)3.7以下版本(以vnc认证为例)

1、服务器发送一个无符号的32位整数标识一个安全类型(与认证有关)。

clip_image014

安全类型:

clip_image016

其他认证类

评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值