有哪些防止反编译 Java 类库 jar 文件的办法？android app怎么防止反编译

本文目录

• 有哪些防止反编译 Java 类库 jar 文件的办法
• android app怎么防止反编译
• python如何防止反编译
• 如何对编译的dll文件进行加密来防止反编译
• Android APP的破解技术有哪些如何防止反编译
• 如何防止程序员反编译
• 如何防止JAVA程序源代码被反编译
• 如何防止C++或C#程序被反编译
• 怎么让android studio的编译的aar防止反编译
• 如何禁止android默认编译选项

有哪些防止反编译 Java 类库 jar 文件的办法

java本就是开源的，你加密感觉怪怪的。想防止反编译，最简单的方法就是你可以向Jar注入无效代码。比如建一个类，建一个没有意义的方法private class Invalid{ }，然后输出为jar。用解压缩软件打开这个jar，以文本方式找到那个类的class，然后将那个方法名的一个字母删掉，然后更新入压缩文件中。用jd-gui反编译提示错误。这种方式不能用于android中。还有种方法就是混淆代码，加密class和高级加密class，方式比较复杂，可以自行百度。

android app怎么防止反编译

APK在PC上面就被看作一个压缩格式文件，在手机上面它就算一个可执行格式文件。两种格式对它的读取要求也有区别，所以说利用这个区别来实现伪加密。对PC端来讲伪加密的APK没法被解包无法被反编译，但是对android系统来说它完全不会影响正常的安装运行(对4.2以前的系统)。伪加密的原理：读取APK的字节，找到连续4位字节标记为”P K 01 02”的后第5位字节，如果是0表示不加密，如果是1就表示加密（伪加密就强行改成1 反伪加密就是把1改成0就可以了）。2伪加密前和伪加密后的对比图如下：伪加密前：3伪加密后： END使用第三方平台加密步骤如下：登录/注册→上传APK→等待系统加密→完成后下载APK→给APK签名→完成！2爱加密作为移动安全行业的第三方平台，为Android APP移动应用提供专业的加固保护方案，包括DEX文件保护、资源文件保护、XML主配文件保护、防二次打包保护、so文件保护、内存保护、高级混淆等，全方位保护Android App，防止被反编译、破解等，维护广大开发者朋友的切身利益！

python如何防止反编译

Python 编译生成 pyc 仅仅为了提升加载速度，并不是为了防止破解，反编译后和原来一模一样。pyinstaller，py2exe，只是把 pyc 打个包，同样很弱。代码混淆也只能增加看懂代码的难度，但并不能防止破解。所以最为稳妥的办法只有修改Python解释器，对源代码进行加密，解释器加载源代码时再解密，这种方法虽然可以防止破解，但给自己带来麻烦不说，发布程序是需要打包自己修改后的解释器，相当麻烦。

如何对编译的dll文件进行加密来防止反编译

为防止这类反向工程的威胁，最有效的办法是模糊。模糊工具运用各种手段达到这一目标，但主要的途径是让变量名字不再具有指示其作用的能力、加密字符串和文字、插入各种欺骗指令使反编译得到的代码不可再编译。例子：对未经模糊处理的代码执行反向工程：PrivateSubCalcPayroll(ByValemployeeGroupAsSpecialList)WhileemployeeGroup.HasMoreemployee=employeeGroup.GetNext(True)employee.updateSalaryDistributeCheck(employee)EndWhileEndSub同样的代码，经过模糊处理再执行反向工程：PrivateSuba(ByValbAsa)Whileb.aa=b.a(True)a.aa(a)EndWhileEndSub显然，两段代码的处理逻辑相同。但是，要说清楚第二段代码到底在做些什么极其困难，甚至要判断它正在访问哪些方法、哪些变量也很困难。　　这种改变变量名称的功能是可配置的，例如，假设正在构造一个DLL，可以要求不改动API，有趣的是，这一处理过程显然只是简单地把大量变量的名称简缩成单个字符，但获得了非常好的模糊效果。

Android APP的破解技术有哪些如何防止反编译

AndroidAPP破解主要依靠利用现有的各种工具，如下：1)APKtool2)dex2jar3)jd-gui4)签名工具防止反编译，介绍一种有效对抗native层代码分析的方法——代码混淆技术。代码混淆的学术定义如下：代码混淆（codeobfuscation）是指将计算机程序的代码，转换成一种功能上等价，所谓功能上的等价是指其在变换前后功能相同或相近。其解释如下：程序P经过混淆变换为P‘，若P没有结束或错误结束，那么P’也不能结束或错误结束；而且P‘程序的结果应与程序P具有相同的输出。否则P’不是P的有效的混淆。目前对于混淆的分类，普遍是以Collberg的理论为基础，分为布局混淆（layoutobfuscation）、数据混淆（dataobfuscation）、控制混淆（controlobfuscation）和预防混淆（preventiveobfuscation）这四种类型。腾讯御安全保护方案提供了以上所述四种混淆分类的多维度的保护，布局混淆方面，御安全提供了针对native代码层中的函数名进行了混淆删除调试信息等功能；数据混淆方面，御安全提供了针对常量字符串加密及全局变量的混淆的功能；控制混淆方面，御安全针对代码流程上，提供了扁平化，插入bogus分支以及代码等价变换等功能；预防混淆方面，御安全在混淆过程中加入了针对主流反编译器的预防混淆的代码，能够有效地抵抗其分析。御安全还对应用开发者提供不同等级的保护力度及多种混淆方式的功能的选择，用户可以根据自己的需求定制不同的混淆功能保护。同时，御安全保护方案除了提供代码混淆保护方面的技术，还提供代码虚拟化技术及反逆向、反调试等其他安全保护方案，综合使用多种保护方案可以有效地提高代码安全。

如何防止程序员反编译

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代码  

• public class Demo{  

• public static void main(String args){  

• System.out.println(“hello world!”);  

• }  

• }  

***隐藏网址***

那又有一个新的问题产生了：ClassLoader又是怎样加载class的呢？其实，AppClassLoader继承自java.lang.ClassLoader类，所以，基本操作都在这个类里面，让我们直接看下面这段核心代码吧：

看看这个方法中的逻辑，非常简单，先从内存中找，如果没有，则从父级或根先找，如果没找到，则再从自己的方法里面找！那findClass里面是什么样的呢？很不幸，这个方法是个抽象（abstract）的，也就是使用什么方式加载，由程序使用ClassLoader自己决定！这就给我们留下了巨大的“”！让我们看一下非常常见的一个ClassLoader的实现，那就是URLClassLoader（几乎所有的j2ee的web项目的容器使用的ClassLoader都是继承自它），让我们看一下它的findClass的实现：

这个方法里面的逻辑也很简单，从定义的ucp（就是各个jar包或class文件的具体路径）中读取指定的class文件的信息（如字节流之类），然后交给defineClass定义到JVM中，让我们继续看一下这个方法的核心部分：

看到这里，已经没有必要再往下面看了（再往下就是native方法了，这是一个重大伏笔哦），我们要做的手脚就在这里！

手脚怎么做呢？很简单，上面的代码逻辑告诉我们，ClassLoader只是拿到class文件中的内容byte，然后交给JVM初始化！于是我们的逻辑就简单了：只要在交给JVM时是正确的class文件就行了，在这之前是什么样子无所谓！所以，我们的加密的整个逻辑就是：

• 在编译代码时（如使用ant或maven），使用插件将代码进行加密（加密方式自己选），将class文件里面的内容读取成byte，然后进行加密后再写回到class文件（这时候class文件里面的内容不是标准的class，无法被反编译了）

• 在启动项目代码时，指定使用我们自定义的ClassLoader就行了，而自定义的部分，主要就是在这里做解密工作！

***隐藏网址***

通过这个方法貌似可以解决代码反编译的问题了！错！这里有一个巨大的坑！因为我们自定义的ClassLoader是不能加密的，要不然JVM不认识，就全歇菜了！如果我来反编译，呵呵，我只要反编译一下这个自定义的ClassLoader，然后把里面解密后的内容写到指定的文件中保存下来，再把这个加了逻辑的自定义ClassLoader放回去运行，你猜结果会怎样？没错，你会想死！因为你好不容易想出来的加密算法，结果人家根本不需要破解，直接就绕过去了！

现在，让我们总结一下这个方法的优缺点：实现方式简单有效，同时对代码几乎没有侵入性，不影响正常开发与发布。缺点也很明显，就是很容易被人破解！

***隐藏网址***

嗯，我觉得这个方法很好，我自己也差点被这个想法感动了，但是，作为一个严谨的程序员，我真的不愿意留下一个隐患在这里！所以，我继续思索！

高级加密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就得跟着这个项目到处走啊！

如何防止JAVA程序源代码被反编译

我们都知道JAVA是一种解析型语言，这就决定JAVA文件编译后不是机器码，而是一个字节码文件，也就是CLASS文件。而这样的文件是存在规律的，经过反编译工具是可以还原回来的。例如Decafe、FrontEnd，YingJAD和Jode等等软件。下面是《Nokia中Short数组转换算法》类中Main函数的ByteCode：0 ldc #162 invokestatic #185 astore_16 return其源代码是：short pixels = parseImage("/ef1s.png");我们通过反编译工具是可以还原出以上源代码的。而通过简单的分析，我们也能自己写出源代码的。第一行：ldc #16ldc为虚拟机的指令，作用是：压入常量池的项，形式如下ldc index这个index就是上面的16，也就是在常量池中的有效索引，当我们去看常量池的时候，我们就会找到index为16的值为String_info，里面存了/ef1s.png.所以这行的意思就是把/ef1s.pn作为一个String存在常量池中，其有效索引为16。第二行：2 invokestatic #18invokestatic为虚拟机指令，作用是：调用类（static）方法，形式如下invokestatic indexbyte1 indexbyte2其中indexbyte1和indexbyte2必须是在常量池中的有效索引，而是指向的类型必须有Methodref标记，对类名,方法名和方法的描述符的引用。所以当我们看常量池中索引为18的地方，我们就会得到以下信息：Class Name : cp_info#1Name Type : cp_info#191 和19都是常量池中的有效索引，值就是右边《中的值，再往下跟踪我就不多说了，有兴趣的朋友可以去JAVA虚拟机规范。这里我简单介绍一下parseImage(Ljava/lang/String;)[S 的意思。这就是parseImage这个函数的运行，我们反过来看看parseImage的原型就明白了short parseImage(String)那么Ljava/lang/String;就是说需要传入一个String对象，而为什么前面要有一个L呢，这是JAVA虚拟机用来表示这是一个Object。如果是基本类型，这里就不需要有L了。然后返回为short的一维数组，也就是对应的[S。是不是很有意思，S对应着Short类型，而“[”对应一维数组，那有些朋友要问了，两维呢，那就“[[”，呵呵，是不是很有意思。好了，调用了函数，返回的值要保存下来吧。那么就是第三行要做的事情了。

如何防止C++或C#程序被反编译

两者都不能反编译，c++ 变成机器码，反汇编就可以。c# 变成 il 字节码，ildasm 就能看。混肴一下，加个壳什么的比较可行。然而加壳容易被杀毒软件杀掉……混肴下代码就好了吧。比如 google 的 sdk 都混肴成变量名全部看不懂了。

怎么让android studio的编译的aar防止反编译

1、 简述在比较大的 Android 项目的开发中，我们经常会遇到工程、jar 包等等之间相互引用的方式。一般我们通过在 gradle 文件中配置依赖来解决通用配置Gradle 的一些基本依赖配置方式如下：compile fileTree(dir: ’xxx’, include: )：将某个目录下所有符合扩展名的文件作为依赖；compile ’com.xx.xx:ProjectName:Version’：配置Maven` 库作为依赖；在 Maven 库中心 可以搜索自己想用的库进行依赖；compile project(’:AnotherModule’)：配置另一个 Module 作为本 Module 的依赖，被依赖的 Module 必须被导入到当前工程中；compile files(’xxx.jar’)：配置某个 jar 包作为依赖。看起来不错，基本通用的配置都已经存在了。一般对于中等小型的工程，这种开发方式完全没有问题。但是有时候 A 和 B 两个工程，想同时引用另一个公共的 Module C，而这个 Module 可能是一个比较复杂的 Android Module，可能包含了一些主题、UI 、资源文件等等，这时候，如果用 Module 依赖的方式来配置，不免有些困难，因为 A 和 B 都要导入 C，而且要随时关注 C 的更改。好在 Android Studio 提供了 aar 库的打包方式，我们可以把 C 作为 library 进行打包，输出 aar 文件，然后在 A 和 B 中，配置 aar 库依赖，就可以解决。2、aar 文件简介要输出 aar 文件，必须将 Module 配置为 library输出 aar ： apply plugin: ’com.android.library’；输出 apk ：apply plugin: ’com.android.application’。将 Module 配置为 library 后，构建输出一个 aar 文件，根据渠道和 BuildType 的不同，在相应的目录下可以找到。比如对 BuildType 为 debug 的配置，输出为：-debug.aar。一份 aar 文件其实就是一份 zip 包，和 jar 不同的是，它将一些资源文件、第三方库文件、so 文件等等都打包在内，而代码文件编译后压缩在在 classes.jar 中。3、导入 aar 的方式引用这种方式比较简单，打开 Project Structure，添加一个新 Module，然后选择 Import *.JAR or *.AAR Package 的方式导入导入后，在你的工程下面，会生成一个文件夹，里面是 aar 文件以及 Android Studio 的配置文件。接着可以在 gradle 中配置依赖了，其他 Module 可以引用这个 Module 了，依赖方式使用 compile project 的方式即可。缺点：被依赖的 aar 无法 F3 跟进去，无法看到资源文件内容以及目录层级等等缺陷。4、使用配置依赖的方式引用gradle 其实还有另一种依赖可以引用 aar：compile(name: ’xxx’, ext: ’aar’)。首先需要将 aar 文件放入引用 Module 的 libs 目录下，和一般的 jar 文件类似。然后在 gradle 配置文件中把 libs 目录加入依赖：repositories flatDir { dirs ’libs’ }}接着在 gradle 的依赖配置中加入 compile(name: ’xxx’, ext: ’aar’) 这一句，依赖即可关联完毕。构建一下工程，在 Module 的build/intermediates/exploded-aar 目录下，可以看到有一些临时文件生成被导入 aar 生成的临时文件Android Studio 安装反编译插件后，可以通过 F3 跟进到 class 文件里面，如果你有被依赖 Module 的源代码的话，还可以 Attach Source 关联源代码查看。另外，可以很方便的查看 aar 中的资源文件。另外，这种依赖方式更新 aar 后，生成的临时文件也会随之变动，不用担心改动不同步的问题。

如何禁止android默认编译选项

为Android应用开发者，不得不面对一个尴尬的局面，就是自己辛辛苦苦开发的应用可以被别人很轻易的就反编译出来。Google似乎也发现了这个问题，从SDK2.3开始我们可以看到在android-sdk-windows\tools\下面多了一个proguard文件夹proguard是一个java代码混淆的工具，通过proguard，别人即使反编译你的apk包，也只会看到一些让人很难看懂的代码，从而达到保护代码的作用。在工程的"default.properties"中添加这样一句话“proguard.config=proguard.cfg”打包签名后的.apk就是混淆的，其实我们只要做一步就可以了就是在"default.properties"中添加这样一句话“proguard.config=proguard.cfg”就可以了。如果想要更加复杂地混淆代码，可以详细地对该文件进行配置.由于apk是Android虚拟机加载的，它有一定的规范，加密apk后Dalvik无法识别apk了。完全避免是不可能的，总有人能够破解你的代码。但是有几种方式来提高被反编译取代码的难度:1 关键代码使用jni调用本地代码，用c或者c++编写，因此相对比较难于反编译2 混淆java代码。混淆是不改变代码逻辑的情况下，增加无用代码，或者重命名，使反编译后的源代码难于看懂。 网上开源的java代码混淆工具较多，一般是用ant的方式来编译的android 混淆文件proguard.cfg详解:-injars androidtest.jar【jar包所在地址】 -outjars out【输出地址】-libraryjars ’D:\android-sdk-windows\platforms\android-9\android.jar’ 【引用的库的jar，用于解析injars所指定的jar类】 -optimizationpasses 5-dontusemixedcaseclassnames 【混淆时不会产生形形色色的类名 】-dontskipnonpubliclibraryclasses 【指定不去忽略非公共的库类。 】-dontpreverify 【不预校验】-verbose-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* 【优化】-keep public class * extends android.app.Activity　　【不进行混淆保持原样】-keep public class * extends android.app.Application-keep public class * extends android.app.Service-keep public class * extends android.content.BroadcastReceiver-keep public class * extends android.content.ContentProvider-keep public class * extends android.app.backup.BackupAgentHelper-keep public class * extends android.preference.Preference-keep public class com.android.vending.licensing.ILicensingService-keep public abstract interface com.asqw.android.Listener{public protected 《methods》; 【所有方法不进行混淆】}-keep public class com.asqw.android{public void Start(java.lang.String); 【对该方法不进行混淆】}-keepclasseswithmembernames class * { 【保护指定的类和类的成员的名称，如果所有指定的类成员出席（在压缩步骤之后）】native 《methods》;}-keepclasseswithmembers class * { 【保护指定的类和类的成员，但条件是所有指定的类和类成员是要存在。】public 《init》(android.content.Context, android.util.AttributeSet);}-keepclasseswithmembers class * {public 《init》(android.content.Context, android.util.AttributeSet, int);}-keepclassmembers class * extends android.app.Activity {【保护指定类的成员，如果此类受到保护他们会保护的更好 】public void *(android.view.View);}-keepclassmembers enum * {public static ** values();public static ** valueOf(java.lang.String);}-keep class * implements android.os.Parcelable {【保护指定的类文件和类的成员】public static final android.os.Parcelable$Creator *;}