2012年6月23日星期六

Homemade RaySource

好吧,我们都知道fs2you链接长什么样,自然也看得出来,fs2you://后面的部分,其实是经过Base64编码的字符串。

比如:

fs2you://Y2FjaGVmaWxlMzIucmF5ZmlsZS5jb20vemgtY24vZG93bmxvYWQvYjI3ODI1NzQ2YjgxOWYyMmY1ZGY0ZTFkNTE0NDFjNmQvJUU3JTk0JUIwJUU0JUI4JUFEJUU4JThBJUIzJUU2JUEwJTkxLnJhcnwxMjkyMTEzOQ==

经过解码,可以得到:

cachefile32.rayfile.com/zh-cn/download/b27825746b819f22f5df4e1d51441c6d/%E7%94%B0%E4%B8%AD%E8%8A%B3%E6%A0%91.rar|12921139

竖线符分隔的第一个部分看起来是一个URL,第二个部分则是文件尺寸。有时候竖线符有两个,第三部分是另外一个文件名。通过抓取客户端RaySource的数据包,可以验证以上猜测。

GET /zh-cn/download/b27825746b819f22f5df4e1d51441c6d/%E7%94%B0%E4%B8%AD%E8%8A%B3%E6%A0%91.rar HTTP/1.0
Host: cachefile32.rayfile.com
Accept: */*
Referer: 
Cookie: 
User-Agent: Grid Service 2.1.10.8366
Grid: aWQ9nc3JxpnLys4mcF9udW09MCZkX3NwZWVkPTA=
Range: bytes=0-262144

Grid又是一个Base64字符串,解码后的内容是:

"id=\x9D\xCD\xC9\xC6\x99\xCB\xCA\xCE&p_num=0&d_speed=0"

id均为8个字节,当成GBK字符解码,可以得到四个看起来像天书的中文。p_num可能是process,同时下载多个文件时会有不同的值。s_speed有可能是当前的下载速率,可我想不出为什么服务器会对这个数值感兴趣。

经验证,构造一个类似的HTTP请求,可以用别的下载工具获取文件,比如:

curl --verbose --remote-name --user-agent "Grid Service 2.1.10.8366" --header "Accept: */*" --header "Referer: " --header "Cookie: " --header "Grid: aWQ9nc3JxpnLys4mcF9udW09MCZkX3NwZWVkPTA=" --header "Range: bytes=0-12921138" "http://cachefile32.rayfile.com/zh-cn/download/b27825746b819f22f5df4e1d51441c6d/%E7%94%B0%E4%B8%AD%E8%8A%B3%E6%A0%91.rar"

正常情况下,可以得到一个206响应。只要一切正常,即可直接下载到目标文件。不过就像大家都知道的那样,网络是很不靠谱的。当下载时遭遇断线,构造正常的Range头,如“Range: bytes=1234-12921138”并不能断点续传。

关于这个问题,抓包并没有太大的帮助。RaySource发出的请求中,Range的两个数字除了0和文件的实际尺寸外,均为256KB的正整数倍,且整个Range不超过5MB。嗯,这也太奇怪了点儿。

通过各种尝试,我发现有时候Range的起始值可以是不大于文件尺寸的任意数,且只要Range不大于8000000,也可以获得服务器正确的响应。不过这个有时候,具体是什么情况,我也说不清楚…

嗯,基本上目前就是这样,问题依旧没有解决的说。

1 条评论 :

oCameLo 说...

可以把东西完整拖回来是基本需求,目前这些成果似乎都还不足以实现这一点…