御盾Conclusions et conditions de décision
- Ne soumettez pas simplement un installateur portant le même nom ; vous devez enregistrer sa source, sa version, son empreinte de fichier, son plan de signature et ses canaux de distribution prévus.
- Ne demandez pas simplement une « force maximale » ; spécifiez quelle logique, si elle était rétro-ingéniérée ou modifiée, entraînerait des pertes métier spécifiques.
- La pile technologique doit couvrir les langages, les systèmes de build, les versions minimales du système d'exploitation, les ABI, les composants natifs, le chargement dynamique, les frameworks multiplateformes et les SDK tiers.
- Définissez les conditions de succès, d'échec, de périmètre non couvert, d'arrêt et de retour arrière avant le PoC pour éviter de confondre un lancement réussi avec une aptitude à la mise en production.
Fournissez d'abord une candidate à la publication uniquement identifiable
La candidate à la publication sert d'objet commun pour la configuration, les tests et les conclusions ultérieurs. Fournissez au minimum le nom du paquet ou l'identifiant de bundle, la version, la source de build, le SHA-256 du fichier, l'état actuel de la signature, le plan de signature cible et les canaux de distribution prévus. Si la livraison du fichier est temporairement impossible, indiquez clairement si le projet est en phase d'architecture, de développement, d'intégration ou de préparation à la publication.
Des fichiers portant le même nom ne représentent pas le même artefact. Une reconstruction, une re-signature, une modification des ressources de canal ou un remplacement de dépendances génèrent une nouvelle identité. Pour chaque changement, spécifiez quelles validations doivent être réexécutées ; n'appliquez pas directement les conclusions de réussite d'anciennes candidates à de nouveaux fichiers.
Lorsqu'il s'agit de code propriétaire ou de données utilisateur, soumettez-les via le flux de travail de projet contrôlé sur la plateforme centrale de Yudun. Les sites de sujets publics fournissent uniquement des méthodes et des points d'entrée ; ils n'acceptent ni comptes, ni installateurs, ni certificats, ni secrets de projet.
| Champ | Contenu exemple | Objectif | Lacunes courantes |
|---|---|---|---|
| Identité de l'application | Nom du paquet ou identifiant de bundle, version | Correspond à la portée de publication, de mise à jour et de test | Seul le nom du magasin est fourni |
| Identité du fichier | SHA-256 et heure de génération | Garantit que toutes les preuves pointent vers le même fichier | Écrasement d'anciens fichiers portant le même nom |
| Source de build | Branche, commit, tâche CI ou enregistrement de publication | Traçabilité des incidents et reconstruction | Impossibilité de spécifier la source |
| Plan de signature | État actuel, certificat final et étapes de signature | Valide l'identité de mise à jour et de publication | Re-signature arbitraire après le PoC |
| Périmètre de distribution | Magasin, entreprise ou canaux privés | Détermine les signaux d'intégrité et les contrôles de livraison | Supposition que tous les canaux sont identiques |
Définir la perte métier pour le code nécessitant une protection
« Force maximale », « protection complète » et « anti-craquage » ne sont pas des exigences exécutables. Listez les algorithmes centraux, les vérifications d'autorisation, la gestion des protocoles, les droits de contenu, les modèles ou les décisions locales critiques, et expliquez la perte spécifique encourue s'ils sont compris, copiés, modifiés ou contournés.
Expliquez simultanément pourquoi cette logique doit rester côté client. Les autorisations à haut risque pouvant être gérées côté serveur doivent d'abord être décidées par le serveur ; la protection côté client ne doit être évaluée que pour les chemins nécessitant une capacité hors ligne, une faible latence ou des fonctionnalités natives de la plateforme. Cela garantit que le VMP est réservé au code qui nécessite véritablement une représentation d'exécution altérée.
Chaque actif doit également avoir un propriétaire, un point d'entrée d'invocation, une fréquence d'exécution, un contexte de thread, des définitions d'entrée/sortie, des dépendances et une procédure de repli en cas d'échec. Les actifs sans parcours de validation indépendant doivent d'abord se voir attribuer des conditions de test, quelle que soit leur valeur.
| Type d'actif | Perte à décrire | Nécessité côté client | Préparation de validation suggérée |
|---|---|---|---|
| Autorisation et droits | Ressources accessibles si les branches locales sont contournées | Capacité hors ligne ou jugement local rapide | États normal, expiré, altéré et de revérification serveur |
| Algorithmes principaux | Perte de valeur commerciale en cas de copie | Performance sur l'appareil, confidentialité ou besoins hors ligne | Cohérence des entrées/sorties, performance et données limites |
| Protocole et utilisation des clés | Conséquences de la relecture, de la falsification ou de l'abus massif | Liaison à l'appareil ou communication locale | Gestion des erreurs, détection de relecture, rotation et limites serveur |
| Modèles ou règles sur l'appareil | Réplication et modification des modèles, invites ou post-traitements | Exigences hors ligne, de confidentialité ou de faible latence | Appairage des versions, chargement, retour arrière et journalisation |
| Interfaces tierces critiques | Conséquences du contournement du SDK ou d'une invocation incorrecte | Exigences de plateforme ou de canal | Comptes réels, signatures et chemins de rappel |
L'inventaire de la pile technologique définit les limites des tests de compatibilité
Les projets Android doivent spécifier les versions de Java, Kotlin, NDK, Gradle et du plugin Android Gradle, minSdk, targetSdk, les ABI publiés, ainsi que l'utilisation de la réflexion, de la sérialisation, du chargement dynamique de classes, des correctifs à chaud, de la pluginisation, de WebView, des composants natifs et des architectures multiprocessus. Les projets iOS doivent spécifier Swift, Objective-C, la version minimale du système d'exploitation, les extensions, les bibliothèques dynamiques, les caractéristiques d'exécution et les capacités de signature.
Pour Flutter, React Native, Unity, Cocos ou d'autres frameworks multiplateformes, enregistrez la version du framework, la méthode de pontage, le moteur et les bibliothèques natives métier. Ne vous contentez pas d'indiquer « multiplateforme », car la structure des artefacts, le comportement au démarrage et les intégrations tierces varient considérablement selon les versions.
La connexion tierce, les paiements, les notifications push, les cartes, l'audio/vidéo, l'analytique, le contrôle des risques, les correctifs à chaud et les services fournisseurs peuvent dépendre de la réflexion, des signatures, des entrées Manifest, des schémas d'URL, de JNI, des ressources ou de leurs propres vérifications d'intégrité. Lister ces éléments complètement lors de l'évaluation initiale fait gagner plus de temps que de les deviner un par un après des plantages.
- Langues, systèmes de build et versions majeures des plugins
- Systèmes d'exploitation, appareils et ABI minimums et cibles
- Composants natifs, JNI, chargement dynamique et frameworks multiplateformes
- Multiprocessus, WebView, correctifs à chaud et pluginisation
- SDK critiques : Connexion, Paiement, Push, Audio/Vidéo, etc.
Clarifier la signature, les canaux et les plans de mise à niveau avant le PoC
Spécifiez quelle signature utilise l'artefact PoC, qui signe la version formelle, si les ressources de canal sont traitées avant ou après la signature, si Play App Signing est utilisé et quelle méthode de distribution est employée pour iOS. Ces facteurs influencent l'installation, les mises à niveau, les signaux d'intégrité et l'identité finale du fichier.
Android indique officiellement que les clés de signature d'application confirment que les mises à jour proviennent du même détenteur de clé. Si le PoC utilise un certificat temporaire, il valide uniquement cet environnement spécifique et ne prouve pas automatiquement la couverture pour les versions en ligne. La validation formelle doit utiliser un plan de signature cohérent avec la chaîne de release, autorisé par les workflows d'autorisation et de sécurité.
Le traitement des canaux doit suivre un ordre fixe. Modifier le corps du paquet après la signature finale rompt la signature ; reconstruire ou resigner après validation génère un nouveau candidat. Les versions de retour arrière doivent également vérifier à l'avance les signatures, les numéros de version, la migration des données et les mises à niveau par écrasement.
| Question | Pourquoi cela importe | État acceptable du PoC | Exigence de validation formelle |
|---|---|---|---|
| Qui effectue la signature finale ? | Détermine la responsabilité de la clé et l'identité de l'artefact | Signature temporaire avec des limitations claires | Cohérent avec le processus formel et auditable |
| Quand le corps du paquet est-il modifié pour les canaux ? | La modification altère le fichier et le contenu signé | L'ordre peut être décrit | Terminé avant la signature avec une identité re-fixée |
| Comment couvrir les versions en ligne ? | Valide la signature et la continuité de version | Peut être ignoré mais marqué comme non couvert | Mise à niveau depuis une version en ligne réelle |
| Comment effectuer un retour arrière ? | Doit être exécutable lors d'incidents | Préparer le candidat de référence | Paquet de retour arrière pré-vérifié avec un propriétaire assigné |
Définir dès le départ les conditions de succès, d'échec et d'arrêt du PoC
Un PoC ne se limite pas à générer un paquet durci installable. Déterminez à l'avance le périmètre de protection à observer, la surface d'exposition statique, le comportement au démarrage, les flux métiers critiques, le budget performance, les systèmes cibles, les ABI, les SDK tiers, l'installation/mise à jour et les replis sur exception. Chaque projet peut avoir des pondérations différentes, mais aucune définition ne peut manquer.
Les conditions de réussite doivent être mesurables, telles que des entrées/sorties de clés cohérentes, la validation de chaque système cible, des modifications de démarrage dans le budget du projet, des chemins d'exception sécurisés et des configurations de protection traçables. Les conditions d'échec incluent le blocage au démarrage, les erreurs métier critiques, les changements de performance inacceptables, les défaillances de compatibilité dans le périmètre cible ou les problèmes non attribuables.
Les conditions d'arrêt empêchent l'expansion aveugle du périmètre. Si les identités candidates sont incohérentes, les références manquantes, les journaux critiques indisponibles, les workflows de signature non confirmés ou si les environnements de test ne correspondent pas au périmètre de release, comblez ces lacunes avant de poursuivre.
| Statut | Signification | Exigence de rapport | Publiable ? |
|---|---|---|---|
| Vérifié | Preuve obtenue pour le même candidat dans le périmètre convenu | Spécifier la méthode, l'environnement, les résultats et les limites | Le jugement n'est valable que pour ce périmètre |
| Échoué | Un blocage reproductible ou un non-respect du budget s'est produit | Conserver les premières différences et l'impact | Impossible de publier avec la configuration d'origine |
| Non exécuté | Appareils, comptes, données ou autorisations manquants | Indiquer la raison et les prochaines étapes | Ne peut être substitué par d'autres résultats |
| Non applicable | Le projet exclut explicitement cette plateforme ou cette capacité | Fournir la base de la détermination | Exclu du périmètre actuel |
project_stage: release-candidate
artifacts:
baseline: identified
protected_candidate: pending
assets:
- entitlement-decision
- protocol-core
stack:
platform: Android
min_os: project-defined
abis: [arm64-v8a]
critical_journeys:
- cold-launch
- sign-in
- protected-operation
acceptance:
functional_parity: required
performance_budget: project-defined
compatibility_matrix: required
rollback_rehearsal: required
boundaries:
- no_unverified_attack_resistance_claim
- uncovered_devices_remain_openLivrables formés par l'évaluation Yudun après soumission complète des données
Une entrée complète prend en charge trois phases consécutives. La phase Un confirme les actifs, la pile technologique et la chaîne de release pour former un périmètre de protection initial et une liste de risques. La phase Deux génère un PoC traçable et exécute des contrôles statiques et runtime sur la même identité candidate. La phase Trois ajuste le périmètre selon les résultats pour finaliser la matrice cible, les limites de release et les conditions de retour arrière.
Les capacités de protection spécifiques, le support des plateformes, les budgets performance et les cycles de livraison doivent être confirmés sur des projets réels. Cette page n'utilise aucun cas client, taux de réussite ou chiffre de performance générique, et ne promet aucun résultat final sans candidat de release.
La connexion, l'inscription, les applications, la tarification et les données de projet sont unifiées au sein de la plateforme centrale Yudun. Les sites thématiques n'établiront pas de second jeu de comptes ou de systèmes d'application. Organisez les matériaux selon cette checklist avant soumission pour éviter de compléter répétitivement les identités candidates et les périmètres de release après le lancement du projet.
- Candidat de release, référence et chaîne de release traçables
- Description claire des actifs protégés et des pertes métiers
- Pile technologique complète, dépendances tierces et matrice cible
- Conditions de succès, d'échec, de périmètre non couvert et de retour arrière définies
- Soumettre les données sensibles uniquement via la plateforme centrale
Limites des preuves et de l’applicabilité
Cette section sépare les faits documentés sur la plate-forme, le jugement technique et les limites qui ne peuvent pas être généralisées à des allégations de produit non vérifiées.
| Article jugement | Base factuelle ou technique | Limite d'applicabilité |
|---|---|---|
| L'identité du candidat de release est la clé primaire commune pour les preuves d'évaluation. | La reconstruction, la signature, les modifications de canal et les changements de dépendances altèrent le fichier final et le comportement runtime potentiel. | SHA-256 identifie le fichier mais n'implique pas que le fichier soit sécurisé. |
| Les cibles de protection VMP doivent découler de la perte métier et de la modélisation des menaces. | OWASP MASVS traite l'anti-rétro-ingénierie et l'anti-altération comme une défense en profondeur contre des menaces spécifiques, et non comme des remplacements pour la logique serveur ou l'architecture globale. | Les normes ne peuvent pas prouver qu'un candidat ou une configuration spécifique a réussi. |
| Les plans de signature et de mise à jour doivent former une boucle fermée lors de la recette formelle. | Android utilise l'identité de signature de l'application pour confirmer la continuité des mises à jour ; les plateformes Apple exigent également que le code exécutable respecte la chaîne de signature de code. | Différentes méthodes de distribution et stratégies de rotation des certificats doivent être vérifiées par projet. |
| La capacité d'installer et de lancer l'application ne constitue pas une conclusion complète de preuve de concept (PoC). | La mise en production implique également des flux métiers critiques, les performances, les systèmes, les ABI, les tiers, les mises à niveau, la surveillance et le retour arrière. | Les projets peuvent réduire la matrice selon le périmètre réel des utilisateurs, mais les éléments non couverts doivent être explicitement indiqués. |
| Les sites thématiques n'acceptent aucune donnée sensible de projet. | Les comptes, applications et données de projet sont gérés uniformément par la plateforme centrale Yudun ; les sites de contenu fournissent uniquement des méthodes publiques et des redirections. | Les autorisations d'accès spécifiques aux données et les règles de conservation relèvent de la plateforme centrale et des accords de projet. |
Questions d'ingénierie
Puis-je demander une évaluation avec seulement un APK et sans le code source ?
Vous pouvez d'abord confirmer l'artefact et les cibles, mais la configuration de protection, l'attribution des problèmes et les capacités de reconstruction pourraient être limitées. Vous devez préciser si vous pouvez fournir une coopération pour la construction, les symboles, des comptes de test et des références.
La signature formelle doit-elle être fournie lors de la première communication ?
Pas nécessairement. Une signature de test contrôlée peut être utilisée pour une preuve de concept partielle, mais il doit être clairement indiqué que cela ne représente ni les mises à niveau en production ni la chaîne de signature formelle. Le plan de mise en production doit être finalisé avant la recette formelle.
Pourquoi lister tous les SDK tiers ?
Les SDK tiers peuvent dépendre de la réflexion, des signatures, des ressources, du JNI, de l'ordre d'initialisation ou de leurs propres vérifications d'intégrité, ce qui en fait une source majeure de problèmes de compatibilité.
Puis-je demander directement la force maximale complète ?
Vous pouvez exprimer vos préférences en matière de risques, mais le périmètre final doit toujours être stratifié selon la valeur métier, la fréquence d'exécution, le rayon d'impact et les capacités de tests de régression ; sinon, il est difficile d'établir une conclusion de version stable.
Les données listées dans cet article peuvent-elles être téléchargées directement via le site thématique ?
Non. Les sites thématiques fournissent uniquement du contenu public. La connexion, l'inscription, les applications et les données de projet doivent être redirigées vers la plateforme centrale Yudun pour traitement.
Vous voulez tester cela sur votre propre application ?
Soumettez la version candidate, les systèmes cibles et les chemins commerciaux critiques pour une évaluation Yudun PoC et de compatibilité.