Rubber Ducky – ATTACKMODE & Variables

Rubber Ducky – ATTACKMODE & Variables

Pour cette seconde vidéo dédiée à la nouvelle Rubber Ducky, je vais vous montrer de nouvelle fonctions comme ATTACKMODE, le Spoof VID/PID, les Constantes & Variables, etc…

On passe un niveau sur cette vidéo mais ce n’est que le début !!!

Attachez vous bien, ça commence à devenir costaud !!!

ATTACKMODE

ATTACKMODE définit la façon dont la Rubber Ducky s’énumère auprès du système cible, c’est-à-dire le ou les types de périphériques USB qu’elle prétend être. Les modes courants sont :

• HID : périphérique d’interface humaine (clavier) pour l’injection de frappes

• STORAGE : périphérique de stockage de masse (clé USB) exposant la carte microSD

• OFF : l’appareil ne s’énumère pas, il devient « invisible » pour l’hôte
  

On peut activer plusieurs modes simultanément (périphérique composite), par exemple HID + STORAGE pour combiner frappe clavier et accès au stockage. Changer d’ATTACKMODE entraîne une ré-énumération côté système, ce qui est utile pour passer d’un rôle à l’autre au cours d’un même scénario (exemple : clavier → clé → clavier+clé → off).

À noter : en l’absence de directive, la Rubber Ducky se comporte par défaut comme un clavier HID.

VID/PID & identité USB
Chaque périphérique USB annonce un Vendor ID (VID) et un Product ID (PID), valeurs hexadécimales 16 bits utilisées par l’OS pour associer des pilotes et, parfois, appliquer des politiques de confiance/whitelisting. En configurant la Rubber Ducky, on peut choisir quel couple VID/PID elle présentera, ainsi que des champs d’identification textuels : Manufacturer (MAN), Product (PROD) et Serial (SERIAL).
Intérêts principaux :

• Compatibilité et UX : certaines plateformes (notamment macOS) réagissent différemment selon l’identité annoncée (par exemple, éviter un assistant de configuration clavier)

• Tests de sécurité : évaluer des environnements où seuls certains VID/PID sont autorisés (politiques d’entreprise, MDM, allow-lists)
  Bonnes pratiques : utiliser des valeurs cohérentes avec un scénario de test documenté, rester dans un cadre légal/éthique et noter que changer d’identité provoque une ré-énumération (donc un comportement visible côté OS), avec parfois un nouveau montage de volume ou une nouvelle instance de pilote

SAVE_ATTACKMODE + bouton : « Panic/Stealth Switch« 

La Rubber Ducky dispose d’une commande pour mémoriser l’état d’ATTACKMODE courant (y compris VID/PID et identifiants), puis d’une autre pour le restaurer. Combinée au bouton physique, cela sert de commutateur furtif :

• Sauvegarder un état (exemple HID + STORAGE avec une identité précise)
• Passer instantanément en OFF via le bouton (disparition de toute énumération, arrêt de la frappe et du stockage visibles)
• Restaurer l’état sauvegardé à la pression suivante (retour du clavier/stockage et de l’identité USB).
  

Ce « panic/stealth switch » est précieux pour mettre en pause une démonstration ou interrompre un test en laboratoire, puis reprendre sans recompiler. Certaines configurations permettent aussi de générer un numéro de série aléatoire à la restauration, utile pour tester des politiques liées à l’iSerial (à manier avec prudence, car chaque restauration peut apparaître comme un nouveau périphérique pour l’OS)

Constantes (DEFINE) & Variables (VAR)
DuckyScript 3 distingue constantes et variables, deux leviers complémentaires pour écrire des payloads propres et maintenables :

• Constantes – DEFINE (pré-compilation) : ce sont des valeurs figées remplacées par le préprocesseur avant l’exécution. Elles servent de panneau de configuration en tête de script (délais, noms, options), évitent les « magical numbers » et permettent d’adapter un payload à un contexte (environnement, cible, durée) sans toucher au corps du code. Bonne pratique : préfixer le nom par un marqueur (souvent #) pour rendre leur usage visible partout dans le script et éviter les collisions de mots

• Variables – VAR (exécution) : ce sont des valeurs modifiables pendant l’exécution (entiers non signés et booléens). Elles permettent de compter, temporiser dynamiquement, ramifier (conditions), itérer (boucles), et plus généralement d’implémenter une logique runtime (progressions, backoff, états)

Ensemble, DEFINE et VAR donnent des payloads paramétrables (par l’opérateur ou l’équipe Blue/Red) et réutilisables, avec une séparation nette entre configuration (compile-time) et comportement (run-time).

Scripts à télécharger : ICI