故人，泛指以前认识的人。

你活了二十年了，认识过了多少人呢？

从亲戚到学校再到社会，故人所指代的人越来越多。曾经那些与你关系不错的“朋友”们，不联系了也就进故人堆中了，你的故人堆越来越高。

没办法的人总在变化的你不可能一辈子只认识这么点人不跟更多的人打交道。但是每当由以前的“朋友”进入故人堆中，你感到过自己情绪的变化吗？惋惜，痛心？亦或是经历的多了根本就无动于衷？

这个小县城，是全中国千千万万个县城中普通的一个，坐落于传统的富庶之地。千百年来，此地的士绅文化根深蒂固，不像是更南方的人们更喜欢经商。在外读书的学子们，学成之后也更偏向于归家，而不是留在求学之地。

这个小县城，只要你的故人多，那你上街随便走两步都能碰到他们，就连坐在这小小图书馆的一个自习室里，你一眼扫去，都能找到好几个疑似你认识的人。

中国是个“人情社会”。

人情，在我的定义中，就是“我帮了你一个忙，你就欠了我一份情”中的“情”，用劳动报酬来解释或许更好一些。

人情社会，就是以人情编织成的网络为基础的社会。举个例子，你爹喝酒上头了，跟你说，儿子，你想不想回来工作，爹帮你去跟局长说一说。

这个“说一说”中，又包含了多少背后的含义呢？

我讨厌人情。

故人来找你帮忙。

你正好闲着没事干，帮了。

故人一句谢谢，结束了这几年中你们为数不多可能是仅有的交流，你甚至找不到一句你们能聊的共同话题。

你还能指望更多的报酬吗？你的时间成本就值那么两个字了？

当然不是，这份我最厌恶的人情，就是委托方亏欠的你仅有的报酬，虚无而飘渺。

小县城是一个小型的人情社会。走两步都能碰到故人的情况下，你被迫地，要去帮故人的忙。

你不帮，是你不念旧情太过高冷不会做人。你帮了，又是白费自己时间获得一句空头的“谢谢”。

这只是整个中国这个大型人情社会的一个小缩影，有人的地方，总会有人情。

近日，一份疑似 iOS 9.3.x 的 iBoot 及其他部分 BootLoader 的源代码被匿名人士 push 上了 Github, 粗略地查看了一下里面的文件之后，大家都惊讶地发现这份源代码的爆点实在是太多了。

项目的 README 中是这么写的：iBoot_BootROM_iBSS_iBSS_iLLB_Source_Code

其中 iBSS 是 iBoot Single Stage 的缩写，而 LLB 是 Low Level Bootloader 的缩写。

我们先来看一下 iOS Devices 的启动流程：

在 Apple 定制的一系列 A 系列 SoC 中有一块存储区域专门存放了一部分最初的启动代码，也就是俗称的 BootROM, 这部分被 Apple 称之为 SecureROM, 它是在电源键被按下，设备上电之后最初加载的代码。SecureROM 检查下一级 BootLoader, 也就是 LLB, 如果签名没有问题，那么就加载并初始化 LLB, 此时设备的 Apple Logo 就出现了。然后 LLB 检查并初始化 iBoot, 同样是通过 Apple Root CA Public 证书验证签名，通过就会把设备带给 iBoot, 而 iBoot 会映射 Device Tree, 然后验证内核签名并加载，最终初始化内核并运行，这时候可以说 iOS 系统已经启动了。

通过简述的启动流程，我们可以看到，BootROM, LLB, iBoot 这三个无论哪一个都是在整个启动流程中充当关键角色的。所以这次源代码的泄露，非常劲爆。

在基于证书链的安全体系下，私钥的泄露可以说是直接把安全性掉到0去了，而这份代码中，在位于 /lib/pki 和其中的 tests 目录下，可以看到有一份 Fake CA 和一些私钥，还有一份中间证书和私钥，如果后续版本也是沿用这些东西的话，整个启动验证链的加密体系，就真的可以说安全性为0了。

因为这份代码是 9.3 时代的，也就是在 iPhone 7 那代发布前的版本，所以我们能看到有许多 T8010 相关的文件（T8010 是 Apple 对于 A10 芯片平台的代号）。而有趣的是，在 /target 目录下出现了 iphone8 这个文件夹，难不成 Apple 内部在 2016 年就开始对 iPhone 8 进行内部测试了？但是点进去看，目录下的文件清晰的指向了另一款产品——iPhone 6s. 往上推，iPhone 7 文件夹对应着 iPhone 6, iPhone 6 文件夹对应着 iPhone 5s, 如果按照这个内部排序，iPhone Ⅹ 这个 Ⅹ的由来，可能更好解释一点。而 iPhone 8, 则更像后来上马的 iPhone 7 Reversion.

除了主引导程序的代码外，泄露的代码中还包含了许多驱动，在 /drivers 目录下，可以清晰地认出 iOS 平台所使用的一些硬件，其中甚至包括了 Thunderbolt 驱动。

内容还有很多，笔者水平有限，也解读不出更多的东西了。

>> endl;

2018年2月2日，AC 又又又倒闭了。

前两天深夜刷微博时，碰巧瞥见一条“新闻”，上书「AcFun 团队缺乏资金，欠薪几个月，已经无力维持网站运营，关站在即。」第不知道多少次看到 AC 要关站新闻的我，也不以为意，不过就是第不知道多少次关站而已，我也早就不是 A 站用户了，对这个网站没什么怀念或者留恋的东西。

然后今天早上醒过来，一刷微博，铺天盖地的，又是一堆“AC 亡了”的消息。有打趣的有悼念的有分析的有写背后故事的，甚至还有缺德的。娱乐至死的年代中，这个消息也只能成为一些人的热点，一些人的谈资，一些人的一条悼念微博，而更多的人，则是好奇：“AcFun 是啥？”

A 站走到今天这个地步，绝非偶然。

一次又一次，他们错过了

从 2012 年说起。

2012年，是我接触更宽广的互联网的第一年。也是在那年，AcFun 举办了第一届宅学会。当时刚刚了解到 A 站是啥的我，在 A 站看了直播——后来的 A 站直播区，叫做“斗鱼”，斗鱼的早期用户中不少都是以 AcFun 账号注册登录的，包括我——然而这样的宅学会，是第一次，也是最后一次像样的，第二届的宅学会就已经朝着“主题漫展”的错误方向去了，而且影响力远没有第一次那么大。第一届的宅学会上，A 站请到了著名配音演员葛平，还有GoHank、性感玉米、林熊猫这三位来主持。

而这时候的 B 站，已经开始逐步用力发展他们的移动客户端业务了。早期的 AB 两站移动客户端体验，B 站的 App 无论在界面设计还是播放体验上，都是比 A 站的要高出一条街的存在。

本文主旨不在于两站对比，故以引用形式略提一句同时期的 B 站发展概况。

搞笑的是，在第一届宅学会过去恰好一年之际，GoHank, 这个对 A 站贡献不少的 UP 后来进入管理层的“猴子”出走了 B 站。当时 A 站不少运营以及用户的理念，在这个帖子中，能够瞥见一番。狗Hank+葛平+ACFUN事件

那hank确实不适合这里了，因为我觉得ac就像是猴王的微博的简介
“只交朋友，不混圈”
走好不送。

还是那句话，
只交朋友，不混圈，混圈的话，隔壁欢迎你。当然这里也欢迎你，不过>这里欢迎的是朋友，不是圈子。
谢谢。

然后就是赛门出走这一重大事件。

2014年4月末，时任“站长”的赛门和投资者闹翻，离开 A 站。

一句话足矣，想要了解详情的，我建议通过知乎查询。

赛门走后，AcFun 的管理层可能是失去了一个大的方向，也可能是陷入了融资后高层权力斗争的漩涡中，网站运营没有起色。

2015年3月，因为版权问题，AcFun 三名高层被刑拘，其中包括业余创作“空之文库”的尼窝猴。而事件解决期间不断有前猴子出走，原来的武汉团队几乎没剩几个老员工。

当时的空之文库在轻小说阅读的体验上可以说是秒天秒地秒空气

2016年2月，匿名版之争，光驱猴投奔 B 站。

……

之后的事情，仿佛 AcFun 已经被大家都淡忘了，不时的传出点消息跟世人说：“我还活着”。

它曾经拥有过很多次机会来扩大自身，但却因为各种各样的变故，都错过了，也许是他们缺少一个如陈睿般的有经验的运营决策者，也许是他们根本不想扩大，小众一点也没什么不好。而从 A 站早中期脱离出来的 MikuFans, 已经成了中国“二次元文化的代表”，甚至已经在准备上市了。

也许，再过几年，大家都会想起，曾经有个网站叫做 AcFun, 是它最早在大陆开始传播隔壁邻居的一些亚文化，是它最早推动了国内的二次创作，是它培养了国内一代亚文化人才。

也许，它会撑过这次危机，如官博所说的那样，“我想再活五百年！ ”。就算小众，但也能给众多喜欢 A 站的“漫友”们提供一个温暖的家，就像它一直以来挂着的那句“天下漫友是一家”那样。

再见，AcFun

但愿这一次，A 站别再活过来了。

就让 AcFun 这个名词进入中国互联网的历史故土堆里，安心地为后来者提供它那一份“历史经验教训”和代表着老一代日本亚文化推广者和受众们的，美好回忆吧。

为了把 RaidFinder 给实现出来，我决定直接自己手动实现一个 Filtered Stream API 的调用，来检查到底是需要什么 Track 关键词才能达到目的。

这里真的要吐槽一下新的 Twitter Developer 页面，以前大量的 API Reference 页面都已经404了，包括一些非常重要有用的 API 文档都能 404, 再看看那个“切换到夜间模式再切换回来之后主题色丢失”的前端 bug 修了几个月才修完，可以说 Twitter 真的药丸。

构造 OAuth 验证

查阅了文档得知，Stream API 需要进行在请求的 HTTP Header 中包含完整的用户验证，也就是走完整的 OAuth 验证流程，由于手上已经拥有了完整的用户和应用的 Key : Secret 对，所以直接进行构造。

一个完整的验证字段中必须包括如下内容：

1. Consumer Key

2. Nonce

3. Signature

4. Signature Method

   Twitter 只支持 HAMC-SHA1 的签名方法

5. Timestamp

6. Access Token

7. OAuth Version

而 Signature 字段又是根据其他6个字段以及 HTTP 请求的 URL 和参数（包括 POST 方法的 Request Body）来产生的，格式如下：

请求方法&请求URL&其他6个字段&请求参数

HMAC-SHA1 签名的产生还需要一个 Key, 这个 Key 是由用户的 Consumer Secret 和 Access Token Secret 来构建的。

抓包

写了半个下午的 OAuth, 写完运行之后还是返回一个 401 给我，仔细检查代码也没有发现哪里出错了。没有办法之下，我想到了抓原版的请求包来看它到底用了什么关键词。于是立即安装 sbt 和 JDK. 其实 Windows 上的 sbt 也就是提供一个 jar 包和 sbt.bat 这个运行脚本来设定 sbt 所需要的运行环境而已。

安装完了，sbt run 先跑一记看看，然后让我没想到的是，在性能比 VPS 强了几倍的情况下，这玩意儿还是跑的稀慢，也可能是 Windows 的问题，总之，构建初始运行环境就花了大概一个半小时，不容易等到开始编译 scala 资源了，开始疯狂报错了。

首先是一个 Python 脚本报错导致后续脚本无法继续，查询项目文档后得知 Windows 上需要 Python 2.X, 而我安装的是 3.6, 没想到在这里会第一次碰到 Python 的版本问题，没办法，下 2.7 改 Path, 好通过了，然后继续报错。

之后报错都是因为 Java 运行环境的限制，主要问题出在内存的设定上，Google 之，然后在 Java 控制面板中添加全局参数，sbt run 之后开任务管理器看到参数起效了，遂继续运行下去，然而还是会报内存不够的错误，不解，好在每次都能按部就班的往下跑一点，几次重启之后也搞定了。把 twitter4j.properties 放到根目录下，sbt run 之后发现貌似请求没走代理，Twitter 请求撞墙超时。这时想到用 Proxifier 将 java.exe 的请求重定向到本地代理去，重定向之后就跑起来了，程序启动的一瞬间有两个 Search API 的请求和一个 Stream API 的请求，然后全是访问 pic.twitter.com 的请求，下图片的。

既然 Proxifier 能够重定向流量，那么我把 java.exe 的请求重定向到 Fiddler 的端口去不就能看到包内容了。但是切过去却发现，所有请求都不通了。期初以为是 Fiddler 没走代理，根据别人的经验添加了转发规则之后仍然出错，百思不得其解中，突然看到程序的出错信息不再是访问 Twitter 超时了，而是 SSL 证书出错。

怎么会呢？我明明把 Fiddler 的证书添加到系统中去了。Google 之，发现 Windows 上的 JRE 自己实现了一套证书环境，我去你大爷的垃圾 Oracle, 放着系统自己的轮子不用非要用自己那套垃圾轮子给人麻烦，前面的网络请求也是自己造的轮子直接跳过系统代理。

没办法，寄人篱下。于是 Google 到添加 SSL 证书的办法，添加完之后发现还需要自定义的命令行让 JRE 读证书，同样使用 Java 控制面板添加参数，然而这次发现参数并没有起效。

切记 keytool 这玩意儿要用管理员身份来跑，添加完之后 keytool 会生成一个 keystore 文件，建议将它移动在自己 Home 文件夹中并重命名为 .keystore

既然 $JAVA_OPTS 这个环境变量看上去对 sbt 没用，那我改 $SBT_OPTS, 利用 Everything 这玩意儿强大的搜索功能找到了存在于 sbt 安装目录\config 下面的 sbtopts 文件，好就是你了，添加自定义命令行，sbt run, 然并卵，一点作用都没起。一头雾水中我打开 sbt.bat 这个 Windows 版 sbt 的实际起效文件，发现了这行：

1

set FN=%SBT_HOME%\..\conf\sbtconfig.txt

我去你妈的，也是个不喜欢用一套轮子的。

把原本写进 sbtopts 文件的自定义命令行改写到 sbtconfig.txt 中，Java 命令行的前缀 -J 并不用添加，最后如下：

1

-DproxySet=true 

2

-DproxyHost=127.0.0.1

3

-DproxyPort=8888   'Fiddler 的代理端口

4

-Djavax.net.ssl.trustStore=<path\to\FiddlerKeystore> '刚刚生成的 keystore 文件的位置，如果移动到了 $Home 下面并重命名为 .keystore 的话这行就不用加

5

-Djavax.net.ssl.trustStorePassword=<Keystore Password> '刚刚 keytool 让你敲的密码

sbt run

终于，我在 Fiddler 中看到了 java.exe 的请求，并且正确地解密了出来。我花了半天时间探寻的内容终于呈现在我眼前：

count=0&track=%E5%8F%82%E5%8A%A0%E8%80%85%E5%8B%9F%E9%9B%86%EF%BC%81%2C%3A%E5%8F%82%E6%88%A6ID%2CI%20need%20backup%21%2C%3ABattle%20ID&stall_warnings=true

URL Decode 之后就是：

count=0&track=参加者募集！,:参戦ID,I need backup!,:Battle ID&stall_warnings=true

我看到这个之后差点吐血，原来他妈就是简单的用, 这玩意儿来分隔开 Track 关键词就能实现日语推的实时 filter???

还要继续实验。

外网访问

前文有讲，家里网络“重做”之后我就把主路由的 DMZ 主机挂在二级路由上，二级路由的 DMZ 挂在自己机器上，这样外网的请求就直接能到自己机器上。

然而从外部使用 DDNS 域名+端口号的方式不能直接访问到 RaidFinder. 哦好像是要配上一个 HTTP Server, 那简单，跑一个 http.server 80 不就行了。

是行了，能访问到所有的静态资源，但是看着 Console 中不断提示的 ws/raids?keepAlive=true 404, 我突然想起来前不久看到的 WebSockets 简介中提到的，要建立一个 WebSockets 连接是需要从 HTTP 请求“转发升级”过去的。于是想到用 NGINX, 下载，这玩意儿才 1MB+ 的大小，真他妈绿色环保。

把自己服务器上的 nginx.conf 拖出来抄配置，终于理解了之前搜到的配置的用处：

1

proxy_pass http://127.0.0.1:$port;

2

proxy_http_version 1.1;

3

proxy_set_header Upgrade $http_upgrade;

4

proxy_set_header Connection "upgrade";

配置中最后两句就是为 WebSockets 而服务的，是一个 HTTP 请求转为 WebSockets 连接的关键点。

那么一切设定好，开始跑，问题又来了：外网无法访问，内网 80 转发正常。

>> endl;

最后这篇折腾记的终点就在这里了，不知道为何，访问就是无限转圈，但是起初寻找关键词的目的还是完成了。

在上一篇文章中，我提到回家要干的一件事情就是更换路由。把新买的二手 Nepgear Netgear R6250 替换掉用了两年多的洋垃圾 RT-N16. 更换到现在已经过去一天半左右的时间了，遇到了几个问题。

拿快递开箱换上配置好一共花了不到半小时就搞定了，然后问题开始浮现：我的 ThinkPad S1 Yoga 连接不到 R6250 提供的 2.4G 无线网络。开始认为是笔记本上那块单频 Intel 7260 的锅，然后把 R6250 的 2.4G 网的频宽从 40MHz 降到了 20MHz, 结果仍然有时断时续的情况出现，认为还是 7260 这张网卡的问题，准备更换网卡。但北美良心想在 BIOS 中做了限制，更换起来很麻烦，所以一筹莫展。结果今晚日常拿起手柄 V 的时候突发奇想连一下无线，发现根本找不到 2.4G 网的 SSID, 就算不容易刷出来了也是连接不上的状态，遂开始感觉是 R6250 的问题。Google 之，发现使用第三方固件的 R6250 大多都存在这种问题，比如 2.4G 网不稳定，2.4G 根本连不上什么的。但是我又不想用回官方那个烂的很的固件，于是掏出从学校快递回家，原本准备用来替换掉配电箱中的主路由的那只被改装过的 TP-Link WR720N, 本就刷好了 LEDE, 稍微改了几个配置就当 2.4G 的 AP 来用了，连接非常稳定。

把 DMZ 主机指定到自己的机器之后，直接通过 DDNS 域名进行内网访问，速度非常快，延迟非常低，爽。

然后用着用着，无心看到 IPv6 的地址头不对，而且怎么本地 DNS 域也变成了 LEDE 了？一看果然是小的 AP 在作怪，上面的 DHCP 服务器没关，也就是一个网段中有两个设备在 DHCP 广播。遂关闭之，顺带着把 Lan 口设置中的网关确定为 2.1, 并把 Dnsmasq 的服务一起关了，问题消失。