Quels sont les risques de sécurité si le SDK n'est pas renforcé ?

Quels sont les risques de sécurité si le SDK n'est pas renforcé ?

1. Il est facile pour des concurrents ou des parties malveillantes de jeter un œil aux détails de mise en œuvre interne ou aux processus d'appel internes, et peuvent même divulguer des données privées #🎜🎜 ##🎜 🎜#La plupart des SDK de la plateforme Android sont écrits en langage Java et sont faciles à décompiler. Un simple obscurcissement peut révéler des détails d'implémentation internes, tandis que les données privées du SDK sont plus susceptibles d'être divulguées. Si ces détails révèlent la méthode de mise en œuvre de la technologie clé, cela équivaut alors à une fuite de la technologie de base.

2. Des publicités malveillantes ou des codes malveillants sont implantés par des parties malveillantes via l'injection de bytecode et d'autres moyens, puis reconditionnés et publiés

En raison de SDK Il est unique. Il n'a pas de logique de vérification de signature comme App. Par conséquent, une fois qu'une personne malveillante implante un code malveillant ou des publicités malveillantes dans votre SDK puis le réédite, il sera difficile à détecter, ce qui affectera sérieusement l'image de la marque. et la réputation du développeur.

3. La personne crackée contourne la logique clé et provoque des pertes économiques

Si le SDK a une fonction de paiement et est analysé par des acteurs malveillants pour trouvez la logique de paiement. Si la logique liée au paiement n'est pas correctement vérifiée côté serveur, une fois que les acteurs malveillants suppriment la logique de paiement via AOP, cela signifie que les services payants seront disponibles gratuitement.

4. Le SDK lui-même peut présenter des vulnérabilités et peut être facilement exploité par des parties malveillantes

Les développeurs du SDK se concentrent souvent sur la mise en œuvre des fonctions. , la sécurité n'est généralement pas trop prise en compte, il est donc difficile de garantir que le SDK développé par soi-même ne présente aucune vulnérabilité. Par conséquent, une fois qu’il existe des vulnérabilités de sécurité dans le SDK et que ces vulnérabilités sont connues et exploitées par des acteurs malveillants, cela revient à poser une mine terrestre qui peut exploser à tout moment. La réputation des développeurs de SDK sera non seulement affectée par les menaces pesant sur la sécurité des données et de la vie privée, mais ils pourront également être tenus responsables d'une compensation financière en cas de problèmes.

Comment résoudre

Comme le montre l'analyse des risques de sécurité ci-dessus, le nœud du problème est que les utilisateurs malveillants peuvent facilement obtenir la logique de mise en œuvre du SDK. Par conséquent, il est recommandé aux développeurs de prendre les mesures de protection suivantes :

1 Les modifications des données clés doivent passer une vérification côté serveur : par exemple, la logique liée au paiement mentionnée ci-dessus, les modifications apportées aux données telles que le solde ou le montant du paiement doit d'abord passer la vérification côté serveur, puis synchroniser les résultats avec le client

2 La logique clé est implémentée dans la couche native : une logique clé de la couche Java est. transféré vers la couche JNI et implémenté en C/C++ Augmentez le seuil de décompilation

3 : Les chaînes du code, en particulier les chaînes d'informations sensibles, doivent être chiffrées et déchiffrées au moment de l'exécution.

Mais atteindre les points ci-dessus ne suffit pas, cela ne peut qu'empêcher les développeurs ordinaires. Le SDK pour lequel nous avons travaillé si dur pourrait devenir de la chair à canon entre les mains de crackers professionnels, entraînant des pertes financières.

Par conséquent, il est recommandé d'accéder à des services de sécurité tiers, tels que le service de renforcement SDK de Yidun.

Introduction au renforcement du SDK Yidun

Avant d'introduire le renforcement du SDK Yidun, présentons d'abord ce que la plupart des développeurs utilisent actuellement sur le marché. La manière d'obscurcir - Progarde. Proguard est l'obscurcissement le plus utilisé sur la plate-forme Android. Il est traité à partir du niveau syntaxique via des arbres de syntaxe abstraits, ce qui rend le code traité difficile à lire et à comprendre. Comme indiqué ci-dessous :

Mais remplacez le nom de la classe et le nom de la méthode par des chaînes aléatoires dénuées de sens, telles que "a,b, c ", bien que cela puisse augmenter les coûts de lecture et de compréhension du cracker, son effet est évidemment extrêmement limité. Pour les crackers, ce n'est qu'une question de temps avant qu'ils puissent comprendre l'intention du code.

Alors, quelle est la solution de renforcement SDK de Yidun ? Ensuite, je vais vous présenter :

1. Solution VMP de renforcement du SDK Yidun

Vider les méthodes de la classe à protéger et extraire Le traitement de chiffrement des instructions est exécuté via une machine virtuelle personnalisée au moment de l'exécution, ce qui empêche les pirates d'obtenir la logique du code d'origine.

L'effet est le suivant :

2. #🎜🎜 #

Cette solution consiste à nativeiser la méthode de la classe à protéger, et en même temps à convertir la logique d'implémentation de la fonction d'origine en code C/C++ correspondant à la couche native, et exécutez directement la fonction native correspondante pendant l'exécution. L'effet est le suivant :

Exemple avant renforcement

# 🎜🎜#

Exemple après renforcement
Du point de vue de l'analyse statique, par rapport à l'obscurcissement Proguard, il est évident que la méthode de renforcement a été nativeisé et implémenté La logique est complètement invisible dans la couche Java. La logique fonctionnelle originale de la couche Java est convertie en implémentation de code C/C++ de la couche JNI. Dans le même temps, la couche native SO générée est cryptée pour améliorer la difficulté de craquage sous tous les aspects.

(Remarque : afin de voir plus clairement dans l'image ci-dessus, la méthode renforcée a été convertie en implémentation de couche native correspondante, et le SO de couche native généré n'est pas chiffré. En réalité, la solution Java2c renforcée du SDK Yidun générera le code renforcé SO pour le cryptage)

.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!