Bilibili
关于卡
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
反正看不了