Ce projet, baptisé GET_DROPPED, est une réponse technique ambitieuse au Deck Dropout Challenge. Il combine une automatisation backend orientée requêtes HTTP (rapide, reproductible, observable) avec une interface immersive WebXR / Meta Quest 3 conçue pour une démo spectaculaire et lisible.
🎯 Objectif du Projet
Construire un agent capable de parcourir un portail universitaire fictif et d’exécuter un « dropout » (désinscription) jusqu’à l’état final attendu par le challenge, malgré des parcours instables (tokens de formulaire, modales, validations, latence réseau, etc.).
🧠 Architecture (Vue d’ensemble)
Le système se découpe en 3 couches :
1) Le moteur d’automatisation : DariusUltimateBot (main.py)
2) Le pont HTTP : API FastAPI (api.py)
3) L’expérience immersive : interface WebXR A-Frame (index.html)
1) Le « Cerveau » — DariusUltimateBot (main.py)
1.1. Philosophie : Request-based Automation
Plutôt que d’automatiser un navigateur complet, le bot pilote le parcours via des appels HTTP sur des endpoints backend. Cette approche apporte :
- Vitesse : pas de rendu DOM, pas de WebDriver.
- Contrôle : chaque étape est explicitement instrumentée (payload, réponse, codes HTTP).
- Résilience : gestion fine des erreurs, retries, timeouts et chemins alternatifs.
1.2. Orchestration algorithmique : pipeline en étapes (state machine)
Le cœur du bot est une séquence d’états (pipeline) :
- Authentification : récupération d’un jeton de préparation de formulaire, envoi des identifiants, puis validation MFA.
- Nettoyage : récupération de l’état utilisateur, suppression des éléments actifs (ex. cours encore inscrits) de manière itérative.
- Régularisation financière : lecture du solde et, si nécessaire, initialisation d’un moyen de paiement puis paiement.
- Dropout final : exécution de la requête de désinscription avec vérification du résultat.
Cette structure se comporte comme une machine à états : chaque phase a une entrée (préconditions), un traitement, puis une sortie (postconditions) avant de passer à l’étape suivante.
1.3. Gestion de session & anti-fragilité réseau
Le bot centralise la communication via une session requests.Session() :
- Cookies gérés automatiquement (continuité d’authentification).
- Headers cohérents (User-Agent, Content-Type, etc.).
- Un wrapper
_request()qui fournit une observabilité maximale :- affichage structuré des endpoints appelés,
- affichage des payloads (avec la possibilité de masquer / redacter les secrets),
- lecture des réponses (JSON ou brut),
- logs horodatés et colorés pour débogage rapide.
1.4. Tokens de formulaires et données « comportementales »
Plusieurs actions nécessitent un token de préparation (ex. form_prep_token). Le bot appelle donc un endpoint dédié avant certaines étapes.
Le bot joint aussi des champs de télémétrie (ex. mouvements souris, temps sur la page, métriques d’input). Dans un contexte hackathon, l’objectif est de simuler un parcours réaliste et d’améliorer la robustesse face à des validations serveur.
1.5. Module de “challenge handling” (approche multi-stratégies)
Le système inclut un module de gestion de challenges (captchas / vérifications) conçu comme un sélecteur de stratégie selon le type de challenge renvoyé par le serveur.
Note : le projet met l’accent sur l’architecture et la résilience. Les détails opérationnels de contournement de protections ne sont pas documentés ici.
Le principe général :
- Récupération d’un lot d’images et métadonnées associées.
- Analyse via une ou plusieurs stratégies :
- Vision locale (OpenCV) : extraction de descripteurs, comparaison avec une petite bibliothèque d’empreintes visuelles.
- Vision IA (optionnelle) : interrogation d’un modèle de vision pour classer une image selon une question simple.
- Soumission de la sélection au backend afin de poursuivre le flux.
1.6. Persistance, retries & boucle contrôlée
Pour les actions sensibles (ex. dropout final), le bot est conçu pour retenter en cas de réponse temporaire, avec pauses contrôlées.
Dans une version “production”, on ajoute :
- un budget temps (timeout global),
- un nombre max de tentatives,
- des codes de sortie clairs (
ok,timed_out,blocked, etc.), - une vérification finale de l’état utilisateur (preuve de succès).
2) Le Pont — API FastAPI (api.py)
L’API expose un endpoint minimal pour déclencher l’exécution du bot :
GET /: sanity check (service en ligne)POST /drop: lance le protocole à partir d’identifiants fournis
Points clés :
- Chronométrage précis (
perf_counter) pour répondre aux critères “vitesse” du challenge. - Encapsulation : l’UI (VR) n’a pas besoin de connaître le détail du pipeline ; elle déclenche simplement un job.
- Évolutions possibles : exécution en tâche de fond, suivi d’avancement, stockage des résultats, etc.
3) L’Interface — Expérience VR WebXR (index.html)
Pour la démo, nous avons construit une expérience A-Frame 1.6.0 ciblant le Meta Quest 3, pensée comme un OS de hacking.
3.1. Phases de l’expérience
1) Login 2D (overlay HTML)
- Formulaire classique au-dessus de la scène.
- Permet une saisie stable sur PC et compatible WebXR.
2) Transition en monde 3D
- Activation progressive de l’environnement.
- Activation des contrôles de déplacement.
- Déclenchement audio et effets (impact / boom).
3) Feedback “backend” en temps réel
- Affichage de faux logs type terminal sur les murs.
- Mur “écran” utilisant une texture vidéo (hack.mp4) pour simuler une injection / scan.
4) Fin de séquence
- À la réponse API, sortie VR et affichage d’un overlay de succès (“You’ve been dropped”).
3.2. Composants A-Frame principaux
login-manager:- gère l’overlay HTML,
- déclenche la transition VR,
- lance l’appel
fetch()vers l’API backend, - orchestre la fin de scène et l’overlay final.
emergency-system:- bouton rouge cliquable,
- effets cinématiques (flash, tremblement caméra),
- particules / étincelles,
- déclenchement de logs animés.
atmospheric-light:- scintillement d’un néon pour donner une ambiance “backrooms / bunker”.
sparkle-burst:- “burst” de particules (sphères) animées pour renforcer l’impact visuel.
3.3. Intégration backend
Le front appelle l’API en POST JSON :
fetch('https://get_dropped.nayl.ca/drop', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ username, password })
})
Le rendu VR est conçu pour rester fluide même si le backend prend quelques secondes : on “occupe” l’utilisateur via animations, murs vidéo, sons et logs.
🌍 Disponibilité & Plateformes
GET_DROPPED est une application web (front A-Frame/WebXR + backend HTTP), donc accessible sur n’importe quelle plateforme disposant d’un navigateur moderne.
- ✅ VR Headset (recommandé pour la démo) : Meta Quest 3 / Quest Browser (WebXR natif)
- ✅ Ordinateur (recommandé pour dev & présentation) : Chrome / Edge / Firefox (mode desktop)
- ✅ Mobile / Tablette (supporté) : expérience 2D (selon compatibilité WebXR / navigateur)
En pratique, la démo a été pensée pour être spectaculaire et parfaitement lisible principalement sur VR Headset et ordinateur, tout en restant accessible partout.
🎥 Vidéo — Test du Mode VR (Quest 3)
Une courte vidéo de test est disponible ici :
https://youtube.com/shorts/fistmr4HAhE?feature=share
Cette vidéo illustre le fonctionnement réel du mode VR sur Meta Quest 3 :
- entrée dans l’expérience WebXR,
- lancement de la séquence “OS de hacking”,
- déclenchement du flow backend via l’API (
POST /drop), - feedback visuel immersif (ambiance, animations, overlay de fin).
Objectif : prouver que l’expérience est stable, démontrable et “wow effect”, même lorsque le backend prend quelques secondes (latence, validations, étapes serveur).
🚀 Lancement rapide
Backend
pip install -r requirements.txt
uvicorn api:app --host 0.0.0.0 --port 8000
Front (VR)
- Servir
index.htmlvia un serveur statique (ex:python -m http.server). - Ouvrir dans le navigateur du Quest (ou sur PC) et lancer la séquence.
🧩 Crédit
GET_DROPPED — ConUHacks 2026 — Deck Dropout Challenge
Built With
- html5
- javascript
- moondream
- opencv
- python
- webxr
Log in or sign up for Devpost to join the conversation.