key文件反编译
Ⅰ 将原安卓apk反编译后签名，有原签名文件
一、可以使用如APKTool之类的反编译工具，使用方法网上有介绍，反编译完成后修改所有引用包名的地方及对应的文件夹，然后重新编译为新的APK，最后再用签名工具签名就行。
二、第一步是用命令行的形式进行的，如果不愿意进行繁琐的配置过程，可以使用一些可视化的APK修改工作，如APK改之理、VTS(Virtuous Ten Stdio)等，但主要修改的地方更第一步是一致的。
Ⅱ Android 如何对apk文件进行反编译以及重新
第一：使用apktool直接反编译apk
第六：把生成的hellodemo.apk安装到手机，可以看到主界面上已经显示的是hello，而不再是你好。说明反编译重新打包成功！
Ⅲ 用mt怎么反编译app获取key
一、工具准备：apktool , dex2jar , jd-gui
二、使用dex2jar + jd-gui 得到apk的java源码
1.用解压工具从 apk包中取出 classes.dex 文件
用命令(dex2jar.bat classes.dex)得到一个 jar文件
2.用jd-gui反编译工具将得到.jar文件反编译成.java文件
三、使用apktool得到apk的xml文件
1.用命令(apktool d xxx.apk xxx_xml)反编译xxx.apk包
2.从 xxx_xml 文件夹得到xml文件
四、第二步 得到的程序源代码 和 第三步 得到的xml文件组合下，即可得到完整的apk源码。
五、应用： 汉化/去广告，加 values-zh-rCN, values-zh-rTW, values-de, values-fr
1.在步骤三的文件夹xxx_xml/res/ 下， 建文件夹: values-zh-rCN,values-zh-rTW
2.1复制values\strings.xml 到 values-zh-rCN 并翻译.
2.2 去广告见；
3.重建APK,用命令(apktool b xxx) ，输出到ABC/dist/out.apk
或命令( apktool b xxx out.apk)
Ⅳ 如何防止代码被反编译
由于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 *;
}
Ⅳ re从零开始的反编译教程
写在开头，引用很喜欢的一句话： 要么学！要么不学！学和不学之间没有中间值 不学就放弃,学就要去认真的学！ --致选择
为了回溯编译过程（或对程序进行逆向工程），我们使用各种工具来撤销汇编和编译过程，这些工具就叫反汇编器和反编译器。反汇编器撤销汇编过程，因此我们可以得到汇编语言形式的输出结果。反编译器则以汇编语言甚至是机器语言为输入，其输出结果为高级语言。
数组的表示方式是：在基本类型前加上前中括号“[”，例如int数组和float数组分别表示为：[I、[F；对象的表示则以L作为开头，格式是 LpackageName/objectName;
（注意必须有个分号跟在最后），例如String对象在smali中为： Ljava/lang/String; ，其中 java/lang 对应 java.lang 包，String就是定义在该包中的一个对象。或许有人问，既然类是用 LpackageName/objectName; 来表示，那类里面的内部类又如何在smali中引用呢？
答案是：在 LpackageName/objectName/subObjectName 的 subObjectName 前加 $ 符号。
方法的定义一般为： Func-Name (Para-Type1Para-Type2Para-Type3...)Return-Type
注意参数与参数之间没有任何分隔符，同样举几个例子就容易明白
无序列表的使用，在符号"-"后加空格使用。如下：
https://www.jianshu.com/p/1c54c1ccf5cc
https://www.cnblogs.com/onelikeone/p/7594177.html
解决：点击进去jd-gui，删除试一试。再不行换最新版本
解析结束后进行编译报错
解决方法： https://blog.csdn.net/fuchaosz/article/details/104800802
Failed parse ring installPackageLI: Targeting R+ (version 30 and above) requires the resources.arsc of installed APKs to be stored uncompress
解决方法：
降低gradle里版本，若出现
signatures do not match the previously installed version; ，
使用adb install命令在手机上安装app时，遇到这个报错。原因是新装的app和手机上现有的旧版app冲突了。
解决方法：删除手机上原来的app，再重新安装即可。
可是转念一想如果反编译的apk都是Version 30 R+以上，难道我解压后挨个改一遍gradle？太彻淡了，一定有解决方法，所以有了下面探究出现这个问题的解决方法：既然报错是资源文件高版本不支持，而且没有4位对齐，那么不编译资源文件就好了
APK签名工具之jarsigner和apksigner：
https://blog.csdn.net/xzytl60937234/article/details/89088215?utm_medium=distribute.pc_relevant.none-task-blog-js_landingword-1&spm=1001.2101.3001.4242
利用apktool反编译apk，并且重新签名打包：
https://blog.csdn.net/qq_21007661/article/details/109851522?utm_medium=distribute.pc_relevant.none-task-blog-js_title-4&spm=1001.2101.3001.4242
验证apktool能否使用
apktool -r d apk名字.apk，不反编译资源文件，为什么这么做，先挖个坑
错误提示没有4位对齐和不支持30版本以上的资源文件。所有尝试不编译资源文件
解决4位对齐的方法：
查看当前目录，生成了新文件：abc.keystor
使用JarSigner对apk进行签名，命令如下
jarsigner -verbose -keystore abc.keystore -signedjar testx.apk src.apk abc.keystore
直接反编译的apk产生上述错误
但是只编译资源文件的apk安装时
发现没有使用V2进行签名，这时候进行V2签名， (apksigner,默认同时使用V1和V2签名 ）
所以先对只编译资源文件的apk进行V2尝试看能否成功
重复1（进行apktool -r d apk名字.apk）-->2 -->3 -->4( 不使用jarsigner而使用apksigner )
将生成的abc.keystore和打包回的apk（ apktoolapp-debugdist 里的app-debug.apk）放入 C:Users aowei.lianAppDataLocalAndroidSdkuild-tools30.0.3 下，因为Android studio的SDK下有apksigner.bat.
对jarsigner只是apk进行了V1签名；在Android7.0引入了V2签名，因此，当进入sdk25.0.0及后续版本，会发现一个apksigner.bat执行脚本。
我们可以通过apksigner进行V2签名，当然，apksigner默认是同时支持V1与V2的，于是：
学习了公钥和密钥的使用和区别，使用私钥的加密算法称为对称加密算法，这种算法实现是接收方和发送方公用一道密钥，优点是效率高，缺点是安全性差，如果被第三人得知密钥则信息泄露，由此衍生了公钥加密算法，也就是非对称加密算法，这个算法是接收方给发送方公钥，发送方用公钥加密后发给接收方，接受方再用私钥解密。这样即使所有人知道公钥也不会造成信息泄露。缺点是效率非常低。
此外了解了RSA签名的大致过程，发送方拥有公钥和私钥，对信息进行摘要然后把摘要通过密钥进行签名，然后把签名和信息一起发出去，那么如何验证该信息就是发送方发出的呢，这时候就使用到了公钥验证，通过公钥对信息进行解签，然后使用一样的摘要算法得到摘要，如果得到的摘要和解签后的内容一致则说明是发送方发出。
总结就是公钥加密，私钥解密。公钥验证，私钥签名
RSA 密码体制是一种公钥密码体制，公钥公开，私钥保密，它的加密解密算法是公开的。由公钥加密的内容可以并且只能由私钥进行解密，而由私钥加密的内容可以并且只能由公钥进行解密。也就是说，RSA 的这一对公钥、私钥都可以用来加密和解密，并且一方加密的内容可以由并且只能由对方进行解密。
因为公钥是公开的，任何公钥持有者都可以将想要发送给私钥持有者的信息进行加密后发送，而这个信息只有私钥持有者才能解密。
它和加密有什么区别呢？因为公钥是公开的，所以任何持有公钥的人都能解密私钥加密过的密文，所以这个过程并不能保证消息的安全性，但是它却能保证消息来源的准确性和不可否认性，也就是说，如果使用公钥能正常解密某一个密文，那么就能证明这段密文一定是由私钥持有者发布的，而不是其他第三方发布的，并且私钥持有者不能否认他曾经发布过该消息。故此将该过程称为“签名”。
Android 签名机制 v1、v2、v3
进入JDK/bin, 输入命令
参数:
进入Android SDK/build-tools/SDK版本, 输入命令
参数:
例如:
最后安装加 -t ：
附上参考链接：
https://blog.csdn.net/A807296772/article/details/102298970
配置NDK的时候如果按钮是灰色的，手动配置
直接在javac后面指定编码是UTF-8就是了。
需要注意的是要加上* -classpath .其中classpath后面的一个黑点是不能省略的。
编译好后如何导入so库
成功运行后发现lib目录下已经apk编进去so了
https://www.52pojie.cn/thread-732298-1-1.html
本节所有到的工具和Demo
IDA
链接： https://pan..com/s/15uCX8o6tTSSelgG_RN7kBQ
Demo
链接： https://pan..com/s/1vKC1SevvHfeI7f0d2c6IqQ
找到so并打开它 因为我的机型是支持arm的所以我这里打开的是armeabi文件夹下的so 如果机型是x86模式的那么这里要打开x86模式下的libJniTest.so
编译过程：
按住键盘组合键 shift + f12 打开字符串窗口 这个窗口将会列举出so中所包含的所有字符串 因为上节课我们只编写了一个字符串 所以这里只有一个hello 52pojie! 如果打开的是x86的so这里还会有一些.so 但是字符串只有这一个
鼠标点在hello 52pojie!字符串上,打开 Hex mp窗口,修改hello 52pojie!对应内存地址的内容
关于字符对应的16进制可以在网络搜索ascii码表 找到字符所对应的16进制
因为我要把hello 52pojie！修改成hello world! 是不是只要找到每个字符所对应的hex修改就好了
这里我看到 hello 52pojie!对应的hex是:68 65 6C 6C 6F 20 35 32 70 6F 6A 69 65 21
我在ascii码表上找到world所对应的十六进制是:77 6F 72 6C 64
所以hello world! 对应的十六进制是:68 65 6C 6C 6F 20 77 6F 72 6C 64 21
注意编辑的时候光标暂停的位置只有先输入字母才能更改成功，修改好后 右键Apply changes应用
退出后保存
此时已经so修改完毕
大功告成，hello 52pojie! --> hello world!
Ⅵ 易语言反破解教程说信息框用自定义窗口就是自己新建窗口，请问新建窗口怎么做到程序等待或者系统等待效果
4．随机验证
随机验证很重要，例如你的一处验证是一直存在的，奸人就很容易地下断点跟踪了。因此在软件启动时进行一次正常验证外，其他情况下的验证最好是随机的，用30分之一或50分之一的机会进行验证，这样奸人会不停地试你的软件在哪一处进行了验证，因此破解的时间会相当地长。
加密第14定理：足够多的随机验证足以让破解者累死。
随机验证包括随机进入不同的验证子程序。
或随机中的最大数大一些，只有30分之一的机会验证。
或在窗口中放上一些颜色与底图一样的图片框，这样奸人不一定会点击这里，但用户万一点中了，就会触发验证。
我们假设所有软件都能被破解，包括易语言在内，那么如果他破解的速度跟不上你发布新软件的速度，那么他永远在破最新版而累死。或者说他破解的时间比你写一个软件的代价大，这时还不如他直接写这个软件来得合算。
反破解的任务之一就是让奸人累死，或浪费他的生命。
下面的办法也可以使用：你可以在读到待验证的注册码、公钥、注册文件后，通过定义10000个数组，存入上述同样的内容以备以后进行验证，这最多浪费一些内存。验证时随机使用其中的一个进行验证，由于奸人不知你用的是数组中的哪一个进行的比对，而且是随机的，每次验证的值都不一样，不让奸人吐血才怪呢。
计次循环首（10000，计次）
数组[计次] = “123456” ’ 复制一万个公开注册码或公钥，破解者知道也无所谓。
计次循环尾
数组[取随机数（1，10000）]
你不要立刻检查注册码，10000份拷贝你只要以后随机找一份用就行了，破解的人不知道你正在用的是那一个，同时你可以事先编好且运行时不断使用一些假的读取注册码数组的调用干扰破解者。这种方法对程序的性能影响微不足到，只是浪费一点内存。因为Debug对内存下断点的局限,这种情况他要下断点,累死的就是破解的人了。
5．不同权限验证
在启动时进行一次验证是非常必要的，这样让奸人知道确实是验证了，以让他心理放松警惕，而这次的验证只是一部分验证，并没有完全验证。
还有的建议在启动时将注册信息读入后不要进行验证，保不定在哪里进行验证，个人认为这样让破解者提高了警惕性，会认为软件作者很有经验。麻痹敌人也很重要呀。
例如，在启动时验证通过一次，验证级别加强一级，然后再在其他的地方再进行验证就可以了。
下面代码是确认了一个级别
计次循环首(到数值（验证1），)
已注册 = 1
计次循环尾（）
……
……
在另一个触发子程序中再通过这个级别再验证：
计次循环首（已注册）
计次循环首(到数值（验证2），)
已注册 = 2
跳出循环（）
计次循环尾（）
跳出循环（）
计次循环尾（）
在其他触发子程序中再通过这个级别再验证：
计次循环首（已注册）
计次循环首(到数值（验证3），)
已注册 =3
跳出循环（）
计次循环尾（）
跳出循环（）
计次循环尾（）
有时也可以将级别降一降，怎么降，当然是不考虑级别直接验证了：
6．忽悠型的GHOFFICE过滤词语验证代码
前面已讲过花指令的原理，在程序中人为地再放一些GHOFFICE过滤词语代码以忽悠奸人也是一个好办法。GHOFFICE过滤词语代码就是一些假的验证代码，基本上是明文的，这样的代码上百上千，足以让奸人累死。
其实对付那些“根据跳转指令的爆破”高手来说，一个办法就够他们头疼的了，就是你在程序中不明显加入与判断是否正版有关的语句，也不做任何提示，以免让他们顺藤摸瓜，而是在判断为盗版后，跳转到另一个看似很合理的分支，而那个分支和正版的分支代码差不多，只是在计算公式或其它算法上稍动一下，使其运算结果不正确，这样，他们就在机器码级别上就分不清哪个是对的，哪个是错的了，即使他们认为破解成功，其实运行时，得的结果错误百出，他们就没兴趣了，呵呵，算损的吧！！！
加密第15定理：大量添加GHOFFICE过滤词语代码虽然是无奈之举，但很管用。
作业1：制作一个常量****器
要求：制作一个常量代码自动生成器。可随机生成成百上千个易语言源代码形式，可直接拷贝到易语言中成为常量。变量也可以这样制作。
写好这样一个程序后，就可以自动生成GHOFFICE过滤词语代码，然后复制，粘贴到易语言的常量表中即可。如下图所示：
变量也可以这样生成，不过生成的变量可以任意拷贝为全局变量，或程序集变量，或局部变量。制作时的名称可以为中文名称，直接编译后不会在EXE文件中找到同名的中文名称。因此您可以放心地将这些名称定义为：“GHOFFICE过滤词语常量1”、“GHOFFICE过滤词语变量1”等等以示与正常代码进行区别。
作业2：制作一个代码迷乱器
本次作业性质同上，也是自动生成易语言的一些无用GHOFFICE过滤词语代码，以迷乱奸人的破解，让他找到的全是GHOFFICE过滤词语代码，从而大大延长了破解时间。
通过直接拷贝编辑框中的内容，粘贴到您的代码中，可自动完成任务，如下图所示：
上图所生成的是一些明文的加密方法的GHOFFICE过滤词语代码，让奸人去研究这些GHOFFICE过滤词语吧。
上述子程序名称最好也有时调用一下，反正不会真正产生作用的，用多线程调用最好。
或者您平时注意多收集一些别人用于加密时的子程序，拷贝到一个易语言程序中，保存，这样的代码作为GHOFFICE过滤词语代码放在你有用的程序中，虽然增加了一些程序的体积，但安全性是大大提高了。并且基本上没有牺牲软件性能与稳定性。
7．伪验证技术
还是先举一个例子说明吧，易表软件在10.0版本前已发现有大量的注册机存在，于是易表作者其后改变了加密方式，易表10.0推出后还是出现了注册机，并且这种注册机注册过的软件可以使用。于是有些用户用注册机取得的注册码使用了，过了一段时间，当盗版用户将重要数据存入易表后，突然有一天数据库被锁定了，于是只好注册易表，并且让易表作者为数据库解锁。
从这里可以基本上判定易表新版本采用了伪验证技术，即在较为明显的地方提供了一级验证，这种验证方式没有经过太强的加密，而二级验证在一定的条件下才触发，而这个条件是检查到了用户输入了重要的数据，或大量的数据，或使用次数较多。
基本原理是注册文件由前后两个注册码拼接而成。一般情况下只进行第一个注册码的验证，而当条件成熟时进行第二个注册码验证。
这是一种双赢的策略，易表作者即收到了注册费，付费的人还会道歉，并且感谢易表作者。哈哈，大家要学习这招哦。
但本办法对于数据库应用及数据量大时检查最好，而对于一些没有生成数据的用户无效。
发布软件的时候发布自己编写的注册机，弄个假破解版，那么想破解的就可能不来了，即使有真的破解，谁会有自己给自己写假破解快啊！可能假破解版中只破解一半，等用户使用了，有数据了再锁定，让他们注册后再给解锁，付了钱还要谢谢你，哈哈，损招，但有用！
加密第16定理：伪验证可以迷惑一般破解者，甚至自己发布一个伪注册机。
8．定时验证、延时验证、客户数据集累验证
过一段时间后再验证，如你在2005年1月发布一个软件，那么就内定2005年6月后触发验证机会。
或您的软件是一个数据库产品，那么您可以在程序中设置如果数据库大于5MB时就进行验证，并且最好您能确定这些数据是不重复的，刻意加入的。
如易表设置了伪验证，这时市场上出现了新的注册机，当用户用这个注册机后，提示是注册成功了，但当用户输入重要数据后的某个日子，突然打不开数据库了，用户很着急，因为以为是破解成功了，所以将重要的资料输入了，只能拿钱向易表作者进行注册了。而且还千恩万谢，后悔自己不该用破解。哈哈，一举两得呀。
这个方法对于数据库应用软件来说是绝好的办法。
作业：制作一个算法程序放在你的数据库软件中，这个子程序可以统计你的数据库软件使用时，用户输入的是否是拷贝的东西，还是正常的数据。当统计到1000时触发验证。方法思路为：可以通过查看用户有没有使用复制与粘贴快捷键，或资料进行排序，如果有大量重复的，就说明是奸人在拷贝数据破解，否则是一个资料一个资料的输入的，说明是正常使用的重要资料，这时进行对比就好了。
本方法对有资料的破解使用者有极好的控制作用，通过第6条的伪验证技术与本技术结合，那么就可以知道是不是正版用户，并且可以锁定数据库，等他注册后再给他解锁。
加密第17定理：加密的结果应该是双赢，伪验证是一个上策。
9．验证与专业知识相结合技术
将验证与专业知识相结合，让奸人必须学习专业知识后才能真正去破解，这样所花的功夫比自己写一个软件的代价还要大，而有的专业知识不是专家是不知道的，因此是一个较好的加密方法。
前述中采用了“到数值（验证1（））”这样的代码返回的是0或1两者之间的一个数，可以用乘法进行混合计算，如：
音量 = 播放位置X到数值（验证1（））
当验证正确时返回的是1，这时的结果是正确的，否则返回0，这时的结果为0，是错误的。
这样的代码可以混合到您的专业知识中，如：算命软件可将天干地支、生辰八字中的某个地方进行此类计算，计算类软件可以将某种特殊的计算过程如此结合计算，绘图类软件可将绘图中的算法部分加入此类计算，音响设计类、机床设计软件……
加密第18定理：你知道的专业知识，破解者不一定了解哦。让专业知识与验证相结合吧。
10．伪装，用易语言写自有支持库
大家可以将DLL文件的扩展名改为易语言的支持库文件FNE扩展名，这样进行非独立编译后，与其他FNE文件混合在一起，甚至您可以用易语言写一个支持库，将其中一部分作为验证部分。
易语言的支持库文件FNE文件其实就是一个DLL文件，只不过扩展名改变了而已，用易语言写支持库的方法金眼睛已发过一篇贴子，进行过说明，请大家在易语言论坛上搜索金眼睛的贴子就可以找到了。
作业：找到金眼睛关于用易语言写支持库的贴子，并且自己写一个支持库。
11．绝妙的暗桩设置
应该想到的用代码实现的暗桩前面都讲了不少，下面是一些特别的暗桩供奸人品味的。
大家可以在一些不起眼的地方再放一些暗桩，如：在窗口最小化事件中随机验证，如在某个组件鼠标被移动事件中验证，
有时需要将数据完整性验证放在更高一级的验证中，不要一上来就检查文件是否被更改。
同一验证可以使用多次，这样奸人认为你已经验证过了，没有必要会再验证一次，而相反这时又产生了验证，让奸人防不胜防。如启动时就立即检查程序完整性，如果发现被更改，那就立即退出程序，而在一些子程序中也随机放这样的验证。
更多的暗桩大家自己设计最好。
加密第19定理：加密重要的是暗桩的设置，破解不完全就是一个无效破解。
12．发布不完整版本
有的软件作者在发布共享软件时，放在外面的是不完整版本，将更多的数据资料在注册后提供。这样做也可以，只是麻烦一些而已。如有的图形制作软件，将图片资源另外打包，用户注册后再给完全版的图片。
也有的将DLL文件中的验证部分作了空处理，而在注册后提供真正的注册DLL文件及注册码。还有的直接将KEY文件放在了DLL文件中另外提供。
加密第20定理：不要发布完整版本，以静制动。
13．程序、数据结合加密技术
把程序运行所必需要的资源放到一个数据库文件中，给这个数据库设密码，密码是主程序的数据摘要变换后的结果。程序运行是先验证有没有注册，如果已经注册，就对运行程序本身（取执行文件名（））取数据摘要，用自己设计的算法多次变换后形成一个字串，用该字串作为数据库的密码打开数据库文件。如果打开数据库失败，就说明主程序被人修改了，终止程序运行即可。（不终止也没戏，程序找不到运行所需的资源。）
另外设计一个程序，用同样的算法算出数据库密码，然后给数据库加密即可。
密码形成算法建议使用大数支持库。但如果是汇编高手用汇编写注册机的话，会直接将支持库的所有反汇编码抄进去就可以了，问题是他们有没有时间搞。
14．自定义算法
前面讲过采用RSA与数值计算支持库交叉计算的办法，这就是一种自有的算法，如果能用上数值计算支持库中的矩阵、傅丽叶变换等高级功能就更好了。
多重RSA交叉打乱：大家也可以多用一些RSA密钥，如用5个，10个都无所谓，重要的是将这些注册码都打乱，让奸人哭死。打乱的方法就是你自己独创的方法了。
更多的自有算法就要靠大家自己去研究了。祝大家好运。
加密第21定理：加密不反对古怪和变态的方法，鼓励哦。
15．加密框图
下面给出一个加密的设计框图，大家可以根据自己的实际情况改变加密的策略：
图中主程序外围进行了花指令编译，并且用加普通壳进行保护。脱壳了也无所谓，因为设置了暗桩，随机检查。
图中表示主程序运行后，首先进行了常规的注册码第一次验证，找有没有注册文件。如果这个被破解，注册码应该是一个短的RSA，而真正的注册码是三个RSA的叠加。会生成伪注册机也无所谓。
主程序中用暗桩的形式对窗口标题、版权信息进行验证，这是考虑到如果一启动就验证这些很容易被奸人看出来从而会跳过去。因此用一些随机，或分级，或条件法取得不固定的验证。
主程序中用暗桩的方式对加壳后主程序的完整性进行校验，这个也不要放在常规的验证中，否则很容易被跳过去。可以查文件长度，MD5或CRC32都可以上。
主程序中用暗桩的方式加入了反调试模块。
主程序中布满GHOFFICE过滤词语验证代码。并且源代码有备注，不会搞错的。
主程序在某个条件下随机进行第二级验证，从注册码中取第二段数据，如果注册码长度不够且取不到第二段数据，那么就说明已使用了伪注册机，将用户的数据库锁定，等他付钱来注册。
主程序在一个条件下再激活验证，从注册码文件中取第三段数据，如果注册码长度不够，且取不到第三段数据，那么就说明已使用了伪注册机，将用户的数据库锁定，等他付钱来注册。
编程中还注意将加密的字符串搅乱且分不同地方存放，用吴氏加密命令加密重要数据，也可加入数值计算支持库的算法，也可以加入一些惩罚手段，也可以再加入自己的一些算法。
以下是一些人的编程体会摘录,基本未改其中的内容,在此表示感谢!
附录1加密已形成密码学
我引用《应用密码学》作者的话：
世界上有两种密码：一种是防止你的小妹妹看你的文件；另一种是防止奸人阅读你的文件资料。
如果把一封信锁在保险柜中，把保险柜藏在纽约的某个地方…，然后告诉你去看这封信。这并不是安全，而是隐藏。相反，如果把一封信锁在保险柜中，然后把保险柜及其设计规范和许多同样的保险柜给你，以便你和世界上最好的开保险柜的专家能够研究锁的装置。而你还是无法打开保险柜去读这封信，这样才是安全的。
意思是说，一个密码系统的安全性只在于密钥的保密性，而不在算法的保密性。
对纯数据的加密的确是这样。对于你不愿意让他看到这些数据（数据的明文）的人，用可靠的加密算法，只要破解者不知道被加密数据的密码，他就不可解读这些数据。
但是，软件的加密不同于数据的加密，它只能是“隐藏”。不管你愿意不愿意让他（合法用户，或 Cracker）看见这些数据（软件的明文），软件最终总要在机器上运行，对机器，它就必须是明文。既然机器可以“看见”这些明文，那么 Cracker，通过一些技术，也可以看到这些明文。
于是，从理论上，任何软件加密技术都可以破解。只是破解的难度不同而已。有的要让最高明的 Cracker 忙上几个月，有的可能不费吹灰之力，就被破解了。
所以，反盗版的任务（技术上的反盗版，而非行政上的反盗版）就是增加 Cracker 的破解难度。让他们花费在破解软件上的成本，比他破解这个软件的获利还要高。这样 Cracker 的破解变得毫无意义——谁会花比正版软件更多的钱去买盗版软件 ？
然而，要做到“难破解”，何尝容易？ Sony 曾宣称的超强反盗版（Key 2 Audio音乐 CD反盗版），使用了很尖端的技术，然而最近却被一枝记号笔破解了，成为人们的饭后笑料！
所以，很多看上去很好的技术，可能在 Cracker 面前的确不堪一击。就像马其诺防线一样，Cracker 不从你的防线入手，而是“绕道”。这样，让你的反盗版技术在你做梦也想不到的地方被 Crack 了。
为什么会这样呢 ？归根到底是因为软件在机器上运行，并且软件和机器是分离的——这一点是关键，如果软件和硬件完全绑定，不能分离，是可以做到象 IDEA 之类几乎不可破解的系统的。这将在后面谈传统软件保护技术时详细说明。
对我的这个解决方案，我不能保证Crack高手在几天之内不能破解它，我只能说：“在这个软件中，我尽量堵住了当前破解者普遍使用的方法以及“我想得到”的可能的缺口。”但是我相信，倾注了我三个月心血的反盗版软件，决不是一个“玩具式”的反盗版软件。
附录2《如何用简单方法防止破解》
北极异型
在Debug的手册里可以看到Debug工具的局限：第一个局限是只能下4个内存区域的断点，每个断点不能控制超过两个字节，这样内存断点不能控制超过16个字节的区域；第二个局限是对多线程只能同时跟踪一个线程。
假设你的注册部分有300行，你可以分成30个子程序调用或重复的func1(),func2()... func30()。将他们随意放到程序的各个部分，一定不能放在一起（自己能找到就行了）。不要用Memcpy等常用系统调用拷贝注册码，尽可能自己写,像Memcpy很好写，性能差点无所谓。经过编译后inline函数展开，注册部分和其他代码混在一起，他要写出注册机就像大海里捞针，在几十万甚至上百万汇编代码里找出有用的注册部分。
利用Debug的第一个局限最重要的一点是:注册码也不要放在一起，假设你的注册码是12位，千万不要用一个12位的数组放注册码，你可以在程序的不同位置定义12个全局字符变量，每个放一位，这样注册码在内存就不连续了。最好再加密处理一下（简单的字符异或就可以），验证时再解密。也不要用连续内存保存验证用到的变量，尽量将用到的验证临时变量分散定义在程序的不同处，再在验证中，不断转移一些值到其他变量中，对付暴力和Loader会比较有效。
没有必要用复杂的加密算法，更容易成为追踪的目标。只要你将注册部分隐藏的足够好，也没有漏洞，你花1天写的加密算法，破解者可能会花100－1000倍的时间破解。大部分人都会放弃。
你将注册做在一起，就像将你的财宝放在现代保险箱里，虽然非常坚固难以解密，对于开锁高手两分钟就打开了。
而古代海盗用的方法是将财宝埋在海岛上，这样没有藏宝图，对所有高手和低手都只有一条路，拿一把铁撬挖，可能要挖一生。程序有那么多代码，反编译出来可能超过百万行,你将注册部分藏在里面，藏的好就如同将财宝埋在海岛里。那些所谓的Crackme只是给高手玩儿的现代保险箱而已，用原始的方法可以达到同样效果。
Ⅶ 反编译修改Android apk的版本号
准备工作完毕后，开始反编译apk。
1.将你要反编译的apk放到apktoo.bat的同一文件夹下，然后cd到这个目录，执行以下命令：
其中debug.apk为你要反编译的apk的名字，替换一下即可
其中dst.apk为打包后生成的apk。
其中 debug.keystore 为你自己的签名文件， debug 为签名文件的 keyAlias 。
然后输入密码就行， dst_signed.apk 为签名后生成的apk文件
执行完后，出现如下命令即代表成功
Ⅷ apk反编译/回编译
再次记录一次apk反编译/回编译过程，链接失效请留言，会及时更新。
参考博客: https://blog.csdn.net/w327918069/article/details/82761437
首先，我们需要一个apk，下图是Android Studio编写并打包的一个apk。
其实apk就相当于一个zip压缩包，通过 WinRar 工具可以对其解压缩，像这样:
此时，祭出我们的神器----> apktool ，当当当当~~~~~~~。
一行命令进行apk反编译:
apktool d -r app-debug.apk 一定要加入参数 -r ，不然后面回编译回报错。
apk反编译到此结束。
回编译就是通过 apk反编译 生成的目录文件转换成一个apk。
十分简单的一行命令:
apktool b app-debug
此时安装apk到手机无法安装成功，还需要对apk进行签名才能安装。
1.生成key.keystore
keytool -genkey -alias key.keystore -keyalg RSA -validity 30000 -keystore key.keystore
可以看到key.keystore已经生成。
2.对apk进行签名
可用于没有签名和已经签名的apk，再次签名。
jarsigner -verbose -keystore [keystorePath] -signedjar [apkOut] [apkin] [alias]
命令格式及参数意义：
-verbose -> 输出签名过程的详细信息
-keystore [keystorePath] -> 密钥的库的位置
-signedjar [apkOut] -> 签名后的输出文件名
[apkin] -> 待签名的文件名
[alias] -> 证书别名
jarsigner -verbose -keystore key.keystore -signedjar app-debug_signed.apk app-debug.apk key.keystore
回编译完成。
Ⅸ 请问wp的xap文件能反编译吗
wp酷七知道团队为您解答
没办法的我试过。至于破解包作者们似乎是对原包进行修饰也不是反编译