自2007年3月开始研究IDA以来，已3年有余！自认为对idc脚本比较熟悉，最大的成果就是重写老外的vb.idc为vb.c。期间还有其它大大小小的脚本。虽如此，仍感力不从心，idc脚本难以构建中大型应用（vb.c有2100多行）。
正如2005年我犹豫是否应该选择Java等高级语言以构建中大型应用，此时也在犹豫是否应该利用C++等高级语言编写IDA插件。
老外的一篇关于使用VB和C#编写IDA插件的文章点醒了我，除了C++，我们还有很多的选择。那时候开始，我选择了C#来做IDA插件，直到今天。
且不论使用C#来做IDA插件是否会成功，这研究的3年里，我得到了非常非常多的东西！
老外的思路是VB和C#做成COM，然后用C++包装，Easy，很容易做好一个插件。但是需要暴露IDA的接口给插件使用的时候，才发现那是一个登月工程。并且C#做成的COM，部署和调试都不方便。
后来向微软的大牛请教，得知一个新的方法，利用C++加载.Net运行时，从而启动C#插件。这下子漂亮多了，但是仍然解决不了暴露接口的问题。IDA的接口很多，大多数都是用不上的，其实只要实现了IDC中的几十个函数即可，于是我开始了登月工程，手工包装暴露接口，历时两年！
直到上个月，例行工作的时候，一时冲动，把包装项目改成CLR来编译，IDA居然还认！！！这可是巨大的发现，这意味着：可以直接使用C++/CLI实现IDA插件！
同时，看到网上更新了IDAPython，忍不住研究一下，看看它是如何实现的。原来它是通过SWIG做的包装，基本做到自动化。还发现，IDA接口本身就提供了对SWIG的支持。SWIG的资料不多，我想借助它来包装C#版本的时候，总是失败。想想算了，三年都过来了，也不在乎这一回，继续手工包装。因为是使用C++/CLI，工作量就大大减少了，同时有IDAPython在那里作为参考，找起接口函数来非常方便。
期间，还有一些小插曲，C++/CLI调用C#没有问题，C#调用C++/CLI编写的插件的时候就有问题了。原来C#类库项目引用C++/CLI项目失败，因为它的输出是plw，vs直接阻止。只好改名dll后调用。在使用的时候，还得用上dll的这一份拷贝，并且要放在IDA根目录才行。
一些额外的收获：
1，C#可以直接操作汇编（是Native Asm，不是IL）。通过委托，可以随意调用PE里面的任意函数，不管它共有私有，因为这个调用是汇编指令级的。
2，学习了.Net的核心机制，知道它是怎么工作的。
3，C#也可以给Native下钩子，结合第一点，就是爱怎么整就怎么整。
4，基本上，C++的开源项目，使用CLR编译后，都有办法供C#使用。
5，意志的磨练……
回到正题！
这是一个IDA插件，名为IDACSharp，同时又是C#插件管理器，它的作用就是充当IDA和C#的桥梁（双向）。
一共四个文件：
1，IDACSharp.plw是主插件，同时也是包装器，已经把常用的接口包装为.Net接口，该文件应该放在Plugins目录；
2，IDACSharp.dll跟IDACSharp.plw就是同一个东西，只是后缀不同而已，该文件应该放在IDA根目录；
3，CSharpLoader.dll是C#编写的插件管理器，放在CSharp目录下，IDACSharp.plw会找到并加载它；
4，IDATest.dll是C#编写的插件例子，列出当前IDA数据库前30个函数，双击跳转到函数所在位置，也是放在CSharp目录下。
IDACSharp尚未完工，CSharpLoader的插件管理还没有做，这块问题不大，重要的是，所包装的接口，绝大部分都还没有测试过，并且还有一些没有包装完成，打算在后面逐步完善！
大石头
nnhy(at)vip.qq.com
QQ群1600800
2010-05-06 03:19
试用地址：
https://files.cnblogs.com/nnhy/%e5%8f%91%e5%b8%83_20100506032141.rar