Rapport technique — Décryptage du message codé (◆=1, ○=0)

20 Sep, 2025

Résumé

Tu m'as fourni une longue chaîne composée de symboles ◆ (un) et ○ (zéro). L'objectif : convertir ◆=1 et ○=0 en binaire, regrouper en octets puis tenter de convertir en texte UTF‑8. Comme le texte brut ne s'est pas affiché lisiblement, j'ai mené une série d'analyses et d'attaques heuristiques pour déterminer si le flux binaire cache un message lisible (notamment la phrase suggérée « bon courage pour trouver ce que ça veut dire »).

Ce document décrit, étape par étape, tout ce que j'ai fait, les scripts/algorithmes utilisés, les sorties importantes et les conclusions. Tu peux copier/partager ce rapport tel quel sur ton blog

1. Données d'origine

Chaîne fournie (abrégée pour lisibilité) :

◆◆◆◆○◆○○◆◆○○○○◆◆◆◆○◆◆○○○◆◆○◆◆○○○○◆○○◆○○◆◆◆◆... (longue suite)

Interprétation initiale : remplacer ◆ par 1 et ○ par 0 pour obtenir un flux binaire.

Longueurs

Nombre de bits (après remplacement) : 857 bits

Nombre d'octets complets (8 bits) : 107 octets (857 // 8 = 107) — il reste 857 % 8 = 1 bit non utilisé (padding implicite)

Remarque : la présence d'un bit restant suggère soit un padding/manque d'octet final soit une formulation volontaire du flux (ex. trame non alignée sur octet)

2. Tests simples et décodages directs

Objectif : vérifier si le binaire correspond directement à un texte encodé standard

1. Conversion directe en octets puis décodage UTF‑8

Méthode : groupement en octets (8 bits en partant du début), puis bytes(...).decode('utf-8', errors='replace')

Résultat : sortie majoritairement non imprimable / caractères de remplacement (garbage)

2. Décodage ISO‑8859‑1 (latin‑1)

Résultat : encore du texte non lisible, quelques caractères accentués isolés mais rien de cohérent

3. Décodage UTF‑16 (BE et LE)

Résultat : non lisible

4. Agrégation en 7‑bits (ASCII 7‑bit packing)

Méthode : regrouper en séquences de 7 bits (à partir du début)

Résultat : non lisible

5. Inversion des bits dans chaque octet (LSB-first)

Méthode : pour chaque octet b7 b6 ... b0, inverser l'ordre en b0 ... b7 puis convertir

Résultat : non lisible

6. Renversement complet du flux (bits inversés)

Résultat : non lisible

7. Tentative Base64

Méthode : décoder l'interprétation ASCII des octets comme s'il s'agissait d'une chaîne base64

Résultat : échec (pas un Base64 valide)

8. Tentative gzip / zlib / gzip décompress

Résultat : échec (pas d'en‑tête gzip/zlib cohérent)

Conclusion intermédiaire : le flux n'est pas un texte brut UTF‑8/latin‑1/UTF‑16 standard, ni un base64 ni un flux gzip/zlib classique.

3. Attaques par XOR / crypto-similaires (tests rapides)

Raisonnement : un flux binaire illisible peut provenir d'un texte clair chiffré par un XOR (clé simple ou clé répétée — méthode classique sur CTFs et challenges). J'ai testé :

3.1 XOR à clé unique (clé 1 octet)

Test : essayer toutes les 256 clés ^ byte et inspecter résultats

Recherche automatique de mots français courants

Résultat : aucun hit convaincant

3.2 XOR répétitif (clé répétée de longueur 1..40)

Méthode : pour chaque taille de clé k, on optimise chaque octet de clé séparément en choisissant la valeur qui maximise un score heuristique (distribution lettres/français). Cela revient à la méthode classique de récupération de clé XOR répétée via fréquence

Résultat initial (tests rapides) : quelques clés candidates « statistiques », mais le texte obtenu est majoritairement illisible

3.3 Tests mots‑clés / clés texte

J'ai essayé comme clé répétée des mots courants (UTF‑8) : ['bonjour','courage','trouver','cle','secret','salut','pour','merci','maman','su','sucre','chocolat','mot']

Résultat : aucun d'eux ne révèle un texte lisible

Observations : l'analyse par fréquence a renvoyé des clés plausibles (selon la métrique), mais aucune n'a donné un texte humainement lisible — donc probablement un faux positif statistique.

4. Phase heuristique avancée : hillclimbing / simulated annealing (attaque agressive)

But : si la clé XOR répétée n'est pas trivialement trouvable par simple fréquence, un algorithme de recherche locale (hillclimb) peut optimiser une clé candidate pour maximiser une fonction score plus riche (proportion de caractères imprimables, accord aux fréquences françaises, présence de mots clés)

Paramètres et implémentation

Espaces de recherche testés : tailles de clé 1 .. 25 (phase initiale), avec possibilité d'étendre ensuite

Pour chaque taille de clé :

Restarts : 60 (initialisations aléatoires par taille)

Itérations/hillclimb par restart : 300

Mutation : modification d'un octet de clé (petit delta ou remplacement complet aléatoire)

Fonction de score : combinaison de

proportion de caractères imprimables (bonus),

score de fréquence basé sur fréquences françaises,

bonus si présence de mots/fragment français (' bon ', 'bonjour', ' pour ', ' trouve', 'courage', 'salut', 'merci', 'maman')

Décodage utilisé pour scoring : latin-1 (pour éviter erreurs d'encodage et garder bijection 0..255)

Résultats de la recherche hillclimb

Temps total (exécution courte / paramétrage donné) : quelques dizaines de secondes dans mon environnement d'exécution contrôlé

Top candidats (extraits) — meilleure solution par score heuristique :

1. keysize = 25 — clé hex : c6bf44fe4b8827d99e800bc9a6260c9c51f80b329a507b5074 — score ≈ 12.78

extrait du texte déchiffré (latin‑1) : 2|\x9c&\x02t\x8cS§/rRc0... (principalement gibberish)

2. keysize = 21 — clé hex : b12abdab267bce2b40dd51ae4b98e915a8aa1affd1 — score ≈ 12.33

extrait : Eéeso\x87e¡yr(5... (incohérent)

3. keysize = 23 — clé hex : 5043e09d35f08eb25c8a95be579abdb155aa78c79a45fb — score ≈ 12.26

Verdict : ces clés maximisent la fonction score spécifiée mais n'amènent pas un texte lisible.

Tests complémentaires automatisés effectués

élargissement de la recherche keysize 1..40 (méthode fréquence puis tri) — clés candidate trouvées, mais mêmes conclusions

tests XOR avec clés « mot texte » — aucun mot courant n’a donné une sortie lisible

5. Résumé des sorties pertinentes (extraits)

Note : j'ai volontairement gardé les extraits courts (car le texte n'est pas lisible). Les clés sont données en hex pour que tu puisses les réutiliser si tu veux.

Meilleurs candidats trouvés (hillclimb)

keysize=25, key_hex=c6bf44fe4b8827d99e800bc9a6260c9c51f80b329a507b5074, score≈12.78 keysize=21, key_hex=b12abdab267bce2b40dd51ae4b98e915a8aa1affd1, score≈12.33 keysize=23, key_hex=5043e09d35f08eb25c8a95be579abdb155aa78c79a45fb, score≈12.26 ... (autres candidats de score proche)

Tentatives rapides qui ont échoué

décodage direct UTF‑8 / latin‑1 / UTF‑16

7‑bit packing

inversion de bits par octet (LSB-first)

renversement complet du flux

Base64 (ASCII candidate)

gzip / zlib

XOR simple (1‑byte key) exhaustive

XOR répétitif keysize 1..40 par fréquence

6. Interprétation et hypothèses plausibles

1. Chiffrement non trivial : le flux pourrait être chiffré avec un algorithme à blocs (AES, etc.) ou un stream cipher basé sur une clé longue/aléatoire — dans ce cas la récupération sans clé est pratiquement impossible

2. Encodage / tramage non standard : le message peut utiliser un regroupement de bits non octet-aligned (ex. 5, 6 bits) ou contenir un en‑tête/trame qui change l'alignement

3. Corruption / padding : la présence d'un bit résiduel pointe vers un frame/structure non alignée — si on décale de 1 bit puis on re-génère octets, on perd un bit à la fin (nous avons testé décalages 0..7 sans succès apparent)

4. Double encapsulation : exemple : (texte -> compressé -> chiffré -> converti en bits) — si l'une des couches est propriétaire/non standard, l'heuristique échoue

5. Faux positif de la conjecture XOR : les clés trouvées par scoring sont des artefacts statistiques et non de vraies clés

7. Recommandations techniques / prochaine étape pour creuser (si tu veux continuer)

1. Indices : tout indice (mot de passe probable, longueur de clé, mot utilisé, format attendu, phrase connue partielle) multiplie les chances. Si l'auteur a donné un indice, donne-le

2. Augmenter la recherche hillclimb :

augmenter restarts (ex. 500+), itérations (1000+), et keysize max (ex. jusqu'à 64)

méthode coûteuse mais parfois fructueuse sur XOR répétitif

3. Tester encodages en 5/6 bits : tester regroupement en n‑bits (n=5..9) et conversion vers ASCII/base32-like

4. Tester décodage bit‑shift/offsets plus exhaustifs : nous avons essayé shift 0..7 mais on peut aussi tester toutes les permutations d'endianness bitwise (rare)

5. Analyser entropie : mesurer entropie du flux binaire ; si élevée → probable chiffrement solide / compression. Si faible → peut-être simple substitution

6. Contacte l’auteur : demander un indice (p. ex. "clé XOR = mot français" ou "regroupement bits = 7" etc.)

8. Pièces jointes utiles (scripts / commandes utilisées)

Extrait de script (Python) — conversion simple et test UTF‑8

conversion symbole->bits

coded = original_string.replace('◆','1').replace('○','0')

convertir en bytes (8 bits) en perdant le(s) bit(s) restants

b = bytes(int(coded[i:i+8],2) for i in range(0, len(coded)//8*8, 8)) print(b.decode('utf-8', errors='replace'))

Extrait — LSB per byte

bytes_list = [coded[i:i+8] for i in range(0, len(coded)//8*8, 8)] lsb_bytes = bytes(int(bs[::-1],2) for bs in bytes_list) print(lsb_bytes.decode('utf-8', errors='replace'))

Extrait — Hillclimb simplifié (esquisse)

scoring: printable ratio + frequence FR + bonus mots

def score_text(s): printable_ratio = sum(32 <= ord(ch) <= 126 for ch in s) / max(1,len(s)) freq_score = ... # compare distribution lettres vs fr_freq bonus = sum([b for (w,b) in word_bonuses if w in s.lower()]) return printable_ratio*10 + freq_score + bonus

hillclimb loop

for restart in range(N_restarts): key = bytearray(random.getrandbits(8) for _ in range(keysize)) for iter in range(N_iters): pos = random.randrange(keysize) old = key[pos] key[pos] = mutate(old) cand = xor_with_key(data, key) if score_text(cand.decode('latin-1')) > best: accept else: revert

9. Données / sorties à disposition

Si tu veux, je peux te fournir :

le dump complet des meilleurs candidats (texte complet décodé pour chaque clé candidate) en fichier .txt

les scripts Python exacts que j’ai exécutés (prêts à exécuter localement)

mesures d'entropie du flux binaire, histogramme des bits et des octets (CSV / PNG)

Dis-moi ce que tu veux que j’exporte et je te prépare les fichiers téléchargeables

10. Conclusion

À l'heure actuelle, aucune méthode testée n'a permis d'extraire un message UTF‑8 lisible ni la phrase que tu suspectais. J'ai couvert : décodages standards, transformations bitwise usuelles, tests XOR (exhaustif et heuristique), tests de compression standard et une phase agressive de hillclimbing. Les chemins restants demandent soit plus de puissance de calcul (recherche plus longue), soit des indices sur la méthode d'encodage/chiffrement utilisée.