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酷七知道團隊為您解答
沒辦法的我試過。至於破解包作者們似乎是對原包進行修飾也不是反編譯