一種Android系統(tǒng)下APK簽名認(rèn)證方法
【專利摘要】本發(fā)明提供了一種Android系統(tǒng)下APK簽名認(rèn)證方法,該方法基于現(xiàn)有技術(shù)中APK簽名認(rèn)證的方法,該方法將需要執(zhí)行的文件和原執(zhí)行文件分別放在兩個(gè)文件夾中,再將兩個(gè)文件夾放在同一個(gè)文件夾壓縮包中,同時(shí)保證需要執(zhí)行的文件在文件壓縮包中的位置為可執(zhí)行文件的最前面,原執(zhí)行文件在文件壓縮包中的位置為可執(zhí)行文件的最后面,從而既通過簽名驗(yàn)證,又能執(zhí)行新的執(zhí)行文件。該方法可以對手機(jī)等基于Android系統(tǒng)的電子產(chǎn)品用戶的行為進(jìn)行監(jiān)控,以防止一些信息的泄露等不安全因素,或者應(yīng)公安機(jī)關(guān)等安全部門的需求,對非法行為進(jìn)行監(jiān)控。
【專利說明】—種Android系統(tǒng)下APK簽名認(rèn)證方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種APK簽名認(rèn)證方法,特別是涉及一種基于Android系統(tǒng)下進(jìn)行APK簽名認(rèn)證的方法。
【背景技術(shù)】
[0002]Android是Google公司開發(fā)的基于Linux架構(gòu)的開源手機(jī)操作系統(tǒng)。其上的安裝程序均為APK (Android Package)格式,APK實(shí)質(zhì)上是一個(gè)ZIP壓縮文件,其中存在RES資源文件、AndroidManifest.xml權(quán)限配置文件及Classes, dex核心dalvik虛擬機(jī)文件等,并對這些文件均進(jìn)行了簽名認(rèn)證(通過SHAl-RSA算法)。
[0003]當(dāng)進(jìn)行APK安裝時(shí),手機(jī)底層核心庫文件會對APK進(jìn)行安裝前檢測(Pre-1nstallVerification),其核心手段是對Classes, dex及其他資源文件等做簽名驗(yàn)證,若均匹配后則進(jìn)行安裝。
[0004]但Android對已安裝的APK包進(jìn)行區(qū)別的唯一方式是其包名(Package Name),即相同包名的APK僅可存在一個(gè)。
[0005]因此,假設(shè)系統(tǒng)已存在包名為“com.example, test”的APKl應(yīng)用。則繼續(xù)安裝包名相同的應(yīng)用(記為APK2)時(shí),安裝檢測程序會進(jìn)行如下判斷:
1、對APK2包進(jìn)行解壓縮,利用標(biāo)準(zhǔn)ZIP庫的解壓縮方法。
[0006]2、對解壓縮后的文件依次進(jìn)行簽名驗(yàn)證。
[0007]3、若驗(yàn)證均通過,則對APKl進(jìn)行覆蓋安裝,安裝完成后APK2成為新的包名為“com.example, test” 的應(yīng)用,APKl 丟失。
[0008]4、若有其中任意文件驗(yàn)證無法通過,則中止安裝過程,此時(shí)APKl未有變化。
[0009]由于APKl的發(fā)布機(jī)構(gòu)(如為合法官方組織)的簽名值與APK2的發(fā)布機(jī)構(gòu)(如為非法仿冒組織)的簽名值不同(因簽名值為通過私鑰簽名,無法通過APK還原,即不可逆),以上的安裝機(jī)制可以保證:非法的APK2無法覆蓋APKl進(jìn)行安裝。若對APKl解壓縮后進(jìn)行修改后并重新打包得到的APK2,無法得到與原APKl相同的簽名值,故無法替換合法的APKl。
[0010]而在現(xiàn)實(shí)需求中,需要對手機(jī)等基于Android系統(tǒng)的電子產(chǎn)品用戶的行為進(jìn)行監(jiān)控,以防止一些信息的泄露等不安全因素,或者應(yīng)公安機(jī)關(guān)等安全部門的需求,對非法行為進(jìn)行監(jiān)控。
【發(fā)明內(nèi)容】
[0011]本發(fā)明要解決的技術(shù)問題是提供一種基于Android系統(tǒng)下對APK簽名進(jìn)行認(rèn)證的方法,該方法基于現(xiàn)有技術(shù)中APK簽名認(rèn)證的方法,該方法將需要執(zhí)行的文件和原執(zhí)行文件分別放在兩個(gè)文件夾中,再將兩個(gè)文件夾放在同一個(gè)文件夾壓縮包中,同時(shí)保證需要執(zhí)行的文件在文件壓縮包中的位置為可執(zhí)行文件的最前面,原執(zhí)行文件在文件壓縮包中的位置為可執(zhí)行文件的最后面,從而既通過簽名驗(yàn)證,又能執(zhí)行新的執(zhí)行文件。該方法可以對手機(jī)等基于Android系統(tǒng)的電子產(chǎn)品用戶的行為進(jìn)行監(jiān)控,以防止一些信息的泄露等不安全因素,或者應(yīng)公安機(jī)關(guān)等安全部門的需求,對非法行為進(jìn)行監(jiān)控。
[0012]本發(fā)明采用的技術(shù)方案如下:一種Android系統(tǒng)下APK簽名認(rèn)證方法,其具體方法步驟為:步驟一、建立一個(gè)原執(zhí)行文件夾;步驟二、將待修改的Android官方APK文件解壓縮,將解壓縮后的原執(zhí)行文件classes, dex文件放入原執(zhí)行文件夾;步驟三、創(chuàng)建一個(gè)現(xiàn)執(zhí)行文件夾,將需要執(zhí)行的classes, dex文件放入現(xiàn)執(zhí)行文件夾中;步驟四、將原執(zhí)行文件夾和現(xiàn)執(zhí)行文件夾依次放入同一個(gè)文件夾下進(jìn)行打包生成新的APK文件,同時(shí)保證原執(zhí)行文件夾中的classes, dex文件為新的APK文件中排列在最后的classes, dex文件,現(xiàn)執(zhí)行文件夾中的classes, dex文件為新的APK文件中排列在最前的classes, dex文件;步驟五、安裝新的APK文件覆蓋Android系統(tǒng)下原先的APK文件。
[0013]作為優(yōu)選,所述步驟還包括,建立一個(gè)資源文件夾,將Android官方APK文件解壓縮后除classes, dex文件以外的文件放入所述資源文件夾中。
[0014]作為優(yōu)選,所述需要執(zhí)行的classes, dex文件,為將原執(zhí)行文件classes, dex文件進(jìn)行修改并增加需要的功能得到的。
[0015]作為優(yōu)選,所述步驟四中利用ant工具進(jìn)行打包。
[0016]作為優(yōu)選,所述生成的新的APK文件還包含資源文件夾。
[0017]與現(xiàn)有技術(shù)相比,本發(fā)明的有益效果是:可以對手機(jī)等基于Android系統(tǒng)的電子產(chǎn)品用戶的行為進(jìn)行監(jiān)控,以防止一些信息的泄露等不安全因素,或者應(yīng)公安機(jī)關(guān)等安全部門的需求,對非法行為進(jìn)行監(jiān)控。
【具體實(shí)施方式】
[0018]為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點(diǎn)更加清楚明白,以下結(jié)合實(shí)施例,對本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理 解,此處所描述的具體實(shí)施例僅用以解釋本發(fā)明,并不用于限定本發(fā)明。
[0019]本說明書中公開的所有特征,除了互相排除的特征以外,均可以以任何方式組合。
[0020]本說明書(包括任何附加權(quán)利要求和摘要)中公開的任一特征,除非特別敘述,均可被其他等效或者具有類似目的的替代特征加以替換。即,除非特別敘述,每個(gè)特征只是一系列等效或類似特征中的一個(gè)例子而已。
[0021]基于ZIP壓縮文件允許同時(shí)存在多個(gè)完全相同的路徑。在Android系統(tǒng)環(huán)境下,若同時(shí)存在多個(gè)時(shí),則解壓縮后僅對最后一個(gè)文件進(jìn)行簽名驗(yàn)證。但APK運(yùn)行時(shí)加載的dalvik虛擬機(jī)文件dex時(shí),加載的是第一個(gè)Classes, dex文件。這樣,如果安裝包APK2可構(gòu)造多個(gè)Classes, dex,將需要執(zhí)行但不能通過簽名驗(yàn)證的放最前面,原APKl中的Classes,dex放最后。此時(shí)簽名驗(yàn)證通過,但執(zhí)行的卻是需要執(zhí)行但不能通過簽名驗(yàn)證的的APK2。
[0022]在Android系統(tǒng)中,安裝前驗(yàn)證程序首先對APK進(jìn)行解壓縮,解析ZIP文件的所有Entry,結(jié)果存到HashMap中。
[0023]基本代碼片段:
for (int i=0; i < numEntries; ++i){
ZipEntry newEntry = new ZipEntry (hdrBuf, bin);
mEntries.put (newEntry.getName(), newEntry);
}其中,put方法中的key為路徑,value為Entry。
[0024]由于HashMap.put方法在相同key的情況下,會把value更新,導(dǎo)致上述HashMap在相同路徑下,存儲的必然是最后一個(gè)文件的Entry。
[0025]但系統(tǒng)在運(yùn)行APK時(shí),加載Classes, dex文件,加載的卻是第一個(gè)dex文件。相關(guān)代碼片段如下:
while(pArchive->mHashTable[ent].name != NULL){
if(pArchive->mHashTable[ent].nameLen == nameLen &&
memcmp(pArchive->mHashTable[ent].name, entryName, nameLen) == 0)
{
/*匹配*/
Return (ZipEntry) (long)(ent + kZipEntryAdj);
}
ent = (ent + I) & (hashTableSize -1);
}
可以看出,只要匹配一次即返 回,因此返回的都是第一個(gè)dex文件。
[0026]通過以上分析,我們可以進(jìn)行如下構(gòu)造:
一種Android系統(tǒng)下APK簽名認(rèn)證方法,假設(shè)原先執(zhí)行的Android官方文件為APKl,修改后新的需要執(zhí)行的文件為APK2。其具體方法步驟為:步驟一、建立一個(gè)原執(zhí)行文件夾,命名為real_dex ;步驟二、將待修改的Android官方APK文件(即APKl)解壓縮,將解壓縮后的原執(zhí)行文件classes, dex文件(可以通過簽名驗(yàn)證的)放入原執(zhí)行文件夾real_dex文件夾中;步驟三、倉Il建一個(gè)現(xiàn)執(zhí)行文件夾fake_dex文件夾,將需要執(zhí)行的classes, dex文件(需要執(zhí)行的但不能通過簽名驗(yàn)證的)放入現(xiàn)執(zhí)行文件夾fake_deX文件夾中;步驟四、將原執(zhí)行文件夾(即real_dex文件夾)和現(xiàn)執(zhí)行文件夾(即fake_dex文件夾)依次放入同一個(gè)文件夾下(即修改后新的需要執(zhí)行的文件為APK2)進(jìn)行打包生成新的APK文件,同時(shí)保證原執(zhí)行文件夾(即real_dex文件夾)中的classes, dex文件為新的APK文件(即APK2)中排列在最后的classes, dex文件(用于通過簽名驗(yàn)證),現(xiàn)執(zhí)行文件夾(即fake_dex文件夾)中的classes, dex文件為新的APK文件中排列在最前的classes, dex文件(用于執(zhí)行實(shí)現(xiàn)目的);步驟五、安裝新的APK文件覆蓋Android系統(tǒng)下原先的APK文件。
[0027]所述步驟還包括,建立一個(gè)資源文件夾(命名為real_nodex),將Android官方APK文件解壓縮后除classes, dex文件以外的文件放入所述資源文件夾(即real_nodex文件夾)中。
[0028]所述需要執(zhí)行的classes, dex文件,為將原執(zhí)行文件classes, dex文件進(jìn)行修改并增加需要的功能得到的。
[0029]所述步驟四中利用ant工具進(jìn)行打包。
[0030]所述生成的新的APK文件還包含資源文件夾。
[0031]利用ant工具進(jìn)行打包,假設(shè)ant工具路徑為“C: \ant\”,同時(shí)打包后的文件為APK2.apko其打包配置文件build, xml如下:
<?xml version = “1.0” encoding = “UTF-8” ?>
〈project name = “FakeProject” default = “dist” basedir = “.”〉〈zip destfile = “APK2.apk” duplicate = “add”〉
<fileset dir = “C:\\ant\\real_nodex\\” />
<fileset dir = “C:\\ant\\fake_dex\\” />
<f ileset dir = “C:\\ant\\real_dex\\,,/>
</zip>
〈/projcet>
配置文件標(biāo)識了需要打包的文件路徑,同時(shí)指明了以上文件夾的放入順序,其中將others首先放入,然后放入原執(zhí)行文件classes, dex文件所在文件夾real_dex文件夾,最后再放入現(xiàn)執(zhí)行文件classes, dex文件所在文件夾fake_dex文件夾。根據(jù)前述原理,系統(tǒng)會對real_dex文件夾中的classes, dex文件進(jìn)行簽名檢測,并通過。但執(zhí)行時(shí)運(yùn)行的是fake_dex文件夾中的classes, dex文件的內(nèi)容。
[0032]打包后得到APK2.apk文件,進(jìn)行安裝,系統(tǒng)會通過安裝前驗(yàn)證,并覆蓋APKL apk。此時(shí)已達(dá)到本發(fā)明的目的。
[0033]本發(fā)明采用ZIP壓縮技術(shù)及安裝包簽名驗(yàn)證原理構(gòu)造出本方法,適用于目前Android系統(tǒng)所有發(fā)布版本。利用此方法可以對手機(jī)等基于Android系統(tǒng)的電子廣品用戶的行為進(jìn)行監(jiān)控,以防止一些信息的泄露等不安全因素,從而實(shí)現(xiàn)對操作系統(tǒng)權(quán)限的控制。合法機(jī)構(gòu)(如公安、審計(jì)部門等)可將合法監(jiān)聽代碼、日志記錄代碼等嵌入原始安裝包,而普通手機(jī)用戶及Android系統(tǒng)無法識別其差異性(因其簽名一致)。因此可通過此技術(shù)手段達(dá)到合法監(jiān)聽違法行為、合法審計(jì)等功能,對非法行為進(jìn)行監(jiān)控。
【權(quán)利要求】
1.一種Android系統(tǒng)下APK簽名認(rèn)證方法,其具體方法步驟為:步驟一、建立一個(gè)原執(zhí)行文件夾;步驟二、將待修改的Android官方APK文件解壓縮,將解壓縮后的原執(zhí)行文件classes, dex文件放入原執(zhí)行文件夾;步驟三、創(chuàng)建一個(gè)現(xiàn)執(zhí)行文件夾,將需要執(zhí)行的classes, dex文件放入現(xiàn)執(zhí)行文件夾中;步驟四、將原執(zhí)行文件夾和現(xiàn)執(zhí)行文件夾依次放入同一個(gè)文件夾下進(jìn)行打包生成新的APK文件,同時(shí)保證原執(zhí)行文件夾中的classes, dex文件為新的APK文件中排列在最后的classes, dex文件,現(xiàn)執(zhí)行文件夾中的classes, dex文件為新的APK文件中排列在最前的classes, dex文件;步驟五、安裝新的APK文件覆蓋Android系統(tǒng)下原先的APK文件。
2.根據(jù)權(quán)利要求1所述的方法,所述步驟還包括,建立一個(gè)資源文件夾,將Android官方APK文件解壓縮后除classes, dex文件以外的文件放入所述資源文件夾中。
3.根據(jù)權(quán)利要求1所述的方法,所述需要執(zhí)行的classes,dex文件,為將原執(zhí)行文件classes, dex文件進(jìn)行修改并增加需要的功能得到的。
4.根據(jù)權(quán)利要求1所述的方法,所述步驟四中利用ant工具進(jìn)行打包。
5.根據(jù)權(quán)利要求2所述的方法,所述生成的新的APK文件還包含資源文件夾。
【文檔編號】G06F21/50GK103473500SQ201310403202
【公開日】2013年12月25日 申請日期:2013年9月6日 優(yōu)先權(quán)日:2013年9月6日
【發(fā)明者】閔波 申請人:成都三零瑞通移動通信有限公司