• 全部
  • VC综合技术
  • 互联网技术
  • MFC AppLauncher
  • .NET 技术
  • 界面
  • 进程
  • 算法
  • 硬件/系统
  • 数据库
  • VC++技术资源

关于 SocksXP 的实现原理猜想,值得一看和讨论哦!!!:)

Neville 2002-05-14 01:04:33
SocksXP 现已成为比较出名的代理软件,
可以通过它在内部网内上 QQ,但是 SocksXP
开始实行收费了。
我因一直对这类协议转换代理软件开发感
兴趣,所以也对 SocksXP 经过一些初步的分析,
形成下面对 SocksXP 核心实现原理的初步猜想:
1)通过 HTTP 1.0 协议(经截包分析所得),
实现在 HTTP 代理服务器上传输数据。其中
用到 HTTP 的 Keep Alive 和 Connect 等。
2)在 1080 端口 Listen,充当 Socks5 代理
服务器。将连接到 1080 端口的数据解析后通过
HTTP 1.0 协议(途经 HTTP 代理服务器)传到
SocksXP 的服务器上。
3)SocksXP 服务器将数据处理后送往目的
服务器(如 QQ 服务器)。
4)接收数据过程恰好相反。
以上乃初步分析,仍有细节未能考虑到。而且也只是
猜想。希望大家加入讨论,得出一个可行的实现方案。
支持这个讨论的热心网友也可以帮忙 up。Thanks :)


...全文
37 点赞 收藏 11
写回复
11 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
voohoo2000 2002-05-14
关注
回复
cxiaobao 2002-05-14
我做过差不多功能的一组程序,原理也差不多。目的是从内网通过http代理上qq,由于socks5服务器太烦,也找不到现成的代码用,我就没有做socks5服务器。具体如下:

1:做一个程序A,在自己机器上运行,这个程序打开udp8000端口,并且使用http协议通过http代理服务器连接到外面机器(类似于sockxp的服务器),这个程序总是保存最后一次向自己发消息的qq的地址和端口,当消息返回时,就把消息发往这个地址端口,所以一个程序A只能有一个qq上线,当有两个以上的qq同时使用这个程序时,它回送的消息就乱套了,解决这个问题有点烦,我没有做。

2:做另一个程序B,在外面的机器上(sockxp的服务器)运行,打开一个tcp端口监听,等待程序A通过http代理的连接,如果程序A来连接,则建立一对socket,一个socket使用tcp协议与A连接,另一个使用udp向tencent或着其他的qq发送接受消息。

3:现在,剩下的事就是如何让QQ把所有的消息都发送到程序A.我使用了替换winsock.dll的方法,截获QQ对sendto的调用。在sendto中,我把真正的目标地址、端口、数据、数据长度重新打包,把重新打包后的数据发往程序A的8000端口(udp)。在重新打包的过程中,我判断了真正的目标地址,如果它本来就是程序a的8000端口(意味着qq想把这个消息发往qq服务器),我就把这个地址改为qq服务器的真正地址。当程序a收到这个数据包(我在socket.dll中重新打包过的)时,它会直接把这个包通过http代理服务器送到程序b,b在接受到这个数据包后按照早先打包的规则解开这个数据包,它就知道应该发往哪里了,使用udp socket发送解包后的数据。当这个udp socket接受到返回的数据时,它让与之相对应的tcp socket发送这个数据包到程序a,程序a再把接受到这个数据包用udp发回qq,这样通讯就完成了。

4:把替换过的winscok.dll放到qq的目录下面,把qq的服务器地址改为程序a所在机器的地址,端口改为程序a打开的udp端口,OK!

事实上证明这个方法是行的通的,但是有一点要注意,由于这个程序只处理了udp消息,所以使用tcp的消息无法通信,比如qq的聊天市。
还有一点我始终不明白,这个法子对与服务器的通讯非常快,但是与其他的qq通信却很少成功(但有时也可以),一般都要经过“服务器中转”,问题是程序b中的udp socket接收返回的消息时出错:“虚电路reset”,好象是对方qq的udp端口没有绑定引起的,但我也不肯定,如果高手知道,希望能告诉我。

我用这个办法上了半年的qq,但是后来不用了,源程序也都被我丢掉了。


回复
adrian_liang 2002-05-14
我把过程写的稍微详细一些,想听一下你的意见:
1. 内部网的机器上运行SocksXP代理Client。
目的:发出伪装的HTTP包,通过局域网HTTP代理服务器到外部网。
2. 外部网中运行一台SocksXP代理Server。
目的:接收伪装的HTTP请求,转换为QQ请求,发送到QQ服务器。
3. 接收数据过程相反。

所以,以上过程中需要有三个程序功能模块:
1. SocksXP Client
2. SocksXP Server
3. QQ Client
其中,2和3可以做在同一个进程中。(略GUI模块部分)

较详细的数据流程为:
a. 1和2之间发送、接收HTTP数据包(当然要通过HTTP代理服务器)
b. 2和3之间跑内部协议。
c. QQ Client发送标准QQ包。

你看如何?
回复
tianlinyi 2002-05-14
up
回复
windwu 2002-05-14
有兴趣可以做一个e-border和SockOnline结合的代理,这样就不用在程序中设置代理了,大家意下如何?
回复
puppet 2002-05-14
socksxp的确很好用。
同意neville (昨夜流星ms)
回复
knl 2002-05-14
服务器不太好找吧!
我现在代理都不好找!!
回复
Neville 2002-05-14
继续讨论,打算作一个免费的 SocksXP 出来。
(当然如果做完了,还要在外面找台服务器运行,呵呵!)

大家踊跃讨论:)
回复
Hover 2002-05-14
同意neville (昨夜流星ms)的观点
回复
lshadow 2002-05-14
我看不动,能不能给分啊?
回复
Neville 2002-05-14
继续:P
回复
相关推荐
综教楼后的那个坑用双向链表实现 描述   在 LIT 综教楼后有一个深坑,关于这个坑的来历,有很多种不同的说法。其中一种说法是,在很多年以前,这个坑就已经在那里了。这种说法也被大多数人认可,这是因为该坑有一种特别的结构,想要人工建造是有相当困难的。   从横截面图来看,坑底成阶梯状,由从左至右的 1..N 个的平面构成(其中 1 ≤ N ≤ 100,000),如图:    *            * :    *            * :    *            * 8    *    **      * 7    *    **      * 6    *    **      * 5    *    ********* 4 <- 高度    *    ********* 3    ************** 2    ************** 1 平面 |  1  |2|   3    | 每个平面 i 可以用两个数字来描述,即它的宽度 Wi 和高度 Hi,其中 1 ≤ Wi ≤ 1,000、1 ≤ Hi ≤ 1,000,000,而这个坑最特别的地方在于坑底每个平面的高度都是不同的。每到夏天,雨水会把坑填满,而在其它的季节,则需要通过人工灌水的方式把坑填满。灌水点设在坑底位置最低的那个平面,每分钟灌水量为一个单位(即高度和宽度均为 1)。随着水位的增长,水自然会向其它平面扩散,当水将某平面覆盖且水高达到一个单位时,就认为该平面被水覆盖了。   请你计算每个平面被水覆盖的时间。    灌水 水满后自动扩散 | | * | * * | * * * * V * * V * * * * * * .... * *~~~~~~~~~~~~* * ** * *~~~~** : * *~~~~**~~~~~~* * ** * *~~~~** : * *~~~~**~~~~~~* * ** * *~~~~**~~~~~~* *~~~~**~~~~~~* * ********* *~~~~********* *~~~~********* *~~~~********* *~~~~********* *~~~~********* ************** ************** ************** ************** ************** **************    4 分钟后    26 分钟后        50 分钟后    平面 1 被水覆盖     平面 3 被水覆盖    平面 2 被水覆盖输入   输入的第一行是一个整数 N,表示平面的数量。从第二行开始的 N 行上分别有两个整数,分别表示平面的宽度和高度。 输出   输出每个平面被水覆盖的时间。
发帖
VC/MFC
创建于2007-09-28

1.5w+

社区成员

VC/MFC相关问题讨论
申请成为版主
帖子事件
创建了帖子
2002-05-14 01:04
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……