必須掌握的技能

1、負責安卓程式的加解密和資料傳輸分析、拆解、逆向等工作; 
2 、逆向APK,瞭解執行過程； 
3 、Andorid本地提權獲得root許可權； 
4 、熟練掌握軟體逆向靜態分析、動態除錯、程式碼跟蹤等； 
5 、熟悉Android開發，瞭解打包、反編譯、破解流程； 
6 、so破解。 
我目前瞭解的如下： 
1，加解密：這就很多了，一般都是遇到後再折騰解密，而且解密程式碼和祕鑰一般都在程式碼裡面。 
2，Andorid本地提權獲得root許可權，一般真機是用recovery刷機包，但是病毒提權是怎麼樣的 
3，ida動態調式和程式碼跟蹤 
4，打包，編譯和破解的流程是什麼樣的？ 
5，so破解：一般就是破殼。各種殼（360，娜迦等等） 
加殼的另一種常用的方式是在二進位制的程式中植入一段程式碼，在執行的時候優先取得程式的控制權，做一些額外的工作。大多數病毒就是基於此原理。加殼的程式經常想盡辦法阻止外部程式或軟體對加殼程式的反彙編分析或者動態分析，以達到它不可告人的目的。這種技術也常用來保護軟體版權，防止被軟體破解。 
6，瞭解反破解的技術 
我目前掌握的技術有： 
1，反模擬器 
2，反靜態程式碼分析器如：反jeb 
應該也是有很多反ida的，也就是加殼。

任職要求

1、具有豐富的Android開發分析經驗，熟悉Android系統架構，熟悉android安全機制； 
2、精通匯編語言、Java、C/C++語言，熟悉Smali語言，對逆向工程有濃厚興趣； 
3、熟練掌握ida、gdb逆向分析工具； 
4、熟練掌握軟體逆向靜態分析、動態除錯、程式碼跟蹤等； 
5、熟悉so和java層hook； 
6、熟悉Android開發，瞭解打包、反編譯、破解流程； 
7、深入理解arm linux和Android底層執行機制； 
8、熟練掌握各種除錯工具：Smali、Dedexer、Dexdump、Apktool、Dex2jar、jd-gui。

1，Android系統架構和android安全機制如下： 
 
android採用自下而上的分層架構，linux核心層，硬體抽象層，執行時和c語言庫，程式框架層和應用層。 
Android以linux核心為基礎實現硬體裝置驅動，程序和記憶體管理，網路協議棧、電源管理等核心系統功能。android基於移動裝置在linux的基礎上補充了記憶體管理，匿名共享記憶體和程序間通訊binder。 
 
HAL(Hardware Abstraction Layer)規定了一套應用層對硬體層的讀寫和配置的統一介面，本質上是將硬體的驅動分為使用者空間和核心空間，其中核心驅動程式執行在核心空間，HAL執行在使用者空間。上圖中的Stub，以so庫的形式存在，可以理解為proxy。上層通過呼叫標識獲得HAL的相關Stub，進而取得相應操作。

當然，還有Android NDK(Native Development Kit)，使得應用程式可以不依賴Dalvik虛擬機器進行開發。Android執行時核心庫提供android.os, android.net, android.media等核心API，而Dalvik虛擬機器依賴Linux核心，實現程序隔離與執行緒排程管理、安全與異常管理、垃圾回收等功能，並被改進以適應低記憶體、低處理器速度的移動裝置環境。

再往上就是應用程式框架層了。一系列的Android應用程式所需的類庫，使得開發人員可以快速地進行程式開發，也可以通過繼承實現個性化的擴充套件。如Activity Manager負責主執行緒ActivityThread的建立、Activity生命週期的維護，併為視窗提供互動的介面。

應用層就是與使用者直接互動的應用程式，如SMS簡訊、圖片瀏覽器、地圖以及開發人員所開發的應用程式。 
也可參考 http://blog.csdn.net/mad1989/article/details/16886189

android安全機制

android安全機制覆蓋到各個層面，求開放的同時也保護使用者的資料，應用程式和裝置的安全。主要安全模型如下： 
程序沙箱隔離機制 
應用程式簽名機制 
許可權宣告機制 
訪問控制機制 
程序通訊機制 
記憶體管理機制 
程序沙箱隔離機制，使得Android應用程式在安裝時被賦予獨特的使用者標識（UID），並永久保持。應用程式及其執行的Dalvik虛擬機器執行在獨立的Linux程序空間，與其它應用程式完全隔離。 
 
有特例程式共享uid； 
應用簽名機制：規定APK檔案必須被開發者進行數字簽名，以便標識應用程式作者和在應用程式之間的信任關係。在安裝應用程式APK時，系統安裝程式首先檢查APK是否被簽名，有簽名才能安裝。當應用程序升級時，需要檢查新版應用的數字簽名與已安裝的應用程式的簽名是否相同，否則，會被當做一個新的應用程式。Android開發者有可能把安裝包命名為相同的名字，通過不同的簽名可以把他們區分開來，也保證簽名不同的包不被替換，同時防止惡意軟體替換安裝的應用。 
許可權宣告機制：要想獲得在物件上進行操作，就需要把許可權和此物件的操作進行繫結。不同級別要求應用程式行使許可權的認證方式也不一樣，Normal級申請就可以使用，Dangerous級需要安裝時由使用者確認，Signature和Signatureorsystem級則必須是系統使用者才可用。 
訪問控制機制：確保檔案系統和永和資料不受非法訪問。 
程序間通訊機制binder，基於共享記憶體的Binder實現，提供輕量級的遠端程序呼叫（RPC）。通過介面描述語言（AIDL）定義介面與交換資料的型別，確保程序間通訊的資料不會溢位越界。 
記憶體管理機制，基於Linux的低記憶體管理機制，設計實現了獨特的LMK，將程序重要性分級、分組，當記憶體不足時，自動清理級別程序所佔用的記憶體空間。同時，引入的Ashmem記憶體機制，使得Android具備清理不再使用共享記憶體區域的能力。

正是因為Android採用多層架構，在保護資訊保安的同時，也保證開放平臺的靈活性。

SE Android

看原始碼見http://blog.csdn.net/luoshengyang/article/details/37613135 
Android是一個基於Linux核心的系統，像傳統的Linux系統一樣，Android也有使用者的概念。只不過這些使用者不需要登入，也可以使用Android系統。Android系統將每一個安裝在系統的APK都對映為一個不同的Linux使用者。也就是每一個APK都有一個對應的UID和GID，這些UID和GID在APK安裝的時候由系統安裝服務PackageManagerService分配。Android沙箱隔離機制就是建立在Linux的UID和GID基礎上。

這種基於Linux UID/GID的安全機制存在什麼樣的問題呢？

Linux將檔案的許可權劃分為讀、寫和執行三種，分別用字母r、w和x表示。每一個檔案有三組讀、寫和執行許可權，分別針對檔案的所有者、檔案所有者所屬的組以及除了所有者以及在所有者所屬組的使用者之外所有其它使用者。這樣，如果一個使用者想要將一個自己建立的檔案交給另外一個使用者訪問，那麼只需要相應地設定一下這個檔案的其它使用者許可權位就可以了。所以，在Linux系統中，檔案的許可權控制在所有者的手中。因此，這種許可權控制方式就稱為自主式的，正式的英文名稱為Discretionary Access Control，簡稱為DAC。

在理想情況下，DAC機制是沒有問題的。然而，一個使用者可能會不小心將自己建立的檔案的許可權位錯誤地修改為允許其它使用者訪問。如果這個使用者是一個特權使用者，並且它錯誤操作的檔案是一個敏感的檔案，那麼就會產生嚴重的安全問題。這種誤操作的產生方式有三種：

使用者執行了錯誤的命令 
負責執行使用者命令的程式有Bug 
負責執行使用者命令的程式受到攻擊 
後來，Linux核心採用了必要的訪問控制機制：SE Linux（Security-Enhanced Linux），它採用了一種強制存取控制MAC（Mandatory Access Control）策略的實現方式，目的在於通過限制系統中的任何程序以及使用者對資源的訪問，保護核心安全。而SE Android（Security-Enhanced Android）是Android與SE Linux的結合，由美國NSA在2012年推出的Android作業系統安全強化套件，以支援在Android平臺上使用SE Linux。

目前SE Android系統中的策略機制主要有三種：

安裝時MAC（install-time MAC） 
許可權取消（permission revocation） 
許可權標籤傳播（tag propagation） 
安裝時MAC通過查詢MAC策略配置來檢查應用程式的許可權。許可權取消可以為已安裝的應用取消許可權，該機制在應用程式執行的許可權檢查時通過查詢許可權取消列表來取消應用的某些許可權。許可權標籤傳播是一種汙點跟蹤方式的應用，Android系統的許可權作為抽象的標籤對映到MAC策略配置檔案中。

SE Android安全機制所要保護的物件是系統中的資源，這些資源分佈在各個子系統中。實際上，系統中需要保護的資源非常多，除了檔案之外，還有程序、socket和IPC等。SE Android是一個複雜的安全模型，本文就不進一步分析了。

如何解決這些安全問題

Android應用會遇到各種各樣的安全性問題，如何從巨集觀上了解各種安全隱患，積極採取適當的防禦措施便變得尤為重要。那麼，Android應用面臨哪些安全問題呢？

病毒 
關鍵資訊洩露 
APP重打包 
程序被劫持 
資料在傳輸過程遭劫持 
Webview漏洞 
病毒不用多說了，都是一些惡意軟體。關鍵資訊洩露，可能有些開發者並不十分留意。雖然Java程式碼可以做混淆，但是Android的幾大元件的建立方式是依賴注入的方式，因此不能被混淆。而且目前常用的一些反編譯工具比如apktool等能夠毫不費勁地還原Java裡的明文資訊，native裡的庫資訊也可以通過objdump或IDA獲取。因此一旦Java或native程式碼裡存在明文敏感資訊，基本上就是毫無安全而言的。重打包即通過反編譯後重新加入惡意的程式碼邏輯，重新打包一個APK檔案。程序被劫持一般通過程序注入或者除錯程序的方式來hook程序，改變程式執行的邏輯和順序，從而獲取程式執行的記憶體資訊。hook需要獲取root許可權或者跟被hook程序相同的許可權。如果手機沒被root，被劫持的可能性還是較小。資料在傳輸過程遭劫持，一般來說是由於資料明文傳輸或沒使用HTTPS。Webview漏洞一般由於JS注入。

現實中，出現的問題可能比上面提及的還要多。總的來說，應該從以下幾個方面來應對Android開發的常見安全問題：

應用許可權控制。通過控制應用程式的許可權防止惡意應用對系統造成破壞，採取的措施包括合理使用系統內建許可權和應用程式自定義許可權。 
應用程式簽名。採用數字簽名為應用程式簽名。 
應用加固。應用加固包括病毒掃描、防注入、防除錯、防篡改四個模組，目前行業內已經出現了很多的應用加固解決方案，如360應用加固、騰訊雲應用加固、百度應用加固等等。 
靜態程式碼分析。通過靜態程式碼分析工具lint監測安全隱患，對程式碼進行優化。 
防火牆。必要時為Android裝置安裝防火牆，以防止遠端網路攻擊。 
資料儲存加密。採用加密的方式保護應用程式敏感資料，如利用SQLCipher加密SQLite資料庫。 
應用程式元件開發的安全要點。Activity, Service, Content Provider, Broadcast Receiver等元件在程式碼層面應採取的安全措施。它們每一個都可以通過隱式的Intent方式開啟，所以這些元件只要不是對外公開的必須在AndroidManifest裡面註明exported為false，禁止其它程式訪問我們的元件。對於要和外部互動的元件，應當新增訪問許可權的控制，還需要要對傳遞的資料進行安全的校驗。
--------------------- 
作者：tangsilian 
來源：CSDN 
原文：https://blog.csdn.net/tangsilian/article/details/51812477 
版權宣告：本文為博主原創文章，轉載請附上博文連結！