（未显示同一用户的12个中间版本）
第7行： 第7行：
  
 
随后地址里的域名会被解析。这个过程是可控的。
 
随后地址里的域名会被解析。这个过程是可控的。
 +
 +
=== 篡改请求内容 ===
 +
篡改部分已经成功。
 +
* 把interface.bilibili.com解析到192.168.1.1
 +
* 将路由上的uhttpd换成lighttpd
 +
* 配置vhost，使得对interface.bilibili.com的请求转发到localhost:8118
 +
<pre>
 +
$HTTP["host"] == "interface.bilibili.com" {
 +
    proxy.balance = "hash"
 +
    proxy.server = ( "" => ( ( "host" => "127.0.0.1" , "port" => 8118 ) ) )
 +
}
 +
</pre>
 +
* 安装配置privoxy
 +
 +
本来这里的计划是用privoxy篡改请求。大概是这样：
 +
首先加个filter:
 +
<pre>
 +
CLIENT-HEADER-FILTER: nomp4 Remove all "&type=mp4"
 +
 +
s/&type=mp4//
 +
</pre>
 +
然后指定action:
 +
<pre>
 +
{+client-header-filter{nomp4}}
 +
/playurl
 +
</pre>
 +
写完之后发现，privoxy报out of memory…… 搜了一下看来是这个bug：
 +
 +
https://dev.openwrt.org/ticket/5494
 +
 +
说不定新版解决了，但是我这个老路由器还是不要折腾了……
 +
 +
研究发现lighttpd自己就可以rewrite，于是写了个rewrite rule
 +
* 配置lighttpd，重写请求
 +
比如说要去掉type=mp4，可以把
 +
<pre>
 +
    url.rewrite = ( "^/(.*)&type=mp4(.*)$" => "/$1$2" )
 +
</pre>
 +
加在lighttpd的vhost配置里。
 +
这样就能用了。
 +
 +
如果以后用SSL了，或者请求的时候检查请求校验和一类的东西了，那就没法篡改了……
 +
 +
=== 篡改重定向结果 ===
 +
在有privoxy的情况下，首先在lighthttpd配置好伪服务器：
 +
<pre>
 +
$HTTP["host"] == "edge.v.iask.com.lxdns.com" {                             
 +
    proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 8118 ) ) )
 +
}
 +
</pre>
 +
 +
其次让edge.v.iask.com.lxdns.com解析为192.168.1.1，这样对它的请求就重定向到privoxy了。
 +
 +
然后在privoxy里，先加上要干的事情：修改user.filter，加
 +
<pre>
 +
SERVER-HEADER-FILTER: lxdns-redirect Redirect to some better servers
 +
                                                                     
 +
s@^(Location:)\s*http://8.37.23[0-9.]+/(.*)$@$1 http://8.37.235.11/$2@i
 +
</pre>
 +
大体上就是说，匹配服务器返回的header里面的Location header，篡改其服务器部分。
 +
 +
其次，说好啥时候用这个rule。修改user.action，加
 +
<pre>
 +
{+server-header-filter{lxdns-redirect}}                               
 +
edge.v.iask.com.lxdns.com/.*                                     
 +
</pre>
 +
就是说在匹配edge.v.xxx的时候用那个filter。
 +
 +
最后把这俩文件加进privoxy的配置文件，就可以了……
  
 
=== 新浪 ===
 
=== 新浪 ===
第25行： 第94行：
  
 
要固定返回的域名…… 可能要改写HTTP请求结果了。
 
要固定返回的域名…… 可能要改写HTTP请求结果了。
 +
 +
==== 再次重定向 ====
 +
某日发现某视频又很卡，抓包得到如下结果，是本机和70.39.191.158 port 80的交流：
 +
<pre>
 +
GET /71186550.hlv?KID=sina,viask.... HTTP/1.1
 +
Host: edge.v.iask.com.lxdns.com
 +
....
 +
</pre>
 +
<pre>
 +
HTTP/1.0 302 Found
 +
Cache-Control: no-cache
 +
Connection: close
 +
Location: http://8.37.235.12/edge.v.iask.com/71186550.hlv?KID=sina,viask&....&wshc_tag=1&wsts_tag=54cefbf7&wsid_tag=a0272e12&wsiphost=ipdbm
 +
</pre>
 +
所以说看来这个cdn又重定向到了别人那里……
 +
 +
这个Location后面的IP会变，返回的大概在8.37.233.x - 8.37.236.x范围里。有些IP的连接情况很糟糕，时不时丢包，甚至一个包都没有…… 有些就很靠谱……
 +
靠谱的：
 +
* 8.37.235.11
 +
不靠谱的:
 +
* 8.37.233.16
 +
* 8.37.236.12
 +
* 8.37.236.14
 +
* 8.37.236.15
 +
 +
计划篡改这个IP，篡改到靠谱的IP上去…… [已实行]
  
 
=== 乐视 ===
 
=== 乐视 ===
第33行： 第128行：
  
 
=== B站 ===
 
=== B站 ===
 +
* us-chicago.acgvideo.com
 +
** 67.159.54.58 Chicago fast smooth <100ms
 
* cc.acgvideo.com 正规名 cc00009.f.cncssr.chinacache.net
 
* cc.acgvideo.com 正规名 cc00009.f.cncssr.chinacache.net
 
** 123.235.32.130
 
** 123.235.32.130
 
** 36.250.90.194 福建省 联通 very slow <50kB/s lag >1000ms
 
** 36.250.90.194 福建省 联通 very slow <50kB/s lag >1000ms
−
** 182.118.9.130 河南省 联通 ok
+
** 182.118.9.130 河南省 联通 varies 30~300kB/s
 
** 221.194.130.206 河北省 联通 slow <100kB/s smooth
 
** 221.194.130.206 河北省 联通 slow <100kB/s smooth
 
** 119.6.246.137 四川省 联通 very slow <50kB/s lag >1000ms
 
** 119.6.246.137 四川省 联通 very slow <50kB/s lag >1000ms
 
** 210.76.57.147 黑龙江 联通 very slow <50kB/s lag >1000ms
 
** 210.76.57.147 黑龙江 联通 very slow <50kB/s lag >1000ms
 
** 112.84.133.214 varies/ok
 
** 112.84.133.214 varies/ok
 +
 +
前一个貌似是个缓存，有一些热门视频。但是Android客户端常常没法拿到这个服务器，主要原因是Android客户端在获取视频地址时指定了type=mp4。如果去掉type=mp4，那获得前一个服务器的机会就大不少。
 +
 +
观察得知前一个服务器获得的视频基本上都是flv的。我怀疑是因为多数人使用网页版上b站，而网页版会请求flv格式，于是缓存服务器基本上也是缓存比较热门的flv格式。
 +
 +
其实Android客户端也可以支持flv格式的内容，因此只要把请求时候的type=mp4去掉，就更有希望获得前一个服务器上的视频。<已使用>
  
 
=== 优酷 ===
 
=== 优酷 ===
 
* k.youku.com
 
* k.youku.com
−
** 119.167.145.95 fast 200~2200kB/s ok 800~1100ms
+
** 119.167.145.95
 
** 还有很多119.167.145.* 都差不多
 
** 还有很多119.167.145.* 都差不多
 +
其实都是youku的前端服务器，连上会给一个redirect，给你一个http://<某ip>/...这样的东西
 +
 +
* youku redirect
 +
** 113.103.44.51 mostly fast ok
 +
** 63.243.196.190 fast 200~2200kB/s ok 800~1100ms
 +
而且直接把某ip篡改了貌似会404，看来和后面的参数也有关系。暂时没法折腾。
  
 
=== PPTV ===
 
=== PPTV ===
 
反正看不了
 
反正看不了

2015年2月9日 (一) 02:45的最新版本

关于卡

B站搞了个测试功能，于是可以观察各个源的情况。

获得视频地址

首先找interface.bilibili.com问视频在哪。目前这个请求是不加密的，有篡改的希望。或者干脆把interface.bilibili.com解析到本地，然后过滤http流量。

随后地址里的域名会被解析。这个过程是可控的。

篡改请求内容

篡改部分已经成功。

  • 把interface.bilibili.com解析到192.168.1.1
  • 将路由上的uhttpd换成lighttpd
  • 配置vhost，使得对interface.bilibili.com的请求转发到localhost:8118
$HTTP["host"] == "interface.bilibili.com" {
    proxy.balance = "hash"
    proxy.server = ( "" => ( ( "host" => "127.0.0.1" , "port" => 8118 ) ) )
}
  • 安装配置privoxy

本来这里的计划是用privoxy篡改请求。大概是这样： 首先加个filter: 

CLIENT-HEADER-FILTER: nomp4 Remove all "&type=mp4"

s/&type=mp4//

然后指定action: 

{+client-header-filter{nomp4}}
/playurl

写完之后发现，privoxy报out of memory…… 搜了一下看来是这个bug：

https://dev.openwrt.org/ticket/5494

说不定新版解决了，但是我这个老路由器还是不要折腾了……

研究发现lighttpd自己就可以rewrite，于是写了个rewrite rule

  • 配置lighttpd，重写请求

比如说要去掉type=mp4，可以把 

    url.rewrite = ( "^/(.*)&type=mp4(.*)$" => "/$1$2" )

加在lighttpd的vhost配置里。 这样就能用了。

如果以后用SSL了，或者请求的时候检查请求校验和一类的东西了，那就没法篡改了……

篡改重定向结果

在有privoxy的情况下，首先在lighthttpd配置好伪服务器： 

$HTTP["host"] == "edge.v.iask.com.lxdns.com" {                              
    proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 8118 ) ) )
}

其次让edge.v.iask.com.lxdns.com解析为192.168.1.1，这样对它的请求就重定向到privoxy了。

然后在privoxy里，先加上要干的事情：修改user.filter，加 

SERVER-HEADER-FILTER: lxdns-redirect Redirect to some better servers
                                                                      
s@^(Location:)\s*http://8.37.23[0-9.]+/(.*)$@$1 http://8.37.235.11/$2@i

大体上就是说，匹配服务器返回的header里面的Location header，篡改其服务器部分。

其次，说好啥时候用这个rule。修改user.action，加 

{+server-header-filter{lxdns-redirect}}                                
edge.v.iask.com.lxdns.com/.*

就是说在匹配edge.v.xxx的时候用那个filter。

最后把这俩文件加进privoxy的配置文件，就可以了……

新浪

新浪主要有俩域名:

  • v.iask.com 应该是主站吧
    • 202.108.37.55 北京 联通
    • 60.28.164.251 天津 联通
  • edge.v.iask.com.lxdns.com 某CDN的节点，正规名为www.ipswitch.glb0.lxdns.com
    • 121.14.35.240 广州 电信
    • 115.231.132.57 杭州 电信
    • 70.39.191.158 LA

首先是给个域名，然后从域名解析出IP。

对前一个域名，北京节点的网速比天津好多了；对后一个域名，当然是LA好。

通过在DNS上固定解析，可以绑定域名和IP。<已实行>

要固定返回的域名…… 可能要改写HTTP请求结果了。

再次重定向

某日发现某视频又很卡，抓包得到如下结果，是本机和70.39.191.158 port 80的交流： 

GET /71186550.hlv?KID=sina,viask.... HTTP/1.1
Host: edge.v.iask.com.lxdns.com
....

HTTP/1.0 302 Found
Cache-Control: no-cache
Connection: close
Location: http://8.37.235.12/edge.v.iask.com/71186550.hlv?KID=sina,viask&....&wshc_tag=1&wsts_tag=54cefbf7&wsid_tag=a0272e12&wsiphost=ipdbm

所以说看来这个cdn又重定向到了别人那里……

这个Location后面的IP会变，返回的大概在8.37.233.x - 8.37.236.x范围里。有些IP的连接情况很糟糕，时不时丢包，甚至一个包都没有…… 有些就很靠谱…… 靠谱的：

  • 8.37.235.11

不靠谱的:

  • 8.37.233.16
  • 8.37.236.12
  • 8.37.236.14
  • 8.37.236.15

计划篡改这个IP，篡改到靠谱的IP上去…… [已实行]

乐视

  • g3.letv.cn
    • 115.182.51.175 北京 (巨快)
    • 117.121.54.219 北京 电信

有的其实看不了，只有广告

B站

  • us-chicago.acgvideo.com
    • 67.159.54.58 Chicago fast smooth <100ms
  • cc.acgvideo.com 正规名 cc00009.f.cncssr.chinacache.net
    • 123.235.32.130
    • 36.250.90.194 福建省 联通 very slow <50kB/s lag >1000ms
    • 182.118.9.130 河南省 联通 varies 30~300kB/s
    • 221.194.130.206 河北省 联通 slow <100kB/s smooth
    • 119.6.246.137 四川省 联通 very slow <50kB/s lag >1000ms
    • 210.76.57.147 黑龙江 联通 very slow <50kB/s lag >1000ms
    • 112.84.133.214 varies/ok

前一个貌似是个缓存，有一些热门视频。但是Android客户端常常没法拿到这个服务器，主要原因是Android客户端在获取视频地址时指定了type=mp4。如果去掉type=mp4，那获得前一个服务器的机会就大不少。

观察得知前一个服务器获得的视频基本上都是flv的。我怀疑是因为多数人使用网页版上b站，而网页版会请求flv格式，于是缓存服务器基本上也是缓存比较热门的flv格式。

其实Android客户端也可以支持flv格式的内容，因此只要把请求时候的type=mp4去掉，就更有希望获得前一个服务器上的视频。<已使用>

优酷

  • k.youku.com
    • 119.167.145.95
    • 还有很多119.167.145.* 都差不多

其实都是youku的前端服务器，连上会给一个redirect，给你一个http://<某ip>/...这样的东西

  • youku redirect
    • 113.103.44.51 mostly fast ok
    • 63.243.196.190 fast 200~2200kB/s ok 800~1100ms

而且直接把某ip篡改了貌似会404，看来和后面的参数也有关系。暂时没法折腾。

PPTV

反正看不了

取自“https://wiki.henryhu.net/index.php?title=Bilibili&oldid=433”
取自“https://wiki.henryhu.net/index.php?title=Bilibili&oldid=433”