Menonaktifkan keadaan runtime memeriksa dalam aplikasi Android

Dalam artikel sebelumnya, saya melakukan review pada OWASP Mobile TOP 10 dan kemudian saya tidak memiliki case yang cocok untuk menunjukkan perlunya melindungi kode sumber. Sebuah kasus yang menarik untuk demonstrasi muncul hanya baru-baru ini dan yang tertarik untuk melihat pengalaman kami menghindari pemeriksaan lingkungan, mari kita pergi di bawah kucing.

Ketika menilai kinerja salah satu proyek, tim kami segera menyadari bahwa kasusnya tidak mudah. Pengembang mendekati masalah keamanan informasi dalam program dengan baik dan mengimplementasikan pemeriksaan pada keadaan lingkungan eksekusi. Aplikasi tidak memulai dalam kondisi berikut:

• perangkat itu rusak;
• sebuah emulator digunakan;
• ketersediaan koneksi melalui USB;
• menggunakan mode pengembang.

Pengembang tidak mengaburkan kode sumber dan tidak ada pemeriksaan bawaan untuk modifikasi kode, yang memungkinkan saya untuk menganalisis metode yang digunakan pemeriksaan dan melakukan manipulasi yang diperlukan dengan mereka.

Jadi mari kita mulai. Menurut OWASP Mobile TOP 10, yang kami gunakan sebagai metodologi pengujian dasar di Hacken, Reverse Engineering - kerentanan ini mencakup analisis file biner untuk menentukan kode sumber, pustaka, algoritma, dll. Perangkat lunak seperti IDA Pro, Hopper, otool, dan alat rekayasa balik lainnya dapat memberikan gambaran tentang operasi internal aplikasi. Ini dapat digunakan untuk mencari kerentanan aplikasi, mengekstrak informasi penting seperti server backend, kunci enkripsi atau properti intelektual.

Untuk melakukan analisis statis dasar, saya menggunakan alat yang menarik seperti MobSF, yang melakukan dekompilasi dan analisis statis dasar. Setelah dekompilasi, saya tertarik pada kode java dan smali dari program ini. Kode Java diperlukan untuk analisis, dan kami akan membuat perubahan pada kode smali. Rincian lebih lanjut tentang bagaimana smali dan java berhubungan dapat ditemukan di sini .

Setelah melihat daftar kelas, saya menemukan file yang bertanggung jawab untuk memeriksa rutin telepon (lihat Gambar 1) - rootingcheck / RootBeerNative.java.


Fig. 1. Daftar kelas aplikasi

Setelah menganalisis kelas, menjadi jelas bahwa kita perlu melihat lebih jauh untuk panggilan ke fungsi checkForRoot () dan setLogDebugMessage () (lihat Gambar 2).


Fig. 2. Kode sumber kelas untuk memeriksa rutovanost

Menggunakan perintah grep, kita mendapatkan hasil berikut, yang memperlihatkan kepada kita file mana yang berisi panggilan ke metode checkForRoot () dan setLogDebugMessage ().

Hasil Pencarian:
root @ kali: ~ / Desktop # grep -nr 'RootBeerNative' ******** _ v_0.9.2 /

********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:1:.class public Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:17: sput-boolean v0, Lrootingcheck/RootBeerNative;->?:Z ********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:28: sput-boolean v0, Lrootingcheck/RootBeerNative;->?:Z ********_v_0.9.2/smali/rootingcheck/RootBeerNative.smali:57: sget-boolean v0, Lrootingcheck/RootBeerNative;->?:Z ********_v_0.9.2/smali/o/CM.smali:591: new-instance v1, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/CM.smali:593: invoke-direct {v1}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/CM.smali:685: new-instance v0, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/CM.smali:687: invoke-direct {v0}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/CM.smali:689: invoke-static {}, Lrootingcheck/RootBeerNative;->?()Z ********_v_0.9.2/smali/o/CM.smali:753: new-instance v4, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/CM.smali:755: invoke-direct {v4}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/CM.smali:764: invoke-virtual {v4, v3}, Lrootingcheck/RootBeerNative;->checkForRoot([Ljava/lang/Object;)I ********_v_0.9.2/smali/o/xZ$5.smali:257: new-instance v1, Lrootingcheck/RootBeerNative; ********_v_0.9.2/smali/o/xZ$5.smali:259: invoke-direct {v1}, Lrootingcheck/RootBeerNative;-><init>()V ********_v_0.9.2/smali/o/xZ$5.smali:261: invoke-static {}, Lrootingcheck/RootBeerNative;->?()Z 

root @ kali: ~ / Desktop # grep -nr 'setLogDebugMessages' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/CM.smali:599: invoke-virtual {v1, v0}, Lrootingcheck/RootBeerNative;->setLogDebugMessages(Z)I ********_v_0.9.2/smali/o/CM.smali:761: invoke-virtual {v4, v0}, Lrootingcheck/RootBeerNative;->setLogDebugMessages(Z)I 

Tapi ini tidak semua cek. Setelah menganalisis kelas MainActivity.java, kami menemukan pemanggilan fungsi di mana string "su", "kunci-uji" dan "yang" dilewati, dengan bantuan yang melakukan pemeriksaan (lihat Gambar 3).


Fig. 3. Pemeriksaan rutin

Dan lagi, dengan perintah grep, kita melihat file smali untuk memeriksa rutin:

Hasil Pencarian:
root @ kali: ~ / Desktop # grep -nr 'su' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/CM.smali:443: const-string v2, "su" ********_v_0.9.2/smali/o/CM.smali:706: const-string v2, "su" ********_v_0.9.2/smali/o/xZ$5.smali:172: const-string v1, "su" ********_v_0.9.2/smali/o/xZ$5.smali:347: const-string v0, "su" 

root @ kali: ~ / Desktop # grep -nr 'test-keys' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/xZ$5.smali:141: const-string v1, "test-keys" ********_v_0.9.2/smali/o/xZ$5.smali:374: const-string v0, "test-keys" 

root @ kali: ~ / Desktop # grep -nr 'yang' ******** _ v_0.9.2 /

 ********_v_0.9.2/smali/o/CM.smali:437: const-string v2, "which" 

Dalam artikel ini saya hanya akan menunjukkan salah satu modifikasi yang ditemukan dari pemeriksaan rutin. Setelah sedikit manipulasi, yaitu mengubah 1 menjadi 0, pemeriksaan rutin dihapus.


Fig. 4. Nilai variabel sama dengan satu jika ponsel di-root


Fig. 5. Sekarang nilai variabel adalah nol jika ponsel di-root

Setelah itu - program dapat dirakit, ditandatangani dengan kunci rilis Anda dan dijalankan di ponsel. Tetapi jika tidak untuk dua TAPI! Yaitu:

1. Pemeriksaan koneksi USB;
2. memeriksa dimasukkannya mode Pengembang - koneksi USB dan mode Pengembang yang disertakan memungkinkan analisis dinamis.

Pemeriksaan mode Pengembang dimatikan dengan cara yang sama seperti pemeriksaan rutin - dengan mengubah unit menjadi nol dalam pemeriksaan

Di kelas MainActivity.java, kami menemukan garis yang bertanggung jawab untuk memeriksa mode Pengembang (lihat Gambar 6). Setelah itu, cari file di mana string "development_settings_enabled" hadir dan modifikasi tanda centang - ubah 1 ke 0 (lihat Gambar 7 dan 8).


Fig. 6. Periksa apakah mode Pengembang diaktifkan di telepon

Hasil Pencarian:
grep -nr "development_settings_enabled" ******** _ v_0.9.2 \

 Binary file ********_v_0.9.2\/build/apk/classes.dex matches ********_v_0.9.2\/smali/o/xZ$1.smali:49: const-string v1, "development_settings_enabled" 

Fig. 7. Tempat di mana Anda perlu melakukan modifikasi


Fig. 8. Modifikasi

Setelah semua manipulasi, Anda dapat menjalankan program dalam mode Pengembang.

Selanjutnya, matikan cek koneksi USB. Pemeriksaan ini ada di kelas MainActivity.java (lihat Gambar 9). Tanpa grep, kami menemukan garis di MainActivity.smali, kami menemukan garis yang berisi garis dengan cek USB - android.hardware.usb.action.USB_STATE. Setelah itu, dalam kode smali, kami memodifikasi baris ke izin lain yang mengembalikan "false" (lihat Gambar 10).


Fig. 9. Periksa koneksi USB dalam kode MainActivity.java


Fig. 10. Baris kode yang akan dihapus di MainActivity.smali

Sekarang tinggal menghasilkan kunci rilis Anda dan menandatangani aplikasi dengan itu. Ini dilakukan sebagai berikut:

1. Anda perlu menginstal dua aplikasi: Keytool dan Jarsinger.
2. Jalankan perintah untuk merakit aplikasi:
3. apktool b C: \ Users \ User \ Desktop \ ********
4. Berikutnya: cd ******** \ dist \
5. Berikutnya: Keytool.exe -genkey -alias key.keystore -keyalg RSA-validitas 20000 -keystore key.keystore
6. Berikutnya: Jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore key.keystore ********. Apk key.keystore
7. Berikutnya: jarsigner -verify -verbose -certs ********. Apk

Di sini, pada prinsipnya, semua manipulasi selesai. Sekarang kami memasang aplikasi di telepon menggunakan adb install atau dari direktori smartphone dan Anda dapat melakukan pengujian kerentanan dinamis.

Setelah menginstal aplikasi, jalankan (lihat Gambar. 11 dan Gambar. 12).


Kesimpulan

Dalam contoh praktis, saya menunjukkan bagaimana Anda dapat menonaktifkan beberapa pemeriksaan pada kondisi runtime. Selanjutnya, dengan bantuan alat-alat lain, kami melakukan analisis kerentanan, tetapi ini adalah cerita yang berbeda ...

Sikap yang lalai terhadap perlindungan kode dapat menyebabkan:

• ini adalah pengelakan dari cek tertentu yang tertanam dalam program
• implementasi kode pihak ketiga, setelah itu program dapat dipublikasikan dan digunakan sebagai berbahaya

Bagaimana saya bisa melindungi diri saya sendiri? Di ByteCode, kami memutuskan untuk tidak menemukan kembali roda dan menyarankan agar klien mengaburkan kode sumber dan menggunakan fungsi yang memeriksa modifikasi kode sumber.

PS

Anda dapat menggunakan metode analisis yang lebih maju - ini adalah debugging smali. Anda dapat membaca lebih lanjut tentang ini di manual .

Sedikit referensi, saya merumuskan daftar garis yang digunakan untuk memeriksa rutin:

• "Kunci-uji";
• "/system/app/Superuser.apk";
• "/ sbin / su";
• "/ system / bin / su";
• "/ system / xbin / su";
• "/ data / lokal / xbin / su";
• "/ data / lokal / bin / su";
• "/ system / sd / xbin / su";
• "/ system / bin /ailsafe / su";
• "/ data / lokal / su";
• "/ su / bin / su";
• "/ system / xbin / that";
• "Su";
• "Yang".