Cara menganalisis keselamatan APK dan mengautomasikan pengauditan

1. Sembang

Mengenai keselamatan mudah alih, anda mungkin tidak biasa dengannya, kerana penyelidikan dalam bidang ini hanya menjadi popular sejak beberapa tahun kebelakangan ini. Jadi apakah keselamatan mudah alih? Pertama sekali, kami tahu bahawa keselamatan mudah alih tidak lebih daripada beberapa isu keselamatan pada platform iOS dan platform Android, termasuk beberapa isu dalam sistem platform itu sendiri dan isu di peringkat aplikasi. Sudah tentu, beberapa protokol komunikasi perlu terlibat apabila klien dan pelayan berinteraksi, terutamanya protokol http dan https, dan sudah tentu beberapa protokol lain, seperti websocket dan sebagainya. Kami tidak akan memberi terlalu banyak perhatian kepada kelemahan protokol ini sendiri Apa yang perlu kami perhatikan ialah sama ada paket data disulitkan apabila perlu semasa penghantaran, sama ada pelayan mengawal kebenaran operasi pengguna dan beberapa perkhidmatan pada pelayan. . Sama ada terdapat kelemahan dalam pemprosesan logik, dsb. Idea dalam aspek ini pada asasnya serupa dengan penembusan web, tetapi terdapat beberapa perbezaan.

2. Serangan Trojan

Bercakap tentang keselamatan mudah alih, sudah tentu, virus dan serangan Trojan amat diperlukan Trojan kawalan jauh yang biasa termasuk droidjack, SpyNote, dsb., dan beberapa ketika dahulu , seperti Perisian Locking bermunculan seperti cendawan selepas hujan.

Rajah 1Droidjack

Rajah 2 Perisian penguncian

Penyerang boleh menggunakan Perisian jenis Droidjack menjana Trojan program kuda. Program kuda Trojan jenis berniat jahat ini biasanya wujud dalam beberapa pasaran APK kadar ketiga. Secara umumnya, penyerang akan meletakkan beberapa maklumat yang menggoda dalam apk ini, seperti tontonan percuma video kecantikan si fulan, klien tanpa iklan untuk video si fulan, penyemak imbas gambar si fulan, dsb. Selepas penyerang menerbitkan APK ini dengan maklumat yang menarik di Internet, mereka akan memulakan program pelayan pada pelayan jauh Setelah pengguna memasang dan menjalankan program berniat jahat ini, penggodam boleh mengawal telefon mudah alih pengguna pada pelayan jauh. pelbagai tingkah laku dan mencuri maklumat peribadi pengguna.

Dalam analisis akhir, serangan peringkat virus Trojan ini terutamanya disebabkan oleh kesedaran keselamatan pengguna yang lemah, jadi ia tidak akan menjadi subjek perbincangan utama Kami akan membincangkan keselamatan aplikasi Android.

3. Perlombongan kerentanan sebelah pelayan apl

Jadi bagaimanakah kita melombong kelemahan apl? Pertama sekali, bagi pekerja keselamatan yang telah beralih daripada keselamatan web kepada perlombongan kerentanan mudah alih, sudah tentu mereka ingin menggali kelemahan yang serupa dengan bidang mereka sendiri Bahagian pelayan aplikasi pada dasarnya sama dengan bahagian pelayan dalam medan keselamatan web, kecuali ia adalah program web Pelanggannya lebih kepada penyemak imbas, manakala aplikasi mudah alih biasanya mempunyai aplikasi yang boleh dipasang pada peranti mudah alih. Oleh itu, untuk melombong kelemahan pelayan aplikasi, kami masih boleh menggunakan pengalaman web kami yang lalu untuk melombong beberapa kelemahan seperti xss, ssrf, suntikan sql dan pembacaan fail sewenang-wenangnya.

Apabila mencari kelemahan dalam aplikasi web, kami boleh mengkonfigurasi proksi dalam penyemak imbas untuk menangkap paket dan menganalisis aplikasi web kami. Jadi, bagaimanakah kami harus melaksanakan analisis paket pada aplikasi mudah alih?

Malah, analisis paket aplikasi Android juga berdasarkan proksi, tetapi konfigurasi proksi agak rumit. Selepas kami mengkonfigurasi ejen yang sepadan dalam burptsuit atau fiddler, kami boleh menggunakannya untuk memintas dan memainkan semula paket data. Langkah-langkah khusus tidak akan dijelaskan secara terperinci di sini. Terdapat tutorial dalam talian, anda boleh menyemaknya sendiri.

Di sini, saya tidak akan membincangkan beberapa kerentanan klasik seperti xss dan suntikan sql. Di sini saya akan bercakap terutamanya tentang kelemahan aplikasi mudah alih. Kami tahu bahawa dalam keselamatan web, kelemahan akses tanpa kebenaran biasanya disebabkan oleh pelayan tidak melaksanakan pengesahan kebenaran pada permintaan pengguna dan melaksanakan permintaan pengguna hanya berdasarkan ID pengguna. Jadi apakah proses pengesahan yang betul? Penerangan ringkas dalam teks ialah: selepas pengguna berjaya log masuk dan disahkan, pelayan akan menulis kebenaran pengguna ke dalam kuki, dan kemudian mengembalikannya ke penyemak imbas akan menyimpan kuki ini paket permintaan seterusnya , pelayan mengesahkan kuki dalam paket data untuk mengenal pasti kebenaran pengguna dan melaksanakan operasi dengan kebenaran yang sepadan.

Rajah 3 proses pengesahan kuki

Sudah tentu, kaedah pengesahan lain ialah pengesahan sesi. Kedua-dua pengesahan sesi dan pengesahan kuki boleh mengesahkan identiti pengguna Jadi, apakah perbezaan antara pengesahan sesi dan pengesahan kuki?  

Ringkasnya, kuki disimpan di bahagian pelanggan, dan sesi disimpan di bahagian pelayan. Dari perspektif keselamatan, kuki adalah agak tidak selamat, manakala sesi adalah agak selamat, kerana kuki disimpan pada bahagian klien, dan penyerang boleh mendapatkan kuki pada bahagian klien Jika medan yang digunakan untuk mengenal pasti identiti pengguna tidak disulitkan, ia adalah mudah untuk menjadi Penghitungan, maka penyerang boleh memalsukan kuki dan melakukan operasi yang tidak dibenarkan. Dan jika pengesahan sesi didayakan, pelanggan hanya akan mendapatkan id sesi yang sepadan selepas log masuk berjaya. Id ini ialah rentetan yang disulitkan dan tidak boleh dilalui.

Jadi bagaimana proses pensijilannya? Pertama sekali, kita perlu tahu bahawa pengesahan sesi juga bergantung pada kuki Selepas pengguna berjaya log masuk, pelayan akan menulis sesi sepadan pengguna ke dalam pangkalan data pelayan Sesi mengandungi beberapa maklumat identiti pengguna dan maklumat lain maka pelayan ID yang sepadan dengan sesi ini akan dihantar kepada klien, jadi kandungan kuki dalam klien biasanya hanya rentetan sessionid=xxxxxx. Pengguna perlu membawa sessionid ini dalam permintaan berikutnya Pelayan mengenal pasti sessionid, kemudian menanyakan pangkalan data untuk mendapatkan maklumat kebenaran pengguna yang sepadan, dan kemudian menentukan sama ada pengguna mempunyai kebenaran untuk melaksanakan operasi respons.

Jelas sekali, mekanisme sesi secara relatifnya lebih selamat, tetapi sisi keselamatan yang lain juga datang pada harga yang lebih tinggi Berbanding dengan kuki, mekanisme sesi menggunakan lebih banyak prestasi pelayan.

Proses pengesahan Sesi Rajah 4

Walau bagaimanapun, dari segi mudah alih, pengesahan identiti pengguna tidak menggunakan kuki, tetapi berdasarkan pengenalan token. Jadi apakah jenis kaedah pengesahan itu? Untuk menyatakannya dalam kata-kata ringkas, proses pengesahannya biasanya seperti ini Selepas pengesahan log masuk klien berjaya, pelayan akan mengembalikan rentetan token ini adalah kelayakan sesi pengguna. Token ini mesti dibawa bersama anda setiap kali supaya identiti pengguna dapat dikenal pasti.

Rajah 5 Proses pengesahan Token

Jika kita menganalisis paket data dan mendapati terdapat permintaan tanpa token, maka paket data ini sangat Ada mungkin kelemahan ultra keistimewaan Sudah tentu, ia mesti dianalisis berdasarkan senario tertentu untuk menentukan sama ada ia mempengaruhi logik perniagaan. Ini adalah postur umum kami untuk mencungkil kelemahan yang tidak dibenarkan pada terminal mudah alih. Walau bagaimanapun, postur ini terlalu terencat akal. Pada dasarnya sesiapa yang menghadapinya boleh menggalinya.

Terdapat cara lain untuk mencari kelemahan akses tanpa kebenaran, yang kelihatan agak pelik Punca kelemahan akses tanpa kebenaran ini ialah ralat dalam strategi pengesahan itu sendiri. Saya masih ingat bahawa lama dahulu, saya menjalankan analisis protokol pada perisian siaran langsung dan mendapati bahawa logik pengesahannya adalah seperti berikut: selepas pengesahan log masuk pengguna berjaya, pelayan mengembalikan ID pengguna, dan kemudian menghasilkan token pengguna secara tempatan . Dalam permintaan seterusnya, Bawa token ini sebagai bukti identiti pengguna. Ini jelas bermasalah, kerana ID pengguna boleh dilalui, dan algoritma penjanaan token adalah setempat, jadi penyerang boleh mengira token itu sendiri selagi dia memperoleh ID pengguna lain dan mengekstrak algoritma penjanaan token tempatan, dan kemudian pengguna palsu log masuk.

Sudah tentu, masih agak sukar untuk menemui kelemahan yang tidak dibenarkan sedemikian, yang memerlukan penggali kerentanan mempunyai keupayaan analisis terbalik dan keupayaan pengekodan yang agak mendalam. Walau bagaimanapun, sebagai pembangun, anda tidak boleh melonggarkan pengukuhan keselamatan aplikasi kerana kesukaran ini, khususnya, pengesahan pengguna, modul berfungsi yang sangat penting, mesti dilindungi dengan baik dari segi keselamatan.

4. Perlombongan kerentanan pelanggan Apk

1 Pengenalan alat yang biasa digunakan

Bagi kelemahan pihak klien, kaedah utama ialah menyahkompilasi klien aplikasi melalui alat penyahkompilasi untuk mendapatkan kod Sumber, dan kemudian menjalankan audit kod sumber statik berdasarkan beberapa pengalaman dan pengetahuan keselamatan. Alat penyahkompilasi biasa termasuk apkide, jeb, apktools, dsb. Biar saya ambil tangkapan skrin untuk anda faham:

Gambar 6 Prinsip perubahan

Gambar 7 Jeb

Sudah tentu, kegemaran saya ialah pembantu songsang android, yang sangat praktikal.

Rajah 8 Android Reverse Assistant

Digunakan dalam kombinasi dengan jeb, ia pada asasnya boleh memenuhi analisis songsang harian.

Platform aplikasi Android terbahagi terutamanya kepada lapisan asli dan lapisan java. Untuk lapisan Java, kita boleh menggunakan alat di atas untuk analisis, dan untuk lapisan asli, kita perlu menggunakan ida untuk analisis. Ida ialah alat pembongkaran yang sangat mudah digunakan. Ia juga menyokong penyahpepijatan dinamik dan boleh menyahpepijat aplikasi apk dari jauh Kami boleh menggunakan penyahpepijatan dinamik ida untuk memintas beberapa pengesahan dalam lapisan jadi, seperti pengesahan pembungkusan sekunder, atau melakukan penyahpepijatan dinamik dan pengecutan.

2. Pengenalan kepada aplikasi shelling

Bercakap tentang aplikasi shelling, ini sangat diperlukan semasa proses analisis apk. Sebelum bercakap tentang membongkar, mari kita fahami dahulu apa itu pembungkusan. Pembungkusan bermaksud untuk mendapatkan kawalan program terlebih dahulu sebelum aplikasi dijalankan, dan kemudian memindahkan kawalan program ke program asal. Pelaksanaan pembungkusan pada platform Android adalah untuk menyulitkan dan menyembunyikan fail dex asal, dan kemudian mendapatkan fail dex asal melalui program shell dan kemudian memulihkannya semula kaedah lain adalah untuk mengekstrak arahan fungsi dan menggunakan cangkuk untuk bertindak balas apabila berjalan. Fungsi pemuatan kelas mengisi arahan kembali.

Untuk aplikasi yang dibungkus, logik program asal pada dasarnya tidak dapat dikenali, dan kami tidak boleh menjalankan analisis keselamatan melalui program yang dibungkus. Oleh itu, kita perlu membongkar aplikasi. Alat pembongkaran automatik yang biasa termasuk drizzledump dan dexhunter. Dexhunter mudah digunakan, tetapi ia memerlukan flashing, dan banyak vendor penyulitan telah menyemaknya, jadi ia tidak akan berfungsi jika anda menggunakannya secara langsung Anda perlu membuat beberapa pengubahsuaian dan memintas beberapa pengesanan. Bagi penggunaan terperinci, anda boleh mencari tutorial dalam talian, jadi saya tidak akan menerangkan butiran di sini. Jika alat itu tidak berfungsi, anda perlu pergi ke ida akhirnya.

3. Audit kod sumber statik

Mari kita lihat secara terperinci isu yang perlu diberi perhatian apabila melibatkan pengesanan keselamatan di peringkat kod sumber.

Keselamatan Komponen

Pertama ialah isu keselamatan komponen Kami tahu bahawa aplikasi Android mempunyai empat komponen utama, iaitu: aktiviti, perkhidmatan, pembekal kandungan dan penyiaran penerima. Jika komponen ini tidak begitu diperlukan, atribut eksportnya, yang dieksport, hendaklah ditetapkan kepada palsu, iaitu, pengeksportan adalah dilarang. Jika ditetapkan kepada benar, ia akan dipanggil oleh aplikasi luaran, yang boleh menyebabkan kebocoran maklumat, pintasan kebenaran dan kelemahan lain. Selain itu, apabila menggunakan Intent.getXXXExtra() untuk mendapatkan atau memproses data, jika try...catch tidak digunakan untuk pengendalian pengecualian, penafian kelemahan perkhidmatan mungkin berlaku termasuk tetapi tidak terhad kepada: pengecualian penuding nol. pengecualian penukaran jenis, dan pengecualian akses di luar sempadan, pengecualian tidak ditentukan kelas, pengecualian bersiri dan penyahserilan.

Seperti keselamatan komponen yang dinyatakan di atas, kami biasanya menilainya dengan menganalisis fail androidManifest.xml Android. AndroidManifest.xml ialah fail masukan untuk aplikasi Android Ia menerangkan komponen yang terdedah dalam pakej (aktiviti, perkhidmatan, dll.), kelas pelaksanaan masing-masing, pelbagai data yang boleh diproses dan lokasi permulaan. Selain mengisytiharkan Aktiviti, Penyedia Kandungan, Perkhidmatan dan Penerima Niat dalam program, kebenaran dan instrumentasi (kawalan dan ujian keselamatan) juga boleh ditentukan. Dengan menganalisis fail manifest.xml ini, kami juga boleh menemui kelemahan seperti sandaran data aplikasi dan penyesuaian aplikasi. Sudah tentu, kelemahan ini secara amnya adalah kerentanan berisiko rendah, iaitu, ia tidak akan memberi banyak kesan kepada logik perniagaan program. Selain itu, disebabkan oleh kelemahan kebolehpenyahpepijatan aplikasi, walaupun boleh dinyahpepijat ditetapkan untuk melarang penyerang daripada menyahpepijat aplikasi, ia tidak akan menghalang penyerang daripada menyahpepijat aplikasi, kerana pembangun hanya boleh mengawal aplikasi itu sendiri daripada menyahpepijat, tetapi tidak boleh mengawal sistem pengguna . Penyerang boleh menyahpepijat semua aplikasi dalam sistem dengan menetapkan sifat dalam ingatan, tidak kira sama ada aplikasi itu ditetapkan untuk dinyahpepijat. Walau bagaimanapun, tetapan ini masih perlu dibuat untuk melumpuhkan penyahpepijatan di sini, kerana tidak semua penganalisis terbalik mengetahui bahawa tetapan ini boleh dipintas.

Isu Keselamatan Paparan Web

Untuk mengatakan bahawa terdapat kerentanan yang lebih serius dalam aplikasi pelanggan Android, ia mestilah kelemahan paparan web. Banyak apl kini mempunyai halaman web terbina dalam, seperti banyak platform e-dagang, Taobao, JD.com, Juhuasuan, dll., seperti yang ditunjukkan di bawah:

Rajah 9 paparan webview

Malah, ini dilaksanakan oleh webview, komponen dalam android. WebView ialah kawalan berdasarkan enjin webkit yang memaparkan halaman web Fungsinya adalah untuk memaparkan dan memaparkan halaman web secara langsung menggunakan fail HTML untuk reka letak dan panggilan secara interaktif dengan javascript. Webview boleh digunakan bersendirian atau digabungkan dengan subkelas lain. Subkelas Webview yang paling biasa digunakan ialah kelas WebSettings, kelas WebViewClient dan kelas WebChromeClient. Saya tidak akan memperkenalkan terlalu banyak di sini Jika anda berminat dengan pengaturcaraan Android, anda boleh mendapatkan maklumat lanjut tentang Baidu.

Komponen Webview boleh digambarkan sebagai pedang bermata dua Di satu pihak, penampilannya boleh mengurangkan beban pembangunan pelanggan dan meletakkan logik utama program pada pelayan untuk pelaksanaan gunakan webview untuk memuatkan halaman web yang sepadan Walau bagaimanapun, jika dikonfigurasikan secara tidak betul, kelemahan pelaksanaan arahan jauh mungkin wujud. CVE yang berkaitan termasuk CVE-2012-6636, CVE-2014-1939 dan CVE-2014-7224.

cve-2012-6636 Kerentanan ini disebabkan oleh program tidak menyekat penggunaan kaedah WebView.addJavascriptInterface dengan betul. Penyerang jauh boleh mengeksploitasi kelemahan ini untuk melaksanakan kaedah objek Java sewenang-wenangnya dengan menggunakan Java Reflection API.

cve-2014-1939 Kerentanan ini disebabkan oleh java/android/webkit/BrowserFrame.java menggunakan API addJavascriptInterface dan mencipta objek kelas SearchBoxImpl Penyerang boleh mengeksploitasi kelemahan ini untuk melaksanakan kod Java sewenang-wenangnya dengan mengakses antara muka searchBoxJavaBridge_.

cve-2014-7224 Penyerang terutamanya menggunakan dua Jambatan Java kebolehaksesan dan kebolehaksesanTraversal untuk melaksanakan kod serangan jauh.

Penjanaan pelaksanaan arahan jauh Webview juga bergantung pada mekanisme pantulan Java. Kaedah addJavascriptInterface dalam Webview boleh menyuntik Objek Java ke dalam WebView, dan kaedah Objek Java ini boleh diakses oleh Javascript. Sebab mengapa addJavascriptInterface disediakan adalah supaya Javascript dalam WebView boleh berkomunikasi dengan Apl tempatan. Ini sememangnya fungsi yang sangat berkuasa Kelebihannya ialah apabila logik Apl tempatan kekal tidak berubah, program boleh dikemas kini tanpa menaik taraf Apl dan halaman Web yang sepadan boleh diubah suai. Walau bagaimanapun, dalam versi awal Android, tiada sekatan pada kaedah yang boleh diakses Dengan menggunakan mekanisme refleksi Java, anda boleh memanggil sebarang kaedah untuk sebarang objek. Ini adalah punca utama kerentanan WebView.

serangan pakej kemas kini apk (serangan man-in-the-middle)

Kerentanan yang dinyatakan di atas adalah agak biasa dalam aplikasi Android dan mempunyai kesan yang agak besar adalah juga beberapa kelemahan Kesan relatifnya agak ringan, tetapi jika digunakan dengan betul, kemudaratannya masih agak serius. Contohnya, serangan man-in-the-middle memerlukan penyerang dan mangsa berada di LAN yang sama, dan trafik mangsa dikawal oleh penyerang. Apa yang boleh dilakukan oleh serangan lelaki di tengah? Main xss? Dapatkan kuki pengguna? Sudah tentu, ia jelas tidak berguna untuk mendapatkan kuki pengguna di sini, ia sepatutnya maklumat token. Dalam serangan mudah alih, serangan man-in-the-middle yang dieksploitasi dengan betul malah boleh membawa kepada pelaksanaan arahan jauh. Sebagai contoh, pakej kemas kini yang dimuat turun apabila aplikasi dikemas kini dikawal dan digantikan dengan paket data serangan berniat jahat Aplikasi melaksanakan program kemas kini dalam pakej pulangan yang diubah suai oleh penyerang tanpa melakukan pengesahan tandatangan yang diperlukan pada pakej kemas kini masalah. Boleh menyebabkan program berniat jahat dilaksanakan.

5. Pelaksanaan alat pengimbasan statik kerentanan Apk

1 Pengenalan projek

Pada masa ini tiada enjin pengimbasan yang baik untuk pengesanan kelemahan pihak pelanggan. Beberapa waktu lalu, saya menyiasat syarikat digital tertentu, Bang tertentu, dan alat pengimbasan keselamatan APK tertentu yang disulitkan. Jadi bolehkah kita menulis sendiri alat pengesanan automatik? Saya juga menulis alat pengimbasan hilang automatik apk sebelum ini.

Biar saya bercakap tentang idea pelaksanaan saya Pertama sekali, kami tahu bahawa objek analisis utama kami ialah fail AndroidManifest.xml dan dex, tetapi kedua-dua ini adalah fail binari yang dikompilasi. Alat yang diperlukan untuk menyahkompilasi AndroidManifest.xml ialah AXMLPrinter.jar dan fail yang diperlukan untuk menyahkompilasi fail dex ialah baksmali.jar. Malah, kedua-dua pakej balang ini juga biasa digunakan oleh beberapa alat kejuruteraan terbalik. Mari kita lihat direktori program alat penyahkompilasi pembantu songsang android:

Rajah 10 Direktori program pembantu songsang Android

Ini dipanggil pembantu songsang android Alat kejuruteraan terbalik terutamanya menggunakan kedua-dua alat ini untuk menyahkompilasi fail AndroidManifest dan dex.

Selagi kami menulis logik yang sepadan dalam alat pengimbasan kebocoran automatik kami, dan memanggil kedua-dua alat ini untuk menyahhimpun fail AndroidManifest dan dex, kami boleh mengesan kerentanan dengan memadankan beberapa ciri kerentanan.

Berikut ialah pengenalan ringkas kepada struktur direktori projek:

Rajah 11 Direktori dan pengenalan projek pengimbasan kerentanan Apk

Mula-mula kami memerlukan nama pakej aplikasi, dan kemudian mengesan beberapa tetapan aplikasi, seperti sama ada sandaran dibenarkan, sama ada ia boleh laras, dsb., kemudian kami memperoleh beberapa maklumat konfigurasi bagi empat komponen, perkhidmatan , pembekal kandungan, penerima siaran, Tentukan sama ada ia boleh dieksport, kemudian dapatkan kebenaran yang digunakan oleh aplikasi untuk menentukan sama ada ia terlalu sensitif mendapatkan kebenaran yang dicipta oleh aplikasi itu sendiri untuk menentukan sama ada ia mempunyai sekatan kebenaran;

Seterusnya, lakukan pengesanan ciri kerentanan pada fail smali yang dinyahkompilasi. Ini bergantung terutamanya pada ciri-ciri kelemahan yang telah kami kumpulkan terlebih dahulu. Di sini saya menulis ciri-ciri kelemahan ke dalam fail xml, dan apabila memulakan imbasan kelemahan, muatkannya ke dalam memori untuk program memanggil. Kami boleh menyesuaikan ciri-ciri kelemahan ini supaya program kami boleh mengimbas lebih banyak kelemahan. Pada masa ini, takrifan ciri kelemahan menyokong rentetan dan bentuk biasa. Projek ini masih dalam penyelenggaraan, tetapi fungsi asas telah dilaksanakan dan boleh memenuhi pengimbasan dan pengesanan harian. Hanya buat beberapa penyelesaian masalah pada hasil pengimbasan.

2. Jenis pengesanan Kerentanan yang kini disokong oleh perisian

1 Kerentanan membaca dan menulis fail sewenang-wenangnya

2 🎜> 3. Penukaran jenis paksa kelemahan perkhidmatan tempatan

4. Komponen sistem penolakan kerentanan perkhidmatan

5 kerentanan suntikan SQL tempatan

7. Pengesanan keselamatan pemuatan dinamik

8 Sijil pengesahan lemah

9 Kerentanan rampasan data

11. Algoritma Hash tidak selamat

12 penyulitan lemah AES

13. Locat membocorkan maklumat peribadi

14 🎜>

15. Risiko penyalahgunaan PendingIntent

16 Panggilan Tersirat

17 pengesanan kerentanan antara muka

19. Pengesanan kelemahan pelaksanaan kod jauh komponen WebView

20 WebView mengabaikan pengesanan ralat sijil SSL

21 >22. Baca sebarang SharedPreferences

23 Baca dan tulis fail sewenang-wenangnya

24 Tidak selamat untuk menggunakan nombor rawak

25 26. Semak sama ada aplikasi boleh dilaraskan

27 Semakan kebenaran aplikasi

28 Semakan kebenaran tersuai aplikasi

30 🎜>3. Penggunaan

1 Letakkan fail apk yang perlu diimbas dalam direktori ruang kerja/apk

2 Klik AndroidCodeCheck.exe atau jalankan python AndroidCodeCheck.py untuk lakukan pengimbasan kerentanan

4 Output laporan

Laluan output laporan berada di bawah laporan

1) format txt

Ia boleh dianggap sebagai log berjalan program Ia juga boleh digunakan sebagai rujukan untuk hasil imbasan.

2) Format HTML

Laporan dalam format html mempunyai direktori Klik pada nama kerentanan dalam direktori untuk melompat ke perihalan jenis kerentanan yang sepadan. Dalam perihalan jenis, anda boleh mengklik Kembali ke Direktori untuk kembali ke senarai direktori kerentanan untuk memudahkan semakan kerentanan.

Akhir sekali, saya akan memberikan anda tangkapan skrin laporan pengimbasan kerentanan Ia agak asas dan akan dipertingkatkan secara beransur-ansur pada masa hadapan.

Rajah 12 Halaman utama direktori lapor

Rajah 13 Butiran Kerentanan

Alamat projek

Alamat projek alat pengimbasan kebocoran kod sumber statik Apk:

https://github.com/zsdlove/ApkVulCheck

Atas ialah kandungan terperinci Cara menganalisis keselamatan APK dan mengautomasikan pengauditan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!