无意射进学籍档案管理系统
0x00 起因
春天终于离开了，夏天轰隆隆地压在我身上透不过气来。快要毕业了啊，十年寒窗苦读就等毕业这一刻了，可苦逼的是居然没在离开之前认识几个年轻的小师妹，好歹自己也曾经算是个名人啊，不立个铜像也要到处留点情嘛！想当年，撸主我还年轻……（撸主你跑题了）。咳咳，正因为学校偶尔碰见清新的妹子又不好意思上前搭讪，看来只能拿到联系方式再慢慢培养感情了。
Posts under category 技術
科普之《窃听风云3》
刚刚考完试那天晚上就自己跑去看了午夜场的《窃听风云3》，第三部相比前面两部稍显逊色了，无论是剧情还是其他各方面因素，至于我是抱着观赏技术的心态去看的，影评什么的不说太多，直接进入主题，科普下《窃听风云3》里面的一些技术手段。
“云”真的安全吗？
现在几乎所有的互联网门户都推出了自家的云产品，容量更是动辄几百 TB，目的是吸引更多的用户。用户把自己的资料上传上去，是真的安全吗？
我以前用百度云做过一次实验，百度云刚上线的时候，以免费无限外链共享而出名，慢慢的积累了庞大的用户群。由于当时没有写这篇文章的打算，所以我重新截了一部分图（可能会跟文章内容有些差异）。我收集了几张不涉及隐私照片和一些网上下载的文档，而且我用 SpyPig 做了一张追踪图片（间谍猪：检测电子邮件有没有被阅读的工具），放到一个名字叫“个人年度考核”的 Word 文档中，然后把他们打包好，上传到百度云。
给 Linux VPS 增加 Swap
许多 Linux 的 VPS 提供的安装镜像往往是没有 Swap 分区的，多数小站长都会选择最低配置的 VPS，内存都在 256 MB 到 512 MB 之间，所以 Swap 在我们这些配置不是特别高的主机上起着很重要的作用。
这时我们可以通过后期操作，给 VPS 分配 Swap。
『Android 软件分享』首发！Infinite Flight 14.10.2 付费全机型 & 地图
最近买了很多软件拿来分享，博客好像都快成 Android 应用黑市了。
我是非常喜欢玩 FSX 的，某天在找手机版的模拟飞行，发现了 Infinite Flight，拿破解版试了试，非常不错，飞机模型非常多，涂装也十分精美，果断从 Google Play 上购买了正版回来，并付款解锁了地图和飞机，在这里就共享出来吧。
**特别注意，安装这个游戏你的手机必须有 Google 服务，并且 Google Play 已经登录。部分同学反映钛备份无法找到 Infinite Flight 的备份，你可以尝试用我提供的这个版本的钛备份，或者用钛备份自己将 Infinite Flight 备份一次再把我的数据包覆盖，然后再恢复一次。切记一点，在这里下载的压缩包回去是要先解压的！！！！解压到内存卡不是直接放进内存卡！！！！。Barkleysu 同学的实测表示，如果遇到无法下载或者无法通过 Google Play 验证的情况，请使用 VPN 或者其他代理方式遨游蓝天→_→。遇到无法恢复或者恢复后仍然提示未购买请使用我提供的钛备份！！**
2014 年 2 月 28 日更新到 1.3 版本，添加了新的飞机模型以及涂装，已经付费购买并打包放出。下载请往下边走。
2014 年 3 月 13 日更新到 1.3.1 版本，之前联飞的窗口不见了！没有其他大更新，估计是修复了 Bug 而已，可以不必更新。
自 1.3.1 发布第二天，紧急发布了 1.3.2 版本，估计 1.3.1 版本有比较严重的 Bug，如果在使用 1.3.1 版本的请升级到 1.3.2。（学校有事情忙一直没发出来）
1.4 版本出来有好几天了，但 1.3 版本的刚出来的时候发布了紧急更新，于是我便等待了几天，暂时没发现有 Bug 的迹象，所以今天再来发布。
严重鄙视贴吧同学转载，本人声明不允许转载，贴吧某人转载不说还不标明出处，之后不会再在贴吧更新了。再发现这种情况以后不再发布更新。
饭卡破解一文后记
本文只作技术研究之用，请勿用于非法用途，否则后果自负！！
《RFID安全之某学校饭卡破解》这篇东西已经写了有好长一段时间了，刚好赶上了 RFID 的研究热潮，大家有许多不同的意见和看法。这几天文章被转到 Freebuf 上去了，我收到了许多读写们的邮件，有的疑惑有的支持有的反对，所以有必要写上一篇后记好好说明下。
[Bugs] 修复 WordPress 3.9 SMTP 连接服务器失败的问题
『转载』 关于 OpenSSL“心脏出血”漏洞的分析
0x00 背景
原作者：Sean Cassidy 原作者 Twitter：@ex509 原作者博客：http://blog.existentialize.com 来源：http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
当我分析 GnuTLS 的漏洞的时候，我曾经说过，那不会是我们看到的最后一个 TLS 栈上的严重 Bug。然而我没想到这次 OpenSSL 的 Bug 会如此严重。
OpenSSL“心脏出血”漏洞是一个非常严重的问题。这个漏洞使攻击者能够从内存中读取多达 64 KB 的数据。一些安全研究员表示：
无需任何特权信息或身份验证，我们就可以从我们自己的（测试机上）偷来 X.509 证书的私钥、用户名与密码、聊天工具的消息、电子邮件以及重要的商业文档和通信等数据。
这一切是如何发生的呢？让我们一起从代码中一探究竟吧。
0x01 Bug
请看 ssl/dl_both.c，漏洞的补丁从这行语句开始：
int
dtls1_process_heartbeat(SSL *s)
{
unsigned char *p = &s->s3->rrec.data[0], *pl;
unsigned short hbtype;
unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
一上来我们就拿到了一个指向一条 SSLv3 记录中数据的指针。结构体 SSL3_RECORD 的定义如下（译者注：结构体 SSL3_RECORD 不是 SSLv3 记录的实际存储格式。一条 SSLv3 记录所遵循的存储格式请参见下文分析）：
typedef struct ssl3_record_st
{
int type; /* type of record /
unsigned int length; / How many bytes available /
unsigned int off; / read/write offset into 'buf' */
unsigned char data; / pointer to the record data */
unsigned char input; / where the decode bytes are */
unsigned char comp; / only used with decompression - malloc()ed /
unsigned long epoch; / epoch number, needed by DTLS1 /
unsigned char seq_num[8]; / sequence number, needed by DTLS1 /
} SSL3_RECORD;
每条 SSLv3 记录中包含一个类型域（type）、一个长度域（length）和一个指向记录数据的指针（data）。我们回头去看dtls1_process_heartbeat：
/ Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;
SSLv3 记录的第一个字节标明了心跳包的类型。宏 n2s 从指针 p 指向的数组中取出前两个字节，并把它们存入变量 payload 中——这实际上是心跳包载荷的长度域（length）。注意程序并没有检查这条 SSLv3 记录的实际长度。变量 pl 则指向由访问者提供的心跳包数据。
这个函数的后面进行了以下工作：
unsigned char *buffer, *bp;
int r;
/* Allocate memory for the response, size is 1 byte
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
所以程序将分配一段由访问者指定大小的内存区域，这段内存区域最大为 (65535 + 1 + 2 + 16) 个字节。变量 bp 是用来访问这段内存区域的指针。
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
宏 s2n 与宏 n2s 干的事情正好相反：s2n 读入一个 16 bit 长的值，然后将它存成双字节值，所以 s2n 会将与请求的心跳包载荷长度相同的长度值存入变量 payload。然后程序从 pl 处开始复制 payload 个字节到新分配的 bp 数组中——pl 指向了用户提供的心跳包数据。最后，程序将所有数据发回给用户。那么 Bug 在哪里呢？
0x01a 用户可以控制变量 payload 和 pl
如果用户并没有在心跳包中提供足够多的数据，会导致什么问题？比如 pl 指向的数据实际上只有一个字节，那么 memcpy 会把这条 SSLv3 记录之后的数据——无论那些数据是什么——都复制出来。
很明显，SSLv3 记录附近有不少东西。
说实话，我对发现了 OpenSSL“心脏出血”漏洞的那些人的声明感到吃惊。当我听到他们的声明时，我认为 64 KB 数据根本不足以推算出像私钥一类的数据。至少在 x86 上，堆是向高地址增长的，所以我认为对指针 pl 的读取只能读到新分配的内存区域，例如指针 bp 指向的区域。存储私钥和其它信息的内存区域的分配早于对指针 pl 指向的内存区域的分配，所以攻击者是无法读到那些敏感数据的。当然，考虑到现代 malloc 的各种神奇实现，我的推断并不总是成立的。
当然，你也没办法读取其它进程的数据，所以“重要的商业文档”必须位于当前进程的内存区域中、小于 64 KB，并且刚好位于指针 pl 指向的内存块附近。
研究者声称他们成功恢复了密钥，我希望能看到 PoC。如果你找到了 PoC，请联系我。
0x01b 漏洞修补
修复代码中最重要的一部分如下：
/* Read type and payload length first /
if (1 + 2 + 16 > s->s3->rrec.length)
return 0; / silently discard */
hbtype = p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; / silently discard per RFC 6520 sec. 4 */
pl = p;
这段代码干了两件事情：首先第一行语句抛弃了长度为0的心跳包，然后第二步检查确保了心跳包足够长。就这么简单。
0x02 前车之鉴
我们能从这个漏洞中学到什么呢？
我是 C 的粉丝。这是我最早接触的编程语言，也是我在工作中使用的第一门得心应手的语言。但是和之前相比，现在我更清楚地看到了 C 语言的局限性。
从 GnuTLS 漏洞和这个漏洞出发，我认为我们应当做到下面三条：
花钱请人对像 OpenSSL 这样的关键安全基础设施进行安全审计；
为这些库写大量的单元测试和综合测试；
开始在更安全的语言中编写替代品。
考虑到使用 C 语言进行安全编程的困难性，我不认为还有什么其他的解决方案。我会试着做这些，你呢？
作者简介：Sean 是一位关于如何把事儿干好的软件工程师。现在他在 Squadron 工作。Squadron 是一个专为 SaaS 应用程序准备的配置与发布管理工具。
测试版本的结果以及检测工具：
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
http://filippo.io/Heartbleed/