这段时间，由于要提取一些关键词，所以要遍历 mysql 中整个表一条条的操作，于是毫不犹豫的写出了下面的语句：
1
SELECT * FROM documents ORDER BY id LIMIT ?, 1
这语句已经是简单的令人发指了，所以也没想太多，直接就跑了起来。
然而，跑着跑着，某次回来看的时候，发现执行很慢，经常更新一个就要卡好久， 刚开始以为是网络不太好，没太在意，后来感觉实在是有点不对劲，就加日志仔细查了下是哪里慢了，结果竟然发现那句 SELECT 异常的慢。 抱着不敢相信的态度，去命令行下执行了一下，发现真的用了快一分钟才执行一句，当时就惊呆了。 我们这可是主键聚簇索引，并且还只取一条数据而已啊！！！
于是仔细又测试了一下，发现在 offset 小的时候没什么问题，之后 offset 大了之后才会有问题， 看查询分析也会发现，里面显示的行数也跟 offset 有关，看来真的就是 offset 不会快速跳过，还是会一个个的扫过来，想想真是恐怖。 虽然不知道为什么会设计成这样，讲道理 B tree 索引应该有能力直接找到第 N 大的元素啊。
昨天做作业的时候，本来是很简单的溢出题吧，老师的意思本来就是直接跳到 shellcode 上执行就好。 但是仔细一看却发现，所给虚拟机上是开了 ASLR 的，而程序是以命令行参数形式进行的输入， 那么也就是说，我们必须要在程序开始运行前就确定下来缓冲区的地址，显然这在 ASLR 的防护下是不现实的。 当然，毕竟是 32 位的系统，暴力肯定是可以跑出来的，不过这题显然不会是要这么麻烦，那么肯定是有什么地方出了问题。
想到作业是给了参考答案的，然后果断打开答案看看，发现程序就是直接读取了自身的栈地址后，execve 到目标程序上， 按照之前的印象，这样显然是错的，execve 过去后，栈地址应该是会被 ASLR 重新随机的， 然后抱着怀疑的态度，运行了参考答案好几次，却神奇的发现每次都成功拿到了 shell，于是当时就开始怀疑起自己的印象来了……
最后，几经波折，找到了这么一篇 blackhat 上的文章，才解开了疑惑。 文章中主要是具体讲了 ASLR 的部分可预测性，与我们这里关系不太大，我们这里主要是因为其中提到的一点：
If an attacker manages to call execve(2) with his desired target process within one jiffy (i.e. 4ms) after his process was launched, then the output of the prf function will be the same since neither pid p nor jiffies j changed. The secret s did not change either and would most likely also not change if re-keying was in fact every second. Thus the target process will use the very same randomization.
前段时间时不时就会要去爬的东西，之前这种情况大多数时候都是直接 python 裸写了，反正就是临时下少量东西，所以没太大关系， 这次想了想，还是决定试用一下现成的框架，毕竟用框架很多轮子不用自己造，还不用担心 cookie、retry、多线程的事，好处多多，唯一就是有个学习成本而已。
长痛不如短痛，趁着现在不是这么急，于是投身了 scrapy 的怀抱。 很早就听闻了这个框架，作为 python 爬虫框架的代表，不得不说，用起来却是感觉是不错，不过使用中也遇到了点小问题，就此记录下，以备不时之需。
作为爬虫框架的代表，scrapy 在去重上自然也是有考虑的， 在一次爬虫运行过程中，scrapy 会自动对请求的所有地址做去重处理，保证同一个 URL 不会被重复访问多次， 一方面是减小了无意义的开销，另一方面更是避免了超链接连成环导致死循环。
然而，这次要爬的某网站的设计比较奇葩：
某内容页面 URL 为 http://domain/path/{id}，这个 URL 本身没有什么问题，
但是这个 URL 访问之后其实是会设置一个 cookie，然后重定向到一个固定网址，然后那个网址会根据 cookie 来给出返回的内容。
这种设计不得不说真还是第一次见，当 scrapy 遇到这种设计的时候， 由于被重定向到的目标网址都是同一个 URL，而 scrapy 遇到重定向的时候实际上是重发一个新请求到新的目标地址，然后这时候去重的判断就会把重发的所有的请求全部认为是重复请求了。 这个问题本身其实并不难解决，但是由于对于重定向的请求去重的时候，scrapy 并没有给出任何日志提醒，所以导致最开始一直找不到原因。 知道原因后，其实很容易搜到，比如 stack overflow 上这篇。
解决方案也就是在构造 Request 对象时增加一个参数 dont_filter=True，从而对此请求禁用掉调度器中的过滤。
想来这个『博客』开始写以来，写的最多的就是 writeup 了吧， 刚开始的那段日子，刚开始玩 CTF，各种比赛之后，一篇篇 writeup 似乎一直补不完……
现在想了想，毕竟每题都写一篇详细的 writeup 不太靠谱，尤其是，越往后，越多时候做的题都是老套路，没有什么新知识的话，就更没有写的欲望了。 其实大概几个月前开始，随着换掉 WordPress 的想法，就没更过单独的详细 writeup 了，就是在 GitHub 上建了了 repo，存简略版的 writeup。 然后现在也是把 repo 转到了队伍的 team 账号名下，希望是队里之后所有人都把自己的 writeup 汇集到一起，帮助后人学习。
自己今后大概 writeup 也会越写越少，一方面是懒，一方面是意义也没之前大了，毕竟重复的知识点没什么太多好说的。 正常来说的话，也是不太会贴 writeup 到这里了，顶多写的简单的放在 repo 里了。 不过一般来说，应该所有 exp 还是会都传到 repo 里面，也是留个档，将来可能有用到的时候。
『五岳归来不看山，黄山归来不看岳』，一年多的时间过去，自己学到了许多，成长了许多，也更是深深的感到了自己与前面人的差距，真的是还有太多需要学习的知识。 希望这里将来也能有更多有意义的笔记吧，每一个都会是成长的记录，放弃了好不容易要铺平的路，选择了安全， 向来懦弱的我，这一次既然选择了挑战，总归还是希望能做出点什么来的。
想来当初选博客的时候，也是看到了 GitHub Pages 的，当时就是觉得这种形式限制会比较多，自定义化程度太低，不喜欢，于是最后还是选了 WordPress。 然而世事轮回，过去了这才一年多，随着越来越习惯 markdown，就愈发觉得 WordPress 还是太繁琐了，还是想弄个能用 markdown 来写的博客，专注于内容才是最实在的，于是还是走回了 Github Pages。
确定要换其实已经有一段时间了，只是现在感觉真的是事情太杂太乱，然后配上自己这拖延症，于是就一拖再拖。 手头也是屯了几篇文章，因为决定要换后，就用 markdown 写的了，懒得再转过去贴上去了，还是注意 CSS 的问题，麻烦。 然后这两天想了想，一狠心，硬着头皮就来做了，不管咋滴，先弄个能用的再说，至于页面细节什么的优化，以后再慢慢来吧。
虽说是尽量随便来了，但是毕竟强迫症患者，于是选主题，检查一些基本细节还是花了好几天的时间，今天总是是弄的差不多了。 接下来就是要开始迁移了，也不知道评论还能不能迁移的好，不过无所谓了，就当从到来过了。 不过以后还是少这样折腾了的好，折腾多了真是伤不起，稳定才是硬道理啊！
然后这次也是打算直接把个人主页也做到里面，之前说做主页，拖到现在还是一点未动，毕竟一想到要设计，要写前端就是一阵头疼，所以还是简简单单一个介绍页面的好。 既然主页要做进来了，于是乎就把域名也顺手换掉了，还是用 www 的了。 反正这次一换，搜索引擎那边肯定要乱掉，于是乎干脆就是一不做而不休，一次性乱个够了～～～
鉴于有些人 OpenVPN 还是用不太溜，然后想了想，复旦内网目测没封 PPTP，只是出外网会封，于是就决定顺手再开了个 PPTP 的 VPN。
不得不说，PPTP 这个 VPN 开起来还真是方便，按照这个教程感觉没多少配置就搞定了，路由表不用推，也没得推 -_-#。
不过唯一遇到的问题就是，opkg install pptpd 会发现找不到 pptpd，原来是 OpenWrt Chaos Calmer 已经默认将 pptpd 移除了，于是找到这个地方下的，也不知道这网站靠谱不靠谱……
不过企图开起 v6 支持的时候却给跪了，按网上说的在 /etc/ppp/options.pptpd 中加入 ipv6 , 还是连不上，netstat -ltp 也发现仍旧只是监听 0.0.0.0 也是郁闷。然后 OpenWrt 上面也没带 socat，于是想了想，反正也可以认为用不到，就懒得搞了。
鉴于上次把寝室网给配的实在用起来太舒服，但其实在寝室呆的时间很短，于是想了想，决定将路由移到实验室，实验室可以直接连接使用，然后开个 VPN，这样在任何有内网的环境中都可以连回来享受同样的网络环境（寝室可以拿室友路由 VPN 连回来），并且还摆脱了对内网服务器的依赖。
由于在实验室直接就有外网，所以配置比在寝室还要容易，只要稍加修改即可，剩下要折腾的主要就是 VPN 了。
然后在某人推荐下，决定用 OpenVPN，虽然各个客户端都不原生支持比较蛋疼，但是据说服务器端配置比较容易，于是乎也就认了。
最后参照 OpenWrt 官方 wiki 上的 Guide 来搭建。
搭建过程一切顺利，VPN 轻松连上，traceroute 结果虽然和它说的不太一样，但感觉应该没问题。然而，当企图访问网络时，却跪了。
测试发现，curl baidu.com 会提示 cannot resolve，但是 nslookup baidu.com 却正确出了结果，返回的复旦内网域名解析服务器的结果，然后 curl ip 也是可以成功访问的，当时我就懵了，真是从未见过如此奇观。
我没有手动设置域名解析服务器，按理说应该都是用的默认域名解析服务器啊，怎么就 curl 不行。然后尝试手动强制指定使用 114 DNS，发现网络立刻就通了，也是醉了。然后测试了下 dig 直接指定路由为 DNS 服务器，发现解析不了了，指定路由器 5353 端口（即之前那个 ss-tunnel，dnsmasq 的上游服务器之一）解析却正常，甚是奇怪，防火墙神马的确认不会有问题，然后 dnsmasq 监听的 0.0.0.0，但就是不给解析，然而直接连在路由下面却是会给解析的。我这到底是跟 DNS 有多大仇，上次折腾也是大部分的时间花在了折腾 DNS 上，这次咋又被 DNS 给坑着了。
在网上查了一圈，找到这个，可以发现，dnsmasq 这玩意虽然监听了所有端口，但是会丢掉所有外部的 dns 请求，也是服气。然后一圈圈的找有啥配置能让其解析所有请求，半天也没找到。
最近电信到期了，想想也是不想续了，效果各种渣不说，还要限制出国网速，丫的在逗我？
想了想，决定一次性搞到位，接回实验室电脑上网的同时，把翻墙问题也解决了算了。本来以为轻松就能搞定，不过没想到还是弄了一天多才搞定。于是还是记录下，以备以后再用。
这次配置，主要是麻烦在了没有一个基础网络，所以从 DNS 解析开始，都得折腾个彻底。
首先，不解释的刷了 OpenWrt（好吧，我也是第一次玩路由，只是听说这个好，也适合折腾），我是买的个 WNDR4300，然后在官网下的固件，其中 ar71xx 是主控，nand 是 flash 型号。
刷完固件，接下来就是装软件，在 sourceforge 上找到这个，由于路由器没有接入网络，我是直接在所给源的页面直接下载了 scp 到路由器，然后通过 opkg install package-name.ipk 安装。
然后其中那个 shadowsocks-libev-spec 是在是用不习惯，因为需求比较复杂，shadowsocks-libev-spec 不适合灵活的修改，所以最后还是用的 shadowsocks-libev。
配置的时候，网上各种资料参考来参考去，最后大概还是参考这个教程来做的。
前两天某人突然表示他在纷印上传文件一上传就立马报失败，换了N个浏览器都屡试不爽，然后大概找了下也不知道是什么问题。于是乎今天找了个空，过去帮他查了一通。
可是，一圈查下来，发现简直一切正常，但就是每次跨域前的OPTIONS请求发都没发到服务器那边去就挂彩了，开burpsuite连个请求都看不到，也是服气。十分怀疑是OPTIONS发不出去，甚至于拿curl试了下，也是果断其余所有请求都能发，就是OPTIONS失败……
于是乎，找不到原因，只能在网上搜来搜去，结果竟然在github上发现了这么一个issue。于是一想到前两天他才刚似乎给装过any connect，虽然好像装失败了还是咋滴，就觉得估计八九不离十了，控制台一看果然有acwebsecagent相关的错误，于是想去卸载any connect，但是根本找不到有any connect这个app，只好再搜怎么卸载acwebsecagent，不过现在问题明确，很容易就找到下面这条卸载命令：
1
sudo /opt/cisco/anyconnect/bin/websecurity_uninstall.sh
运行完之后再试，果然什么问题都没了，不得不说真是深深的给any connect跪了，竟然还有这种破事，网上一搜这个问题也是，除了说CORS的，还有说浏览器网速变慢的，真是不知道这玩意是闹哪样。
看来以后装真的小心，千万得把Web security的勾去掉了，不然真的容易死都不知道咋死的。
之前服务器https访问的时候，总是喜欢动不动就抽风，浏览器报证书不受信，搞的十分蛋疼，但由于是偶发，又一直没啥时间和心情去研究，所以拖到现在也没有解决。
然后今天又被抽风之后，有点愤怒，于是跑去网上搜了下，找到这么个网站，可以检测服务器的SSL证书状态，并且给出非常详细的相关信息，甚爽，于是赶快研究了一下服务器SSL证书的配置。
首先还是导致之前浏览器报错的证书链的问题，我们一般会有三种证书： RootCA.crt（rCA，被信任的根证书）、IntermediateCA.crt（mCA，某些厂商有多个中间证书）、server.crt（sCA，通过CSR签下来的证书），某些厂商的rCA和mCA是需要用户自己下载的。为了让浏览器能够信任我们的证书，我们需要配置一条完整的证书链，证书链由sCA和mCA构成就好，rCA是浏览器内置，不需要服务器给提供。nginx配置证书链的时候，就是指定一个证书文件，这个文件中含有我们整个证书链的所有证书就好，证书合并的时候，正确的合并方法是把 mCA 合并到 sCA 中。当有多个 mCA 文件时，mCA 从下级到上级（根证书为最上级）依次合并到 sCA 中。在这个过程中，rCA 被视为多余的文件。
1
2
3
4
5
6
7
8
9
10
11
12
13
# Combined Certificates
-----BEGIN CERTIFICATE-----
...... sCA ......
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
...... mCA (lower) ......
------END CERTIFICATE------
-----BEGIN CERTIFICATE-----
...... mCA (upper) ......
------END CERTIFICATE------