技术笔记:SOCKS5协议解析

本文涉及的产品
.cn 域名,1个 12个月
密钥管理服务KMS,1000个密钥,100个凭据,1个月
全局流量管理 GTM,标准版 1个月
简介: 技术笔记:SOCKS5协议解析

socks的官方文档:


  SOCKS5 是一种网络传输协议,主要用于客户端与外网服务器之间通讯的中间传递。SOCKS5 服务器通过将前端发来的请求转发给真正的目标服务器,模拟了一个前端的行为。在这里,前端和SOCKS5之间也是通过TCP/IP协议进行通讯,前端将原本要发送给真正服务器的请求发送给SOCKS5服务器,然后SOCKS5服务器将请求转发给真正的服务器。


注意:本文中程序仅适用于Windows端


一、SOCKS5通信流程


1.客户端与服务器身份验证


2.代理服务器响应客户端请求


3.客户端向代理服务器发送请求地址


4.代理服务器响应客户端请求(代理与远程服务器建立链接,代理服务器相应客户端请求)


5.客户端向代理传输数据


6.代理服务器将数据转发给远程服务器


7.远程服务器将数据发送到代理服务器


8.代理服务器将数据转发给客户端


(一)客户端发送的报头


VERSION


METHODS_COUNT


METHODS


1字节


1字节


1到255字节,长度由METHODS_COUNT值决定


0x05


0x03


……


VERSION:socks 版本,这里用的是 socks5,所以是0x05。


METHODS_COUNT: METHODS 部分的长度。


METHODS:代表客户端拥有的加密方式。每个方法占 1 字节。当前的定义是:


0x00 不加密


0x01 GSSAPI


0x02 用户名、密码认证


0x03 - 0x7F 由IANA分配(保留)


0x80 - 0xFE //代码效果参考:http://www.jhylw.com.cn/312239967.html

为私人方法保留

0xFF 无可接受的方法


// 客户端认证请求


typedef struct client_license_request {


char ver; // 客户端的协议版本号 0x05:socks5 0x04:socks4


char nmethods; // 客户端所支持认证方式的长度


char methods【255】; // 客户端支持的认证方式(可以有255种)


}client_license_request;


// Client端 -- 发送认证信息


client_license_request license_request;


license_request = {0};


license_request.ver = 0x5;


send_len = send(s_server, (char )&license_request, sizeof(license_request),0);


if (send_len < 0)


{


cout [ "验证认证信息失败!" [ endl;


}


// 代理服务器端 -- 接收认证信息


int srlen = 0;


//接收认证信息


char buffer【257】;


recv(fd, buffer, sizeof(buffer), 0);


client_license_request license_request = (client_license_request )buffer;


//验证认证信息


printf("客户端版本%d\n", license_request->ver);


if (license_request->ver != 0x5)


{


printf("协议版本错误\n");


return 0;


}


(二)代理服务器响应的报头


VERSION


METHODS


1字节


1字节


0x05


从客户端发送的加密方式里面选一个


VERSION:socks 版本,这里用的是 socks5,所以是0x05。


METHODS:代表代理服务器选择了一种握手方式。占 1 字节。


例如,代理服务器发送的 5 0,代表 版本5 选择了“不加密”的握手方式。


如果客户端的所有握手方式代理服务器都不满足,直接断开连接。


如果代理服务器发送 5 2,代表 版本5 选择了“用户名、密码认证”的握手方式。此时客户端会发送账号密码数据给代理服务器,再由代理服务器检验,并返回结果。格式如下:


VERSION


USERNAME_LENGTH


USERNAME


PASSWORD_LENGTH


PASSWORD


1字节


1字节


1-255字节


1字节


1-255字节


0x01


0x01


……


0x01


……


VERSION:认证子协商版本(与 SOCKS 协议版本的0x05无关系)


USERNAME_LENGTH:用户名长度


USERNAME:用户名字节数组,长度为 USERNAME_LENGTH


PASSWORD_LENGTH:密码长度


PASSWORD:密码字节数组,长度为 PASSWORD_LENGTH


VERSION


USERNAME_LENGTH


1字节


1字节


0x01


0x01


VERSION:认证子协商版本,与客户端 VERSION 字段一致


?STATUS:认证结果(0x00 认证成功 / 大于0x00 认证失败)


// 服务端回应认证


typedef struct server_license_response {


char ver; // 服务端的协议版本号


char method; // 服务端选择的认证方式


}server_license_response;


// 代理服务器端 -- 响应认证信息


server_license_response license_response;


license_response.ver = 0x5;


license_response.method = 0x0;


char buff【2】 = { 0 };


memcpy(buff, &license_response, sizeof(buff));


//回应认证信息


srlen = send(fd, buff, sizeof(buff), 0);


if (srlen <= 0)


{


}


printf("已发送回应请求\n");


// Client端 -- 接收代理服务器的回应


server_license_response license_response;


license_response = { 0 };


recv(s_server,(char)&license_response, sizeof(license_response), 0);


if (license_response.ver != 0x5 || license_response.method != 0x0)


{


cout [ "代理服务器回应认证失败!" [ endl;


}


(三)客户端发送需要访问的IP和端口,以及协议


VERSION


COMMAND


RSV


ADDRESS_TYPE


DST.ADDR


DST.PORT


1字节


1字节


1字节


1字节


可变成长度


2字节


VERSION:SOCKS 协议版本,固定 0x05


COMMAND:命令


0x01:CONNECT请求,连接上游服务器(使用TCP)


0x02:BIND 绑定,客户端会接收来自代理服务器的链接,著名的FTP被动模式


0x03:UDP ASSOCIATE UDP 中继(UDP 转发)


RSV:保留字段,无实际作用


ADDRESS_TYPE:目标服务器地址类型


0x01:表示 IPv4 地址


0x03:域名地址(没有打错,就是没有0x02)


0x04:IPv6 地址


DST.ADDR:目标服务器地址(如果是ipv6,该字段的第一个字节是域名长度,剩下字节为域名)


DST.PORT:目标服务器端口


// 客户端连接请求


#pragma pack(1)


typedef struct client_connect_request {


char ver; //客户端协议版本号


char cmd; //连接方式


char rsv = 0x00; //保留位0x00


char type; //类型


char addr【20】 = "10.18.33.21"; //目的服务器ip


char port【6】 = "2019"; //目的服务器端口


}client_connect_request;


// Client端 -- 向代理服务器发送请求


client_connect_request connect_request;


connect_request.ver = 0x5;


connect_request.cmd = 0x1;


connect_request.type = 0x01;


send_len = send(s_server,(char )&connect_request, sizeof(client_connect_request) , 0);


if (send_len < 0)


{


cout [ "向代理服务器发送请求失败!" [ endl;


}


(四)代理服务器响应


VERSION


RESPONSE


RSV


ADDRESS_TYPE


BND.ADDR


BND.PORT


1字节


1字节


1字节


1字节


1-255字节


2字节


VERSION:SOCKS 协议版本,固定 0x05


RESPONSE:响应命令


0x00:代理服务器连接目标服务器成功


0x01:代理服务器故障


0x02:代理服务器规则集不允许连接


0x03:网络无法访问


0x04:目标服务器无法访问(主机名无效)


0x05:连接目标服务器被拒绝


0x06:TTL已过期


0x07:不支持的命令


0x08:不支持的目标服务器地址类型


0x09 - 0xFF:未分配


RSV:保留字段


ADDRESS_TYPE:后面的地址类型


0x01:ipv4


0x03:域名


0x04:ipv6


BND.ADDR:代理服务器连接目标服务器成功后的代理服务器 IP


BND.PORT:代理服务器连接目标服务器成功后的代理服务器端口


// 代理服务器端 -- 接收IP与PORT,链接目标机,发回成功信息给 Client


char buf【4096】;


srlen = recv(fd, buf, 4, 0); // 03 05 00 01


if (srlen <= 0)


{


}


if (srlen <= 0) return -1;


if (srlen < 4) return 0;


if (buf【0】 != 0x05 || buf【2】 != 0x00)


{


}


int client_fd = 0;


char ip4【256】, port【5】;


int re = -1;


if (buf【3】 == 0x04)


{ // 如果是 ipv6


// ...


return 0;


}


else if (buf【3】 == 0x01) { // 如果是 ipv4


srlen = recv(fd, ip4, 4, 0);


srlen = recv(fd, port, 2, 0);


ip4【4】 = '\0';


port【2】 = '\0';


client_fd = socket(AF_INET, SOCK_STREAM, 0);


struct sockaddr_in server;


server.sin_family = AF_INET;


memcpy(&server.sin_addr.s_addr, ip4, 4);


server.sin_port = ((uint16_t)port);


re = connect(client_fd, (struct sockaddr)&server, sizeof(server));


if (re == -1)


{


}


// ...


}


else if (buf【3】 == 0x03) { // 是用域名表示的


// 域名字段中第一个字节是真实的域名的长度,后面才是真实的域名


char doname_len;


char doname【256】;


srlen = recv(fd, &doname_len, 1, 0);


if (len < 1) return 0;


len = recv(fd, doname, doname_len, 0);


doname【len】 = '\0';


struct hostent host = gethostbyname(doname);


if (host != nullptr)


{


memcpy(ip4, host->h_addr, host->h_length);


len = recv(fd, port, 2, 0);


client_fd = socket(AF_INET, SOCK_STREAM, 0);


struct sockaddr_in server;


server.sin_family = AF_INET;


memcpy(&server.sin_addr.s_addr, ip4, 4);


server.sin_port = ((uint16_t)port);


re = connect(client_fd, (struct sockaddr)&server, sizeof(server));


if (re == -1)


{


}


}


}


else


{


}


//成功连接则发送回应信息


//回应连接信息


char buffer1【10】 = { 0 };


server_connect_response connect_response = { 0 };


connect_response.ver = 0x5;


connect_response.rep = 0x00; //连接成功标志


connect_response.rsv = 0x00;


connect_response.type = 0x01;


相关文章
|
18天前
|
机器学习/深度学习 人工智能 自然语言处理
AI技术深度解析:从基础到应用的全面介绍
人工智能(AI)技术的迅猛发展,正在深刻改变着我们的生活和工作方式。从自然语言处理(NLP)到机器学习,从神经网络到大型语言模型(LLM),AI技术的每一次进步都带来了前所未有的机遇和挑战。本文将从背景、历史、业务场景、Python代码示例、流程图以及如何上手等多个方面,对AI技术中的关键组件进行深度解析,为读者呈现一个全面而深入的AI技术世界。
90 10
|
1天前
|
自然语言处理 文字识别 数据处理
多模态文件信息抽取:技术解析与实践评测!
在大数据和人工智能时代,企业和开发者面临的挑战是如何高效处理多模态数据(文本、图像、音频、视频)以快速提取有价值信息。传统方法效率低下,难以满足现代需求。本文将深度评测阿里云的多模态文件信息抽取解决方案,涵盖部署、应用、功能与性能,揭示其在复杂数据处理中的潜力。通过自然语言处理(NLP)、计算机视觉(CV)、语音识别(ASR)等技术,该方案助力企业挖掘多模态数据的价值,提升数据利用效率。
12 4
多模态文件信息抽取:技术解析与实践评测!
|
4天前
|
域名解析 负载均衡 安全
DNS技术标准趋势和安全研究
本文探讨了互联网域名基础设施的结构性安全风险,由清华大学段教授团队多年研究总结。文章指出,DNS系统的安全性不仅受代码实现影响,更源于其设计、实现、运营及治理中的固有缺陷。主要风险包括协议设计缺陷(如明文传输)、生态演进隐患(如单点故障增加)和薄弱的信任关系(如威胁情报被操纵)。团队通过多项研究揭示了这些深层次问题,并呼吁构建更加可信的DNS基础设施,以保障全球互联网的安全稳定运行。
|
4天前
|
缓存 网络协议 安全
融合DNS技术产品和生态
本文介绍了阿里云在互联网基础资源领域的最新进展和解决方案,重点围绕共筑韧性寻址、赋能新质生产展开。随着应用规模的增长,基础服务的韧性变得尤为重要。阿里云作为互联网资源的践行者,致力于推动互联网基础资源技术研究和自主创新,打造更韧性的寻址基础服务。文章还详细介绍了浙江省IPv6创新实验室的成立背景与工作进展,以及阿里云在IPv6规模化部署、DNS产品能力升级等方面的成果。此外,阿里云通过端云融合场景下的企业级DNS服务,帮助企业构建稳定安全的DNS系统,确保企业在数字世界中的稳定运行。最后,文章强调了全链路极致高可用的企业DNS解决方案,为全球互联网基础资源的创新提供了中国标准和数字化解决方案。
|
4天前
|
缓存 边缘计算 网络协议
深入解析CDN技术:加速互联网内容分发的幕后英雄
内容分发网络(CDN)是现代互联网架构的重要组成部分,通过全球分布的服务器节点,加速网站、应用和多媒体内容的传递。它不仅提升了访问速度和用户体验,还减轻了源站服务器的负担。CDN的核心技术包括缓存机制、动态加速、流媒体加速和安全防护,广泛应用于静态资源、动态内容、视频直播及大文件下载等场景,具有低延迟、高带宽、稳定性强等优势,有效降低成本并保障安全。
25 3
|
11天前
|
网络协议 安全 网络安全
探索网络模型与协议:从OSI到HTTPs的原理解析
OSI七层网络模型和TCP/IP四层模型是理解和设计计算机网络的框架。OSI模型包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层,而TCP/IP模型则简化为链路层、网络层、传输层和 HTTPS协议基于HTTP并通过TLS/SSL加密数据,确保安全传输。其连接过程涉及TCP三次握手、SSL证书验证、对称密钥交换等步骤,以保障通信的安全性和完整性。数字信封技术使用非对称加密和数字证书确保数据的机密性和身份认证。 浏览器通过Https访问网站的过程包括输入网址、DNS解析、建立TCP连接、发送HTTPS请求、接收响应、验证证书和解析网页内容等步骤,确保用户与服务器之间的安全通信。
59 1
|
22天前
|
数据采集 存储 JavaScript
网页爬虫技术全解析:从基础到实战
在信息爆炸的时代,网页爬虫作为数据采集的重要工具,已成为数据科学家、研究人员和开发者不可或缺的技术。本文全面解析网页爬虫的基础概念、工作原理、技术栈与工具,以及实战案例,探讨其合法性与道德问题,分享爬虫设计与实现的详细步骤,介绍优化与维护的方法,应对反爬虫机制、动态内容加载等挑战,旨在帮助读者深入理解并合理运用网页爬虫技术。
|
17天前
|
传感器
Modbus协议深入解析
Modbus协议是由Modicon公司(现施耐德电气)于1979年发明的串行通信协议,主要用于工业自动化系统中的PLC通信。本文深入解析了Modbus协议的主从模式、数据类型(线圈、离散输入、保持寄存器、输入寄存器)、帧结构和通信过程,并介绍了其应用场景和重要性。
18 0
|
2月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
87 2
|
10天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析

推荐镜像

更多