Plan de renforcement anti-piratage du limiteur

[Mario Da Conceicao]

Document de planification du 01/08/2026 — renforcement anti-piratage du "limiteur", pour la future commercialisation. Complète limiteur.py avec les protections concrètes à ajouter une fois un système fonctionnel en place.

Principe honnête de départ

Aucune protection logicielle n’est inviolable à 100% — vrai pour tous les éditeurs commerciaux, sans exception. L’objectif réaliste : rendre le contournement suffisamment long et coûteux pour décourager l’écrasante majorité des tentatives, pas atteindre l’impossible.

Protections concrètes à construire

1. Vérification côté serveur, jamais seulement locale
Le point faible de limiteur.py actuel : la vérification (statut_abonnement()) se fait entièrement sur la clé elle-même. Un fichier local, même bien caché, peut toujours être trouvé et modifié par quelqu’un de déterminé. La vraie protection : la clé interroge le futur site à chaque vérification, et le site fait autorité, pas le fichier local — celui-ci n’est qu’un cache temporaire entre deux vérifications.

2. Chiffrement du code sensible
Le cœur de MIRA (moteur_ia.py, les spécialités, MIRA_LANG) ne doit pas être lisible en clair sur la clé. Chiffré, et déchiffré uniquement en mémoire au moment de l’exécution, après vérification réussie du limiteur.

3. Liaison au matériel (fingerprint)
La licence client se lie à des caractéristiques uniques de la machine ou de la clé USB elle-même (numéro de série, identifiants matériels) — copier les fichiers ne suffit plus, la licence refuse de fonctionner sur un autre support.

4. Vérification d’intégrité
Au démarrage, MIRA vérifie que ses propres fichiers n’ont pas été modifiés (empreintes/hash comparées à des valeurs attendues) — détecte une tentative de modification du code de protection lui-même.

5. Obfuscation du code
Rendre le code difficile à lire/comprendre même si quelqu’un y accède (noms de variables sans signification, structure brouillée) — ne bloque pas un expert déterminé, mais élimine la quasi-totalité des tentatives amateurs.

6. Aucun point de contournement unique
Répartir les vérifications à plusieurs endroits du programme plutôt qu’un seul if licence_valide: — un attaquant qui contourne UN verrou doit alors en trouver d’autres, cachés ailleurs.

Ce qui reste à faire, dans l’ordre logique

1. D’abord : avoir OS-MIRE et le moteur qui tournent réellement (priorité actuelle)
2. Construire le futur site de vérification (mentionné dans limiteur.py)
3. Ajouter le chiffrement + la liaison matérielle une fois le système stable
4. Ne jamais négliger l’obfuscation/intégrité — mais ce sont les dernières couches, pas les premières

Pour la réparation en cas de souci (mentionné : "avoir une IA avancée pour réparer si besoin")

Une fois MIRA installée et fonctionnelle, elle pourra effectivement s’appuyer sur ses propres capacités (spécialité "programmeur", auto-diagnostic) pour détecter et signaler une anomalie sur une clé cliente — mais la décision de réparer, mettre à jour, ou révoquer un accès reste toujours entre tes mains (mode créateur), jamais automatique.

[Auteur]

Messages