临近国庆了,要抢火车票了,但是发现"12306分流"抢票软件是基于.NET4.0开发的,要求安装.NET4.0.
Windows XP集成了.NET2.0版本
Windows 7集成了.NET3.5版本
Windows 8集成了.NET4.0版本
由于目前使用的是Windows 7,没有.NET4.0环境.当然安装是没问题的.
但是作为一个系统技术爱好者,总是想研究一下与众不同的方案??? 有没有可能免安装.NET4.0环境?
百度找到一些陈旧的资料, 说明跟我有一样需求的人还是存在的.
方案一:使用MONO
MONO是为了让.NET程序跨平台的产物,支持Windows系统
软件下载地址: https://www.mono-project.com/download/stable
经过一番研究,并没有成功运行我的程序.
估计是需要用它的SDK重新编译程序,才能跨平台运行吧.
方案二:使用飞信.NET虚拟机
老版本的飞信软件,基于.NET开发,使用了定制版RemoteSoft DotNET Linker工具.
下载后发现它可以运行大部分.NET2.0版本的程序.
运行方法是FetionVM.exe your.exe
但是不能运行.NET4.0的程序.
由于它的核心方案是利用RemoteSoft DotNET Linker,所以我去找原版工具研究下.
方案三:RemoteSoft DotNET Linker
这个软件是商业性质软件,不过我觉得吧,除了像我这种crazy爱好者,应该没有什么企业会考虑这个方案吧.
目前早已经停止更新了,官网也下线了,网上能找到的最新版本是2.1.0破解版.
这个工具包目的就是把你的.NET程序打包为绿色版,它会自动收集所需的文件,并生成一个文件夹.
所以今天的重点就是研究RemoteSoft DotNET Linker能不能实现运行基于.NET4.0的程序.
文件夹结构如下图:
经过研究,飞信里面的FetionVM.exe其实就是mini.exe.
飞信里面的rsdeploy.dll版本号是1.0.6
这里下载的rsdeploy.dll版本号是2.1.0,这个版本可能要新一些?
尝试打包一个小工具后,发现要打包的目标程序会被命名为mini.rsm文件.由mini.exe进行启动.
还会生成一个文件夹结构,与飞信非常类似.
飞信的FetionVM.exe也是加载FetionVM.rsm,这个FetionVM.rsm就是一个空的.NET引导程序.
它会运行命令行参数指定的程序.经过实验验证这种方案兼容性要差一些.
兼容性最好的办法是直接把要运行的程序改为为mini.rsm,由mini.exe直接运行.成功率高很多.
由于它们提供的.NET版本都是2.0.50727,为了研究它能不能支持.NET4.0的程序.
对工具包的文件结构进行了分析,经过分析这套工具的原理大概是类似于IO重定向,
运行.NET程序时需要访问的注册表和文件都重定向到本地目录.
mdeploy.registry这个文件就是重定向的虚拟注册表.
另外还有一个叫c的文件夹,里面装的是windows\assemly.这就是重定向的虚拟系统盘路径.
基于这个原理,我猜测理论上应该是可以支持任意版本的.NET程序的!
毕竟Windows系统的核心内容不就是注册表和文件组成的吗?..............................
为了证明这个猜测,我从装好.NET4.0的虚拟机里面提取出.NET4.0相关的所有文件,以及注册表.
把注册表中HKLM\SOFTWARE的内容导出到mdeploy.registry
把虚拟机C:\Windows\Microsoft.NET\Framework下面的v4.0.30319全部复制到本地文件夹.
把虚拟机C:\Windows\assemly下面的文件全部复制到本地文件夹.
把bypass.exe改名为mini.rsm运行mini.exe测试一下.
报错!.......
报错!.......
报错!.......
这个时候轮到procmon上场了,跟踪一下是缺少哪个文件?
唔,发现一个问题,它要加载c\windows\assembly\GAC_MSIL\System\4.0.0.0__b77a5c561934e089
而实际上在安装好.NET4的Windows7系统中并没有这个文件.
搜索了一下,发现微软真是奇葩,竟然把.NET4的GAC文件移到了C:\Windows\Microsoft.NET\assembly文件夹.
而C:\Windows\assembly下面只有.NET2.0的GAC文件!!!
把这些缺失的文件拷贝到本地目录,再次测试.....
还是报错!.......
还是报错!.......
还是报错!.......
唔,发现一个问题,mini.exe运行时加载的程序集名称是:4.0.0.0__b77a5c561934e089
但是微软的命名又改了,变成了:v4.0_4.0.0.0__b77a5c561934e089
多了一个v4.0_的前缀,真是日了MS了!!!!
原本.NET2.0版本的命名都是规范的2.0.0.0__b77a5c561934e089
为什么到了.NET4.0要把名改为了v4.0_4.0.0.0__b77a5c561934e089???
加个v4.0的前缀是几个意思???难道4.0.0.0还不能表示版本号吗???
这次把所有带v4.0前缀的文件夹,全都改名.再次测试.....
还是报错!.......
还是报错!.......
还是报错!.......
唔,发现一个问题,缺少msvcr100_clr400.dll
少文件都好说,添加进来就是了..再次测试...
啊! 真的运行起来了!虽然启动慢了点,但是成功了!
分流会提示我软件名不能修改,要改为bypass.exe才行.
改名后,又发现版本要更新....
更新后,又发现文件被它替换了.
真正的bypass.exe被我改名为bypass.rsm了.
而现在的bypass.exe是我的加载器,结果被它自动更新程序替换成了真正的bypass.exe.
又得重新改名字..................
每次运行程序都要把目标程序改名为mini.rsm文件.虽然麻烦了点.
但是RemoteSoft DotNET Linker真是个好东西!
开发出这样的软件是个有想法的人!
这套工具的兼容性还不错,我试了好几个程序,都能正常运行.
目前添加的文件和注册表内容有点多, 还有待精简,..................
还有就是要修改一下mini.exe的程序逻辑,让它可以加载任意程序文件就好了................
最后把工具包的最小系统(不含任何.NET文件)上传上来,做个存档以后备用:
下载地址:https://download.csdn.net/download/qq446252221/11672183