前几天freebuf上出现了一篇文章，黑暗幽灵（DCM）木马详细分析，这个木马为了防止被直接找出服务器地址，在上传用户数据时伪装成了DNS查询，然后在关键节点捕获带有特定标识的网络包后进行转发。
抛开一切，不得不说这样的想法还是很好玩。于是就来写了个demo实验了一下。
假定我们伪装成查询www.google.com的IPv4地址，实际发送的数据是nise DNS query
Continue reading A rather marvelous means to send data anonymously via fake DNS query
update (2016-04-05):
Ternary Search Tree (improved)的实现有误，将稍后更正。
There is always a topic that how to store a set of strings. Throughout the years, many kinds of data structure had been proposed and applied, for instance, hash tables, binary search tree, digital search tree, ternary search tree and so on and so forth.
如何存储一组字符串总是一个经久不衰的话题。在这些年间，有许多种不同的数据结构不断被提出和应用，例如哈希表、二分搜索树、数字查找树、三元搜索树等等。
Let's begin with ternary search tree which is proposed by Jon and Robert at Pricenton[1]. There is one more pointer in the node compared with binary search tree, and it's the exactly minor change that not only makes it combine the time efficiency of digital tries with the space efficiency of binary search trees, but also provides more features like prefix search and fuzz search.
让我们从三元搜索树开始，它是由Jon和Robert在Pricenton[1]提出的。和二分搜索树相比起来，它的每个节点中多了一个指针，也正是这么一个小小的改动，不仅使它结合了数字查找树的时间效率和二分搜索树的空间效率，还使得它提供了诸如前缀搜索和模糊搜索这样的特性。
But can we make it more efficient in time with a tolerable space increment? We need to analyse the algorithm and the data structure of ternary search tree.
但是我们能在可容忍的空间使用增加上，进一步提高它的时间效率吗？我们需要分析三元搜素树的算法与结构。
As we memtioned in the Application of Ternary Search Tree, a typical node structure of TST is
正如我们在Ternary Search Tree的应用中提到的那样，一个典型的TST结点的结构题如下
typedef struct tsnode { char c; struct tsnode * le, * eq, * gt; } tsnode, * tstree;
Its insertion and searching are really fast when the string in given strings set is short (I'm not going to define the exactly length of a string that we could say it's short, but we will see the decrement of running time after we applying the improvement). When the string length increases, the insertion and searching time grow, of course. The question is, we only compare one char at a time.
当给定输入集的字符串都比较短的时候（我并不打算定义低于多少个字节长才叫短，但是在应用了改进之后，我们将会明显看见运行时间的减少）。当字符串长度增加时，理所当然的，插入和搜索的时间也会增加。但问题在于，我们一次只比较了一个字符。
最近在研究Key-Value数据库，思考之后打算尝试着重造轮子。目标是做一个高效Key-Value数据库，要实现一个Key-Value数据库本身并不困难，但是要做到存取、查询效率足够高的话，还是要靠背后的数据结构。在一番搜索之后，暂时决定用Ternary Search Tree来实现试试。
简单说明一下Ternary Search Tree，它的结构十分简单，每个结点储存一个字符，还有三个指针，分别对应下一个字符与当前字符的大小关系——小于、等于、大于。
下面是一个典型的三分搜索树的结点的结构
typedef struct tsnode { char c; struct tsnode * le, * eq, * gt; } tsnode, * tstree;
查找/插入的字符小于当前字符就转向左子树，大于则转向右子树。当等于的时候，考虑两种情况，一是查找的字符已经是NULL，即需要搜索/插入的字符串已经走到了结尾。如果是插入的话，此时就可以将要插入的字符串的地址赋给当前结点指向等于关系的指针。如果是搜索的话，则可直接返回当前结点指向等于关系的指针（因为我们在插入时将这一指针赋值为了字符串的地址）。
以前研究过如何获取Xcode里文档下载的URL，获取Xcode文档下载地址，然而前些日子有朋友说用这种方法已经获取不到了，而且在cycript中执行choose(NSURLSession)之后再回到Xcode时，程序会崩溃。
那么趁着今天晚上有些空闲时间，就研究了一下。于是就有了这么一个东西吧——XcodeDocsFetcher
P.S 其实大多数时候直接用Xcode下载也还是挺快的。下载完了可以参考这篇文章的方法安装文档，欺骗Xcode从本机安装Docset
早在2012的时候，iTunes 11就可以从封面中自动提取出主要的颜色用在歌曲列表里的字体和背景上了。
然而当时的我万万没有想到的是，如今自己也需要这样的算法了。
简单考虑了一下，打算用OpenCV读图，然后自己实现一下K-means算法来计算出给定图像中主要颜色。
对于聚类算法的综合性介绍可以参见这篇zhihu上的回答，用于数据挖掘的聚类算法有哪些，各有何优势？，及其这篇scikit-learn上的文章，scikit-learn Clustering¶。本文不再对聚类算法展开叙述。
之前写了Sieve of Eratosthenes筛法，但总觉得算法还不够好，因为我们为每个数都留了一个bit，而显然的，除了2以外的偶数都不可能是质数，那么如果我们只为奇数申请bit位来标记的话，效率应该有进一步的提升。
在原来的算法中，我们初始化时是这样的
Sieve of Eratosthenes筛法初始化
那么，我们真的需要把偶数放进来吗？
Why on earth do we need even numbers while we pick primes
Sieve of Eratosthenes筛法是一种找质数的算法。我们知道，对于一个合数，那么它必定可以分解为两个质数相乘，比如21=3x7。那么我们也可以理解为，一个合数必定是一个质数的倍数，对于刚才的例子，21就是质数3的7倍（当然也可以说是质数7的3倍）。
那么我们求给定范围内的质数就可以利用这一点——先把所有的数列出来，然后从2开始，把所有数的倍数都去掉，这样我们就能留下给定范围内的质数了。举个例子，求42以内的所有质数，那么我们的算法大致上是这样操作的：
前几天在Hopper的pesudo code里面看到这样一句，
r0 = *__gxx_personality_sj0;
当时没明白是做什么的，今天正好有空，搬来了梯子请出Google老师。
众所周知，cycript有一个非常便利的功能——choose(CLASS_NAME)。通过这个function，我们可以获取到当前进程中所有类名为CLASS_NAME的实例对象，在逆向的过程中能给我们节省不少时间。
然而，在编写tweak时却用不了这个function，当然不用这个也能写，但是有的话，也是一大便利。