android加固原理

⑴ android開發App如何進行加固

1.避
免技巧：使用內部API。即便我們總是建議不要這么做，但還是有一些開發者選擇使用那些不支持或者內部的API。例如，許多開發者使用內部的亮度控制和藍
牙切換API，這些API出現在1.0和1.1版本上。一個Bug——在Android
1.5上進行了修正——允許App在不需要請求許可權的情況下使用這些API。結果，使用了這些API的App在1.5上掛掉了。如果你在App中使用了這
些內部API，你需要做的是：停止這一做法，更新你的程序。

2.避
免技巧：直接操作Settings。嚴格來講，這一條不算，因為我們可以通過Android本身進行操作。但之所以我們加上了這一條，是因為一些開發者做
了一些調皮的事情：一些App悄無聲息地修改了系統設定，而沒有通知用戶。例如，一些App沒有詢問用戶就直接打開了GPS，而另外一些則可能直接打開了
數據傳輸。

因此，應用程序不能直接操作某個特定的系統設定值，即便是它們之前能這么做。例如，App不能直接打開或關閉GPS。不是說使
用會導致App崩潰，而是不應該使用這些API。代替的，App需要發出一個Intent來啟動相應的Settings配置畫面，這樣用戶可以手動地修改
這些設定。詳細情況可以參考android.provider.Settings.Secure類，你可以在1.5_pre（和之後的）SDK文檔中找
到。注意，只有那些移動到Settings.Secure類中設定受到影響。其它的，還會像Android 1.1那樣有著相同的功能。

3.避
免技巧：過分布局。由於View渲染部分的變化，在布局中，過於深（超過10層左右）或過於多（超過30個左右）的View樹層次可能會導致程序崩潰。過
於復雜的布局總歸是有危險的，盡管你可以認為Android
1.5已經好於1.1。大多數開發者不需要對此擔心，但如果你的App有著非常復雜的布局，你還是應該對其「瘦身」。你可以使用一些高級的布局類，如
FrameLayout和TableLayout，來簡化你的布局。

4.避
免技巧：不好的硬體假設。Android
1.5支持軟鍵盤，因此，不久就會有很多設備不再包含物理鍵盤。如果你的程序假設物理鍵盤存在（例如，如果你創建一個自定義的View，並接收鍵按下消
息），你必須保證在只有軟鍵盤的設備上也工作正常。想了解更多關於這方面的信息，請繼續關注這個Blog，我們將會有更多關於處理軟鍵盤的詳細資料。

5.避
免技巧：無意識的旋轉。運行Android
1.5（及以上）的設備能夠根據用戶手持設備的方向自動地旋轉屏幕。一些1.5的設備默認這么做，而其它的需要用戶手動設置。應用程序自己的重定向在某種
程度上會導致不可預期的行為（不論是使用加速度計還是其它一些東西）。這種情況通常發生在應用程序假設有物理鍵盤時才能旋轉；如果設備沒有物理鍵盤，這些
App就不能進行重定向，而這明顯就是個編碼錯誤。開發者應該明確應用程序能在任何時間都能處理重定向。
同樣，App可以使用加速度計做到與系統
相同的事情——直接重定向自己，這也會引發奇怪的結果。一些App使用加速度計來監測像晃動動作什麼的，而又不將其方向鎖定為垂直或水平，經常會導致在方
向上來回翻動。而這就會激怒用戶。（你可以在manifest文件中使用android:screenOrientation特性來鎖定App的方向為垂
直或水平。）

⑵ android apk 加固加密演算法有哪些

、jd-gui：可以查看jar中的類，其實他就是解析class文件，只要了解class文件的格式就可以
2、dex2jar：將dex文件轉化成jar，原理也是一樣的，只要知道Dex文件的格式，能夠解析出dex文件中的類信息就可以了

⑶ "愛加密"加固原理

大概就是通過載入data/app/xx.apk，並且解密載入原dex，替換載入的apk的cookie為解密後
的dex，就可以運行了。

⑷ app加固如何實現app加固原理是什麼，加固的話能做到防破解嗎

「Android APP二次打包」則是盜版正規Android APP，破解後植入惡意代碼重新打包。不管從性能、用戶體驗、外觀它都跟正規APP一模一樣但是背後它確悄悄運行著可怕的程序，它會在不知不覺中浪費手機電量、流量，惡意扣費、偷窺隱私等等行為。http://www.ijiami.cn/newsInfo?id=341
愛加密的加密保護是全方位的，目前提供的服務有：DEX加殼保護、DEX指令動態載入保護、高級混淆保護，SO庫保護，主配置文件保護，資源文件保護，二次打包防護。愛加密的基礎保護就包含對資源文件的加固保護，通過混淆代碼的方式，可以阻止打包黨讀取資源文件的信息。此外，一個APK的唯一正版識別是通過包名+簽名共同的方式來判斷。

⑸ 怎麼加固安卓軟體

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

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 apk加固

加固的過程中需要三個對象：1、需要加密的Apk(源Apk)2、殼程序Apk(負責解密Apk工作)3、加密工具(將源Apk進行加密和殼Dex合並成新的Dex)主要步驟：我們拿到需要加密的Apk和自己的殼程序Apk，然後用加密演算法對源Apk進行加密在將殼Apk進行合並得到新的Dex文件，最後替換殼程序中的dex文件即可，得到新的Apk,那麼這個新的Apk我們也叫作脫殼程序Apk.他已經不是一個完整意義上的Apk程序了，他的主要工作是：負責解密源Apk.然後載入Apk,讓其正常運行起來。

⑺ Android的handler機制的原理

Android的handler機制的原理分為非同步通信准備，消息發送，消息循環，消息處理。

1、非同步通信准備

在主線程中創建處理器對象(Looper)、消息隊列對象(Message Queue)和Handler對象。

2、消息入隊

工作線程通過Handler發送消息(Message) 到消息隊列(Message Queue)中。

3、消息循環

消息出隊: Looper循環取出消息隊列(Message Queue) 中的的消息(Message)。

消息分發: Looper將取出的消息 (Message) 發送給創建該消息的處理者(Handler)。

4、消息處理

處理者(Handler) 接收處理器(Looper) 發送過來的消息(Message)，根據消息(Message) 進行U操作。

handler的作用

handler是android線程之間的消息機制，主要的作用是將一個任務切換到指定的線程中去執行，（准確的說是切換到構成handler的looper所在的線程中去出處理）android系統中的一個例子就是主線程中的所有操作都是通過主線程中的handler去處理的。

Handler的運行需要底層的 messagequeue和 looper做支撐。

⑻ 怎麼加固安卓軟體自己製作的

今天又到周末了，憋了好久又要出博客了，今天來介紹一下Android中的如何對Apk進行加固的原理。現階段。我們知道Android中的反編譯工作越來越讓人操作熟練，我們辛苦的開發出一個apk,結果被人反編譯了，那心情真心不舒服。雖然我們混淆，做到native層，但是這都是治標不治本。反編譯的技術在更新，那麼保護Apk的技術就不能停止。現在網上有很多Apk加固的第三方平台，最有名的應當屬於：愛加密和梆梆加固了。其實加固有些人認為很高深的技術，其實不然，說的簡單點就是對源Apk進行加密，然後在套上一層殼即可，當然這里還有一些細節需要處理，這就是本文需要介紹的內容了。

⑼ android混淆和加固的區別

2.3SDK的兩個新特點：

1.剛安裝上2.3時，查看sdk目錄，發現在\tools下新增了一文件夾「proguard」,如下圖,我就在想是不是Google終於官方對proguard考慮進去了。理論上，對java的混淆都是可以的，但關鍵在於如何編寫proguard的混淆腳本。2.使用SDK2.3後，新建的工程下和之前相比，都會多了一個文件「proguard.cfg」。一打開，相當驚喜，這就是混淆所需的proguard腳本啊。

如下圖：其代碼如下：

view plain to clipboardprint?

-optimizationpasses 5

-dontusemixedcaseclassnames

-

-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 com.android.vending.licensing.ILicensingService

-keepclasseswithmembernames class * {

native ;

}

-keepclasseswithmembernames class * {

public (android.content.Context, android.util.AttributeSet);

}

-keepclasseswithmembernames class * {

public (android.content.Context, android.util.AttributeSet, int);

}

-keepclassmembers enum * {

public static **[] values();

public static ** valueOf(java.lang.String);

}

-keep class * implements android.os.Parcelable {

public static final android.os.Parcelable$Creator *;

}

-optimizationpasses 5

-dontusemixedcaseclassnames

-

-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 com.android.vending.licensing.ILicensingService

-keepclasseswithmembernames class * {

native ;

}

-keepclasseswithmembernames class * {

public (android.content.Context, android.util.AttributeSet);

}

-keepclasseswithmembernames class * {

public (android.content.Context, android.util.AttributeSet, int);

}

-keepclassmembers enum * {

public static **[] values();

public static ** valueOf(java.lang.String);

}

-keep class * implements android.os.Parcelable {

public static final android.os.Parcelable$Creator *;

}

從腳本中可以看到，混淆中保留了繼承自Activity、Service、Application、BroadcastReceiver、ContentProvider等基本組件。

並保留了所有的Native變數名及類名，所有類中部分以設定了固定參數格式的構造函數，枚舉等等。(詳細信息請參考\examples中的例子及注釋。)

好了，進行得差不多了，下面就來看看如何真正的生成混淆APK吧。這兒又得提醒一下，SDK新的特性在文檔里都是有的，所以文檔很重要。

查看SDK2.3的文檔，在路徑「/docs/guide/developing/tools/proguard.html」的「Enabling
ProGuard 」中是這樣描述的：

To enable ProGuard so that it runs as part of an Ant or Eclipse build, set
the proguard.config property in the /default.properties file. The path can be an
absolute path or a path relative to the project's root.

好的，那就這樣做吧。

在工程的"default.properties"中添加這樣一句話「proguard.config=proguard.cfg」，如下圖：這樣就已經設置好ADT的混淆操作了。接下來就是正常的打包和簽名了。。

下圖是我混淆SDK Demo中自帶的Notepad效果圖：注意要點:

1.混淆以後的包會比混淆前的包小一點，一定要注意這點.

如果混淆不成功,請在第2步,將proguard.config=proguard.cfg修改為proguard.config=E:\Mobile_Develop\Google_Android\publicGoldenBeach_new\proguard.cfg這種類似的用絕對路徑,請注意絕對路徑中的文件夾名不能含有空格,如果有空格請替換為"_".

2.android在用proguard混淆時，一般情況下使用系統自帶的配置文件就可以保持大部分外部需要引用的類，比如Activity，view擴展等等，但是有些情況下一些引入的外部lib，如果被混淆也會出現各種各樣的問題，如果不想混淆這些包，就要加上

-keep class packagename.** {*;}

這樣就能完整保持原有class了