Abus de privilèges d’offre et transferts restrictifs

Création ou restriction peut changer capacités des utilisateurs, mais code présent ou un transfert échoué ne prouve pas indépendamment usage malveillant sur tous les portefeuilles.

Séparez capacité accessible, invocation observée, effet d’état et intention attribuée. Un nom mint ne suffit pas : inspectez implémentation, autorisation et voies alternatives. Création privilégiée observée exige identité exacte du token, rapprochement événement/état, bloc et montant. Un slogan de plafond peut être limité par mises à niveau ou rôles alternatifs. Une restriction peut avoir objectifs légitimes déclarés, mais effets réels se testent à état défini.

Pour transferts sélectifs, précisez classe d’expéditeur, destinataire, route, montant, bloc et méthode. Succès privilégié ne prouve pas sortie des utilisateurs ordinaires ; échec ordinaire ne prouve pas échec universel. Reverts peuvent venir de solde, allocation, route, échéance, état ou politique. Perte économique de sortie diffère aussi des frais nominaux. Conservez explications alternatives et dépendances non résolues.

L’exemple utilise lignes papier, pas simulations ou transactions réelles. Radar est nommé mais ne produit aucune sortie réelle. Rapportez modifications techniques dans leur périmètre stipulé et refusez attribution humaine/d’intention sans preuve indépendante.

Capacité : comportement privilégié accessible.

Invocation : usage enregistré de ce comportement.

Restriction sélective : résultats différents sous conditions d’expéditeur/route indiquées.

Périmètre de test : état et paramètres exacts d’une observation d’exécution.

ILLUSTRATIVE au bloc B : création stipulée du rôle M ajoute 200 à offre 1000, donnant 1200. À B+1, W ordinaire échoue transfert de 10 unités sur R pour POLICY ; P privilégié réussit même montant/route. Soldes et allocations stipulés suffisants. Implémentation et couverture plus large absentes.

Matrice de permissions avec création M et transferts W/P, paramètres papier exacts et résultats. Ajouter lacunes de routes/montants non testés, pas badge universel de honeypot.

Caption: Modification privilégiée et résultats sélectifs fictifs ; aucune conclusion universelle de sortie ou d’intention.

SPECIFICATION_ONLY — le visuel rendu n’a pas été produit ni examiné indépendamment.

Dans la fiction, offre augmente de 20% et deux scénarios d’expéditeur ont résultats de politique différents. Observations papier limitées.

Aucune création réelle, déploiement, échec universel, intention nuisible, identité de contrôleur ou résultat Radar indépendant établi. Une route et un montant ne couvrent pas toutes les sorties.

Appeler présence de code invocation observée ; supposer succès privilégié prouve sortie publique ; généraliser une route ; traiter restriction comme fraude automatique.

Calculez variation d’offre, rédigez tableau de scénarios et classez « tous peuvent sortir », « personne ne peut transférer » et « politique diffère selon expéditeur ». Nommez deux tests manquants.

• Séparer capacité, invocation et effet.
• Rapprocher offre en unités brutes compatibles.
• Limiter expéditeur/montant/route/état.
• Conserver explications alternatives et intention inconnue.

Effets privilégiés observés et différences limitées d’exécution exigent enregistrements précis sans devenir assertions universelles ou criminelles.

• Une fonction accessible ne prouve pas qu’elle a été utilisée.
• Le succès d’un compte privilégié ne prouve pas qu’un utilisateur ordinaire peut sortir.
• Un seul scénario testé ne règle pas toutes les voies d’exécution.

P13-L05

Utilisez l’outil BlockAssay nommé uniquement comme contexte de lecture des preuves. Cette leçon ne crée aucune sortie d’outil, session de compte ni droit d’accès. Exercice hors ligne ; ne signez, ne déployez, n’approuvez et ne financez rien.

• ERC20: Norme ERC-20 — Interface du token et sémantique des autorisations ; la norme n’établit ni l’identité de l’émetteur ni la sécurité des permissions. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.
• PROXY: Emplacements de stockage du proxy ERC-1967 — Emplacements normalisés d’implémentation/admin ; renoncer à un rôle ne prouve pas que toutes les voies de mise à niveau sont désactivées. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.

ILLUSTRATIVE — entrées hors ligne entièrement fictives ; aucune observation actuelle.

null — aucune observation réelle

1

null

needs_review