发现一篇写得更好的：http://insight-labs.org/?p=2009
程序要求输入一个flag。拿ida加载后，发现是Upx壳，脱壳后加载入ida进行分析。定位到输入flag的地方，如下图：
在od中在0x401455处下断点，执行到此。继续f8执行下去，发现程序来到一块不在程序代码段的用户空间。如下图：
这一段执行完后，程序在修改代码段的内容，是动态代码修改。修改完成后，跳转到0x0040189e去执行。如下图：
我就觉得是一个壳，而0x0040189e则是OEP。因此，我使用OllyDump对程序进行脱壳，并使用ImportRec进行导入表的修复。修复成功后，成功得到一个exe。
得到exe后，我尝试运行，发现不能运行，因此我就拖入ida进行分析。发现程序在动态修改代码段的内容，而代码段是不能执行的，因此不能运行。不过对于静态分析还是不错的，在里面我清晰地看到程序的算法。
将数据调整完顺序后，会与一个字符串比较，如果相同，则成功，否则，则失败。
Hexlify(char *s, char *d, int len):将s表示为16进制放在d中，d的长度为s的两倍。
Xor(char *source, int len) :source里的每两个字符是一个字符的16进制表示，将source里的每两个字符与第一第二个字符比较，如果都相等，这两个字符分别异或0x19和0x20，如果都不相等则将字符异或0x18。
Core_algo()为一个递归算法，将产生打乱后的顺序。
Disorder(0)则根据core_algo产生的打乱后的顺序将final的顺序打乱。
我发现只有两个函数对final这个字符串数组进行了操作，也就是说打乱的顺序与输入的数据没有关系。我将core_algo执行完后，把内容从40adf8开始的0x510字节dump出来，并写了个脚本拿到了打乱后的顺序。
因此，可以从后向前推出flag。脚本如下：
