Apakah risiko keselamatan jika SDK tidak dikeraskan?

Apakah risiko keselamatan yang akan ada jika SDK tidak dikeraskan?

1 Mudah untuk pesaing atau pihak yang berniat jahat untuk mengintip butiran pelaksanaan dalaman atau proses panggilan dalaman, malah mungkin membocorkan data peribadi

Android. platform SDK adalah sangat besar Sebahagian daripada mereka ditulis dalam bahasa Java dan boleh dinyahkompilasi dengan mudah. Kekeliruan mudah mungkin mendedahkan butiran pelaksanaan dalaman, manakala data peribadi dalam SDK berkemungkinan besar untuk dibocorkan. Jika butiran ini mendedahkan kaedah pelaksanaan teknologi utama, maka ia sama dengan membocorkan teknologi teras.

2. Iklan berniat jahat atau kod berniat jahat ditanamkan oleh pelaku berniat jahat melalui suntikan bytecode dan cara lain dan kemudian dibungkus semula dan dikeluarkan

Disebabkan kekhususan SDK, tidak seperti Apl Terdapat logik pengesahan tandatangan seperti itu, jadi sebaik sahaja orang yang berniat jahat menanamkan beberapa kod berniat jahat atau iklan berniat jahat dalam SDK anda dan kemudian mengeluarkannya semula, ia akan menjadi sukar untuk dikesan, menjejaskan imej jenama dan reputasi pembangun secara serius.

3. Orang yang retak memintas logik utama dan menyebabkan kerugian ekonomi

Jika SDK mempunyai fungsi pembayaran, orang yang berniat jahat akan menganalisis dan mencari logik pembayaran, yang berlaku untuk melibatkan logik berkaitan pembayaran. Jika pengesahan sisi pelayan tidak dilakukan dengan baik, sebaik sahaja pelakon yang berniat jahat mengalih keluar logik pembayaran ini melalui AOP, ini bermakna perkhidmatan berbayar akan tersedia secara percuma.

4. SDK itu sendiri mungkin mempunyai kelemahan dan boleh dieksploitasi dengan mudah oleh pihak yang berniat jahat

Pembangun SDK sering menumpukan pada pelaksanaan fungsi semasa pembangunan tidak dipandang terlalu serius, jadi sukar untuk memastikan SDK yang anda bangunkan tidak mempunyai sebarang kelemahan. Oleh itu, apabila terdapat beberapa kelemahan keselamatan dalam SDK, dan kelemahan ini diketahui dan dieksploitasi oleh pelakon yang berniat jahat, ia seperti meletakkan periuk api yang mungkin meletup pada bila-bila masa. Reputasi pembangun SDK bukan sahaja akan terjejas oleh ancaman terhadap keselamatan data dan privasi, tetapi mereka juga mungkin bertanggungjawab untuk pampasan kewangan jika masalah timbul.

Bagaimana untuk menyelesaikan

Daripada analisis risiko keselamatan di atas, kita dapat melihat bahawa pokok masalahnya ialah pengguna berniat jahat boleh dengan mudah mendapatkan logik pelaksanaan SDK . Oleh itu, adalah disyorkan bahawa pembangun mengambil langkah perlindungan berikut:

1 Pengubahsuaian data utama mesti lulus pengesahan bahagian pelayan: Contohnya, dalam logik berkaitan pembayaran yang dinyatakan di atas, pengubahsuaian kepada data seperti baki. atau jumlah pembayaran mesti lulus terlebih dahulu Pelayan mengesahkan, dan kemudian menyegerakkan keputusan kepada pelanggan; dan laksanakannya dalam C/C++ untuk meningkatkan ambang penyahkompilasi ;

3 Sulitkan rentetan: Rentetan dalam kod, terutamanya rentetan dengan maklumat sensitif, mesti disulitkan dan dinyahsulitkan pada masa jalan.

Tetapi mencapai mata di atas tidak mencukupi. Ia hanya boleh menghalang pemaju biasa. SDK yang kami bekerja keras untuk membangunkan mungkin menjadi makanan meriam di tangan keropok profesional, mengakibatkan kerugian kewangan.

Oleh itu, adalah disyorkan untuk menyambung kepada perkhidmatan keselamatan pihak ketiga, seperti perkhidmatan pengukuhan SDK Yidun.

Sebelum memperkenalkan peneguhan SDK Yidun, mari kita perkenalkan dahulu kaedah pengeliruan yang kini digunakan oleh kebanyakan pembangun di pasaran - Proguard . Proguard ialah pengeliruan yang paling banyak digunakan pada platform Android Ia diproses dari peringkat sintaks melalui pepohon sintaks abstrak, menjadikan kod yang diproses sukar dibaca dan difahami. Seperti yang ditunjukkan di bawah:

Walau bagaimanapun, menukar nama kelas dan nama kaedah kepada beberapa rentetan rawak yang tidak bermakna, seperti "a, b, c", walaupun ia boleh meningkatkan Ia memerlukan keropok untuk membaca dan memahami, tetapi jelas kesannya amat terhad. Untuk keropok, hanya menunggu masa sebelum mereka dapat mengetahui maksud kod itu.

Jadi apakah penyelesaian pengukuhan SDK Yidun? Seterusnya, saya akan memperkenalkan kepada anda:

Kosongkan kaedah kelas yang akan dilindungi, dan enkripsikan arahan yang diekstrak runtime dilaksanakan melalui mesin maya tersuai, menjadikannya mustahil untuk keropok mendapatkan logik kod asal.

Kesannya adalah seperti berikut:

Penyelesaian ini ialah Nativeize kaedah kelas untuk dilindungi, dan pada masa yang sama menukar logik pelaksanaan fungsi asal ke dalam kod C/C++ yang sepadan dengan lapisan Native, dan secara langsung melaksanakan fungsi Native yang sepadan semasa runtime. Kesannya adalah seperti berikut:

Contoh selepas pengerasan

Dari perspektif analisis statik, berbanding dengan Proguard obfuscation, adalah jelas bahawa kaedah yang dikeraskan telah Nativeized, dan logik pelaksanaan tidak dapat dilihat sepenuhnya dalam lapisan Java. Logik fungsi asal lapisan Java ditukarkan kepada pelaksanaan kod C/C++ bagi lapisan JNI Pada masa yang sama, lapisan Asli yang dijana SO disulitkan untuk menambah baik kesukaran meretak dalam semua aspek.

(Nota: Untuk melihat dengan lebih jelas dalam gambar di atas, kaedah yang dikeraskan telah ditukar kepada pelaksanaan lapisan Native yang sepadan, dan lapisan Native SO yang dihasilkan tidak disulitkan. Sebenarnya, penyelesaian Java2c yang dikeraskan Yidun SDK akan Lapisan asli SO untuk penyulitan)

Atas ialah kandungan terperinci Apakah risiko keselamatan jika SDK tidak dikeraskan?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!