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，也可以获得服务器正确的响应。不过这个有时候，具体是什么情况，我也说不清楚…

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