1. 如何防止foxpro的exe文件被反编译
foxpro的编译是一种伪编译,在编译的exe文件中仍是以某种形式的字节码保存的,运行时其实仍然是在解释执行。所以用它开发的软件易被反编译。
克服的办法--换用真编译的开发工具,再加上反跟踪、加壳等等。
2. 如何防止程序员反编译
java从诞生以来,其基因就是开放精神,也正因此,其可以得到广泛爱好者的支持和奉献,最终很快发展壮大,以至于有今天之风光!但随着java的应用领域越来越广,特别是一些功能要发布到终端用户手中(如Android开发的app),有时候,公司为了商业技术的保密考虑,不希望这里面的一些核心代码能够被人破解(破解之后,甚至可以被简单改改就发布出去,说严重点,就可能会扰乱公司的正常软件的市场行为),这时候就要求这些java代码不能够被反编译。
这里要先说一下反编译的现象。因为java一直秉持着开放共享的理念,所以大家也都知道,我们一般共享一个自己写的jar包时,同时会共享一个对应的source包。但这些依然与反编译没有什么关系,但java的共享理念,不只是建议我们这样做,而且它自己也在底层上“强迫”我们这么做!在java写的.java文件后,使用javac编译成class文件,在编译的过程,不像C/C++或C#那样编译时进行加密或混淆,它是直接对其进行符号化、标记化的编译处理,于是,也产生了一个逆向工程的问题:可以根据class文件反向解析成原来的java文件!这就是反编译的由来。
但很多时候,有些公司出于如上述的原因考虑时,真的不希望自己写的代码被别人反编译,尤其是那些收费的app或桌面软件(甚至还有一些j2ee的wen项目)!这时候,防止反编译就成了必然!但前面也说过了,因为开放理念的原因,class是可以被反编译的,那现在有这样的需求之后,有哪些方式可以做到防止反编译呢?经过研究java源代码并进行了一些技术实现(结果发现,以前都有人想到过,所以在对应章节的时候,我会贴出一些写得比较细的文章,而我就简单阐述一下,也算偷个懒吧),我总共整理出以下这几种方式:
代码混淆
这种方式的做法正如其名,是把代码打乱,并掺入一些随机或特殊的字符,让代码的可读性大大降低,“曲线救国”似的达到所谓的加密。其实,其本质就是打乱代码的顺序、将各类符号(如类名、方法名、属性名)进行随机或乱命名,使其无意义,让人读代码时很累,进而让人乍一看,以为这些代码是加过密的!
由其实现方式上可知,其实现原理只是扰乱正常的代码可读性,并不是真正的加密,如果一个人的耐心很好,依然可以理出整个程序在做什么,更何况,一个应用中,其核心代码才是人们想去了解的,所以大大缩小了代码阅读的范围!
当然,这种方式的存在,而且还比较流行,其原因在于,基本能防范一些技术人员进行反编译(比如说我,让我破解一个混淆的代码,我宁愿自己重写一个了)!而且其实现较为简单,对项目的代码又无开发上的侵入性。目前业界也有较多这类工具,有商用的,也有免费的,目前比较流行的免费的是:proguard(我现象临时用的就是这个)。
上面说了,这种方式其实并不是真正加密代码,其实代码还是能够被人反编译(有人可能说,使用proguard中的optimize选项,可以从字节流层面更改代码,甚至可以让JD这些反编译软件可以无法得到内容。说得有点道理,但有两个问题:1、使用optimize对JDK及环境要求较高,容易造成混淆后的代码无法正常运行;2、这种方式其实还是混淆,JD反编译有点问题,可以有更强悍的工具,矛盾哲学在哪儿都是存在的^_^)。那如何能做到我的class代码无法被人反编译呢?那就需要我们下面的“加密class”!
加密class
在说加密class之前,我们要先了解一些java的基本概念,如:ClassLoader。做java的人已经或者以后会知道,java程序的运行,是类中的逻辑在JVM中运行,而类又是怎么加载到JVM中的呢(JVM内幕之类的,不在本文中阐述,所以点到为止)?答案是:ClassLoader。JVM在启动时是如何初始化整个环境的,有哪些ClassLoader及作用是什么,大家可以自己问度娘,也不在本文中讨论。
让我们从最常见的代码开始,揭开一下ClassLoader的一点点面纱!看下面的代码:
Java代码
publicclassDemo{
publicstaticvoidmain(String[]args){
System.out.println(“helloworld!”);
}
}
上面这段代码,大家都认识。但我要问的是:如果我们使用javac对其进行编译,然后使用java使其运行(为什么不在Eclipse中使用Runas功能呢?因为Eclipse帮我们封闭,从而简化了太多东西,使我们忽略了太多的底层细节,只有从原始的操作上,我们才能看到本质),那么,它是怎么加载到JVM中的?答案是:通过AppClassLoader加载的(相关知识点可以参考:http://hxraid.iteye.com/blog/747625)!如果不相信的话,可以输出一下System.out.println(Thread.currentThrea().getContextLoader());看看。
那又有一个新的问题产生了:ClassLoader又是怎样加载class的呢?其实,AppClassLoader继承自java.lang.ClassLoader类,所以,基本操作都在这个类里面,让我们直接看下面这段核心代码吧:
看到这里,已经没有必要再往下面看了(再往下就是native方法了,这是一个重大伏笔哦),我们要做的手脚就在这里!
手脚怎么做呢?很简单,上面的代码逻辑告诉我们,ClassLoader只是拿到class文件中的内容byte[],然后交给JVM初始化!于是我们的逻辑就简单了:只要在交给JVM时是正确的class文件就行了,在这之前是什么样子无所谓!所以,我们的加密的整个逻辑就是:
在编译代码时(如使用ant或maven),使用插件将代码进行加密(加密方式自己选),将class文件里面的内容读取成byte[],然后进行加密后再写回到class文件(这时候class文件里面的内容不是标准的class,无法被反编译了)
在启动项目代码时,指定使用我们自定义的ClassLoader就行了,而自定义的部分,主要就是在这里做解密工作!
如此,搞定!以上的做法比较完整的阐述,可以仔细阅读一下这篇文章:https://www.ddtsoft.com/#developerworks/cn/java/l-secureclass/文章中的介绍。
通过这个方法貌似可以解决代码反编译的问题了!错!这里有一个巨大的坑!因为我们自定义的ClassLoader是不能加密的,要不然JVM不认识,就全歇菜了!如果我来反编译,呵呵,我只要反编译一下这个自定义的ClassLoader,然后把里面解密后的内容写到指定的文件中保存下来,再把这个加了逻辑的自定义ClassLoader放回去运行,你猜结果会怎样?没错,你会想死!因为你好不容易想出来的加密算法,结果人家根本不需要破解,直接就绕过去了!
现在,让我们总结一下这个方法的优缺点:实现方式简单有效,同时对代码几乎没有侵入性,不影响正常开发与发布。缺点也很明显,就是很容易被人破解!
当然啦,关于缺点问题,你也可以这么干:先对所有代码进行混淆、再进行加密,保证:1、不容易找到我们自定义的那个ClassLoader;2、就算找到了,破解了,代码可读性还是很差,让你看得吐血!(有一篇文章,我觉得写得不错,大家可以看一看:http://www.scjgcj.com/#blog/851544)
嗯,我觉得这个方法很好,我自己也差点被这个想法感动了,但是,作为一个严谨的程序员,我真的不愿意留下一个隐患在这里!所以,我继续思索!
高级加密class
前面我们说过有个伏笔来着,还记得吧?没错,就是那个native!native定义的方法是什么方法?就是我们传说中的JNI调用!前面介绍过的有一篇文章中提到过,其实jvm的真实身份并不是java,而是c++写的jvm.dll(windows版本下),java与dll文件的调用就是通过JNI实现的!于是,我们就可以这样想:JNI可以调用第三方语言的类库,那么,我们可不可以把解密与装载使用第三方语言写(如C++,因为它们生成的库是不好反编译的),这样它可以把解密出来的class内容直接调jvm.dll的加载接口进行初始化成class,再返回给我们的ClassLoader?这样,我们自定义的ClassLoader只要使用JNI调用这个第三方语言写的组件,整个解密过程,都在黑盒中进行,别人就无从破解了!
嗯,这个方法真的很不错的!但也有两个小问题:1.使用第三方语言写,得会第三方语言,我说的会,是指很溜!2.对于不同的操作系统,甚至同一操作系统不同的版本,都可能要有差异化的代码生成对应环境下的组件(如window下是exe,linux是so等)!如果你不在乎这两个问题,我觉得,这个方式真的挺不错的。但对于我来说,我的信条是,越复杂的方式越容易出错!我个人比较崇尚简洁的美,所以,这个方法我不会轻易使用!
对了,如果大家觉得这个方法还算可行的话,可以推荐一个我无意中看到的东西给大家看看(我都没有用过的):jinstall,
更改JVM
看到这个标题,我想你可能会震惊。是的,你没看错,做为一个程序员,是应该要具有怀疑一切、敢想敢做的信念。如果你有意留心的话,你会发现JVM版本在业界其实也有好几个版本的,如:Sun公司的、IBM的、Apache的、Google的……
所以,不要阻碍自己的想象力,现在没有这个能力,并不代表不可能。所以,我想到,如果我把jvm改了,在里面对加载的类进行解密,那不就可以了吗?我在设计构思过程中,突然发现:人老了就是容易糊涂!前面使用第三方语言实现解密的两个问题,正好也是更改JVM要面对的两个问题,而且还有一个更大的问题:这个JVM就得跟着这个项目到处走啊!
3. C#如何防止被别人反编译
C#
编写的代码通过VS编译器生成
dll
或
exe
,很容易被一些反编译工具查看到源码或对源码进行修改。
为防止代码被反编译或被篡改,我们可以进行一定的防范措施。但不能杜绝,因为DotNet编写代码运行必须编译成IL
中间语言,IL是很规则,同时也很好反编译。
反编译防范措施:
设置项目代码反汇编属性
混淆
方法一:防止
Ildasm.exe(MSIL
反汇编程序)
反汇编程序集
方法很简单在项目文件AssemblyInfo.cs中增加SuppressIldasm属性。
当项目中增加SuppressIldasm属性后在使用ildasm.exe反编译代码,会提示:"受保护的模块
--
无法进行反汇编"
ildasm.exe
读取项目中包含
SuppressIldasm
属性就不对此程序集进行反编译。但ILSyp,Reflector等反编译工具针对程序集设置SuppressIldasm属性置之不理,一样可以反编译源码。
缺点:
可见SuppressIldasm
属性只针对ildasm.exe工具起效果,同时也能删除ildasm.exe工具的此项限制。参考:《去掉ILDasm的SuppressIldasmAttribute限制》
方法二:混淆
混淆原理:将VS编译出的文件(exe
或
dll)通过ildasm对文件进行重命名,字符串加密,移动等方式将原始代码打乱。这种方式比较常见。
VS2013
自带混淆工具:工具-->PreEmptive
Dotfuscator
and
Analytics
但VS2013自带Dotfuscator
5.5
需购买激活才能使用全部功能。目前网络提供
DotfuscatorPro
4.9
破解版版本下载。
打开
DotfuscatorPro
4.9
主界面
Settings->Global
Options
全局配置
常用功能配置:Disable
String
Encryption=NO
启用字符串加密
选择需混淆C#编译代码(dll
或
exe)
其中Library不要勾选,否则有些类、变量等等不会混淆;
Rename
重命名配置
常用功能配置:
勾选
=
use
enhanced
overload
inction
使用增强模式
重命名方案
Renaming
Scheme
=
Unprintable
(不可打印字符,即乱码),也可以选择其他如小写字母、大写字符、数字的方式。
String
Encryption
字符串加密
勾选需要加密字符串文件(exe
或
dll)
可根据各自需求可进行其他相关配置。(如:control
flow,Output,Setting
->Build
Settings,Settings
-->
Project
Properties等)
最后生成混淆文件
Build
Project。
Build
Project
生成混淆项目错误:
Could
not
find
a
compatible
version
of
ildasm
to
run
on
assembly
C:Users***.exe.??This
assembly
was
originally
built
with
.NET
Framework
v4.0.30319.
Build
Error.
处理方法:
ILASM_v4.0.30319
=
C:WindowsMicrosoft.NETFrameworkv4.0.30319ilasm.exe
ILDASM_v4.0.30319
=
C:Program
Files
(x86)Microsoft
SDKsWindowsv8.1AinNETFX
4.5.1
Toolsildasm.exe
[安装VS版本不同对应目录会有所变化]
混淆代码对比
未使用混淆工具,反编译出的源码:
使用混淆工具,反编译出的源码:
效果很明显,很难看出反编译代码所写的真正逻辑。
缺点:
C#代码通过混淆工具生成后,增加了很多转换过程。这使得反编译工具无法很直观看到源码真正逻辑。但源码代码过多转换会使软件本身运行效率降低,甚至会出现报错情况。
4. unity exe 怎么防止反编译
加入加密技术或者进行代码混淆。
5. c#防止反编译,如何将exe文件做成资源文件(加壳)
1.新建一个项目(所谓的壳)。命名为Test
2.将要加壳的程序test.exe文件做成资源文件防在Test文件中。
打开新建的项目Test,双击最右侧的Solution
Explorer的第一个按钮Properties。
会出现这个画面
然后点击Resourse-AddResource-添加现有资源,就将你要添加的test.exe添加进去,然后再solution
Explorer中会生成一个文件夹
Resource你的test文件就在那里面,然后右键test.exe的属性将他改为嵌入的资源即(Embedded
Resource),然后就搞定了。
3.之后将新建的项目Form1删除,
将Programma.cs打开替换成以下代码
[STAThread]
static
void
Main(string[]
args){
String
projectName
=
Assembly.GetExecutingAssembly().GetName().Name.ToString();
Stream
stream
=
Assembly.GetExecutingAssembly().GetManifestResourceStrea
m(projectName
+
".Resources"
+
".test.exe");
byte[]
bs
=
new
byte[stream.Length];
stream.Read(bs,
0,
(int)stream.Length);
Assembly
asm
=
Assembly.Load(bs);
MethodInfo
info
=
asm.EntryPoint;
ParameterInfo[]
parameters
=
info.GetParameters();
if
((parameters
!=
null)
&&
(parameters.Length0))
info.Invoke(null,
(object[])args);else
info.Invoke(null,
null);}大功告成了。
新生成的test.exe会打开你导入的exe文件,这样当别人用反编译软件的时候,他只是显示你新建的项目中的Programma。cs中的代码。
6. VC2008 编译的.exe程序,能被反编译破解码如何防止破解
其他语言我不知道,但是C++程序的话是很容易破解的,用ida pro可以反编译生成代码,这样就可以看到你用了什么语句来检验注册码
温柔一点破解的话可以这样做出注册机,如果暴力一点直接可以修改代码,随便输入一个注册码都通过
但是生成的代码并不完全是开发时候的代码,而是损失了一定的信息的,比如不能分辨是不是指针,至于防止,我只能说尽量让语句复杂一点,来增加破解的工作量,但是不要想有什么方法可以无法破解
7. C#怎样防止反编译
我使用的方法是利用加壳工具:virboxProtectorStandalone。直接进行加壳。高级混淆、虚拟化代码、智能压缩等加密策略。如果要授权控制,可使用许可版本的virboxProtector。
未经加壳保护的 ILspy 反编译效果如下:
public int add(int a, int b){
return a + b;}public int div(int a, int b){
return a / b;}public int mul(int a, int b){
return a * b;}public int sub(int a, int b){
return a - b;}
解决方案:
深思自主研发了为 C# .net 语言做保护的外壳(Virbox Protector)。将C# .net 编译成的执行程序(.exe),动态库(.dll)直接拖入加壳工具即可完成保护操作,十分方便。并且在效果上已经完全看不到源码中的逻辑。
加密后的效果
public int add(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16416u, 21, 16384u, 32u, 31516u, 5).Invoke(this, new object[]
{
this,
a,
b
});}
public int div(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16956u, 21, 16924u, 32u, 31516u, 2).Invoke(this, new object[]
{
this,
a,
b
});}
public int mul(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16776u, 21, 16744u, 32u, 31516u, 3).Invoke(this, new object[]
{
this,
a,
b
});}
public int sub(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16596u, 21, 16564u, 32u, 31516u, 4).Invoke(this, new object[]
{
this,
a,
b
});}
架构支持
IIS 服务架构的后台逻辑 DLL 文件
windows PC 应用程序 EXE 文件
windows PC 应用程序动态库 DLL 文件
UG等第三方绘图工具使用的 DLL 文件
Unity3d 编译使用的 DLL 文件
8. 如何防VB的EXE文件被反编译
VB是直接编译成机器代码的,基本不用顾虑被他人反编译的问题。
如果你说的是VB.NET,那么它是被编译成中间语言的,则可以使用VS提供的一个混淆器阻止他人反编译。
9. python exe如何防止反编译
Python 编译生成 pyc 仅仅为了提升加载速度,并不是为了防止破解,反编译后和原来一模一样。pyinstaller,py2exe,只是把 pyc 打个包,同样很弱。代码混淆也只能增加看懂代码的难度,但并不能防止破解。所以最为稳妥的办法只有修改Python解释器,对源代码进行加密,解释器加载源代码时再解密,这种方法虽然可以防止破解,但给自己带来麻烦不说,发布程序是需要打包自己修改后的解释器,相当麻烦。