Liuw's Thinkpad

在某处看到一篇文章，使用grep来找回没有分区表的硬盘中的文本文件内容。基本命令是：

grep "keyword" /dev/DEVICE

有可能需要加上其他的一些选项。

能这样做是因为在Unix中万物皆文件，即使没有Filesystem的信息，也可以通过bypass掉Filesystem的方法去读取block，得到raw data。

这个方法是有局限的。Filesystem处理数据时以block为单位，而多block的文件，block的分布不一定是连续的。也就是说grep也许能找到一部分数据，但是不大可能把所有的数据都找回来。当然，一个block一般是1K或者4K找回来的数据量对于一个文本文件来说也是相当可观的了。

为了证实我的想法，我做了以下的实验。

dd if=/dev/urandom of=hd.img bs=1M count=10

之所以用urandom而不是zero做输入，是为了增加数据，模拟真实的Filesystem。

losetup hd.img /dev/loop0

把这个文件连接到loop0，成为一个设备。

mkfs.ext3 -b 1024 /dev/loop0
mount /dev/loop0 /mnt
echo -e "This is a small file for testing.\nsecond line\nthird line" > /mnt/f1
umount /mnt

建立block大小为1024的ext3分区，然后挂载，向里面写入少量数据（少于1个block）。

grep --binary-files=text -z "file" /dev/loop0

不用-z的话，只会grep一行。

这样确实可以看到原来文件的内容。假如文件修改过有几个版本的话，可能还可以看到几个版本的内容。也许这是一个提高Filesystem效率的措施。

再测试大于1 block的文件。

perl -e 'print "string1 " x 128; print "string2 " x 128' > /mnt/f2
perl -e 'print "string3 " x 128; print "string4 " x 128' > /mnt/f3
for i in `seq 4 9`; do echo "$i" > "f$i" ; done
perl -e 'print "paddin" x 128' >> /mnt/f2
perl -e 'print " ssssss " x 128' >> /mnt/f2
...

上面其实进行了很多操作，这里就不一一列出了。block大小为1K，用stat可以看到它们的I/O block。之所以做多个文件，是为了防止ext3 bitmap在再次分配block的时候分配连续block，模拟真实环境。写完文件之后记得sync或者umount，把cache都flush到硬盘上。

再grep一次，可以发现各种数据是夹杂在一起的。

所以，最好还是注意保护自己的Filesystem吧。这些技巧只能解决小问题。

New release, new features.

New stubdom target domb.

Working Dom0 daemon dombd, responsible for communicating with DomB.

Usable domain builder inside DomB.

Coming soon…

这是暑期实习的成果。原来查了Phrack和PacketStorm等网站，都没有发现这方面的文档。

这篇文章主要解决了如何编写Unicode-proof ARM Shellcode的问题，个人觉得还是比较有意义的。其实也不一定是局限于Windows Mobile系统，只要是ARM架构，遇到要写Unicode-proof Shellcode这样的问题，这篇文章里面的方法都可以作为参考，因而放上来与大家一起分享。

本文采用Attribution-Noncommercial-Share Alike 2.5 China Mainland授权。

文章有点长，所以只放目录了，有兴趣看的再下PDF吧由于和导师有协议，所以不能把文章放出来，实在需要的联系我。

目 录
第一章 绪论 4
1.1 研究背景和意义 4
1.2 章节安排 4
第二章 相关概念和工具 5
2.1 Windows Mobile 6.1系统 5
2.2 ARM架构 5
2.3 Unicode编码 6
2.4 缓冲区溢出漏洞 6
2.5 相关工具软件 6
第三章 ARM架构 7
第四章 Windows CE 5.2 7
4.1 Windows CE 5.2的内存架构 7
4.2 当前运行进程的内存映射情况 9
4.3 Windows CE 5.2下的ARM栈祯结构 10
4.4 Windows CE 5.2下的ARM汇编 10
4.5 Windows CE 5.2系统安全性分析 11
第五章 漏洞分析与攻击 12
5.1 漏洞描述 12
5.2 漏洞成因 12
5.3 分析与攻击 12
第六章 已知的Shellcode编写技术 14
6.1 IA-32上Unicode-proof Shellcode的编写 14
6.2 纯数字字母的ARM Shellcode的编写 15
6.3 对两个方法的总结 16
第七章 Unicode-proof ARM Shellcode 16
7.1 ARM与x86在Shellcode编写上的差异 17
7.2 指令分析 17
7.2.1 Condition field 17
7.2.2 Data-processing instructions 18
7.2.3 Branch instructions 21
7.2.4 Load and store instructions 23
7.3 Shellcode编写方法：DirectConstructor 24
7.4 Shellcode实例：DirectConstructor方法 26
7.5 Shellcode编写方法：MagicLoopDecoder 31
7.6 Shellcode实例：MagicLoopDecoder方法 32
7.7 对编写Shellcode的一些建议 36
第八章 总结和展望 36
8.1 项目已完成部分 37
8.1.1 对千千静听1.29版的攻击 37
8.1.2 Unicode-proof ARM Shellcode的编写方法 37
8.1.3 辅助工具的编写 37
8.2 未来工作 37
8.2.1 Thumb状态指令Shellcode的编写 37
8.2.2 全自动化Shellcode生成工具的编写 38
参考文献 38
致谢 39
附录 40
A.1 trans工具的使用 40
A.2 findmagic工具的使用 41

一个新的想法，做了一天。

想在原来写Shellcode的方法之上更进一步。

后来发现在一条指令上卡住了。

限制很多，虽然没有走通，但是也是很有收获了。

至少可以说明ARM Shellcode在Unicode环境下是不可能有直接生成的循环解码器了。

在看PicoWebServer的一个security flaw分析，嗯，典型的栈溢出。虽然多了一个Unicode，但是还是可以做到DoS攻击的。作者的分析也挺不错，把出现问题的地方说得清楚了。

不过末尾有一句话有点大雷了：

An attacker has full control over the device if he is able to let the overwritten return address point to a “0D F0 A0 E1″ (“MOV PC, SP”) equivalent byte sequence. Since SP is the only register pointing into the potential shellcode supplied by an attacker, the aim of an attacker is to let PC equal SP.

还好作者用的是if he is able to，还有点不确定的意思。我是老老实实地用IDA Pro搜索了整个地址空间（是的，“整个”），也没有发现有这样的序列。首先，编译器不会产生这样的代码，那么在代码段内找是徒劳的了。其次，数据段有的话，那真是纯粹巧合了，看人品，而且数据段能不能执行，还是未知之数。

所以啊，总是easier said than done，虽然现在有这样的possibility，但是实际上做不做得到，那还真是认真考证一下才清楚。

师兄也和我说了，搞个什么MessageBox出来，那是不难，但是我们的目标还是要再远一点，要有点实际的东西出来。我也挺认同的，理念上的东西，大家都清楚，但是到底能不能用，可不可以，那还真是要做过才知道。不产生实际危害的漏洞，不是好漏洞（DoS不在考虑之列，这是比较次的危害）。

提一下我们现在的问题是什么：某个软件，接收ANSI字符（0×00-0xFF），然后把接收到的字符转换成Unicode再存储到缓冲区，然后造成了缓冲区溢出。问题是，我们虽然可以改写栈上PC的值，但是这是有限制的（Unicode转换的存在）。如何把控制流改到我们注入到栈上的shellcode中，这需要很多工夫了。目前这是第一步，先不考虑shellcode是否有效，就是要把PC的值搞到栈上就OK了。

这一周基本都在考虑这个问题，也有不少的想法，但是最后都被自己否掉了。罗列如下吧：

1. 把要发过去的ANSI串A看作是Unicode，先进行Unicode到ANSI的变换得到B，把B发过去，这样在Server端变换之后，就变成了A。这个想法的致命点是，ANSI只能映射Unicode的一个很小的子集，也就是说，变换过程不是满射的。而且从比例来看，只有1%左右有情况可以逆变换成功。于是有第二个想法。
2. 寻找Unicode编码中的闭包子集S，发过去S中的A变换后得到的B仍然在S之内，这样可以很容易通过控制A的生成来得到理想的B。但是现在我还没有找到这样的闭包。即使找到，也只有万里长征第一步，因为这样的S估计不会很大，变换出来的编码有限的话，对于地址的选择就很有讲究了。
3. 在其他段寻找如MOV PC, SP这样的序列（也就是上面文章的想法）。不用说，目前失败。
4. 构造某个系统调用/API的输入，然后跳转到那个系统调用/API。要求是这个系统调用/API足够强大，可以完成很多功能。但是矛盾的地方是，功能强大的API通常参数是十分复杂的，很难构造。而且，Windows CE的calling convention中，首先使用R0-R4去传送参数，不够才使用栈。怎么让R0-R4符合API的要求？看运气？否掉。
5. 从转换函数入手，当然，这个想法很烂。但是也不是说完全没有可能，先留着呗。

现在基本是能想到的都想了，但是总是有这样那样的限制，使得这些想法成为不可能。明天和师兄讨论一下，看他有没有什么其他想法吧。

msimg32.dll，Kingsoft Internet Security Safe Msn

我的环境是Windows XP SP2，此DLL在MSN登录的时候会出错（当然，出错信息还是一样的没有任何价值）。

再安装一次，发现这个DLL是金山MSN防护盾的一部分。已经加入到了MSN的安装包之中。那么，在安装的时候，不安装这个产品就可以了。现在MSN运行正常。

因为我的机器上装有一大堆的开发工具，开始我还以为是我的runtime太多太乱导致了问题。后来看看错误报告，它唯一有价值的地方就是告诉我哪个DLL出错了。

金山出了如此的错误，还真是令我挺惊讶的，不知道是不是个案了。

过来中科院的，做的是从来都没有接触过的移动平台安全。师兄给了我两个方向，一个是漏洞挖掘，一个是漏洞利用，叫我先看看资料，看看自己喜欢哪个。

挖掘，主要使用的方法是fuzzing，其实从原理上说还不是特别的难，要写程序也挺容易，所以花在上面的时间不多。利用，师兄说其实和x86上的漏洞利用是差不多的，无非也是溢出。不过因为手机一般是使用ARM的处理器，所以汇编是不大一样的。于是上周基本在资料和小程序实验中试过，主要方面都花在钻手机漏洞利用方法了。

现在要讲的，倒也不是ARM汇编，而是在做实验中发现的一个有趣的东西，叫security cookie，可以检测是否有栈溢出发生。

在返回之前，调用了一个security_check_cookie的函数。

security cookie是编译器的一个feature（当然是可以关掉的）。原理是这样的，在每次进入函数的时候，在缓冲区边界处留出一个存储空间，复制一份security cookie的值，然后在函数返回之前，检查此地址的内容与security cookie是否一致。假如不一致，就说明栈发生了溢出。security cookie是一个magic number，基本上程序每次运行时都是不一样的，要猜中是很难的。即使猜中了，此cookie也会影响shellcode的编写。security cookie的一套代码，都是由编译器自动生成的，因而程序是不需要作什么修改的。