Le commentaire de la classe BillingService recommande que : p>
Vous devez modifier et obscurcir ce code avant de l'utiliser. p> blockQuote>
OK, mais ce que strud> doit être modifié? P>
Le nom de la classe? La balise utilisée pour la journalisation? Noms de méthode et membres de données? La logique et le flux de programme lui-même? Autre? P>
En d'autres termes, je peux comprendre le besoin d'obfuscation, mais comment puis-je m'éloigner avec la mise en œuvre de la recommandation sans réécrire tout de zéro em> (potentiellement avec des bugs qui pires que ne rien modifier)? p>
3 Réponses :
Ils l'expliquent comme suit: p>
L'application d'échantillon de facturation intégrée est distribuée publiquement et peut être téléchargé par n'importe qui, ce qui signifie qu'il est relativement facile pour un attaquant pour inverser l'ingénieur Votre application si vous utilisez l'échantillon code exactement comme il est publié. L'exemple d'application est destiné à être utilisé que comme exemple. Si vous utilisez une partie de l'échantillon application, vous devez la modifier avant de la publier ou de le publier comme une partie d'une application de production. P>
En particulier, les attaquants recherchent des points d'entrée connus et des points de sortie Dans une application, il est donc important que vous modifiez ces parties de votre code identique à l'application exemple. P> blockQuote>
Cela signifie que vous n'utilisez pas le code comme indiqué, en modifiant une partie de celui-ci afin que les pirates informatiques ne puissent pas savoir quel code vous utilisez. P>
Fondamentalement, je ne pense pas qu'ils signifiaient la facturation elle-même, mais la façon dont vous l'utilisez dans votre application. P>
OK, mais ce commentaire apparaît dans plusieurs modules de l'échantillon, au début de chaque module: BillingService, ResponsibleHandler, achetéAtabase. Quel genre de changements?
Modifications apportées à l'application qui les utilise, non modifiées directement.
J'aime votre interprétation, mais j'ai bien peur que ce soit le contraire de ce que Google signifiait: "Si vous utilisez Toute pièce B> de l'application exemple, vous devez la modifier avant de le publier ou de le publier dans le cadre duquel b> d'une application de production. " Cela signifie que cela signifie une restructuration au moins des 3 modules mentionnés ci-dessus.
BillingService n'est pas de l'application de l'application, il s'agit d'un service utilisé dans l'exemple d'application. Donc, ce que vous avez à faire est de modifier le code d'application exemple.
Aucune bonne nouvelle ici: Vous devez changer tout ce que vous pouvez, en plus d'utiliser PROGUARD. Cela inclut la fusion de cours, les fractionnement, déplacer certaines méthodes d'un module à l'autre, et notamment le cryptage des informations d'achat stockées dans la base de données, comme la description de la classe Vous devez utiliser un obfousciateur avant de stocker des informations pour
stockage persistant. L'obfousciateur doit utiliser une clé spécifique
à l'appareil et / ou à l'utilisateur. Sinon un attaquant pourrait copier une base de données
plein d'achats valides et distribuez-le aux autres. p>
blockQuote>
La raison en est que, avec des outils tels que Antilvl, il est très facile de comparer votre code décompilé (obscurposé!) à l'échantillon d'origine et de déduire de celui-ci au besoin pour le compromettre. Il est impossible d'éviter complètement la fissuration, mais vous devriez essayer de le rendre aussi difficile que possible. P> achetéeAtabase code> suggère: p>
Je travaille à ce moment-là et mon approche, jusqu'à présent, c'est comme suit: P>
J'espère que cela aide. P>
Votre réponse détaillée mérite définitivement le +50. Merci.