由于百度云客户端下载速度跟便秘似的，因此我试着破解了下载文件链接，没想到还真的找到了入口。great～
电脑配置：
系统：Mac OS X 10_11_6
浏览器：Chrome 58.0.3029.110虽然可以确定百度云的所有信息都是异步加载的，但并不能立刻确定下载包含在哪一个请求中，所以我尝试随便点了一个比较小的文件，看网络请求。
点下载会发出2个请求：/api/sharedownload 和/share/autoincre
查看其返回内容明显确定了是/api/sharedownload这个接口返回了包含下载信息的数据，dlink即为下载的链接。
于是乎我对一个大的文件进行下载过程检测。然额，很明显其返回的数据字段变化了。没有dlink字段，反而多出一个莫名其妙的list字段，看来这一步需要绕个弯子。不过我依然确定这个接口是解开的关键。
我尝试查看调取此接口的js代码，发现了一些可疑的名词：
send @ base_2b5a80b.js:5
ajax @ base_2b5a80b.js:5
s.ajaxGetDlinkShare @ widget-sync_28bad21.js:4
s.getDlinkShare @ widget-sync_28bad21.js:4
u._serverCallGuanjia @ widget-sync_28bad21.js:7
(anonymous) @ widget-sync_28bad21.js:7
success @ widget-sync_28bad21.js:9
l @ base_2b5a80b.js:4
fireWith @ base_2b5a80b.js:4
r @ base_2b5a80b.js:5
n @ base_2b5a80b.js:5明显看到此处 getDlinkShare 出现了两次，Guanjia出现过一次，看到这里只要不是傻子都能大致猜到这两个方法代表的含义了。
getDlinkShare多半是获取下载链接的方法，而Guanjia则是唤起百度云管家的方法。没错，我验证了一次的确如此。
既然找到了关键突破点，那么联想到百度云下载大文件的逻辑，我基本可以确定在唤起云管家客户端这一步之前已经得到了实际的下载地址。
所以我认为有必要在_serverCallGuanjia中间加点料，把真实下载地址duang出来。
代码如下：
....
u.prototype._serverCallGuanjia = function(i) {
// 插入代码开始
console.warn(unescape(`正在分析下载文件地址：${this._mOpts.list[0].server_filename}`))
l.getDlinkShare(this._mOpts, (i)=>{
try{
with(i.list[0]) console.log(`${server_filename}: ${dlink}`)
}catch(e){
console.error(unescape('获取失败'),e.message)
}
})
return;
// 插入代码结束
var t = this;
...这样下次点击下载的时候，就会直接在控制台输出下载的文件地址，贴到迅雷里下载就好了。
正在分析下载文件地址：0200_港中_PCSD00071_杀戮地带佣兵_0112.VPK
0200_港中_PCSD00071_杀戮地带佣兵_0112.VPK: https://d.pcs.baidu.com/file/906ed86dbd4499697fa2bf59cd8ad264?fid=4128995152-250528-469636608296533&time=1496494085&rt=sh&sign=FDTAERV-DCb740ccc5511e5e8fedcff06b081203-UKVTQzfWQ3pW1%2FZ6g1Rm0ESgNy4%3D&expires=8h&chkv=1&chkbd=0&chkpc=&dp-logid=3568603884836824082&dp-callid=0&r=703837631
这速度咔咔咔的就上去了，500k的感觉就是爽。用客户端就他妈的没上过60k。
附录：
替换js文件内容的行为，需要使用我写的chrome插件：https://github.com/treemonster/chrome-jshooker
相关文档
随便看看
畅言模块加载中