前一篇提到了通过改变委托中的指针来改变实际的调用目标。修改委托实例中的_target、_methodPtr、_methodPtrAux这三个成员,都能够改变跳转目标;特别是后两个,它们的类型是IntPtr,可以构造出任意数值的指针设置进去,那样就可以跳转到任意目标了。
但只能指定目标地址,却不能随意控制目标里的代码,显然还不够好玩。如果要跳转的目标是托管方法,那构造一个正常的委托就够了。如果能在不使用P/Invoke也不使用unsafe code的条件下在C#程序里执行一小块自定义的native code就好玩多了。先前的两篇日志(这里和这里)我提到在内存里生成native code并执行并不是件难事。那么在CLR上的C#也能做到么?
===========================================================================
要玩怎样的代码?
如果能执行任意native code的话,不得不说可玩的东西就多了。例如说把整个调用栈给乱搅一通、把SEH链全都破坏掉;或者……嗯还是别想那么可怕的玩法了,我还不想把自己的系统弄垮。等什么时候我再装个用了就扔的虚拟机镜像再试可怕的玩法……
还是跟前面一样,写段类似HelloWorld的代码,往标准输出流写句话,表明“可以做”就算了。想用System.Console.WriteLine()会有点不爽,因为它要接收CLR对象(的引用)为参数,而我不想费事去在自己的native code里去找出System.String的type token、调用CORINFO_HELP_NEWSFAST创建新实例、调用构造器之类的一大堆麻烦事。我就想把一个C风格的字符串输出而已。那么,就不用.NET标准库里的方法了,干脆直接用Win32 API,简单省事,WriteConsole()函数正好够用。调用Win32函数时也懒得通过P/Invoke,而是在native code里直接call过去。
要用Win32 API,首先得确保需要的DLL已经被加载到当前进程中。CLR为了自身的正常运行,本来就需要加载很多模块。可以看看一个HelloWorld式的托管程序都加载些什么模块进来。
- using System;
- static class Program {
- static void Main(string[] args) {
- // block the program so that we could easily attach a debugger
- var name = Console.ReadLine();
- Console.WriteLine("Greet me, {0}", name);
- }
- }
using System; static class Program { static void Main(string[] args) { // block the program so that we could easily attach a debugger var name = Console.ReadLine(); Console.WriteLine("Greet me, {0}", name); } }
除了这个exe本身之外,可以看到加载进来的模块有:
COMCTL32
COMCTL_1
GDI32
IMM32
KERNEL32
LPK
MSCOREE
MSCORJIT
MSCORLIB
MSCORWKS
MSVCR80
MSVCRT
OLE32
RPCRT4
SECUR32
SHELL32
SHLWAPI32
USER32
USP10
光是一个HelloWorld就加载了这么多DLL,可以用的函数那就多了 XD
要调用的WriteConsoleA()函数位于Kernel32.dll中,在列表里可以找到,没问题。其实就没什么Win32程序是不加载Kernel32.dll的吧 =v=
怎么获取Win32 API的函数地址呢?如果是在C里,那不用管函数地址,引入windows.h或相关头文件后正常用那些函数就行。要不然LoadLibrary()得到模块句柄然后GetProcAddress()得到函数地址也行。前者在C#里固然是不行(即使用P/Invoke然后用个委托指向包装函数,得到的地址也是stub的地址而不是底下实际目标函数的地址);后者有自举困难——LoadLibrary()的地址从哪儿来?
所以干脆ad-hoc点,既然是玩嘛就先别那么麻烦,先弄出能演示的版本再说。用别的办法找到需要用的函数的地址,然后硬编码到我们生成的native code里就算了。因为DLL有默认的加载地址,只要一个进程里加载的DLL没有地址冲突,它们所在的位置就是可预测的,其中函数的位置也是可预测的。当然,我是在XP上玩,在Vista之后有ASLR,地址就不好预测了……但如果按照下文的方法保存生成的native code的话,程序在遇到ASLR前先就被DEP干掉了。
OK,废话那么多,我想达到的效果要是用C直接写会是怎样呢?
- #include <windows.h>
- int main() {
- HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE);
- WriteConsole(hStdout, "Greetings from generated code!\n", 31, NULL, NULL);
- return 0;
- }
#include <windows.h> int main() { HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE); WriteConsole(hStdout, "Greetings from generated code!\n", 31, NULL, NULL); return 0; }
很简单对吧?基本对应的机器码和汇编,后面还会用到:
- 55 push ebp
- 8BEC mov ebp,esp
- 6A F5 push -0B ; /DevType = STD_OUTPUT_HANDLE
- B8 D92F817C mov eax,KERNEL32.GetStdHandle ; |
- FFD0 call eax ; \GetStdHandle
- 6A 00 push 0 ; /pReserved = NULL
- 6A 00 push 0 ; |pWritten = NULL
- 6A 1F push 1F ; |CharsToWrite = 1F (31.)
- E8 00000000 call <&next_instruction> ; |
- 830424 10 add dword ptr ss:[esp],10 ; |Buffer
- 50 push eax ; |hConsole
- BA 5DCC817C mov edx,KERNEL32.WriteConsoleA ; |
- FFD2 call edx ; \WriteConsoleA
- 8BE5 mov esp,ebp
- 5D pop ebp
- C3 ret
55 push ebp 8BEC mov ebp,esp 6A F5 push -0B ; /DevType = STD_OUTPUT_HANDLE B8 D92F817C mov eax,KERNEL32.GetStdHandle ; | FFD0 call eax ; \GetStdHandle 6A 00 push 0 ; /pReserved = NULL 6A 00 push 0 ; |pWritten = NULL 6A 1F push 1F ; |CharsToWrite = 1F (31.) E8 00000000 call <&next_instruction> ; | 830424 10 add dword ptr ss:[esp],10 ; |Buffer 50 push eax ; |hConsole BA 5DCC817C mov edx,KERNEL32.WriteConsoleA ; | FFD2 call edx ; \WriteConsoleA 8BE5 mov esp,ebp 5D pop ebp C3 ret
我准备把要输出的字符串紧接在代码后面。注意这里用了之前介绍过的一个技巧,通过call指令来获取当前IP(指令指针)的值,并由此计算出要输出的字符串的地址。其实不用这个技巧也可以的,毕竟我已经知道代码的起始地址了。不过玩嘛,呵呵~
我用call r32指令而不是call imm32指令来调用那两个Win32函数,是因为前者的r32里装的是虚拟内存的绝对地址,而后者的imm32里装的是相对下一条指令的偏移量;我懒得在生成代码的时候去计算偏移量所以用前者了。
另外还要注意,Win32 API的calling convention是WINAPI,也就是__stdcall,是由被调用方来清理栈的。
其实要让CLR无声无息的就停掉,在native code里调用TerminateProcess()应该也行。这次的例子还是专于HelloWorld好了 =v=
===========================================================================
如何存放生成的native code?
之前用C来演示运行时操纵代码的时候,是把native code“生成”到malloc出来的一块堆空间上的。在C#里我要怎么找到可写可执行的一块放代码的空间呢?
在前一篇的后半段中我介绍了改变委托的_target成员也可以改变最终被调用的目标。留意到_target的类型是System.Object,也就是说任何对象都可以放在里面。如果构造一个委托实例时,它是指向静态方法的,那么它的_methodPtr成员就会指向那个特定的stub:(stub会根据委托类型的参数个数不同而不同,下面是接收一个参数的委托的情况)
- mov eax,ecx ; 把第一参数(_target)复制到EAX
- mov ecx,edx ; 把原本的第二参数变为第一参数
- add eax,10h ; 把_target._methodPtrAux的地址设到EAX
- jmp dword ptr [eax] ; 间接调用EAX,也就是调用_target._methodPtrAux
mov eax,ecx ; 把第一参数(_target)复制到EAX mov ecx,edx ; 把原本的第二参数变为第一参数 add eax,10h ; 把_target._methodPtrAux的地址设到EAX jmp dword ptr [eax] ; 间接调用EAX,也就是调用_target._methodPtrAux
这个stub完全不理会_target到底是什么类型的,直接从偏移量0x10的地方取出一个DWORD,然后就间接跳转过去了。正常情况下_target指向委托自身,那么在偏移量0x10的地方就是_methodPtrAux成员,整个逻辑就是对的。那要是狸猫换太子,放点什么别的东西进去当作_target呢?
C#里,引用类型的默认内存布局是LayoutKind.Auto,值类型的默认内存布局是LayoutKind.Sequential,而我们现在需要的是在一个确定的偏移量保持跳转目标的地址。给类型指定LayoutKind.Explicit可以达到目的,不过其实有更简单的办法,连特殊类型都不需要声明——直接用数组就行了嘛。数组里的元素肯定是按顺序保存的。
CLR里,一个最简单不过的int[]在内存中的布局如下:(括号中数字表示距离数组起始地址的偏移量)
----------------------- | SyncBlk索引 | (-4) ----------------------- | 指向MethodTable的指针 | (+0) ----------------------- | 数组长度 Length | (+4) ----------------------- | 下标为0的元素 | (+8+4*0) ----------------------- | 下标为1的元素 | (+8+4*1) ----------------------- | ... | ----------------------- | 下标为n的元素 | (+8+4*n) ----------------------- | ... | -----------------------
而一个委托实例的开头部分在内存中的布局是:
----------------------- | SyncBlk索引 | (-4) ----------------------- | 指向MethodTable的指针 | (+0) ----------------------- | _target | (+4) ----------------------- | _methodBase | (+8) ----------------------- | _methodPtr | (+12) ----------------------- | _methodPtrAux | (+16) ----------------------- | _invocationList | (+20) ----------------------- | _invocationCount | (+24) -----------------------
那么只要用一个int[](或者uint[]),在下标为2的地方放一个数字,然后把该数组设为某个委托的_target,那就……嘿嘿。
在Windows XP上,DEP还没有对所有程序默认开启,所以基本上在堆上申请到的空间都是可写可执行的。CLR里的托管数组都在堆上分配空间,可以把native code“生成”到数组里保存着。不过Vista和Windows 7上DEP默认对所有程序都启用,而不通过VirtualAlloc()或者VirtualProtect()就没办法申请到可写可执行的空间,所以下面的办法在这些新的系统上运行会看到AccessViolationException。
结合我们需要在特定偏移量保存伪装的_methodPtrAux的需要,我们需要构造的int[]或者uint[]数组应该像这样:
----------------------- | SyncBlk索引 | (-4) ----------------------- | 指向MethodTable的指针 | (+0) ----------------------- | 数组长度 Length | (+4) ----------------------- | 0 | (+8+4*0==8,下标为0) ----------------------- | 0 | (+8+4*1==12,下标为1) ----------------------- | 假的_methodPtrAux | (+8+4*2==16,下标为2) ----------------------- | 生成的native code | (+8+4*3==20 ...) | ... | -----------------------
其中,在下标为2的地方放置“假的_methodPtrAux”;该值应该等于下标为3的地址,好让委托调用到“生成”的native code。
于是又有问题了:我们该如何得到数组的地址?
===========================================================================
如何获得对象的地址?
可能会有人想到用对象的hashcode来找出对象的地址。让我们笼统的分析一下其合理性。
Java的java.lang.Object和.NET的System.Object都支持获取对象的hashcode。如果一个对象在“活着”的时候不会被移动,则其起始地址不会发生改变;对象间不应该有交叠,所以用对象地址直接作为hashcode是一种很直观的实现。事实上Android里的Dalvik虚拟机就是这样实现Object.hashCode()的,详细可查看Dalvik源码的vm/native/java_lang_Object.c中的Dalvik_java_lang_Object_hashCode()和InternalNative.c中的dvmGetObjectHashCode()。
- /*
- * Return the hash code for the specified object.
- */
- u4 dvmGetObjectHashCode(Object* obj)
- {
- return (u4) obj;
- }
/* * Return the hash code for the specified object. */ u4 dvmGetObjectHashCode(Object* obj) { return (u4) obj; }
注意到Dalvik的GC是典型的标记-清除(mark-and-sweep)式,不会移动堆中的对象。
也可以留意一下Apache Harmony里的其中一种hashcode计算方式,第16页:Design a Product-Ready JVM for Apache Harmony
也有一些JVM的实现会选择以对象地址为源通过位移、异或等运算来计算hashcode,这种情况下要从hashcode反推回来原本的地址就有点困难了。
Mono在使用不移动对象的GC时,采用的hashcode算法来自Thomas Wang,Address Based Hash Function
其算法实现是:
- uint32 address_hash(char* addr)
- {
- register uint32 key;
- key = (uint32) addr;
- return (key >> 3) * 2654435761;
- }
uint32 address_hash(char* addr) { register uint32 key; key = (uint32) addr; return (key >> 3) * 2654435761; }
那要是GC会移动对象呢,例如说采用了拷贝式收集器或者压缩式收集器的话?一个办法是可以拿对象第一次被分配的地址为hashcode的源,另一个办法是干脆无视对象的地址,用别的办法来得到能够区分对象身份的值;还有些别的办法是上面两种的混合。Xiao-Feng在Object hashcode implementation一帖中描述了Apache Harmony实现hashcode的三种方案,可以参考阅读一下。
CLR中System.Object.GetHashCode()并不返回对象的地址,所以很可惜不能从这里挖出点指针来玩玩。
---------------------------------------------------------------------------
然后可能会有人想到像C那样用union来骗过类型系统。
- #include <stdio.h>
- typedef union tagMyUnion {
- int i;
- float f;
- } MyUnion;
- int main() {
- MyUnion u;
- int i;
- u.f = 2.0f; // 0x40000000
- i = u.i; // 0x40000000
- u.i = i + (1 << 23); // 0x40800000
- printf("%f\n", u.f); // 4.000000
- printf("%d, 0x%08x\n", i, i); // 1073741824, 0x40000000
- printf("%d, 0x%08x\n", (int)u.f, (int)u.f); // 4, 0x00000004
- return 0;
- }
#include <stdio.h> typedef union tagMyUnion { int i; float f; } MyUnion; int main() { MyUnion u; int i; u.f = 2.0f; // 0x40000000 i = u.i; // 0x40000000 u.i = i + (1 << 23); // 0x40800000 printf("%f\n", u.f); // 4.000000 printf("%d, 0x%08x\n", i, i); // 1073741824, 0x40000000 printf("%d, 0x%08x\n", (int)u.f, (int)u.f); // 4, 0x00000004 return 0; }
在C里,要直接把float类型的值的底层表示“看作”int,光靠类型转换是不行的,因为编译器会在转换的地方插入类似inttofloat()的函数,把底层表示从单精度浮点数格式改变为二的补码整数格式。以前专门的浮点数运算器不普及时,程序员经常自己用整数运算去模拟浮点数运算,需要在不改变底层表示的前提下操作。怎么办呢?像上面那样用union就可以做到。通过union,任意等宽度的类型间都可以做不改变底层表示的转换,跟后来C++的reinterpret_cast作用一样。
CLR里的引用用指针的形式来实现,而指针以直接记录地址的形式来实现。(注意:引用、指针和地址是三个在不同抽象层次上的相关概念,不应该把它们看作同一抽象层次上的概念。)
虽然C#中没有reinterpret_cast,但有模拟C的union的结构:显式指定内存布局的struct。如果可以在C#里实现一个union,把IntPtr值和Object引用保存在同一位置,不就可以提取到对象的地址了吗?于是:
- using System;
- using System.Runtime.InteropServices;
- namespace TestCLR2Crash {
- [StructLayout( LayoutKind.Explicit )]
- struct Reinterpreter {
- [FieldOffset( 0 )]
- IntPtr _pointer;
- [FieldOffset( 0 )]
- object _target;
- public IntPtr Cast( object obj ) {
- _target = obj;
- return _pointer;
- }
- }
- static class Program {
- static void Main( string[ ] args ) {
- var reinterpreter = new Reinterpreter( );
- var arr = new[ ] { 1, 2, 3 };
- var ptr = reinterpreter.Cast( arr );
- Console.WriteLine( ptr.ToString( "X" ) );
- }
- }
- }
using System; using System.Runtime.InteropServices; namespace TestCLR2Crash { [StructLayout( LayoutKind.Explicit )] struct Reinterpreter { [FieldOffset( 0 )] IntPtr _pointer; [FieldOffset( 0 )] object _target; public IntPtr Cast( object obj ) { _target = obj; return _pointer; } } static class Program { static void Main( string[ ] args ) { var reinterpreter = new Reinterpreter( ); var arr = new[ ] { 1, 2, 3 }; var ptr = reinterpreter.Cast( arr ); Console.WriteLine( ptr.ToString( "X" ) ); } } }
很可惜CLR已经预料到这种玩法,不允许值类型与引用类型的域交叠。上面的代码可以通过编译,但在加载Reinterpreter类型时会出错:
at TestCLR2Crash.Program.Main(String[] args)
此路不通 =x=|||
---------------------------------------------------------------------------
其实.NET标准库里有System.Runtime.InteropServices.GCHandle这么个值类型。它的作用主要体现在托管代码与native code的互操作中,以避免需要用到的托管对象在native code执行过程中意外被GC回收。GCHandle也可以把对象“定”(pin)住,以避免native code访问对象的过程中对象地址发生改变。
GCHandle有个AddrOfPinnedObject()方法,正好可以提供对象的地址;使用GCHandle还附带了保证对象不被回收的功能,对这帖想要玩的代码是正合适。
创建GCHandle时用到的Alloc()方法要求调用它的程序集有SecurityPermissionFlag.UnmanagedCode权限。不过即便用了它,我也没有在代码中显式使用unsafe code,满足我的要求。
要用GCHandle定住一个对象的话,创建GCHandle时会对一些类型的对象给予特别待遇,包括:
1、System.String
2、元素为原始类型的数组
3、元素为值类型且Blittable的数组
4、其它Blittable类型
任何不在上述范围内的对象obj,传给GCHandle.Alloc(obj, GCHandleType.Pinned)的话,会引发异常:
- using System;
- using System.Runtime.InteropServices;
- namespace TestCLR2Crash {
- static class Program {
- static void Main( string[ ] args ) {
- var o = new object( );
- var handle = GCHandle.Alloc( o, GCHandleType.Pinned );
- var addr = handle.AddrOfPinnedObject( );
- handle.Free( );
- }
- }
- }
using System; using System.Runtime.InteropServices; namespace TestCLR2Crash { static class Program { static void Main( string[ ] args ) { var o = new object( ); var handle = GCHandle.Alloc( o, GCHandleType.Pinned ); var addr = handle.AddrOfPinnedObject( ); handle.Free( ); } } }
non-blittable data.
at System.Runtime.InteropServices.GCHandle.InternalAlloc(Object value, GCHandleType type)
at TestCLR2Crash.Program.Main(String[] args) in F:\document\Visual Studio 2008\Projects\TestDev9\TestCLR2Crash\Program.cs:line 8
换成一个字符串就没问题:
- using System;
- using System.Runtime.InteropServices;
- namespace TestCLR2Crash {
- static class Program {
- static void Main( string[ ] args ) {
- var str = "check me";
- var handle = GCHandle.Alloc( str, GCHandleType.Pinned );
- var addr = handle.AddrOfPinnedObject( );
- Console.WriteLine( "{0}, {1}", str, addr.ToInt32( ) );
- handle.Free( );
- }
- }
- }
using System; using System.Runtime.InteropServices; namespace TestCLR2Crash { static class Program { static void Main( string[ ] args ) { var str = "check me"; var handle = GCHandle.Alloc( str, GCHandleType.Pinned ); var addr = handle.AddrOfPinnedObject( ); Console.WriteLine( "{0}, {1}", str, addr.ToInt32( ) ); handle.Free( ); } } }
GCHandle.Alloc()文档中对此有提及。我差点看漏了以为文档没说……
有趣的是,GCHandle对类型的挑剔还不止于此。GCHandle.AddrOfPinnedObject()方法乍一看像是返回对象自身的起始地址,实际不然,返回的是对象的“数据区”的起始地址。对System.String来说,“数据区”就是实际存放字符的char数组(CLR的String实现把char数组融合到String里了,没有单独的“char数组成员”。忽略ObjHeader,跳过MethodTable指针和其它成员,例如m_arrayLength、m_stringLength,跳到m_firstChar也就是融合后char数组的开始);而对数组来说,“数据区”就是实际存放值的区域(忽略ObjHeader,跳过MethodTable指针和Length);对其它Blittable类型来说,“数据区”就是Object里MethodTable指针之后的部分。
===========================================================================
完事俱备,只欠开工写代码来实现前面讨论的内容。
先上代码:
- using System;
- using System.Reflection;
- using System.Runtime.InteropServices;
- namespace TestCLR2Crash {
- static void Main( string[ ] args ) {
- // declare a delegate that refers to a static method,
- // in this case it's a static method generated from the
- // anonymous delegate.
- Action action = delegate( ) { };
- // "generate" code into an array of uint
- var fakeDelegate = new uint[ ] {
- // dummy values
- 0x00000000, 0x00000000,
- // fake _methodPtrAux
- 0x00000000,
- // native code/string
- 0x6AEC8B55, 0x2FD9B8F5, 0xD0FF7C81, 0x006A006A,
- 0x00E81F6A, 0x83000000, 0x50102404, 0x81CC5DBA,
- 0x8BD2FF7C, 0x47C35DE5, 0x74656572, 0x73676E69,
- 0x6F726620, 0x6567206D, 0x6172656E, 0x20646574,
- 0x65646F63, 0x00000A21
- };
- // fill in the fake _methodPtrAux,
- // make it point to the code region in fakeDelegate
- var handle = GCHandle.Alloc( fakeDelegate, GCHandleType.Pinned );
- var addr = handle.AddrOfPinnedObject( );
- const int sizeOfUInt32 = sizeof( uint ); // 4
- const int indexOfCode = 3;
- fakeDelegate[ 2 ] = Convert.ToUInt32( addr.ToInt32( ) + sizeOfUInt32 * indexOfCode );
- var targetInfo = typeof( Action )
- .GetField( "_target", BindingFlags.NonPublic | BindingFlags.Instance );
- targetInfo.SetValue( action, fakeDelegate );
- action( ); // Greetings from generated code!
- Console.WriteLine( "Greetings from managed code!" );
- handle.Free( );
- }
- }
- }
using System; using System.Reflection; using System.Runtime.InteropServices; namespace TestCLR2Crash { static void Main( string[ ] args ) { // declare a delegate that refers to a static method, // in this case it's a static method generated from the // anonymous delegate. Action action = delegate( ) { }; // "generate" code into an array of uint var fakeDelegate = new uint[ ] { // dummy values 0x00000000, 0x00000000, // fake _methodPtrAux 0x00000000, // native code/string 0x6AEC8B55, 0x2FD9B8F5, 0xD0FF7C81, 0x006A006A, 0x00E81F6A, 0x83000000, 0x50102404, 0x81CC5DBA, 0x8BD2FF7C, 0x47C35DE5, 0x74656572, 0x73676E69, 0x6F726620, 0x6567206D, 0x6172656E, 0x20646574, 0x65646F63, 0x00000A21 }; // fill in the fake _methodPtrAux, // make it point to the code region in fakeDelegate var handle = GCHandle.Alloc( fakeDelegate, GCHandleType.Pinned ); var addr = handle.AddrOfPinnedObject( ); const int sizeOfUInt32 = sizeof( uint ); // 4 const int indexOfCode = 3; fakeDelegate[ 2 ] = Convert.ToUInt32( addr.ToInt32( ) + sizeOfUInt32 * indexOfCode ); var targetInfo = typeof( Action ) .GetField( "_target", BindingFlags.NonPublic | BindingFlags.Instance ); targetInfo.SetValue( action, fakeDelegate ); action( ); // Greetings from generated code! Console.WriteLine( "Greetings from managed code!" ); handle.Free( ); } } }
执行结果是:(再次提醒:在Vista或者Windows 7上运行会遇到AccessViolationException)
Greetings from managed code!
Good!成功的让CLR执行了一段我们指定的native code,在标准输出流上显示了"Greetings from generated code!\n",而且没有显式使用P/Invoke或者unsafe code。为了演示从native code返回后CLR仍在正常运行,所以通过Console.WriteLine()再输出了一行"Greetings from managed code!"。
前文基本上已经把代码的原理解释得差不多了(吧?),所以这边就不再详细解释。
fakeDelegate数组里的native code/string那段可能不太直观,其实那就是前面给出的x86机器码以及"Greetings from generated code!\n"。需要注意的是因为x86的字节序(endian)是little-endian,低位字节在前;而本例中用的数组元素类型是uint,是4字节的整型,所以以4字节为单位,其中的顺序是“反”的。
就以第一个数字0x6AEC8B55为例,它在内存中是0x55 0x8B 0xEC 0x6A这4个字节,其中头3个字节就是这两条指令:
- 55 push ebp
- 8BEC mov ebp,esp
55 push ebp 8BEC mov ebp,esp
这样应该就好理解了吧?
===========================================================================
回顾标题,“要让CLR挂掉的话”,上面的例子都还没让CLR挂掉,似乎有点不够意思。其实真要让CLR连最后的防护措施都挂掉、连异常都抓不到,那还挺难的。但我们可以很轻松的做出些例子,观察一下平时难得一见的异常。
(在家实验的同学们千万注意了:要自行尝试引发错误的话,一定要小心,不要在有重要资料的系统上试。任意篡改代码或者栈上/堆上的数据,实际会引发什么后果很难预料。发生什么糟糕后果责任要自己承担的哦~)
如果构造这样的一段代码:
- 83C4 08 add esp,8
- C3 ret
83C4 08 add esp,8 C3 ret
把它放到上面的C#例子里:
- using System;
- using System.Reflection;
- using System.Runtime.InteropServices;
- namespace TestCLR2Crash {
- static void Main( string[ ] args ) {
- // declare a delegate that refers to a static method,
- // in this case it's a static method generated from the
- // anonymous delegate.
- Action action = delegate( ) { };
- // "generate" code into an array of uint
- var fakeDelegate = new uint[ ] {
- // dummy values
- 0x00000000, 0x00000000,
- // fake _methodPtrAux
- 0x00000000,
- // native code
- 0xC308C483
- };
- // fill in the fake _methodPtrAux,
- // make it point to the code region in fakeDelegate
- var handle = GCHandle.Alloc( fakeDelegate, GCHandleType.Pinned );
- var addr = handle.AddrOfPinnedObject( );
- const int sizeOfUInt32 = sizeof( uint ); // 4
- const int indexOfCode = 3;
- fakeDelegate[ 2 ] = Convert.ToUInt32( addr.ToInt32( ) + sizeOfUInt32 * indexOfCode );
- var targetInfo = typeof( Action )
- .GetField( "_target", BindingFlags.NonPublic | BindingFlags.Instance );
- targetInfo.SetValue( action, fakeDelegate );
- action( );
- handle.Free( );
- }
- }
- }
using System; using System.Reflection; using System.Runtime.InteropServices; namespace TestCLR2Crash { static void Main( string[ ] args ) { // declare a delegate that refers to a static method, // in this case it's a static method generated from the // anonymous delegate. Action action = delegate( ) { }; // "generate" code into an array of uint var fakeDelegate = new uint[ ] { // dummy values 0x00000000, 0x00000000, // fake _methodPtrAux 0x00000000, // native code 0xC308C483 }; // fill in the fake _methodPtrAux, // make it point to the code region in fakeDelegate var handle = GCHandle.Alloc( fakeDelegate, GCHandleType.Pinned ); var addr = handle.AddrOfPinnedObject( ); const int sizeOfUInt32 = sizeof( uint ); // 4 const int indexOfCode = 3; fakeDelegate[ 2 ] = Convert.ToUInt32( addr.ToInt32( ) + sizeOfUInt32 * indexOfCode ); var targetInfo = typeof( Action ) .GetField( "_target", BindingFlags.NonPublic | BindingFlags.Instance ); targetInfo.SetValue( action, fakeDelegate ); action( ); handle.Free( ); } } }
执行,我们会看到什么呢?
把构造的代码改为
- 83C4 18 add esp,18h
- C3 ret
83C4 18 add esp,18h C3 ret
(也就是native code那段的数字是0xC318C483)
执行结果是:
stack trace是:
mscorwks.dll!_CallDescrWorker@20() + 0x33 bytes
mscorwks.dll!_CallDescrWorkerWithHandler@24() + 0x9f bytes
mscorwks.dll!MethodDesc::CallDescr() + 0x15a bytes
mscorwks.dll!MethodDesc::CallTargetWorker() + 0x1f bytes
mscorwks.dll!MethodDescCallSite::CallWithValueTypes() + 0x1a bytes
mscorwks.dll!ClassLoader::RunMain() - 0x39028 bytes
mscorwks.dll!Assembly::ExecuteMainMethod() + 0xa4 bytes
mscorwks.dll!SystemDomain::ExecuteMainMethod() + 0x416 bytes
mscorwks.dll!ExecuteEXE() + 0x49 bytes
mscorwks.dll!__CorExeMain@0() + 0x98 bytes
mscoree.dll!__CorExeMain@0() + 0x34 bytes
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes
EIP停下的位置是:
- 0012F4F9 F4 hlt
0012F4F9 F4 hlt
这个地址是Windows上很典型的栈地址。EIP居然跑到这个地方来,把数据当成指令执行了一句“HLT”指令……
HLT是一个Ring 0指令,用户模式的应用程序没办法是用这条指令,所以试图执行它引发了错误。
SEHException这种泛泛的异常少见吧?成功的搞出了一个没有映射到有具体含义的CLR异常,呵呵 ^ ^
P.S. 这帖告诉我们,类型安全的真面目就是:一旦你开始玩裸指针、玩union、玩goto,啥类型安全都是浮云……
P.P.S. 查了文档,Silverlight 3里的GCHandle.Alloc和GCHandle.AddrOfPinnedObject果然是SecurityCritical的,从用户代码里无法调用它。然而Type.GetMethod和Type.GetField之类还是Transparent的,还是有搞头——至少在Moonlight上 XD
P.P.P.S. 呜,但是FieldInfo.SetValue只能用来设置可访问的域的值……又没搞头了