Obfuscation et protection du code à l'ère des agents

Le 11 octobre 2026, l'ingénieur Ishank Choudhary a fait analyser par REA des applications Electron dont il connaissait le source, y compris un bundle minifié. Dans ce bundle, l'outil a restitué le libellé d'un canal dynamique sous sa forme réelle, "job:"+e, avec la variable renommée par le minifieur, plutôt qu'une chaîne inventée¹. Le renommage des variables, qui coûtait des heures à un analyste humain, n'a pas empêché l'analyse statique de suivre l'expression. Voici ce que l'obfuscation protège encore, et où placer la défense.

Ce que l'obfuscation fait vraiment

Renommer les identifiants, aplatir le flux de contrôle, chiffrer les chaînes, minifier et regrouper le JavaScript, compiler en natif : chacune de ces techniques augmente le temps nécessaire pour comprendre un programme. Aucune ne le rend illisible, puisque la machine doit toujours exécuter le code. L'obfuscation a toujours été un pari économique : rendre l'analyse plus chère que ce qu'elle rapporte.

Ce que les agents changent

Les agents cassent ce calcul. REA orchestre des outils spécialisés et donne leurs résultats à un modèle qui lit sans se lasser (REA expliqué en trois schémas). Pour le JavaScript, sa commande de récupération de sources dérive des modules lisibles à partir de bundles, en s'appuyant sur l'outil Wakaru, sans jamais exécuter le code². Pour une application Electron, il lit aussi les source maps embarquées et l'état des fusibles du binaire (débogage --inspect autorisé ou non, validation d'intégrité de l'ASAR) sans lancer l'application³. Pour le code natif, il pilote Ghidra, Hopper ou IDA et rend du pseudocode, des chaînes, des symboles et des références.

Le test d'Ishank Choudhary donne la mesure. Sur une application de 100 Mo, REA a parcouru 3 114 427 nœuds de syntaxe en 52,2 secondes, et ses comptages de fenêtres, de ponts contextBridge et de gestionnaires IPC correspondaient à ceux obtenus par recherche textuelle dans le source¹. Le même test montre les limites : deux scripts preload chargés par un appel indirect lui ont échappé. La structure de l'application, elle, est apparue en moins d'une minute. Nos constats détaillés sur ce type de cible sont dans ce qu'une analyse REA révèle d'une application Electron.

Ce que l'obfuscation protège encore

Elle fait encore gagner du temps contre un attaquant peu outillé, et elle reste utile en combinaison avec d'autres mesures : attestation de l'intégrité du client côté serveur, rotation des secrets, détection d'altération, fusibles Electron qui empêchent l'exécution de code modifié. L'analyse dynamique et le code chargé à l'exécution posent aussi des difficultés réelles aux outils statiques, et REA signale ce qu'il ne parvient pas à résoudre. Ces inconnues indiquent où un attaquant devra fournir plus d'effort ; elles ne garantissent rien. Seule, l'obfuscation ne protège ni la logique métier embarquée dans le client, ni les clés et jetons qui s'y trouvent.

Où placer la défense

Traitez tout ce que vous livrez sur le poste ou le téléphone du client comme public. Un secret durable n'a rien à faire dans un binaire : les clés d'API se remplacent par des jetons courts, obtenus à l'exécution et révocables. La logique qui crée de la valeur ou qui décide d'un droit (tarification, contrôle d'éligibilité, validation d'une transaction) s'exécute côté serveur, où le client ne peut ni la lire ni la contourner. La validation côté client sert le confort de l'utilisateur ; la validation côté serveur fait foi.

Testez ensuite votre propre produit comme le ferait un tiers : faites analyser vos livrables par un agent, en environnement confiné, et regardez ce qui en sort. La lecture d'une telle sortie demande de la méthode (voir lire une sortie REA).

La protection juridique complète l'architecture sans la remplacer. Le droit d'auteur protège le code copié, mais la Cour de justice de l'Union a jugé en 2012 (affaire C-406/10, SAS Institute) que la fonctionnalité d'un programme n'est pas protégée en tant que telle⁴. En France, une clause de licence ne peut pas interdire l'observation du fonctionnement lors d'une utilisation autorisée (voir ce qui est nul en France). Le panorama est dans clean-room ou reverse engineering.

Pas de guide de contournement

Cette page reste défensive. Elle n'explique pas comment lever une protection, un DRM ou un contrôle de licence. Le DISCLAIMER de REA exclut d'ailleurs l'aide au contournement de « DRM, license checks, anti-cheat systems or other technical protection measures »⁵.

Questions fréquentes

L'obfuscation est-elle devenue inutile ?

Non, mais elle ne suffit plus seule. Elle retarde un attaquant peu outillé et complète d'autres mesures.

La minification protège-t-elle mon code JavaScript ?

Peu. Les tests publics montrent qu'un agent suit les expressions réelles dans un bundle minifié, et des outils de désobfuscation reconstruisent des modules lisibles.

Où mettre la défense ?

Côté serveur pour la logique et les secrets, dans le contrat et le droit pour le code lui-même, et dans des tests réguliers de ce que votre application expose.

Faut-il arrêter de compiler en natif pour cette raison ?

Non. La compilation native se choisit pour d'autres motifs. Elle ne doit simplement plus compter comme une protection de la logique.

L'offre AI Cyber de SFEIR analyse vos applications en boîte blanche et identifie ce qu'elles exposent : secrets embarqués, logique sensible côté client, failles exploitables.

Sources

1. Ishank Choudhary, I Pointed REA at a 100 MB Electron App. Here's What It Found and the Two Preload Files It Missed., publié sur Medium puis sur DEV — dev.to, 12 octobre 2026 ; repris sur hackernoon.com sous le titre I Tested REA, GitHub's Viral Reverse Engineering Tool, on a Real Electron App, 14 octobre 2026.
2. morluto/rea, docs/javascript-recovery.md — github.com, consulté le 16 octobre 2026.
3. morluto/rea, README (tableau des cibles) et docs/electron-fuses.md — github.com, consulté le 16 octobre 2026.
4. CJUE, 2 mai 2012, SAS Institute Inc. c. World Programming Ltd, C-406/10 — curia.europa.eu.
5. morluto/rea, DISCLAIMER.md — github.com, consulté le 16 octobre 2026.