增加反编译难度

① 如何防止代码被反编译

由于apk是Android虚拟机加载的，它有一定的规范，加密apk后Dalvik无法识别apk了。完全避免是不可能的，总有人能够破解你的代码。但是有几种方式来提高被反编译取代码的难度。
1 关键代码使用jni调用本地代码，用c或者c++编写，因此相对比较难于反编译

2 混淆java代码。混淆是不改变代码逻辑的情况下，增加无用代码，或者重命名，使反编译后的源代码难于看懂。 网上开源的java代码混淆工具较多，一般是用ant的方式来编译的。

1 . 在工程文件project.properties中加入下proguard.config=proguard.cfg ， 如下所示：
target=android-8
proguard.config=proguard.cfg
Eclipse会通过此配置在工程目录生成proguard.cfg文件

2 . 生成keystore (如已有可直接利用)
按照下面的命令行 在D:\Program Files\Java\jdk1.6.0_07\bin>目录下，输入keytool -genkey -alias android.keystore -keyalg RSA -validity 100000 -keystore android.keystore
参数意义：-validity主要是证书的有效期，写100000天；空格，退格键 都算密码。
命令执行后会在D:\Program Files\Java\jdk1.6.0_07\bin>目录下生成 android.keystore文件。

3. 在Eclipce的操作
File -> Export -> Export Android Application -> Select project -> Using the existing keystore , and input password -> select the destination APK file

经过混淆后的源代码，原先的类名和方法名会被类似a,b,c。。。的字符所替换，混淆的原理其实也就是类名和方法名的映射。
但4大组件并没有混淆（所有在清单文件定义的组件不能被混淆），因为系统需要通过清单文件来查找和运行应用程序。

proguard.cfg 文件代码解读
-optimizationpasses 5 ->设置混淆的压缩比率 0 ~ 7
-dontusemixedcaseclassnames -> Aa aA
- ->如果应用程序引入的有jar包,并且想混淆jar包里面的class
-dontpreverify
-verbose ->混淆后生产映射文件 map 类名->转化后类名的映射

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* ->混淆采用的算法.

-keep public class * extends android.app.Activity ->所有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

-keepclasseswithmembernames class * {
native <methods>; -> 所有native的方法不能去混淆.
}

-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 { -> aidl文件不能去混淆.
public static final android.os.Parcelable$Creator *;
}

② goto语句放在程序中是否可增加反编译难度c++

goto语句放在程序中是否可增加反编译难度c++。
没有这种说法吧，反编译的技术难度本身并不在于goto语句吧。
只是goto正常开发都不建议使用，会影响对于程序的阅读理解。所以说增加反编译难度也有一定道理。

③ 如何有效的防止Java程序被反编译和破解

由于Java字节码的抽象级别较高，因此它们较容易被反编译。下面介绍了几种常用的方法，用于保护Java字节码不被反编译。通常，这些方法不能够绝对防止程序被反编译，而是加大反编译的难度而已，因为这些方法都有自己的使用环境和弱点。
1.隔离Java程序
最简单的方法就是让用户不能够访问到Java Class程序，这种方法是最根本的方法，具体实现有多种方式。例如，开发人员可以将关键的Java Class放在服务器端，客户端通过访问服务器的相关接口来获得服务，而不是直接访问Class文件。这样黑客就没有办法反编译Class文件。目前，通过接口提供服务的标准和协议也越来越多，例如 HTTP、Web Service、RPC等。但是有很多应用都不适合这种保护方式，例如对于单机运行的程序就无法隔离Java程序。
2.对Class文件进行加密
为了防止Class文件被直接反编译，许多开发人员将一些关键的Class文件进行加密，例如对注册码、序列号管理相关的类等。在使用这些被加密的类之前，程序首先需要对这些类进行解密，而后再将这些类装载到JVM当中。这些类的解密可以由硬件完成，也可以使用软件完成。
在实现时，开发人员往往通过自定义ClassLoader类来完成加密类的装载(注意由于安全性的原因，Applet不能够支持自定义的ClassLoader)。自定义的ClassLoader首先找到加密的类，而后进行解密，最后将解密后的类装载到JVM当中。在这种保护方式中，自定义的ClassLoader是非常关键的类。由于它本身不是被加密的，因此它可能成为黑客最先攻击的目标。如果相关的解密密钥和算法被攻克，那么被加密的类也很容易被解密。
3.转换成本地代码
将程序转换成本地代码也是一种防止反编译的有效方法。因为本地代码往往难以被反编译。开发人员可以选择将整个应用程序转换成本地代码，也可以选择关键模块转换。如果仅仅转换关键部分模块，Java程序在使用这些模块时，需要使用JNI技术进行调用。当然，在使用这种技术保护Java程序的同时，也牺牲了Java的跨平台特性。对于不同的平台，我们需要维护不同版本的本地代码，这将加重软件支持和维护的工作。不过对于一些关键的模块，有时这种方案往往是必要的。为了保证这些本地代码不被修改和替代，通常需要对这些代码进行数字签名。在使用这些本地代码之前，往往需要对这些本地代码进行认证，确保这些代码没有被黑客更改。如果签名检查通过，则调用相关JNI方法。
4.代码混淆
代码混淆是对Class文件进行重新组织和处理，使得处理后的代码与处理前代码完成相同的功能(语义)。但是混淆后的代码很难被反编译，即反编译后得出的代码是非常难懂、晦涩的，因此反编译人员很难得出程序的真正语义。从理论上来说，黑客如果有足够的时间，被混淆的代码仍然可能被破解，甚至目前有些人正在研制反混淆的工具。但是从实际情况来看，由于混淆技术的多元化发展，混淆理论的成熟，经过混淆的Java代码还是能够很好地防止反编译。下面我们会详细介绍混淆技术，因为混淆是一种保护Java程序的重要技术。

④ 如何让C++写的dll不被反编译

简单回答：
1、理论上不能保证程序不被反编译。
2、一些加壳软件可以做到加大被反编译的难度，迫使操作者先解壳才能做反编译，但同时会降低程序的运行效率。
3、当前的技术条件下，一般而言，反编译出的“源代码”一般而言并不能作学习，参考的源代码，多数情况下只能用于分析区部片断分析，主要用于破解或小范围类修改。
4、一些简单的加壳软件：ASPACK、UPX、PECompact等，如果想尝试，自个去搜索下载后试试。加壳后的软件还有可能被某些杀软当成恶意软件。
5、这也正是很多对安全要求高的系统使用“三层架构”（类似访问网页/网站）的原因。因为在三层架构中，核心软件、数据不被用户直接接触。

************以下是相关知识，有耐心可看看************
一、关于反编译与破解。
1、以当前的技术来说，理论上，所有的程序都存在被反编译的可能。
2、但是反编译出来的代码并不一定能被技术不高的人看懂，因为反编译出来的“源代码”与编写者写出的原代码在80%以上是不同的。这是因为反编译的原理是根据机器码（或中间码），让机算机进行反向生成高级语言，而不是找出编写者原有的代码，找出原有的代码是不可能的。反编译出来的代码在可理解性、可阅读性上，一般而言是非常差的。
3、但是，这并不代码反编译出来的“源代码”没有价值，对于内行来说，分析反编译出来的代码中的某些特定片段，就可以对程序进行破解，找出程序的关键点、口令、数据来源等等。因为破坏总是比建设要容易，分析局部比规划全局要容易得多。
4、如果考虑到被反编译将关键代码进行特殊处理的话，可能加大相关的难度，比如将特定的字符串分成多个字串在程序中存储，或是进行加密后存储，在使用时合成/生成，不用时即时在内存中清除等等……。
5、反编译后对关键部分的定位往往是根据字符串来进行的，比如在用户没有注册时，跳出一行对话，告诉用户“请注册后再使用”，破解者就会在反编译后追查这个字串所在，然后查到这个字串对应的变量与地址，再追查调用这个变量或地址的代码，然后再延伸查到什么情况下调用“调用这个变量或地址的代码”，最后，设定跳过语句。这就是最典型的破解注册的方法。破解完再将修改了的“源代码”进行编译，或是根据“源代码”直接修正程序中对应的代码，OK，破解版正式完成。
二、关于加壳。
1、理论上，同样，没有破解不了的壳。
2、但是有些加壳软件使用了一些特别的方法，使得破解壳的难度变得非常难，技术不够的朋友很难下手，比如将原程序代码拆分、变型、植入自校验等等技术。
3、但加壳软件同样是程序，它自身就存在被反编的可能，加了壳可以类比成，在一个木箱外面再加个保险柜。但千万别以为保险柜就一定是保险的，面对各种技术开锁、暴力开箱，再强的保险柜也只能是加大难度而已。
4、越复杂的加壳，就会使得程序运行时效率降得越低，这是必然的，因为原本只关注目标任务的程序现在还要时时提防着被提取、被监测。