TWI649694B - 一種安卓動態框架及其方法 - Google Patents

一種安卓動態框架及其方法 Download PDF

Info

Publication number
TWI649694B
TWI649694B TW106137368A TW106137368A TWI649694B TW I649694 B TWI649694 B TW I649694B TW 106137368 A TW106137368 A TW 106137368A TW 106137368 A TW106137368 A TW 106137368A TW I649694 B TWI649694 B TW I649694B
Authority
TW
Taiwan
Prior art keywords
function
hook
apk
file
intercepted
Prior art date
Application number
TW106137368A
Other languages
English (en)
Other versions
TW201917569A (zh
Inventor
廖世偉
林冠宇
劉建旻
楊傑勛
賈脈瑄
李宜霖
柯百嶽
Original Assignee
國立臺灣大學
聯發科技股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 國立臺灣大學, 聯發科技股份有限公司 filed Critical 國立臺灣大學
Priority to TW106137368A priority Critical patent/TWI649694B/zh
Priority to US15/897,153 priority patent/US20190129733A1/en
Application granted granted Critical
Publication of TWI649694B publication Critical patent/TWI649694B/zh
Publication of TW201917569A publication Critical patent/TW201917569A/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45529—Embedded in an application, e.g. JavaScript in a Web browser

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

一種安卓動態框架ADF(Android Dynamic Framework)及其方法，係應用於安卓虛擬機(Virtual Machine)的函式攔截替換技術環境中，利用本發明之安卓動態框架進行其方法以完成函式攔截替換時，首先進行應用程式APP開展APP Launch，並檢查版本(Version);而當版本需要即時更新(Patch)時，將下載勾行檔案Hook Files，包含Hook Apk與DF_File;進而，判斷是否為Native Hook，若為Native Hook，則編譯(Compile)Hook Apk，而若非為Native Hook，則更新Hook Share Library;繼之，將重新啟動應用程式APP。

Description

一種安卓動態框架及其方法
本發明係有關於安卓系統及方法，更詳而言之，係有關於一種應用於安卓虛擬機VM(Virtual Machine)之函式攔截替換技術環境的安卓動態框架ADF(Android Dynamic Framework)及其方法，利用修改虛擬機的Class Loading相關機制、以及途徑，使用者不需要Root 手機獲得最高權限，能對原生函式進行攔截替換，也不須安裝另外的控制應用程式即可進行基於Android虛擬機的修改而達成應用程式APP函式攔截，並在不影響系統效能、不需ROOT 權限的情況下，能對JAVA 及原生函式進行攔截與替換。
就現今的手機系統使用而言，安卓Android 是世界上最大的開源程式碼系統之一，而各家手機廠都能夠對其修改並擁有自己客製化的版本，然而，是存在著一些問題。
習知技術所碰到的問題有，缺乏模組化：許多廠商會同時推出多款行動裝置，而各裝置間可能只有小部分的變動，但卻需要花同樣多的時間去開發、驗證、測試。換言之，目前之習知技術無法能實現將行動裝置模組化，抽換不同行動裝置的特定函式，大幅縮短開發、測試的時間成本。
另，由於Android API 的快速變動：Android 不間斷的推出新的版本、新的API，而這對APP 的開發者是一大負擔，當使用者更新了他的Android系統使API 有了改動，開發者的APP 很可能就失去功能，造成使用者體驗不佳。換言之，目前的習知技術無法解決如何能讓透過函式的攔截與替換，讓使開發者能夠即時替換掉使用過時API 的函式，達到熱修復的功能。
再，目前習知技術無法具有應用程式的靈活性：在原本的系統中，除非重新編譯APK 否則用戶無法改變任何現有的程式行為。換言之，目前的習知技術無法解決如何實現在不修改任何原始碼的情況下，動態的在任意函式前後注入新的客製函式，而能提升了應用程式的靈活性。
雖然目前國外已有Android 的函示攔截替換之相關技術，例如， Xposed:http://repo.xposed.info/module/de.robv.android.xposed.installer，而Xposed的技術是提出了一個利用Proxy Handler 的做法實現函式的攔截與替換，該應用透過在欲攔截的函式前加入Proxy Handler，當呼叫的此函式時，該Proxy Handler 就會透過JNI (Java Native Interface)呼叫該應用的管理程序(Xposed Bridge)，再由該管理程序決定是否進行攔截與替換。
惟，就Xposed技術而言，雖然也能完成函式的攔截與替換，但由於實作的方式，有幾項不可避免的缺點：1.JNI呼叫的成本很高，使用者將會感到不流暢，使得體驗不佳;2.該應用的管理程序需要ROOT權限，所以使用者需要利用漏洞破解行動裝置進而取得最高權限，造成系統暴露在風險中;3.一個應用程式APP 的應用，使用了不只JAVA 的函式，還會用到NATIVE 原生函式來建構。而此應用僅能攔截替換JAVA 函式，對原生函式沒辦法進行攔截替換，使得實用性受限;以及，4.在函式攔截替換失敗時，往往會造成系統的崩壞。造成的後果，輕則應用程式停止執行，重則整個系統崩壞，需重新啟動裝置。換言之，在此類技術的操作方式中，使用者需要犧牲系統效能，ROOT 行動裝置，使其能得到最高權限，以及攔截只侷限在JAVA 函式的問題。
所以，如何能解決，Xposed技術所造成的問題，能實現將行動裝置模組化，抽換不同行動裝置的特定函式，大幅縮短開發、測試的時間成本;能讓透過函式的攔截與替換，讓使開發者能夠即時替換掉使用過時API 的函式，達到熱修復的功能;以及，能實現在不修改任何原始碼的情況下，動態的在任意函式前後注入新的客製函式，而能提升了應用程式的靈活性;換言之，如何能基於Android 虛擬機的修改，達到函式攔截的目的，並在不影響系統效能、不需ROOT 權限的情況下，能對JAVA 及原生函式進行攔截與替換;以上種種討論，均是待解決的問題。
本發明之主要目的便是在於提供一種安卓動態框架ADF(Android Dynamic Framework)及其方法，係應用於安卓虛擬機VM(Virtual Machine)的函式攔截替換技術環境中，利用修改虛擬機的Class Loading相關機制、以及途徑，使用者不需要Root 手機獲得最高權限，能對原生函式進行攔截替換，也不須安裝另外的控制應用程式即可進行基於Android虛擬機的修改而達成應用程式APP函式攔截，並在不影響系統效能、不需ROOT 權限的情況下，能對JAVA 及原生函式進行攔截與替換。
本發明之又一目的便是在於提供一種安卓動態框架ADF及其方法，係應用於安卓虛擬機VM的函式攔截替換技術環境中，能實現將行動裝置模組化，抽換不同行動裝置的特定函式，大幅縮短開發、測試的時間成本;能讓透過函式的攔截與替換，讓使開發者能夠即時替換掉使用過時API 的函式，達到熱修復的功能;以及，能實現在不修改任何原始碼的情況下，動態的在任意函式前後注入新的客製函式，而能提升了應用程式的靈活性。
本發明之再一目的便是在於提供一種安卓動態框架ADF及其方法，係應用於安卓虛擬機VM的函式攔截替換技術環境中，開發一個基於Android 虛擬機之Android 動態框架，能夠在不修改任何原始APK的前提下，動態改變應用程式APP的行為，且不影響系統效能與穩定性，透過此種機制能夠更加強化Android系統的靈活性，並做到現今 Android 系統尚無法做到的各種應用。
本發明之另一目的便是在於提供一種安卓動態框架ADF及其方法，係應用於安卓虛擬機VM的函式攔截替換技術環境中，利用修改虛擬機的途徑，可解決Xposed技術所造成的問題;可用於任何手機應用程式App，在操作上，使用者不需要修改任何原生應用程式App;透過使用者推送修改後的函式及控制文件，即會攔截就函式並進行替換;可藉由攔截任一App 的onCreate 函式達成封鎖自定義黑名單中的應用程式App (AppBlocker);可進行遠端即時原始碼更新，讓使用者不必重新下載整包 APK 檔案，也不必重新安裝，APP開發者也不必重新打包釋出APK，只需要替換掉有問題的函式;以及，可藉由攔截第三方廣告API 並攔截相關函式，達成廣告屏蔽(AdBlocker)。
根據以上所述之目的，本發明提供一種安卓動態框架ADF，該安卓動態框架ADF包含處理機制(mechanism)、以及替換表(Replace Table)。
當應用程式APP啟動時，Google ART虛擬機進行應用程式APP Launching System Flow以便將所有Class與Method載入完成，並會進行連結程式碼(Link Code)。每一個ArtMethod物件都有一個進入點(Entrypoint)，進入點會決定這個函式要如何執行，而Link Code的工作就是設定每一個ArtMethod的進入點，如果函式在安裝時有經由AOT產生原生機器碼，ART就會將它對應的ArtMethod進入點與對應的OatMethod進行連結，而OatMethod中儲存著此函式的機器碼位置，因此當這個ArtMethod被執行時，就會自動跳轉到預先產生的機器碼。但並非所有的函式都會進行AOT產生原生機器碼，因此部份沒有預編譯的函式，其對應的ArtMethod進入點就會被設定為DexFile中此函式的DEX Code，當這個ArtMethod被執行時，就會跳轉到DEX Code並交由直譯器(Interpreter)來執行。
處理機制，於所有Class與Method載入完成後，該處理機制將可直接對Google ART虛擬機進行修改，攔截替換原生函式(Native Library Function);首先，定義要被攔截的函式以及要用哪一個函式來予以代替，這樣的資訊被定義在名為"DF_File"的檔案中，而於DF-File Format，內容詳細定義了被抽換函式(亦即，Original Method)以及代替函式(亦即，Hook Method)的所在Class名稱、函式名稱、函式簽名(Signature)，另外當然也必須要提供一個包含Hook Method的APK檔案，稱為Hook Apk。
另，當啟動一個應用程式APP時，該處理機制會依序做以下三件事:1.載入DF_File;2.載入Hook Apk;以及，3. 載入APP APK並判斷每個函式是否需要被攔截抽換;在此，該處理機制首先會將 DF_File 讀入記憶體，寫入特殊之資料結構的替換表中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代。替換表(Replace Table)初始化完成後，會載入 Hook Apk，若 Hook Apk 是首次被載入，系統會先對其進行編譯，此時，系統記憶體中擁有Hook Apk中所有Class 的所有 ArtMethod 物件。一切就緒後，開始載入 APP Class 的工作。ClassLinker 會將APK 中的 Class 一個一個讀入記憶體，並寫入對應的資料結構。而系統在載入 ArtMethod 時，就是我們對其攔截的時間點。在每次載入函式並寫入ArtMethod 之前，系統都會去查詢 Replace Table 中的資訊，檢查此函式是否需要被攔截抽換。如果沒有，就照常載入，如果是需要被攔截的對象，系統就會從預先載入的 Hook Class 中取出候選的替換 函式之ArtMethod 物件，並將此物件整個複製到 APP 原本預計要載入的 Original Method 的 ArtMethod 物件中。
替換表，處理機制首先會將DF_File讀入記憶體，寫入特殊之資料結構的替換表(Replace Table)中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代;於替換表(Replace Table)初始化完成後，會載入Hook ApK，若Hook ApK是首次被載入，系統會先對其進行編譯，此時，系統記憶體中擁有Hook Apk中所有Class的所有ArtMethod物件。
繼之，開始載入APP Class的工作，ClassLinker會將APK中的Class一個一個讀入記憶體，並寫入對應的資料結構，而處理機制在載入ArtMethod時，也就是對其攔截的時間點，在每次載入函式並寫入ArtMethod之前，處理機制都會去查詢替換表(Replace Table)中的資訊，檢查此函式是否需要被攔截替換;如果沒有，就照常載入，如果是需要被攔截的對象，處理機制就會從預先載入的Hook Class中取出候選的替換函式之ArtMethod物件，並將此物件整個複製到應用程式APP原本預計要載入的Original Method的ArtMethod物件中;因而，於之後應用程式APP在執行時，跳轉到的ArtMethod物件，即為被替換掉的函式。
利用本發明之安卓動態框架進行安卓動態框架方法的過程時，首先，進行應用程式APP開展APP Launch，並檢查版本(Version)。
之後，當版本需要即時更新(Patch)時，將下載勾行檔案Hook Files，包含Hook Apk與DF_file。
在此，其中，處理機制定義要被攔截的函式以及要用哪一個函式來予以代替，這樣的資訊被定義在名為"DF_File"的檔案中，而於DF_File Format，內容詳細定義了被抽換函式(亦即，Original Method)以及代替函式(亦即，Hook Method)的所在Class名稱、函式名稱、函式簽名(Signature)，另，提供一個包含Hook Method的APK檔案，稱為Hook Apk;以及，處理機制會將DF_File讀入記憶體，寫入特殊之資料結構的替換表(Replace Table)中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代，而替換表初始化完成後，會載入 Hook Apk。
進而，於替換表初始化完成並載入 Hook Apk後，將判斷是否為Native Hook，若為Native Hook，則編譯(Compile)Hook Apk，而若非為Native Hook，則更新Hook Share Library;亦即，於替換表(Replace Table)初始化完成後，會載入Hook Apk，若Hook Apk是首次被載入，處理機制會先對其進行編譯，而若非為首次被載入，則處理機制會更新Hook Share Library，此時，系統記憶體中擁有Hook Apk中所有Class的所有ArtMethod物件。
在此，其中，開始載入APP Class的工作，ClassLinker會將APK中的Class一個一個讀入記憶體，並寫入對應的資料結構，而處理機制在載入ArtMethod時，也就是對其攔截的時間點，在每次載入函式並寫入ArtMethod之前，處理機制都會去查詢替換表(Replace Table)中的資訊，檢查此函式是否需要被攔截替換;如果沒有，就照常載入，如果是需要被攔截的對象，處理機制就會從預先載入的Hook Class中取出候選的替換函式之ArtMethod物件，並將此物件整個複製到應用程式APP原本預計要載入的Original Method的ArtMethod物件中;因而，於之後應用程式APP在執行時，跳轉到的ArtMethod物件，即為被替換掉的函式。
繼之，將重新啟動應用程式APP。
爲使熟悉該項技藝人士瞭解本發明之目的、特徵及功效，茲藉由下述具體實施例，並配合所附之圖式，對本發明詳加說明如後:
第1圖為一系統示意圖，用以顯示說明本發明之安卓動態框架之系統架構、以及運作情形。如第1圖中所示之，安卓動態框架ADF 1包含處理機制(mechanism)2、以及替換表(Replace Table)3。
當應用程式APP啟動時，Google ART虛擬機(未圖示之)進行應用程式APP Launching System Flow以便將所有Class與Method載入完成，並會進行連結程式碼(Link Code)。每一個ArtMethod物件都有一個進入點(Entrypoint)，進入點會決定這個函式要如何執行，而Link Code的工作就是設定每一個ArtMethod的進入點，如果函式在安裝時有經由AOT產生原生機器碼，ART就會將它對應的ArtMethod進入點與對應的OatMethod進行連結，而OatMethod中儲存著此函式的機器碼位置，因此當這個ArtMethod被執行時，就會自動跳轉到預先產生的機器碼。但並非所有的函式都會進行AOT產生原生機器碼，因此部份沒有預編譯的函式，其對應的ArtMethod進入點就會被設定為DexFile中此函式的DEX Code，當這個ArtMethod被執行時，就會跳轉到DEX Code並交由直譯器(Interpreter)來執行。
處理機制2，於所有Class與Method載入完成後，該處理機制2將可直接對Google ART虛擬機進行修改，攔截替換原生函式(Native Library Function);首先，定義要被攔截的函式以及要用哪一個函式來予以代替，這樣的資訊被定義在名為"DF_File"的檔案中，而於DF_File Format，內容詳細定義了被抽換函式(亦即，Original Method)以及代替函式(亦即，Hook Method)的所在Class名稱、函式名稱、函式簽名(Signature)，另外當然也必須要提供一個包含Hook Method的APK檔案，稱為Hook Apk。
另，當啟動一個應用程式APP時，該處理機制2會依序做以下三件事:1.載入DF_File;2.載入Hook Apk;以及，3.載入APP APK並判斷每個函式是否需要被攔截抽換;在此，該處理機制2首先會將 DF_File 讀入記憶體(未圖示之)，寫入特殊之資料結構的替換表3中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代。替換表(Replace Table)3初始化完成後，會載入 Hook Apk，若 Hook Apk 是首次被載入，系統會先對其進行編譯，此時，系統記憶體中擁有Hook Apk中所有Class 的所有 ArtMethod 物件。一切就緒後，開始載入 APP Class 的工作。ClassLinker 會將APK 中的 Class 一個一個讀入記憶體，並寫入對應的資料結構。而系統在載入 ArtMethod 時，就是我們對其攔截的時間點。在每次載入函式並寫入ArtMethod 之前，系統都會去查詢替換表3中的資訊，檢查此函式是否需要被攔截抽換。如果沒有，就照常載入，如果是需要被攔截的對象，系統就會從預先載入的 Hook Class 中取出候選的替換函式之ArtMethod 物件，並將此物件整個複製到APP原本預計要載入的 Original Method 的 ArtMethod 物件中。
替換表3，處理機制2首先會將DF_File讀入記憶體，寫入特殊之資料結構的替換表3中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代;於替換表3初始化完成後，會載入Hook Apk，若Hook Apk是首次被載入，系統會先對其進行編譯，此時，系統記憶體中擁有Hook Apk中所有Class的所有ArtMethod物件。
繼之，開始載入APP Class的工作，ClassLinker會將APK中的Class一個一個讀入記憶體，並寫入對應的資料結構，而處理機制2在載入ArtMethod時，也就是對其攔截的時間點，在每次載入函式並寫入ArtMethod之前，處理機制2都會去查詢替換表3中的資訊，檢查此函式是否需要被攔截替換;如果沒有，就照常載入，如果是需要被攔截的對象，處理機制2就會從預先載入的Hook Class中取出候選的替換函式之ArtMethod物件，並將此物件整個複製到應用程式APP原本預計要載入的Original Method的ArtMethod物件中;因而，於之後應用程式APP在執行時，跳轉到的ArtMethod物件，即為被替換掉的函式。
第2圖為一流程圖，用以顯示說明利用如第1圖中之本發明之安卓動態框架以進行安卓動態框架方法的流程步驟。如第2圖中所示之，首先，於步驟101，進行應用程式APP開展APP Launch，並檢查版本，並進到步驟102。
於步驟102，當版本需要即時更新(Patch)時，將下載勾行檔案Hook Files，包含Hook Apk與DF_File，並進到步驟103。
在此，於步驟102，其中，處理機制2定義要被攔截的函式以及要用哪一個函式來予以代替，這樣的資訊被定義在名為"DF_File"的檔案中，而於DF_File 格式(Format)，內容詳細定義了被抽換函式(亦即，Original Method)以及代替函式(亦即，Hook Method)的所在Class名稱、函式名稱、函式簽名(Signature)，另，提供一個包含Hook Method的APK檔案，稱為Hook Apk;以及，處理機制2會將DF_File讀入記憶體，寫入特殊之資料結構的替換表3中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代，而替換表3初始化完成後，會載入 Hook Apk。
於步驟103，於替換表3初始化完成並載入 Hook Apk後，將判斷是否為Native Hook，若為Native Hook，則編譯Hook Apk，而若非為Native Hook，則更新Hook Share Library，並進到步驟104;亦即，於替換表3初始化完成後，會載入Hook Apk，若Hook Apk是首次被載入，處理機制2會先對其進行編譯，而若非為首次被載入，則處理機制2會更新Hook Share Library，此時，系統記憶體中擁有Hook Apk中所有Class的所有ArtMethod物件。
在此，於步驟103，其中，開始載入APP Class的工作，ClassLinker會將APK中的Class一個一個讀入記憶體，並寫入對應的資料結構，而處理機制2在載入ArtMethod時，也就是對其攔截的時間點，在每次載入函式並寫入ArtMethod之前，處理機制2都會去查詢替換表3中的資訊，檢查此函式是否需要被攔截替換;如果沒有，就照常載入，如果是需要被攔截的對象，處理機制2就會從預先載入的Hook Class中取出候選的替換函式之ArtMethod物件，並將此物件整個複製到應用程式APP原本預計要載入的Original Method的ArtMethod物件中;因而，於之後應用程式APP在執行時，跳轉到的ArtMethod物件，即為被替換掉的函式。
於步驟104，將重新啟動應用程式APP。
第3圖為一示意圖，用以顯示說明本發明之安卓動態框架的一實施例、以及實際運作情形。如第3圖中所示之，安卓動態框架ADF 1包含處理機制2、以及替換表3，用以處理新應用程式(New APP)8。
流程21，將所需之DexFile與DF_File讀入ROM 4，並進到流程22;其中，使用者可將DexFile與DF_File載入ROM 4並重新啟動(reboot)安卓虛擬機VM 5系統，而於啟始時間(boot time)不同階段(stage)，安卓動態框架1會使用DexFile與DF_File。
流程22，處理機制2將初始化替換表3，並進到流程23;其中，在啟始Zygote 6之前，安卓動態框架ADF 1之處理機制2將解析(parse)DF_File並利用輸出以初始化替換表3，該替換表3儲存所有之替換資訊(replacement information)。
Zygote 6是一種服務(daemon service)，主要工作是啟始(launch)應用程式APP程序(process)。而該程序的起始可經由init.rc的起動，是由app_process啟始。Zygote 6的主要工作是啟動系統伺服器(Start System Server)創造一接口socket，以傾聽(listening)啟始應用(starting application)，而於啟動系統伺服器之前，先進行Register Zygote、以及預載(Preload) Class。於運作時期，為增進應用程式APP啟始時間，Zygote 6會先預載所有之所需的Java classes以及資源(resources)。系統伺服器為由Zygote所啟始的第一個程序，於啟始後，Zygote開始傾聽一接口socket的指令以便啟始應用程式。而由於Android是基於Linux，將使用copy-on-write策略來引衍生(fork)程序。
流程23，編譯DexFile並預載(Preload)其classes，並進到流程24;其中，在啟始Zygote 6階段，處理機制2將編譯於ROM 4中的DexFile，並將其classes預載入記憶體中。
流程24，載入classes、查找(look up)替換表3，並進到流程25;其中，當Zygote 6預載classes或啟始應用程式時，Zygote 6經由ClassLinker而載入所需之classes object;以及，當載入class，而ClassLinker查找替換表3以確認於class中的methods是否為攔截替換對象。
流程25，於框架(framework)7中，替換欲攔截替換對象;其中，一旦ClassLinker所找到之method為攔截替換對象，ClassLinker將以相關之新method來替換該method。
當應用程式APP啟動時，Google ART虛擬機進行應用程式APP Launching System Flow以便將所有Class與Method載入完成，並會進行連結程式碼(Link Code)。每一個ArtMethod物件都有一個進入點(Entrypoint)，進入點會決定這個函式要如何執行，而Link Code的工作就是設定每一個ArtMethod的進入點，如果函式在安裝時有經由AOT產生原生機器碼，ART就會將它對應的ArtMethod進入點與對應的OatMethod進行連結，而OatMethod中儲存著此函式的機器碼位置，因此當這個ArtMethod被執行時，就會自動跳轉到預先產生的機器碼。但並非所有的函式都會進行AOT產生原生機器碼，因此部份沒有預編譯的函式，其對應的ArtMethod進入點就會被設定為DexFile中此函式的DEX Code，當這個ArtMethod被執行時，就會跳轉到DEX Code並交由直譯器(Interpreter)來執行。
處理機制2，於所有Class與Method載入完成後，該處理機制2將可直接對Google ART虛擬機進行修改，攔截替換原生函式(Native Library Function);首先，定義要被攔截的函式以及要用哪一個函式來予以代替，這樣的資訊被定義在如第4圖中的名為"DF_File"的檔案中。
另，當啟動一個應用程式APP時，該處理機制2會依序做以下三件事:1.載入DF_File;2.載入Hook Apk;以及，3.載入APP APK並判斷每個函式是否需要被攔截抽換;在此，該處理機制2首先會將 DF_File 讀入記憶體(未圖示之)，寫入特殊之資料結構的替換表3中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代。替換表3初始化完成後，會載入 Hook Apk，若 Hook Apk 是首次被載入，系統會先對其進行編譯，此時，系統記憶體中擁有Hook Apk中所有Class 的所有 ArtMethod 物件。一切就緒後，開始載入 APP Class 的工作。ClassLinker 會將APK 中的 Class 一個一個讀入記憶體，並寫入對應的資料結構。而系統在載入 ArtMethod 時，就是我們對其攔截的時間點。在每次載入函式並寫入ArtMethod 之前，系統都會去查詢替換表3中的資訊，檢查此函式是否需要被攔截抽換。如果沒有，就照常載入，如 果是需要被攔截的對象，系統就會從預先載入的 Hook Class 中取出候選的替換函式之ArtMethod 物件，並將此物件整個複製到APP原本預計要載入的 Original Method 的 ArtMethod 物件中。
替換表3，處理機制2首先會將DF_File讀入記憶體，寫入特殊之資料結構的替換表3中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代;於替換表3初始化完成後，會載入Hook Apk，若Hook Apk是首次被載入，系統會先對其進行編譯，此時，系統記憶體中擁有Hook Apk中所有Class的所有ArtMethod物件。
繼之，開始載入APP Class的工作，ClassLinker會將APK中的Class一個一個讀入記憶體，並寫入對應的資料結構，而處理機制2在載入ArtMethod時，也就是對其攔截的時間點，在每次載入函式並寫入ArtMethod之前，處理機制2都會去查詢替換表3中的資訊，檢查此函式是否需要被攔截替換;如果沒有，就照常載入，如果是需要被攔截的對象，處理機制2就會從預先載入的Hook Class中取出候選的替換函式之ArtMethod物件，並將此物件整個複製到應用程式APP原本預計要載入的Original Method的ArtMethod物件中;因而，於之後應用程式APP在執行時，跳轉到的ArtMethod物件，即為被替換掉的函式。
第4圖為一示意圖，用以顯示說明於第3圖中之DF_File Format格式。如第4圖中所述之，於DF-File Format，內容詳細定義了被抽換函式(亦即，Original Method)以及代替函式(亦即，Hook Method)的所在Class名稱、函式名稱、函式簽名(Signature)，另外當然也必須要提供一個包含Hook Method的APK檔案，稱為Hook Apk。
如第4圖中所述之，原先之Original Class Name途徑、原先之Original Method Signature、原先之Original Method Name、Hook Class Name、Hook Method Signature、以及Hook Method Name。
第5圖為一示意圖，用以顯示說明利用第3圖之實施例所進行的一method處理方法。如第5圖中所示之，所進行的method處理方法method 1與method 2為Before/After Hook方式，在此，進行廣告移除(AdBlocker)。
目前Android APP中的廣告大多來自第三方廣告API，因此分析第三方廣告API，替換特定APP 的onCreate 函式，造成該APP 無法被創建;在攔截抽換一個函式之後，可以藉由Java Reflection取得原始的函式並呼叫，並將其中關於廣告顯示相關的Method進行攔截後，就能夠很輕易地阻擋廣告顯示。
第6圖為一示意圖，用以顯示說明利用第3圖之實施例所進行的再一method處理方法。如第6圖中所示之，所進行的method處理方法為method 1與method 2 Beforea/After Hook方式，在此，進行函式擴展(Method Extension)。
如第6圖中所示之，在攔截抽換一個函式之後，可以藉由Java Reflection取得原始的函式並呼叫，如此一來可以就看作是在原始的函式前後多做了許多事情，達到"函式擴展(Method Extension)"的效果，而利用此方式，就能做到許多不同的應用。
第7圖為一流程圖，用以顯示說明利用如第3圖中之本發明之安卓動態框架的一實施例以進行安卓動態框架方法的一流程步驟。如第7圖中所示之，首先，於步驟201，進行應用程式APP開展APP Launch，並檢查版本(Version)，並進到步驟202。
於步驟202，判斷版本是否需要更新(Patch)，若無須更新則直接進到步驟203，而若版本必須更新，則進到步驟204。
於步驟203，啟始應用程式APP。
於步驟204，當版本需要即時更新(Patch)時，將下載勾行檔案Hook Files，包含Hook Apk與DF_File，並進到步驟205。
在此，於步驟204，其中，處理機制2定義要被攔截的函式以及要用哪一個函式來予以代替，這樣的資訊被定義在名為"DF_File"的檔案中，而於DF_File Format，內容詳細定義了被抽換函式(亦即，Original Method)以及代替函式(亦即，Hook Method)的所在Class名稱、函式名稱、函式簽名(Signature)，另，提供一個包含Hook Method的APK檔案，稱為Hook Apk;以及，處理機制2會將DF_File讀入記憶體，寫入特殊之資料結構的替換表3中，詳細記錄哪些函式必須要被攔截，並且由哪一個函式來做取代，而替換表3初始化完成後，會載入 Hook Apk。
於步驟205，於替換表3初始化完成並載入 Hook Apk後，將判斷是否為Native Hook，若為Native Hook，則進到步驟206;而若非為Native Hook，則進到步驟207。
於步驟206，編譯Hook Apk，並進到步驟208。
於步驟207，更新Hook Share Library，並進到步驟208。
亦即，於步驟205、206、207，於替換表3初始化完成後，會載入Hook Apk，若Hook Apk是首次被載入，處理機制2會先對其進行編譯，而若非為首次被載入，則處理機制2會更新Hook Share Library，此時，系統記憶體中擁有Hook Apk中所有Class的所有ArtMethod物件。
在此，於步驟205、206、207，開始載入APP Class的工作，ClassLinker會將APK中的Class一個一個讀入記憶體，並寫入對應的資料結構，而處理機制2在載入ArtMethod時，也就是對其攔截的時間點，在每次載入函式並寫入ArtMethod之前，處理機制2都會去查詢替換表3中的資訊，檢查此函式是否需要被攔截替換;如果沒有，就照常載入，如果是需要被攔截的對象，處理機制2就會從預先載入的Hook Class中取出候選的替換函式之ArtMethod物件，並將此物件整個複製到應用程式APP原本預計要載入的Original Method的ArtMethod物件中;因而，於之後應用程式APP在執行時，跳轉到的ArtMethod物件，即為被替換掉的函式。
於步驟208，重新啟動應用程式APP。
綜合以上之該些實施例，我們可以得到本發明之一種安卓動態框架ADF(Android Dynamic Framework)及其方法，係應用於安卓虛擬機(Virtual Machine)的函式攔截替換技術環境中，利用本發明之安卓動態框架進行其方法以完成函式攔截替換時，首先進行應用程式APP開展APP Launch，並檢查版本(Version);而當版本需要即時更新(Patch)時，將下載勾行檔案Hook Files，包含Hook Apk與DF_File;進而，判斷是否為Native Hook，若為Native Hook，則編譯(Compile)Hook Apk，而若非為Native Hook，則更新Hook Share Library;繼之，將重新啟動應用程式APP。本發明之安卓動態框架ADF(Android Dynamic Framework)及其方法包含以下優點:
利用修改虛擬機的Class Loading相關機制、以及途徑，使用者不需要Root 手機獲得最高權限，能對原生函式進行攔截替換，也不須安裝另外的控制應用程式即可進行基於Android虛擬機的修改而達成應用程式APP函式攔截，並在不影響系統效能、不需ROOT 權限的情況下，能對JAVA 及原生函式進行攔截與替換。
能實現將行動裝置模組化，抽換不同行動裝置的特定函式，大幅縮短開發、測試的時間成本;能讓透過函式的攔截與替換，讓使開發者能夠即時替換掉使用過時API 的函式，達到熱修復的功能;以及，能實現在不修改任何原始碼的情況下，動態的在任意函式前後注入新的客製函式，而能提升了應用程式的靈活性。
開發一個基於Android 虛擬機之Android 動態框架，能夠在不修改任何原始APK的前提下，動態改變應用程式APP的行為，且不影響系統效能與穩定性。透過此種機制能夠更加強化Android系統的靈活性，並做到現今 Android 系統尚無法做到的各種應用。
利用修改虛擬機的途徑，可解決Xposed技術所造成的問題;可用於任何手機應用程式App，在操作上，使用者不需要修改任何原生應用程式App;透過使用者推送修改後的函式及控制文件，即會攔截就函式並進行替換;可藉由攔截任一App 的onCreate 函式達成封鎖自定義黑名單中的應用程式App (AppBlocker);可進行遠端即時原始碼更新，讓使用者不必重新下載整包 APK 檔案，也不必重新安裝，APP開發者也不必重新打包釋出APK，只需要替換掉有問題的函式;以及，可藉由攔截第三方廣告API 並攔截相關函式，達成廣告屏蔽(AdBlocker)。
以上所述僅為本發明之較佳實施例而已，並非用以限定本發明之範圍;凡其它未脫離本發明所揭示之精神下所完成之等效改變或修飾，均應包含在下述之專利範圍內。
1‧‧‧安卓動態框架ADF
2‧‧‧處理機制
3‧‧‧替換表
4‧‧‧ROM
5‧‧‧安卓虛擬機VM
6‧‧‧Zygote
7‧‧‧框架
8‧‧‧新應用程式
21 22 23 24 25‧‧‧流程
101 102 103 104‧‧‧步驟
201 202 203 204 205 206 207 208‧‧‧步驟
第1圖為一系統示意圖，用以顯示說明本發明之安卓動態框架之系統架構、以及運作情形; 第2圖為一流程圖，用以顯示說明利用如第1圖中之本發明之安卓動態框架以進行安卓動態框架方法的流程步驟; 第3圖為一示意圖，用以顯示說明本發明之安卓動態框架的一實施例、以及實際運作情形; 第4圖為一示意圖，用以顯示說明於第3圖中之DF_File Format格式; 第5圖為一示意圖，用以顯示說明利用第3圖之實施例所進行的一method處理方法; 第6圖為一示意圖，用以顯示說明利用第3圖之實施例所進行的再一method處理方法;以及 第7圖為一流程圖，用以顯示說明利用如第3圖中之本發明之安卓動態框架的一實施例以進行安卓動態框架方法的一流程步驟。

Claims (6)

  1. 一種安卓動態框架ADF方法，係應用於安卓虛擬機的函式攔截替換技術環境中，包含以下程序：進行應用程式APP開展APP Launch，並檢查版本；當該版本需要即時更新時，將下載包含Hook Apk與DF_File的勾行檔案Hook Files；判斷是否為Native Hook，若為Native Hook，則編譯該Hook Apk，而若非為該Native Hook，則更新Hook Share Library；以及將重新啟動該應用程式APP；其中，利用修改該安卓虛擬機的Class Loading相關機制、以及途徑，能對原生函式進行攔截替換，該DF_File包含被攔截之函式的資訊、以及替換被攔截之該函式的函式的資訊。
  2. 如申請專利範圍第1項所述之安卓動態框架ADF方法，其中，於該DF_File的格式，定義了被攔截之該函式、以及代替函式的所在Class名稱、函式名稱、函式簽名，提供一個包含Hook Method的該Hook Apk，其中，該代替函式為替換被攔截之該函式的該函式。
  3. 如申請專利範圍第2項所述之安卓動態框架ADF方法，其中，將該DF_File讀入記憶體，寫入替換表中，記錄被攔截之該函式、以及該代替函式，於該替換表初始化完成後，會載入該Hook Apk。
  4. 一種安卓動態框架ADF，係應用於安卓虛擬機的函式攔截替換技術環境中，包含：替換表；以及 處理機制，進行應用程式APP開展APP Launch檢查版本，當該版本需要即時更新時，該處理機制將下載包含Hook Apk與DF_File的勾行檔案Hook Files；該處理機制判斷是否為Native Hook，若為Native Hook，則編譯該Hook Apk，而若非為該Native Hook，則更新Hook Share Library；以及，該處理機制會將該DF_File讀入記憶體，寫入該替換表中；其中，利用修改該安卓虛擬機的Class Loading相關機制、以及途徑，能對原生函式進行攔截替換，該DF_File包含被攔截之函式的資訊、以及替換被攔截之該函式的函式的資訊。
  5. 如申請專利範圍第4項所述之安卓動態框架ADF，其中，於該DF_File的格式，定義了被攔截之該函式、以及代替函式的所在Class名稱、函式名稱、函式簽名，提供一個包含Hook Method的該Hook Apk，其中，該代替函式為替換被攔截之該函式的該函式。
  6. 如申請專利範圍第5項所述之安卓動態框架ADF，其中，將該DF_File讀入該記憶體，寫入該替換表中，記錄被攔截之該函式、以及該代替函式，於該替換表初始化完成後，會載入該Hook Apk。
TW106137368A 2017-10-30 2017-10-30 一種安卓動態框架及其方法 TWI649694B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
TW106137368A TWI649694B (zh) 2017-10-30 2017-10-30 一種安卓動態框架及其方法
US15/897,153 US20190129733A1 (en) 2017-10-30 2018-02-15 Android dynamic framework and a method thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TW106137368A TWI649694B (zh) 2017-10-30 2017-10-30 一種安卓動態框架及其方法

Publications (2)

Publication Number Publication Date
TWI649694B true TWI649694B (zh) 2019-02-01
TW201917569A TW201917569A (zh) 2019-05-01

Family

ID=66213498

Family Applications (1)

Application Number Title Priority Date Filing Date
TW106137368A TWI649694B (zh) 2017-10-30 2017-10-30 一種安卓動態框架及其方法

Country Status (2)

Country Link
US (1) US20190129733A1 (zh)
TW (1) TWI649694B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114138344A (zh) * 2020-09-04 2022-03-04 青岛海信移动通信技术股份有限公司 一种系统校验的方法及终端

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113050962B (zh) * 2019-12-27 2024-04-26 华为技术有限公司 移动服务升级方法、装置和终端
CN111352673B (zh) * 2020-01-02 2023-10-03 上海域幂信息科技有限公司 一种新型Hook方法、存储介质及电子装置
CN111523097B (zh) * 2020-04-09 2023-08-29 北京智慧章鱼科技有限公司 基于安卓系统的app刷子用户识别方法、设备及存储介质
CN111444065B (zh) * 2020-05-18 2022-03-11 江苏电力信息技术有限公司 一种基于AspectJ的移动端性能指标监控方法
CN113238946A (zh) * 2021-05-18 2021-08-10 北京达佳互联信息技术有限公司 检测hook框架的方法、装置及电子设备
CN113268280B (zh) * 2021-05-19 2022-11-01 网易（杭州）网络有限公司 动态加载插件的方法、装置及电子设备
CN115114148A (zh) * 2022-06-15 2022-09-27 马上消费金融股份有限公司 应用程序的合规检测方法、装置及电子设备
CN116126427B (zh) * 2023-04-14 2023-07-18 杭州比智科技有限公司 基于面向切面编程的无侵入sdk辅助集成插件的实现方法
CN116991504B (zh) * 2023-09-26 2024-02-23 厦门她趣信息技术有限公司 一种安卓App多资源动态加载、更新方法和装置以及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104793980A (zh) * 2015-05-19 2015-07-22 北京奇虎科技有限公司 应用程序更新通知方法及其装置
CN106203120A (zh) * 2016-07-15 2016-12-07 北京邮电大学 一种针对Android加固应用的多点Hook逆向方法
TW201706834A (zh) * 2014-08-07 2017-02-16 飛搜股份有限公司 應用程式與虛擬機器通訊連接的系統與方法
US9594905B1 (en) * 2013-02-23 2017-03-14 Fireeye, Inc. Framework for efficient security coverage of mobile software applications using machine learning
CN107220074A (zh) * 2016-03-21 2017-09-29 阿里巴巴集团控股有限公司 对支撑层软件功能的访问、升级方法及装置
CN107220083A (zh) * 2017-05-22 2017-09-29 韩皓 一种安卓系统中免安装运行应用程序的方法和系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140007117A1 (en) * 2012-06-13 2014-01-02 Bluebox Methods and apparatus for modifying software applications
US9087191B2 (en) * 2012-08-24 2015-07-21 Vmware, Inc. Method and system for facilitating isolated workspace for applications
US20160085513A1 (en) * 2014-09-19 2016-03-24 Microsoft Corporation Loading Code in Self-Contained Applications
EP3576436B1 (en) * 2014-12-29 2021-02-17 Visa International Service Association Over-the-air provisioning of application library

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9594905B1 (en) * 2013-02-23 2017-03-14 Fireeye, Inc. Framework for efficient security coverage of mobile software applications using machine learning
TW201706834A (zh) * 2014-08-07 2017-02-16 飛搜股份有限公司 應用程式與虛擬機器通訊連接的系統與方法
CN104793980A (zh) * 2015-05-19 2015-07-22 北京奇虎科技有限公司 应用程序更新通知方法及其装置
CN107220074A (zh) * 2016-03-21 2017-09-29 阿里巴巴集团控股有限公司 对支撑层软件功能的访问、升级方法及装置
CN106203120A (zh) * 2016-07-15 2016-12-07 北京邮电大学 一种针对Android加固应用的多点Hook逆向方法
CN107220083A (zh) * 2017-05-22 2017-09-29 韩皓 一种安卓系统中免安装运行应用程序的方法和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Costamagna, V., & Zheng, C. (2016, April). ARTDroid: A Virtual-Method Hooking Framework on Android ART Runtime. In IMPS@ ESSoS (pp. 20-28). *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114138344A (zh) * 2020-09-04 2022-03-04 青岛海信移动通信技术股份有限公司 一种系统校验的方法及终端
CN114138344B (zh) * 2020-09-04 2024-06-04 青岛海信移动通信技术有限公司 一种系统校验的方法及终端

Also Published As

Publication number Publication date
TW201917569A (zh) 2019-05-01
US20190129733A1 (en) 2019-05-02

Similar Documents

Publication Publication Date Title
TWI649694B (zh) 一種安卓動態框架及其方法
US9996374B2 (en) Deployment and installation of updates in a virtual environment
Olivier et al. A binary-compatible unikernel
US10938954B2 (en) Method and system for mobile applications update in the cloud
CN109491695B (zh) 一种集成安卓应用的增量更新方法
Smalley et al. Security enhanced (se) android: bringing flexible mac to android.
US10241774B2 (en) Release lifecycle management system for multi-node application
TWI579769B (zh) 虛擬機遷移工具
US9208328B2 (en) Security system and method for operating systems
US10296323B2 (en) System and method for fast initial and incremental deployment of apps
US20150332043A1 (en) Application analysis system for electronic devices
US11340893B2 (en) Mobile application update preserving changes to the application made by a client
US6754828B1 (en) Algorithm for non-volatile memory updates
JP2021002317A (ja) アプリケーションをアップグレードするための方法、装置、デバイスならびに記憶媒体
US8701104B2 (en) System and method for user agent code patch management
WO2019019668A1 (zh) 应用程序启动方法、装置、计算机设备和存储介质
US9378013B2 (en) Incremental source code analysis
CN111880987A (zh) 应用程序的动态监测方法、装置、存储介质以及电子装置
RU2635891C2 (ru) Механизм инсталляции и формат пакета для распараллеливаемых надежных инсталляций
US20200379742A1 (en) Validation of configurations of factory installations
CN103793248A (zh) 一种应用程序升级的方法及装置
US20170322792A1 (en) Updating of operating system images
CN109933355B (zh) 应用程序升级方法及装置
WO2022120640A1 (zh) 基于electron的更新方法及系统
CN104699618A (zh) 指定用户对高权限进程自动化测试的方法及装置