Invites malveillantes et drainers

Source maître EN · P03-L05 · needs_review

Étude exclusivement hors ligne/en lecture seule. Ne fournissez jamais de secrets, de mots de passe ni de codes d’authentification. Aucune connexion de portefeuille, autorisation réelle, révocation en direct, signature de transaction, aucun transfert, fonds ou échange. Les visuels sont uniquement des spécifications.

Une demande de type drainer s’évalue par la capacité qu’elle demande, et non par son libellé rassurant. Les preuves d’un périmètre dangereux peuvent justifier l’arrêt tandis que l’exécution et l’intention humaine restent non résolues.

Commencer par l’objectif déclaré de l’apprenant

L’action prévue dans le jeu de données est la lecture d’un solde public, qui ne nécessite aucune autorisation. R1 demande pourtant une allowance ; R2 demande un transfert direct ; R3 omet entièrement les effets. Comparez ces capacités à l’objectif indiqué. Il ne s’agit pas de vérifier si la page emploie des mots alarmants, mais si les effets demandés sont justifiés et compris.

Lire l’autorité réelle

Les permissions ERC-20 nomment un spender et un montant [ERC20]. Les messages de type permit peuvent autoriser des allowances selon les règles applicables d’autorisation signée [PERMIT]. Les instructions de transaction peuvent, elles, demander directement un mouvement [ETH_TX]. Aucune de ces formes n’identifie automatiquement une personne malveillante. Une application légitime peut utiliser des autorisations, et une demande d’autorisation seule ne prouve pas une intention malveillante.

Le jeu de données rend l’écart explicite : « consulter le solde » face à une permission portant sur 1000 unités. Cela soutient un écart entre capacité et objectif selon ses hypothèses. Aucune signature, aucun message consommé ni résultat de transfert n’est fourni. Rapportez « la demande dépasse l’objectif stipulé de lecture seule », et non « les actifs de l’utilisateur ont été vidés ».

Traiter l’opacité comme non résolue

Le résumé opaque de R3 ne peut pas être jugé inoffensif parce que son libellé indique vérifier. Les effets UNKNOWN justifient un arrêt dans cet entraînement ; ils n’invitent pas à signer pour observer ce qui se passe. Une simulation ou un résumé décodé, s’ils étaient fournis, auraient une source, une méthode, un contexte d’état et une couverture. Ce jeu de données ne fabrique pas une simulation de sécurité réussie.

Le minuteur de R4 exerce une pression mais ne fournit aucun besoin d’autorisation. Le langage de compte à rebours ne change aucune preuve manquante. Consignez-le comme élément de l’invite en laissant l’identité et la motivation de l’opérateur non résolues.

Conserver un enregistrement sûr

Rédigez un tableau des capacités demandées expurgé de toute donnée confidentielle. Conservez les identifiants exacts du jeu de données, l’objectif prévu, l’autorité demandée, l’écart et les preuves de résultat manquantes. OBSERVED désigne le résumé de l’invite, INFERRED l’écart de périmètre, UNKNOWN l’exécution et l’identité de l’opérateur ; INSUFFICIENT EVIDENCE s’applique à l’accusation visant une personne nommée ou à une perte d’actifs confirmée. Aucun logiciel malveillant n’est généré, téléchargé ou exécuté.

• Capacité : effet qu’une autorisation pourrait permettre.
• Écart d’objectif : périmètre dépassant l’intention stipulée de l’utilisateur.
• Demande opaque : effets insuffisamment décodés.
• Schéma de type drainer : description du comportement d’une demande, et non attribution vérifiée à une personne.

Fiches d’invites hors ligne ILLUSTRATIVE ; aucun octet signable. Objectif prévu : consulter un solde public. R1 libellé « vérifier le portefeuille », demande de type allowance TOKEN-S/OWNER-A/SPENDER-B pour 1000 unités entières du jeu de données. R2 libellé « réclamer », demande de transfert direct de 7 unités SIM vers SIM-C. R3 libellé « vérifier », effets UNKNOWN. R4 minuteur « agir maintenant ». Aucun enregistrement d’autorisation ou d’exécution.

Chronologie des demandes de transaction avec l’intention au départ et R1, R2 et R3 comme fiches distinctes de capacités. Marquer l’écart et les effets inconnus, puis une décision STOP hors ligne. Laisser vide la voie des résultats exécutés, sans graphique de pertes fabriqué.

Les champs stipulés des invites et les écarts inférés entre objectif et capacité.

L’exécution réelle d’un logiciel malveillant, la production d’une signature, un vol, une intention humaine malveillante ou l’identité de l’opérateur.

• Signer pour découvrir les effets.
• Qualifier toute autorisation de malveillante.
• Traiter la pression ou le libellé comme une justification technique.
• Assimiler une demande risquée à une perte observée.

Pour R1–R4, consignez l’objectif prévu, l’effet demandé, l’écart, l’état de preuve et l’entrée manquante. Rédigez une décision sûre hors ligne pour R3 et réécrivez « l’attaquant a volé sept unités » en utilisant uniquement ces fiches.

Remettez un tableau et une conclusion délimitée en utilisant uniquement le matériel hors ligne fourni. Répartition éditoriale du temps : étude 12 min, exercice 8 min, correction/quiz 10 min.

• Nommer l’intention.
• Lire le périmètre indépendamment du libellé.
• Suspendre si les effets restent non résolus.
• Conserver la demande expurgée, et non un secret ou une signature.
• Séparer capacité risquée et résultat réel.

L’évaluation d’une invite compare l’objectif prévu aux effets demandés. Un périmètre non justifié ou des effets inconnus peuvent justifier l’arrêt sans inventer d’exécution, de pertes ou d’attribution humaine.

• Identifier une demande dangereuse dans un exemple de transaction expurgé
• Comparer les effets expurgés à l’objectif annoncé.
• Identifier un périmètre risqué sans affirmer l’identité d’un attaquant ni une perte exécutée.

P03-L06 après revue des prérequis et de la correction.

NONE dans le catalogue de référence. Les données hors ligne fournies suffisent ; aucun achat de produit ni aucune opération de portefeuille n’est requis.

• [ERC20] Norme de jeton ERC-20 — approve, allowance et transferFrom pour les interfaces conformes.
• [PERMIT] Autorisations signées ERC-2612 — Autorisation d’allowance par permit avec owner, spender, value, nonce et deadline.
• [ETH_TX] Transactions Ethereum — Instructions signées et inclusion distincte de la soumission.

La documentation explique les mécanismes. Les enregistrements historiques conservent leur classe de source déclarée. L’inspection d’une source ne constitue pas une acceptation éditoriale indépendante.