本文主要介紹了APP安全漏洞整理，分享給大家，具體如下：

1.源碼安全漏洞

1.1 代碼混淆漏洞

當(dāng)前APK文件的安全性是非常令人堪憂的。APK運(yùn)行環(huán)境依賴的文件/文件夾 res、DEX、主配文件Lib 只有簡(jiǎn)單的加密或者甚至沒(méi)有任何加密。諸如apktool這類工具可輕易將其破解，再配合其他例如dex2jar、jd-gui等工具基本可以做到：源碼暴露、資源文件暴露、主配文件篡改、核心SO庫(kù)暴露、暴力破解惡意利用等。因此需要對(duì)安卓代碼進(jìn)行代碼混淆。

代碼混淆(Obfuscated code)亦稱花指令，是將計(jì)算機(jī)程序的代碼，轉(zhuǎn)換成一種功能上等價(jià)，但是難于閱讀和理解的形式的行為。將代碼中的各種元素，如變量，函數(shù)，類的名字改寫(xiě)成無(wú)意義的名字。比如改寫(xiě)成無(wú)意義的單個(gè)或多個(gè)字母，如a，Ac，甚至改寫(xiě)成“__”這樣的符號(hào)，使得閱讀的人無(wú)法根據(jù)名字猜測(cè)其用途。代碼混淆并不能真正阻止反向工程，只能增大其難度。因此，對(duì)于對(duì)安全性要求很高的場(chǎng)合，僅僅使用代碼混淆并不能保證源代碼的安全，但是可以在一定程度上保護(hù)開(kāi)發(fā)者的勞動(dòng)成果。

1.2 Dex保護(hù)漏洞

Dex是Dalvik VM executes的全稱，即Android Dalvik執(zhí)行程序，相當(dāng)于安卓中的.exe文件，Dex為Android應(yīng)用的核心，保護(hù)不當(dāng)容易被反編譯，暴露程序重要信息，面臨被植入廣告、惡意代碼、病毒等風(fēng)險(xiǎn)。

另外當(dāng)使用DexClassLoader加載外部的 apk、jar 或 dex文件，當(dāng)外部文件的來(lái)源無(wú)法控制時(shí)或是被篡改，此時(shí)無(wú)法保證加載的文件是否安全。加載惡意的dex文件將會(huì)導(dǎo)致任意命令的執(zhí)行。

1.3 so保護(hù)漏洞

so庫(kù)一般是程序里面核心代碼塊，通過(guò)Android提供的NDK技術(shù)將核心代碼用安全性更高的C/C++語(yǔ)言實(shí)現(xiàn)并提供給Java層調(diào)用來(lái)保證程序核心代碼的安全。高性能的代碼一般都會(huì)采取C/C++實(shí)現(xiàn)，通過(guò)Android的NDK技術(shù)來(lái)讓Java層直接使用。其安全性相對(duì)于Java會(huì)高很多，相對(duì)于Java代碼來(lái)說(shuō)其反編譯難度要大很多，但對(duì)于經(jīng)驗(yàn)豐富的破解者來(lái)說(shuō)，仍然是很容易的事，可以通過(guò)暴力破解或國(guó)外高價(jià)工具來(lái)將其破解。應(yīng)用的關(guān)鍵性功能或算法，都會(huì)在so中實(shí)現(xiàn)，如果so被逆向，應(yīng)用的關(guān)鍵性代碼和算法都將會(huì)暴露。

1.4 調(diào)試設(shè)置漏洞

如果在AndroidManifest.xml配置文件中設(shè)置了application屬性為debuggable=“true”，則應(yīng)用可以被任意調(diào)試，這就為攻擊者調(diào)試和破解程序提供了極大方便。如果開(kāi)啟，可被Java調(diào)試工具例如jdb進(jìn)行調(diào)試，獲取和篡改用戶敏感信息，甚至分析并且修改代碼實(shí)現(xiàn)的業(yè)務(wù)邏輯，例如竊取用戶密碼，繞過(guò)驗(yàn)證碼防護(hù)等。

2. 組件安全漏洞

2.1組件導(dǎo)出漏洞

組成Apk的四個(gè)組件，Activity，Service，Broadcast Receiver 和Content Provider，如果設(shè)置了導(dǎo)出權(quán)限，都可能被系統(tǒng)或者第三方的應(yīng)用程序直接調(diào)出并使用。組件導(dǎo)出可能導(dǎo)致登錄界面被繞過(guò)、信息泄露、數(shù)據(jù)庫(kù)SQL注入、DOS、惡意調(diào)用等風(fēng)險(xiǎn)。

2.2 Activity組件漏洞

Activity是Android組件中最基本也是最為常見(jiàn)用的四大組件之一，是一個(gè)負(fù)責(zé)與用戶交互的組件。Activity組件中存在以下常見(jiàn)的漏洞。

 (1)activity綁定browserable與自定義協(xié)議

activity設(shè)置“android.intent.category.BROWSABLE”屬性并同時(shí)設(shè)置了自定義的協(xié)議android:scheme意味著可以通過(guò)瀏覽器使用自定義協(xié)議打開(kāi)此activity?？赡芡ㄟ^(guò)瀏覽器對(duì)app進(jìn)行越權(quán)調(diào)用。

(2)ActivityManager漏洞

ActivityManager類中的killBackgroundProcesses函數(shù)，用于殺死進(jìn)程，屬于風(fēng)險(xiǎn)API。

還有通過(guò)ActivityManager被動(dòng)嗅探intent。Intent嗅探腳本首先調(diào)用一個(gè)Context.getSystemService()函數(shù)，并傳給它一個(gè)ACTIVITY_SERVICE標(biāo)志的標(biāo)識(shí)符，該函數(shù)返回一個(gè)ActivityManager類的實(shí)例，它使得該腳本能夠與activity manager進(jìn)行交互，并通過(guò)這個(gè)對(duì)象調(diào)用ActivityManager.getRecentTasks()方法。最后把intent相關(guān)的信息格式化成字符串返回出來(lái)。

2.3 Service組件漏洞

Service作為Android中四大組件之一，擁有重要的地位。Service具有和Activity一樣的級(jí)別，只是沒(méi)有界面，是運(yùn)行于后臺(tái)的服務(wù)。其他應(yīng)用組件能夠啟動(dòng)Service，并且當(dāng)用戶切換到另外的應(yīng)用場(chǎng)景，Service將持續(xù)在后臺(tái)運(yùn)行。另外，一個(gè)組件能夠綁定到一個(gè)service與之交互（IPC機(jī)制），例如，一個(gè)service可能會(huì)處理網(wǎng)絡(luò)操作，播放音樂(lè)，操作文件I/O或者與內(nèi)容提供者（content provider）交互，所有這些活動(dòng)都是在后臺(tái)進(jìn)行。從表面上看service并不具備危害性，但實(shí)際上service可以在后臺(tái)執(zhí)行一些敏感的操作。

Service存在的安全漏洞包括：權(quán)限提升，拒絕服務(wù)攻擊。沒(méi)有聲明任何權(quán)限的應(yīng)用即可在沒(méi)有任何提示的情況下啟動(dòng)該服務(wù)，完成該服務(wù)所作操作，對(duì)系統(tǒng)安全性產(chǎn)生極大影響。

2.4 Broadcast Receiver組件漏洞

Broadcast Receiver是“廣播接收者”的意思，就是用來(lái)接收來(lái)自系統(tǒng)和應(yīng)用中的廣播。

（1）權(quán)限管理不當(dāng)

Broadcast Receiver執(zhí)行一些敏感操作時(shí)，會(huì)通過(guò)intent來(lái)傳遞這些信息，這種傳遞數(shù)據(jù)的方式是容易被惡意攻擊的。在發(fā)掘broadcastreceiver中的漏洞時(shí)，最大的問(wèn)題是確定輸入是否可信，以及破壞性有多強(qiáng)。

 以下面這段代碼為例（有縮略）：

    <receiver
android:name=”.broadcastreceivers.SendSMSNowReceiver”
android:label=”Send SMS”>
    …………
         <actionandroid:name=”org.owasp.goatdroid.SOCIAL_SMS” />
    …………
    <uses-permissionandroid:name=”android.permission.SEND_SMS”/>
    …………

在上面這段代碼中，濫用了一個(gè)沒(méi)有進(jìn)行適當(dāng)權(quán)限保護(hù)的broadcast receiver，由于這個(gè)組件缺乏權(quán)限保護(hù)，使得攻擊者可以在沒(méi)有發(fā)送短信權(quán)限的情況下發(fā)送短信，這個(gè)漏洞的危害在于，攻擊者可以在用戶不知情的情況下發(fā)送短信去訂購(gòu)一個(gè)付費(fèi)服務(wù)，或者泄漏設(shè)備中的信息。

（2）BroadcastReceiver導(dǎo)出漏洞

當(dāng)應(yīng)用廣播接收器默認(rèn)設(shè)置exported='true'，導(dǎo)致應(yīng)用可能接收到第三方惡意應(yīng)用偽造的廣播，利用這一漏洞，攻擊者可以在用戶手機(jī)通知欄上推送任意消息，通過(guò)配合其它漏洞盜取本地隱私文件和執(zhí)行任意代碼。

（3）動(dòng)態(tài)注冊(cè)廣播組件暴露漏洞

Android 可以在配置文件中聲明一個(gè)receiver或者動(dòng)態(tài)注冊(cè)一個(gè)receiver來(lái)接收廣播信息，攻擊者假冒APP構(gòu)造廣播發(fā)送給被攻擊的receiver，是被攻擊的APP執(zhí)行某些敏感行為或者返回敏感信息等，如果receiver接收到有害的數(shù)據(jù)或者命令時(shí)可能泄露數(shù)據(jù)或者做一些不當(dāng)?shù)牟僮?，?huì)造成用戶的信息泄漏甚至是財(cái)產(chǎn)損失。

2.5 Content Provider組件漏洞

Content Provider為存儲(chǔ)和獲取數(shù)據(jù)提供統(tǒng)一的接口?？梢栽诓煌膽?yīng)用程序之間共享數(shù)據(jù)。

（1）讀寫(xiě)權(quán)限漏洞

Content Provider中通常都含有大量有價(jià)值的信息，比如用的電話號(hào)碼或者社交帳號(hào)登錄口令，而確認(rèn)一個(gè)content provider是否有能被攻擊的漏洞的最好的辦法，就是嘗試攻擊它一下。

可以用drozer來(lái)尋找一些不需要權(quán)限的contentprovider:

dz> runapp.provider.info –permission null

這條命令能列出所有不需要任何讀寫(xiě)權(quán)限的Content Provider，然后找到相對(duì)應(yīng)的包，去訪問(wèn)給定包存放在它的Content Provider中的數(shù)據(jù)。如果一些Content Provider的URI不需要讀權(quán)限，那就可以通過(guò)drozer工具提取其中的數(shù)據(jù)。在某些情況下，設(shè)置和執(zhí)行讀寫(xiě)權(quán)限不當(dāng)，也會(huì)將ContentProvider中的數(shù)據(jù)暴露給攻擊者。除了提取數(shù)據(jù)，對(duì)于寫(xiě)權(quán)限管理不當(dāng)?shù)腃ontent Provider還可以向其中寫(xiě)入數(shù)據(jù)，使得攻擊者可以將惡意數(shù)據(jù)插入到數(shù)據(jù)庫(kù)中。

（2）Content Provider中的SQL注入漏洞

和Web漏洞類似，安卓APP也要使用數(shù)據(jù)庫(kù)，那就也有可能存在SQL注入漏洞。主要有兩類，第一類是SQL語(yǔ)句中的查詢條件子語(yǔ)句是可注入的，第二類是投影操作子句是可注入的。使用drozer可以很容易的找出查詢條件子句可注入的content provider。

dz> runapp.provider.query [URI] –selection “1=1”

也可以使用其他恒為真的值，例如“1-1=0”，“0=0”等等。如果APP存在SQL注入漏洞，那么輸入這行指令后就會(huì)返回?cái)?shù)據(jù)庫(kù)中的整張表。

（3）Provider文件目錄遍歷漏洞

當(dāng)Provider被導(dǎo)出且覆寫(xiě)了openFile方法時(shí)，沒(méi)有對(duì)Content Query Uri進(jìn)行有效判斷或過(guò)濾。攻擊者可以利用openFile()接口進(jìn)行文件目錄遍歷以達(dá)到訪問(wèn)任意可讀文件的目的。

2.6 Intent組件漏洞

Intent（意圖）主要是解決Android應(yīng)用的各項(xiàng)組件之間的通訊。

（1）隱式意圖調(diào)用漏洞

封裝Intent時(shí)采用隱式設(shè)置，只設(shè)定action，未限定具體的接收對(duì)象，導(dǎo)致Intent可被其他應(yīng)用獲取并讀取其中數(shù)據(jù)。Intent隱式調(diào)用發(fā)送的意圖可能被第三方劫持，可能導(dǎo)致內(nèi)部隱私數(shù)據(jù)泄露。

（2）意圖協(xié)議URL漏洞

intent schemeURLs(意圖協(xié)議URL)，可以通過(guò)解析特定格式的URL直接向系統(tǒng)發(fā)送意圖，導(dǎo)致自身的未導(dǎo)出的組件可被調(diào)用,隱私信息泄露。

2.7 WebView組件漏洞

WebView是一個(gè)基于webkit引擎、展現(xiàn)web頁(yè)面的控件。

（1）Webview明文存儲(chǔ)密碼風(fēng)險(xiǎn)

Android的Webview組件中默認(rèn)打開(kāi)了提示用戶是否保存密碼的功能，如果用戶選擇保存，用戶名和密碼將被明文存儲(chǔ)到該應(yīng)用目錄databases/webview.db中。而本地明文存儲(chǔ)的用戶名和密碼，不僅會(huì)被該應(yīng)用隨意瀏覽，其他惡意程序也可能通過(guò)提權(quán)或者root的方式訪問(wèn)該應(yīng)用的webview數(shù)據(jù)庫(kù)，從而竊取用戶登錄過(guò)的用戶名信息以及密碼。

（2）Webview遠(yuǎn)程代碼執(zhí)行漏洞

Webview是Android用于瀏覽網(wǎng)頁(yè)的組件，其包含的接口函數(shù)addJavascriptInterface可以將Java類或方法導(dǎo)出以供JavaScript調(diào)用，實(shí)現(xiàn)網(wǎng)頁(yè)JS與本地JAVA的交互。由于系統(tǒng)沒(méi)有限制已注冊(cè)JAVA類的方法調(diào)用，因此未注冊(cè)的其它任何JAVA類也可以被反射機(jī)制調(diào)用，這樣可能導(dǎo)致被篡改的URL中存在的惡意代碼被執(zhí)行，用戶手機(jī)被安裝木馬程序，發(fā)送扣費(fèi)短信，通信錄或者短信被竊取，甚至手機(jī)被遠(yuǎn)程控制。

（3）Webview繞過(guò)證書(shū)校驗(yàn)漏洞

客戶端的Webview組件訪問(wèn)使用HTTPS協(xié)議加密的url時(shí)，如果服務(wù)器證書(shū)校驗(yàn)錯(cuò)誤，客戶端應(yīng)該拒絕繼續(xù)加載頁(yè)面。但如果重載WebView的onReceivedSslError()函數(shù)并在其中執(zhí)行handler.proceed()，客戶端可以繞過(guò)證書(shū)校驗(yàn)錯(cuò)誤繼續(xù)訪問(wèn)此非法URL。這樣將會(huì)導(dǎo)致“中間人攻擊”，攻擊者冒充服務(wù)器與銀行客戶端進(jìn)行交互，同時(shí)冒充銀行客戶端與銀行服務(wù)器進(jìn)行交互，在充當(dāng)中間人轉(zhuǎn)發(fā)信息的時(shí)候，竊取手機(jī)號(hào)，賬號(hào)，密碼等敏感信息。

（4）未移除有風(fēng)險(xiǎn)的Webview系統(tǒng)隱藏接口

android webview組件包含3個(gè)隱藏的系統(tǒng)接口：searchBoxJavaBridge, accessibilityTraversal以及accessibility，惡意程序可以利用它們實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。需通過(guò)顯示調(diào)用removeJavascriptInterface移除這三個(gè)系統(tǒng)隱藏接口。

（5）WebView忽略SSL證書(shū)錯(cuò)誤

WebView調(diào)用onReceivedSslError方法時(shí)，直接執(zhí)行handler.proceed()來(lái)忽略該證書(shū)錯(cuò)誤。忽略SSL證書(shū)錯(cuò)誤可能引起中間人攻擊。 

3.數(shù)據(jù)安全漏洞

3.1 數(shù)據(jù)存儲(chǔ)漏洞

（1）SharedPreferences漏洞

當(dāng)使用getSharedPreferences打開(kāi)文件，第二個(gè)參數(shù)設(shè)置為MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE。當(dāng)前文件可以被其他應(yīng)用讀取或?qū)懭氪鄹?，?dǎo)致信息泄漏或更嚴(yán)重的問(wèn)題。

（2）File任意讀寫(xiě)漏洞

如果開(kāi)發(fā)者使用openFileOutput(String name,int mode)方法創(chuàng)建內(nèi)部文件時(shí)，使用MODE_WORLD_READABLE或 MODE_WORLD_WRITEABLE模式，就會(huì)讓這個(gè)文件變?yōu)槿挚勺x或全局可寫(xiě)的。

3.2 數(shù)據(jù)加密漏洞

（1）明文數(shù)字證書(shū)漏洞

Apk中使用的數(shù)字證書(shū)可被用來(lái)校驗(yàn)服務(wù)器的合法身份，以及在與服務(wù)器進(jìn)行通信的過(guò)程中對(duì)傳輸數(shù)據(jù)進(jìn)行加密、解密運(yùn)算，保證傳輸數(shù)據(jù)的保密性、完整性。明文存儲(chǔ)的數(shù)字證書(shū)如果被篡改，客戶端可能連接到假冒的服務(wù)端上，導(dǎo)致用戶名、密碼等信息被竊?。蝗绻魑淖C書(shū)被盜取，可能造成傳輸數(shù)據(jù)被截獲解密，用戶信息泄露，或者偽造客戶端向服務(wù)器發(fā)送請(qǐng)求，篡改服務(wù)器中的用戶數(shù)據(jù)或造成服務(wù)器響應(yīng)異常。

（2）AES/DES弱加密

在AES加密時(shí)，使用“AES/ECB/NoPadding”或“AES/ECB/PKCS5padding”的模式。ECB是將文件分塊后對(duì)文件塊做同一加密，破解加密只需要針對(duì)一個(gè)文件塊進(jìn)行解密，降低了破解難度和文件安全性。

（3）setSeed偽隨機(jī)數(shù)漏洞

本地加密時(shí)如果使用SecureRandom中的setSeed方法設(shè)置種子將會(huì)造成生成的隨機(jī)數(shù)不隨機(jī)，使加密數(shù)據(jù)容易被破解。在SecureRandom生成隨機(jī)數(shù)時(shí)，如果不調(diào)用setSeed方法，SecureRandom會(huì)從系統(tǒng)中找到一個(gè)默認(rèn)隨機(jī)源。每次生成隨機(jī)數(shù)時(shí)都會(huì)從這個(gè)隨機(jī)源中取seed。

3.3 數(shù)據(jù)傳輸漏洞

（1）SSL通信服務(wù)端檢測(cè)信任任意證書(shū)

自定義SSL x509 TrustManager，重寫(xiě)checkServerTrusted方法，方法內(nèi)不做任何服務(wù)端的證書(shū)校驗(yàn)。黑客可以使用中間人攻擊獲取加密內(nèi)容。

（2）未使用HTTPS協(xié)議的數(shù)據(jù)傳輸

無(wú)線傳輸?shù)臄?shù)據(jù)能被第三方輕易截獲，由于客戶端與服務(wù)器之間的傳輸數(shù)據(jù)遵循通信協(xié)議指定的格式和內(nèi)容類型，如果未使用加密措施，傳輸數(shù)據(jù)可被還原成網(wǎng)絡(luò)層的數(shù)據(jù)包并進(jìn)行解包分析，直接暴露用戶的各種關(guān)鍵數(shù)據(jù)，例如用戶名，密碼等。加入了SSL（Secure SocketLayer）子層實(shí)現(xiàn)的HTTPS協(xié)議可確保數(shù)據(jù)在網(wǎng)絡(luò)上加密傳輸，即使傳輸?shù)臄?shù)據(jù)被截獲，也無(wú)法解密和還原。

（3）HTTPS未校驗(yàn)服務(wù)器證書(shū)漏洞

使用HTTPS協(xié)議時(shí)，客戶端必須對(duì)服務(wù)器證書(shū)進(jìn)行完整校驗(yàn)，以驗(yàn)證服務(wù)器是真實(shí)合法的目標(biāo)服務(wù)器。如果沒(méi)有校驗(yàn)，客戶端可能與仿冒的服務(wù)器建立通信鏈接，即“中間人攻擊”。仿冒的中間人可以冒充服務(wù)器與銀行客戶端進(jìn)行交互，同時(shí)冒充銀行客戶端與銀行服務(wù)器進(jìn)行交互，在充當(dāng)中間人轉(zhuǎn)發(fā)信息的時(shí)候，竊取手機(jī)號(hào)，賬號(hào)，密碼等敏感信息。

（4）HTTPS關(guān)閉主機(jī)名驗(yàn)證

構(gòu)造HttpClient時(shí)，設(shè)置HostnameVerifier時(shí)參數(shù)使用ALLOW_ALL_HOSTNAME_VERIFIER或空的HostnameVerifier。關(guān)閉主機(jī)名校驗(yàn)可以導(dǎo)致黑客使用中間人攻擊獲取加密內(nèi)容。

（5）開(kāi)放socket端口

app綁定端口進(jìn)行監(jiān)聽(tīng)，建立連接后可接收外部發(fā)送的數(shù)據(jù)。攻擊者可構(gòu)造惡意數(shù)據(jù)對(duì)端口進(jìn)行測(cè)試，對(duì)于綁定了IP 0.0.0.0的app可發(fā)起遠(yuǎn)程攻擊。

3.4 日志信息漏洞

（1）調(diào)試日志函數(shù)調(diào)用風(fēng)險(xiǎn)

調(diào)試日志函數(shù)可能輸出重要的日志文件，其中包含的信息可能導(dǎo)致客戶端用戶信息泄露，暴露客戶端代碼邏輯等，為發(fā)起攻擊提供便利，例如：Activity的組件名，是Activity劫持需要的信息；通信交互的日志，會(huì)成為發(fā)動(dòng)服務(wù)器攻擊的依據(jù)；跟蹤的變量值，可能泄露一些敏感數(shù)據(jù)，輸入的賬號(hào)、密碼等。

4.業(yè)務(wù)邏輯漏洞

4.1 權(quán)限漏洞

（1）全局文件可讀寫(xiě)

APP在創(chuàng)建內(nèi)部存儲(chǔ)文件時(shí)，將文件設(shè)置了全局的可讀權(quán)限。攻擊者惡意讀取文件內(nèi)容，獲取敏感信息，或惡意寫(xiě)文件，破壞完整性。

（2）敏感權(quán)限調(diào)用

在Manifest文件中調(diào)用一些敏感的用戶權(quán)限，敏感行為包括發(fā)送、攔截短信，讀取、修改通訊錄、通話記錄，撥打電話，發(fā)送地理位置，使用攝像頭，訪問(wèn)瀏覽器歷史記錄等。函數(shù)調(diào)用這些敏感行為，可能導(dǎo)致用戶隱私數(shù)據(jù)泄露，釣魚(yú)扣費(fèi)等風(fēng)險(xiǎn)。

（3）冗余權(quán)限

如果調(diào)用了非必須的權(quán)限，就會(huì)出現(xiàn)冗余權(quán)限，冗余權(quán)限可導(dǎo)致串謀攻擊，串權(quán)限攻擊的核心思想是程序A有某個(gè)特定的執(zhí)行權(quán)限，程序B沒(méi)有這個(gè)權(quán)限。但是B可以利用A的權(quán)限來(lái)執(zhí)行需要A權(quán)限才能完成的功能。

4.2 業(yè)務(wù)漏洞

業(yè)務(wù)漏洞需要依靠機(jī)器和人共同檢測(cè)，需要根據(jù)應(yīng)用功能作用的不同來(lái)進(jìn)行判斷。機(jī)器可以檢測(cè)一些通用的業(yè)務(wù)漏洞，例如廣告、非授權(quán)下載、扣費(fèi)短信等業(yè)務(wù)，而人工則判斷應(yīng)用在面向不同業(yè)務(wù)邏輯時(shí)產(chǎn)生的漏洞，例如登錄驗(yàn)證不完善、不可信的敏感數(shù)據(jù)交付等。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論