Thursday, June 23, 2011

Gocode——用于Go语言的自动补全工具

原文发表于「桃源」: http://linux.cuit.edu.cn/?p=1362

一直以来, 我不太习惯于使用自动补全, 一是没有发现合适的 (这方面VS和Xcode这些IDE明显做得更好), 二来也觉得自己敲还来得快一点 (=_,=). 前几天发现 Gocode, 试用下来感觉还不错, 配置也不算繁琐, 推荐给使用Go语言的同学.

Gocode

Gocode现在支持的编辑器有Vim和Emacs, 分别利用Vim的omni completion和Emacs的 Auto Complete Mode. 想看实际演示效果的同学可以点 这里. 这里主要讲一下安装和Emacs的配置, Vim的配置由于比较简单, 可以参考 官方文档.

很多同学在安装Gocode的时候都会出现编译错误, 这主要是因为Go语言发展比较迅速, 这个星期的版本和上个星期的版本之间都可能存在不兼容, 默认 clone 下来的Gocode代码都是兼容最新版Go语言的 (这作者真勤劳), 因此如果你的Go编译器版本太陈旧的话就可能编译失败. 比如我电脑上的Go版本是 r57.1 (weekly.2011-05-03), 是一个release版, 而最新的Gocode是针对weekly.2011-06-16的, 这是一个开发者版. 理所当然的, 我在编译的时候遇到了编译错误, 这时我有两种选择, 要么升级Go, 要么降级Gocode. 升级Go对于我来说不太方便, 因为我的Go版本都是随着软件仓库一起更新的, 因此我选择了降级Gocode. 还好Gocode的作者给那些存在兼容问题的版本都打上了tag, 我们只需找到兼容自己电脑上当前Go版本的tag, 再回滚就行了.

$ git log --decorate
$ git checkout compatible-with-go-weekly.2011-04-27

接下来是编译和安装.

$ gomake
$ sudo gomake install

编译完成之后会生成 gocode 命令, 默认情况下 gomake install 会将 gocode 放到 GOBIN 环境变量指定的目录, 如果你没有设置 GOBIN, 那就会放到 ${GOROOT}/bin 里. 必须确保 gocode 命令可以在 PATH 环境变量中找到.

最后是配置Emacs. 首先你需要安装 Auto Complete Mode 扩展, 安装步骤可以参考 这里. 然后将Gocode提供的Emacs Lisp文件放到Emacs的 load-path 里即可. 注意这里使用到的el文件需要是最新版的 (非回滚版), 否则补全将失败.

现在用Emacs打开一个Go源文件试试看吧~

Saturday, June 11, 2011

CTF Quals 2011记录

上周末跟几个朋友一起参加了 DEF CON 19 CTF Quals, DEF CON是一年一度的黑客大会, 期间会举办一些比赛, 最有名的就是CTF (Capture the Flag). 要进入CTF世界总决赛, 必须先参加CTF Quals, 也就是预选赛, 这是一个在线的竞速赛, 前12名就可以免费去Las Vegas. 当然我们是去不了了, 虽然比赛前还各种畅想…

今年的题型和往年不同, 新增了两类题. 当然这是从题型的名字上来说的, 其实考查的知识点还是大同小异, 只是今年的题要变态很多. 你可以在 这里 看到今年的所有题目, 一共有5种题型:

  • Grab Bag: 这里面的题是各种混杂
  • Retro Revisited
  • Binary L33tness
  • Potent Pwnables: 逆向工程题居多
  • Forensics

每种题型都有5道题, 分值分别是100, 200, 300, 400, 500. 我主要负责Forensics, 有点类似于数字取证, 也同时涉及一些与文件格式相关的知识. 网络安全领域我接触不多, 但是由于CTF Quals的大部分题都是在Unix/Linux下进行, 所以还是可以帮上一些忙. 比赛前做了一些准备, 把前三年的题都看了一遍, 当时感觉题目难度还行, 搞定100、200应该可以, 后面的如果下些功夫再加上运气也许也能做出来, 不过今年的题确实把我打击得不小.

比赛开始时间是6月4日凌晨3点, 我们几个人在3号晚上11点左右就提前聚集到实验室等待, 期间我等得无聊的时候便从萝莉哥那里拷了一部叫 Hackers 的电影来看. 这电影实在是不咋的, 拍得有点太假了, 不过里面的男女主角居然是sick boy和Angelina Jolie, 倒是有点意外. 终于到3点了, 但官网迟迟没有公布比赛网址, 在IRC里面看到有人在说服务器停电了需要推迟6个小时, 当时就觉得这也太滑稽了, 这么大一比赛居然会出这种状况. 后来证明我们并不需要等6个小时, 那是一个假消息, 不过比赛还是推迟了1个小时左右.

接下来就是艰苦的做题过程, 由于时差问题, 我们不得不熬了两个通宵. B100是最先放出的题目, 这道题多亏源哥思路活跃, 想到了把所有字符Base64解码, 可我们还是卡在了最后一步, 找不出key在哪里, 事后看别人的write-up时真是撞墙的冲动都有, 原来key就直接写在那里, 我们又想复杂了…

RR100很搞笑, 题目只有三根横线和一个感叹号: ____ ___ ______!, 当时大叔跟我说这道题的时候我立刻就想到了 “Hack the planet!”, 为什么呢? 因为这就是 “Hackers” 电影里的一句台词… 真是巧合, 看来CTF的人很喜欢这部电影, 往年的题目也有提到这句话.

F100是一道诡异的图片题, 给了一个19025x1像素的PNG图片, 这次还是源哥想到可以把图片切成很多段, 再拼接起来说不定会有什么结果. 事实是我们的确把图片拼出来了, 但却是误入了red herring, 我们把切割的像素搞错了. 只要切割正确, key立刻就会呈现出来, 这又是一道撞墙题.

F200倒是一道很典型的Forensics题目, 给了一个NTFS文件系统的dump, 需要从中找出蛛丝马迹. 往年这类题都是要想办法提取出文件系统中被删除的文件和内容, 今年貌似不太一样, 因为这个文件系统里没有删除过文件… 里面有100个文件夹, 每个文件夹里又有220个以key打头的小文件, 这倒如何是好? 每个key文件用 hexdump 看确实是有一些规律, 其中只包含了0到9, A到F这些字符, 这很容易联想到16进制, 但提取出来再组合成二进制文件貌似也没有什么特别的地方, 这道题也就卡在这里. 不过这道题貌似也没有队伍做出来, 现在还不清楚该如何解决.

F300是一道很有意思的题, 直接给了一个iOS系统的dump, 里面包含了成千上万的小文件、图片、音乐等等内容. 题目的提示说这道题跟一个地名有关, 于是我们就在里面寻找任何跟地址有关的信息. 最开始查了短信记录, 分析出这个iPhone貌似是一个二手货. 后来又看了邮件记录, 这里面倒是有很多地名, 还有一个貌似摩斯码的东西, 让我们欣喜若狂以为找到了key, 结果提交上去一个都不正确. 后来看write-up才知道是以iPhone定时记录的GPS信息为线索, 这个是不是在讽刺苹果侵犯用户隐私呢? :) 通过GPS找到的地点居然是在南极洲… 而且从Google地图上可以神奇地发现 那里 有一个类似藏宝图上红X的标记, 这道题果然跟海盗、宝藏有关, 真是佩服出题人. 后面找到key就顺理成章了.

F400因为时间关系我们没怎么看, 但需要利用的是 JailbreakMe 发现的针对iOS的PDF漏洞, 只要知道这个这道题也就迎刃而解.

几天时间下来遗憾颇多, 也能感到与高手间的差距, CTF Quals是竞速赛, 因此不仅要会做, 还得做得快, 毕竟这么大的题量不是一般人能搞定的. 地域文化的差别有时也会导致某些题目只有美国选手比较了解. 无论怎样, 能够在毕业之前和几个朋友一起参加这个比赛, 这种经历很爽, 明年我还希望再来.

SPDY简介

今天在看CTF write-up时发现 有人提到 SPDY这样一个东西, 貌似跟Chrome项目有关, 于是在Geek原始冲动的驱使下了解了一下.

首先SPDY是一个应用层协议, 它被创造出来的唯一目的就是让Web更快、更快,还是更快. Google这家公司似乎很喜欢 “快” 这个东西, Chrome从诞生到现在每次几乎必定宣传自己有多么得快, 搞得大家已经产生了某种心理暗示. SPDY诞生于2009年, 其实这是对外公开发布的时间, 开始研究的时间应该更早. 众所周知, 如今的Web是通过HTTP协议和TCP协议进行传输, 但种种因素导致HTTP传输变得很慢:

  • 每一个TCP连接一次只能发一个HTTP请求, 这个估计是HTTP协议的最大弊端. 想象一下如今的网站已经包含大量的图片、CSS、JS需要加载, 如果一个请求一个请求地发, 那肯定会慢死, 所以浏览器通常都是通过建立多个连接来回避这个问题, 但毕竟治标不治本.
  • 只能由客户端主动发起HTTP请求, 即时有时服务器知道还需要回复其它资源, 它也只能等客户端先发起再回复. 服务器真可怜, 太被动了.
  • HTTP头没有压缩, 而且HTTP头也有一些重复信息, 比如User-Agent就没有必要每次都发来发去, 太浪费带宽了.
  • 数据压缩是可选的, Google认为必须强制要求.

既然HTTP有这么多缺点, 那应该不止Google自己想要解决, 其实是有的, 本着不重复造轮子的原则Google列举了现有的一些改进方案:

  • HTTP pipelining: 以流水线的形式传输请求和数据, 这里吐槽一下, 以前在公司时Facebook的某牛来介绍时谈到了他们开发的BigPipe, 思想也是流水线, 同样也是为了优化Web性能, 不知道他们是不是借鉴了HTTP pipelining, :)
  • SCTP: 用于替代TCP的传输层协议, 提供了multiplexed streams (多路复用流) 和stream-aware congestion control (流感知拥塞控制)
  • SST: 同样用于替代TCP协议 (TCP同学真是众矢之的…), 也可以运行在UDP协议之上.
  • MUXSMUX: 运行在传输层和应用层之间的中间协议, 同样提供了复用流.

但是Google同学觉得以上这些都还不够, 它要追求更大程度的性能提升. 考虑到TCP现在应用还很广泛, 想替代也不是一天两天的事情, 但HTTP就不一样了, 它是应用层的! 所以说有自家的浏览器就是好办, 发明个应用层协议马上就可以上线. SPDY在刚出来的时候Google还在说这并不是用来替代HTTP协议的, 它只是一个中间协议, 但看看 最新的协议文档 里面已经将SPDY分为了两层, 其中一层被描述为HTTP-like, 大有取代HTTP的意图. 可以想到Google已经将提议提交给IETF, 也许未来的某一天我们就不再使用HTTP协议了. SPDY主要有以下一些特性:

  • multiplexed streams, 一个TCP连接将支持无限的并发HTTP请求
  • 请求优先级, 因为现在支持并发请求, 就必须得为每一个请求设置一定的优先级
  • 压缩HTTP头, 去掉多余的头信息
  • 全部请求都是通过SSL加密, Google认为安全网络连接必定是未来的发展方向, 即使加密会微微增加一些传输时间
  • Web服务器将能够主动发起通信, 也就是server push
  • 还有一个类似的叫server hint, 不同于server push的是它仅仅向客户端发送一个suggest, 提示客户端需要发送一个HTTP请求

这些改进到底能有多大提升? Google给出的数据是39%~55%, 在丢包严重或高延迟环境下, SPDY变现更加出色.

要支持SPDY, 除了客户端必须支持外, 还要有相应的Web服务器. 现在已经有 PythonJavaApache moudleRuby 等各种实现.

最后, 如果你正在使用Chrome浏览器, 并且访问Google的网站, 那你已经开始使用SPDY了, 输入 chrome://net-internals/#spdy 还可以了解更加详细的信息.