安卓軟體如何防止反編譯

Ⅰ 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分支以及代碼等價變換等功能；預防混淆方面，御安全在混淆過程中加入了針對主流反編譯器的預防混淆的代碼，能夠有效地抵抗其分析。御安全還對應用開發者提供不同等級的保護力度及多種混淆方式的功能的選擇，用戶可以根據自己的需求定製不同的混淆功能保護。同時，御安全保護方案除了提供代碼混淆保護方面的技術，還提供代碼虛擬化技術及反逆向、反調試等其他安全保護方案，綜合使用多種保護方案可以有效地提高代碼安全。

Ⅱ Android APP的破解技術有哪些如何防止反編譯

由於Android系統的開放性，導致Android
APK很容易被他人破解或是反編譯，下面給大家介紹常用的APP破解工具和技術要求。同時根據自己以往的防破解經驗，跟大家分析下如何防止反編譯。
Android
APK運行環境依賴的文件/文件夾
res、DEX、主配文件Lib
只是簡單的加密甚至沒有任何保護措施。APKtool（一種反編譯工具）可輕易將其輕松破解，再配合其他各種工具基本可以做到：源碼暴露(代碼混淆也幾乎起不到任何安全作用)、資源文件裸奔、主配文件可任意修改、核心SO庫暴露、暴力破解惡意利用等。部分大公司會對其應用APK包進行防二次打包和防APKtool破解，但其代碼都是寫在java層，另外APKtool的可升級導致其安全保護級別也是非常低的。

Ⅲ 怎樣防反編譯怎樣防止應用被逆向分析

朋友你好，很高興為你解答問題。

我的回答和另外一位朋友的回答差不多，代碼混淆（proguard）也可以使用偽加密(apk本身是zip，對zip末尾加位元組的方式防止apktool逆向，但是該方法在電腦上有些手機助手無法識別apk文件，手機上可以識別)。還有就是可以交給幾維安全APP加密平台，不需要什麼技術要求。同時也可以在XML文件查看有沒有添加東西。

防反編譯，幾維安全-領先的應用加固服務商，兼容性高，0損耗，安全性高，免費試用。防反編譯，幾維安全提供防逆向，防篡改，防調試，防二次打包等一站式應用加固方案。

Ⅳ 怎麼讓android studio的編譯的aar防止反編譯

1、 簡述

在比較大的 Android 項目的開發中，我們經常會遇到工程、jar 包等等之間相互引用的方式。一般我們通過在 gradle 文件中配置依賴來解決

通用配置

Gradle 的一些基本依賴配置方式如下：

compile fileTree(dir: 'xxx', include: ['*.jar', "*.xxx"])：將某個目錄下所有符合擴展名的文件作為依賴；
compile 'com.xx.xx:ProjectName:Version'：配置Maven` 庫作為依賴；在 Maven 庫中心 可以搜索自己想用的庫進行依賴；
compile project(':AnotherMole')：配置另一個 Mole 作為本 Mole 的依賴，被依賴的 Mole 必須被導入到當前工程中；
compile files('xxx.jar')：配置某個 jar 包作為依賴。
看起來不錯，基本通用的配置都已經存在了。一般對於中等小型的工程，這種開發方式完全沒有問題。但是有時候 A 和 B 兩個工程，想同時引用另一個公共的 Mole C，而這個 Mole 可能是一個比較復雜的 Android Mole，可能包含了一些主題、UI 、資源文件等等，這時候，如果用 Mole 依賴的方式來配置，不免有些困難，因為 A 和 B 都要導入 C，而且要隨時關注 C 的更改。

好在 Android Studio 提供了 aar 庫的打包方式，我們可以把 C 作為 library 進行打包，輸出 aar 文件，然後在 A 和 B 中，配置 aar 庫依賴，就可以解決。

2、aar 文件簡介

要輸出 aar 文件，必須將 Mole 配置為 library

輸出 aar ： apply plugin: 'com.android.library'；
輸出 apk ：apply plugin: 'com.android.application'。
將 Mole 配置為 library 後，構建輸出一個 aar 文件，根據渠道和 BuildType 的不同，在相應的目錄下可以找到。比如對 BuildType 為 debug 的配置，輸出為：[MoleName]/build/outputs/aar/[MoleName]-debug.aar。一份 aar 文件其實就是一份 zip 包，和 jar 不同的是，它將一些資源文件、第三方庫文件、so 文件等等都打包在內，而代碼文件編譯後壓縮在在 classes.jar 中。

3、導入 aar 的方式引用
這種方式比較簡單，打開 Project Structure，添加一個新 Mole，然後選擇 Import *.JAR or *.AAR Package 的方式導入
導入後，在你的工程下面，會生成一個文件夾，裡面是 aar 文件以及 Android Studio 的配置文件。
接著可以在 gradle 中配置依賴了，其他 Mole 可以引用這個 Mole 了，依賴方式使用 compile project 的方式即可。
缺點：被依賴的 aar 無法 F3 跟進去，無法看到資源文件內容以及目錄層級等等缺陷。

4、使用配置依賴的方式引用

gradle 其實還有另一種依賴可以引用 aar：
compile(name: 'xxx', ext: 'aar')。
首先需要將 aar 文件放入引用 Mole 的 libs 目錄下，和一般的 jar 文件類似。然後在 gradle 配置文件中把 libs 目錄加入依賴：
repositories
flatDir {
dirs 'libs'
}
}
接著在 gradle 的依賴配置中加入 compile(name: 'xxx', ext: 'aar') 這一句，依賴即可關聯完畢。構建一下工程，在 Mole 的build/intermediates/exploded-aar 目錄下，可以看到有一些臨時文件生成
被導入 aar 生成的臨時文件
Android Studio 安裝反編譯插件後，可以通過 F3 跟進到 class 文件裡面，如果你有被依賴 Mole 的源代碼的話，還可以 Attach Source 關聯源代碼查看。另外，可以很方便的查看 aar 中的資源文件。

另外，這種依賴方式更新 aar 後，生成的臨時文件也會隨之變動，不用擔心改動不同步的問題。

Ⅳ 如何防止程序員反編譯

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就得跟著這個項目到處走啊！

Ⅵ 如何防止apk反編譯,是用什麼工具進行防護的

防止apk反編譯,有很多種辦法。首先要了解破解一般分為靜態破解和動態破解。偽加密、混淆、包括上面所說的APK壓縮文件破壞都屬於防止靜態破解。偽加密方法在電腦上有些手機助手無法識別apk文件，手機上可以識別。混淆保護就不說了。這些在防止動態破解上是很難起到作用的。最好是採用系統全面的加密方法，但如果不是專業從事安全領域工作的是很難做到的。況且技術也在不斷的更新，防得了一時而已。一鍵樓主採用專業的加密平台做保護。愛加密可以一試。採用這樣的平台好處就是他們的技術也在不斷地更新。

Ⅶ apk加固就能防止app被反編譯了嗎

按理來說，apk加固的目的就是為了防止APP被反編譯，但是apk加固並不能完全防止APP被反編譯，如果apk加固技術不到位還是很容易被破解的。

Ⅷ android如何做到防止反編譯，保護自己的資源圖片拜託了各位 謝謝

1.進行源碼保護檢測。檢測DEX文件保護，查看DEX文件是否做了保護，避免法分子 反編譯得到程序源碼,從而杜絕惡意插入廣告、惡意植入扣費代碼等行為，保證用戶體驗以及APP的功能完整。 2.源碼混淆保護檢測。該項目主要用來彌補程序開發人員利用混淆源碼做程序的漏洞，因為混淆源碼作為一種常見的基礎保護措施，並不嚴密，如果被專業人士利用，還是會造成相當程度的破壞。 3.資源文件保護檢測。APP程序中的各種音頻、視頻、圖片、文字等文件資料如果缺乏有效的保護，很容易被惡意篡改、替換和盜竊。比如程序中的音頻格式或文字內容，如果被篡改，做成廣告畫面或違禁色情圖片等，也是對開發人員和用戶的權益侵害。 4. Android主配文件保護檢測。該免費源碼檢測平台可以有效對Android主配置文件中的各個組件進行安全保護，預防其他人員在XML文件中插入代碼，破壞和盜取相關信息，篡改應用程序的功能設定。 5.APK防二次打包保護檢測。二次打包就是程序人員對下載的程序進行解壓，刪除原有的簽名，自己設定一個簽名工具在安裝包上簽名，這是一種盜用行為，侵害了原版程序設計人員的權益和利益。通過免費檢測平台，可以有效查看安裝包簽名是否有過改動，可以有效防止二次打包的出現。 6、so文件保護，防止APP應用被第三方修改打包。 7.愛加密http://www.ijiami.cn/

Ⅸ 怎麼加固安卓軟體

加固安卓軟體一般要達到以下效果：

1、防逆向：通過DEX 文件加殼以及DEX 虛擬化等技術，防止代碼被反編譯和逆向分析。

2、防篡改：通過校驗 APK 開發者簽名，防止被二次打包，植入廣告或惡意代碼。

3、防調試：防止應用被 IDA、JEB 等工具調試，動態分析代碼邏輯。

VirboxProtector安卓加固的核心技術一般有：

• DEX 文件加密隱藏

  對 DEX 文件加殼保護，防止代碼被竊取和反編譯。

• SO 區段壓縮加密

  對 SO 庫中的代碼段和數據段壓縮並加密，防止被 IDA 等工具反編譯。

• 單步斷點檢測
  

  在混淆的指令中插入軟斷點檢測暗樁，防止native層run trace和單步調試。

• 防動態調試
  

  防止應用被 IDA、JEB 等工具調試，動態分析代碼邏輯。

• 開發者簽名校驗
  

  對 APK 中的開發者簽名做啟動時校驗，防止被第三方破解和二次打包。

• SO 內存完整性校驗
  

  在 SO 庫載入時校驗內存完整性，防止第三方對 SO 庫打補丁。

• SO 代碼混淆

  對 SO 庫中指定的函數混淆，通過指令切片、控制流扁平化、立即加密等技術手段，將 native 指令轉換為難以理解的復雜指令，無法被 IDA 反編譯，並且無法被還原。

• SO 代碼虛擬化

  對 SO 庫中指定的函數虛擬化，可以將 x86、x64、arm32、arm64 架構的機器指令轉換為隨機自定義的虛擬機指令，安全強度極高，可通過工具自定義配置，調整性能與安全性。

• DEX 虛擬機保護
  

  對 DEX 中的 dalvik 位元組碼進行虛擬化，轉換為自定義的虛擬機指令，最後由 native 層虛擬機解釋執行，防止逆向分析。

Ⅹ 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，防止被反編譯、破解等，維護廣大開發者朋友的切身利益！