APK檔案淺析-Android

  2011~2015，5年時間，斷斷續續學習了Android。
  最近打算在2011年2個月認真學習的基礎上，深入學習下。
  由於有之前的Android基礎，加上N年的Java等變成經驗，自我感覺Android應用開發還是比較簡單的。
  至少相比iOS開發來說。
  
  繼續堅持自己的習慣，寫點自己的體會，總結自己的經驗。
  學了又忘了，沒啥用啊~
  
  Android打包之後，生成了APK檔案。
  APK檔案其實是個zip檔案。
  
  比如，FileExplorer.apk，把字尾改成zip，就成了 FileExplorer.zip。
  類似的還有Excel檔案，比如FansUnion.xlsx，改字尾FansUnion.zip，解壓之後：
  _rels
  docProps
  xl
  [Content_Types].xml
  有興趣的可以自己試試哦~
  
  
  
  解壓之後：
  META-INF
    --CERT.RSA
--CERT.SF
--MANIFEST.MF（Java打包的程式，基本都有這個檔案.最初以為和Java中的一樣，後來發現不是的。）

     （1）MANIFEST.MF：這是摘要檔案。程式遍歷Apk包中的所有檔案(entry)，對非資料夾非簽名檔案的檔案，逐個用SHA1生成摘要資訊，再用Base64進行編碼。如果你改變了apk包中的檔案，那麼在apk安裝校驗時，改變後的檔案摘要資訊與MANIFEST.MF的檢驗資訊不同，於是程式就不能成功安裝。
說明：如果攻擊者修改了程式的內容，有重新生成了新的摘要，那麼就可以通過驗證，所以這是一個非常簡單的驗證。
（2）CERT.SF：這是對摘要的簽名檔案。對前一步生成的MANIFEST.MF，使用SHA1-RSA演算法，用開發者的私鑰進行簽名。在安裝時只能使用公鑰才能解密它。解密之後，將它與未加密的摘要資訊（即，MANIFEST.MF檔案）進行對比，如果相符，則表明內容沒有被異常修改。
說明：在這一步，即使開發者修改了程式內容，並生成了新的摘要檔案，但是攻擊者沒有開發者的私鑰，所以不能生成正確的簽名檔案（CERT.SF）。系統在對程式進行驗證的時候，用開發者公鑰對不正確的簽名檔案進行解密，得到的結果和摘要檔案（MANIFEST.MF）對應不起來，所以不能通過檢驗，不能成功安裝檔案。
（3）CERT.RSA檔案中儲存了公鑰、所採用的加密演算法等資訊。
說明：系統對簽名檔案進行解密，所需要的公鑰就是從這個檔案裡取出來的。
結論：從上面的總結可以看出，META-INFO裡面的說那個檔案環環相扣，從而保證Android程式的安全性。（只是防止開發者的程式不被攻擊者修改，如果開發者的公私鑰對對攻擊者得到或者開發者開發出攻擊程式，Android系統都無法檢測出來。）

  res（各種XML資原始檔）
   --drawable
   --layout
   --等等
   
   這個目錄，有個特別的“戰略意義”~
   上次看一篇Android文章，關於漢化的。漢化Android程式，先把APK檔案解壓，然後修改res資原始檔，最後再次打包，再安裝，
 這樣就漢化了Android程式。我覺得，理論是可行的，目前沒有試過。
 
 AndroidManifest.xml（Android專案的標準檔案）
 
 classes.dex（Java檔案最後生成的，.java->.class->.dex）
 resources.arsc(也是資原始檔）
 只有那些型別為res/animator、res/anim、res/color、res/drawable（非Bitmap檔案，即非.png、.9.png、.jpg、.gif檔案）、
 res/layout、res/menu、res/values和res/xml的資原始檔均會從文字格式的XML檔案編譯成二進位制格式的XML檔案。
 好處應該是效率。
 
 參考資料：
  Android簽名與認證詳細分析之一（CERT.RSA剖析）
http://myeyeofjava.iteye.com/blog/2125348

 Android應用程式資源的編譯和打包過程分析
 http://www.cnblogs.com/mfryf/archive/2013/05/21/3090844.html
 
 
 小雷FansUnion--一個正在學習Android的程式設計師