js-reverse

MCP Frontend JS Reverse Engineering – Guide de travail

ACTION REQUISE (à exécuter immédiatement après lecture)

1. MAINTENANT : Lire ../field-journal/precedent-reverse.md — vérifier que l'opération est une opération courante autorisée
2. MAINTENANT : Confirmer que la tâche actuelle entre dans le périmètre d'application de ce skill
3. SUIVANT : Lire ../tool-index.md pour valider la disponibilité des outils et leurs chemins réels
4. SUIVANT : En cas de manque d'outil, appeler le bootstrap, ne pas deviner les chemins
5. AGIR : Entrer dans la première étape du « workflow » et exécuter, ne pas rester en état de confirmation

Périmètre d'application

Ce skill est prioritaire lorsque la tâche correspond à l'un des scénarios suivants :

• Localisation de signature d'API, paramètre chiffré, champ de risque
• Observation de la chaîne de requêtes et des sources de scripts
• Capture des paramètres d'entrée et valeurs de retour en cours d'exécution
• Traçage du point de déclenchement d'un XHR/Fetch/WebSocket
• Ramener les preuves de la page vers Node pour reproduction locale et complément d'environnement

Si la cible est un binaire, APK, PE, ELF, DLL ou SO, utilisez plutôt ida-reverse, radare2 ou reverse-engineering.

Mappage des outils par défaut de l'environnement

Ce skill ne suppose pas l'existence de noms de commandes nus, mais se lie par défaut aux outils js-reverse_* disponibles dans l'environnement client actuel.

Si la tâche mentionne explicitement jshookmcp, JS hook, CDP, point d'arrêt navigateur, interception réseau, SourceMap ou désobfuscation AST, elle reste dans ce skill ; il suffit de basculer la couche MCP sous-jacente vers jshookmcp, sans en faire une nouvelle entrée globale.

Condition préalable : jshookmcp n'est pas un outil de commande local, mais un serveur MCP qui doit d'abord être téléchargé, enregistré explicitement et activé. Les outils associés ne sont réellement appelables qu'après avoir été intégrés et activés dans la configuration MCP du client choisi (Claude, Codex, etc.).

Mappage courant :

• list_scripts -> js-reverse_list_scripts
• get_script_source -> js-reverse_get_script_source
• search_in_sources -> js-reverse_search_in_sources
• break_on_xhr -> js-reverse_break_on_xhr
• evaluate_script -> js-reverse_evaluate_script
• get_paused_info -> js-reverse_get_paused_info
• set_breakpoint_on_text -> js-reverse_set_breakpoint_on_text
• list_network_requests -> js-reverse_list_network_requests
• get_request_initiator -> js-reverse_get_request_initiator
• get_websocket_messages -> js-reverse_get_websocket_messages
• take_screenshot -> js-reverse_take_screenshot
• new_page -> js-reverse_new_page
• navigate_page -> js-reverse_navigate_page
• select_page -> js-reverse_select_page
• select_frame -> js-reverse_select_frame
• pause/resume -> js-reverse_pause_or_resume

Si le préfixe des outils change à l'avenir, mettez d'abord à jour cette section, ne faites pas de suppositions temporaires lors de l'exécution.

Positionnement de jshookmcp

• Rôle : couche d'exécution renforcée de js-reverse, pas un contrôleur indépendant
• Adapté à : automatisation navigateur, débogage CDP, Hook JS, interception réseau, reconstruction SourceMap, assistance AST
• Condition d'appel : télécharger d'abord @jshookmcp/jshook et l'enregistrer dans la configuration du client MCP, puis s'assurer que le serveur est activé
• Entrée suggérée : suivre toujours le cycle Observer → Capturer → Reconstruire, mais dans les phases Observer/Capturer, privilégier les capacités navigateur et Hook de jshookmcp
• Relation avec anything-analyzer : les deux peuvent faire de la capture réseau ; anything-analyzer est plus orienté capture de paquets et analyse HTTP, tandis que jshookmcp est plus tourné vers le runtime JS, CDP, Hook et compréhension du code source

Principes fondamentaux

• Observer d'abord
• Hook de préférence
• Point d'arrêt en dernier recours
• Reconstruction orientée
• Preuve avant tout

Observer la page d'abord, puis échantillonner minimalement, puis compléter l'environnement localement. Ne sautez pas la phase de preuve pour deviner l'environnement.

Workflow en cinq phases

1. Observer

Objectif : d'abord confirmer la requête cible, les scripts associés, les fonctions candidates, sans deviner l'environnement.

Actions par défaut :

• Ouvrir la page cible avec js-reverse_new_page ou js-reverse_navigate_page
• Chercher la requête cible avec js-reverse_list_network_requests
• Remonter à la source de l'appel avec js-reverse_get_request_initiator
• Restreindre la portée des scripts avec js-reverse_list_scripts, js-reverse_search_in_sources

Livrables obligatoires :

• URL ou caractéristique de la requête cible
• Piste de l'initiateur (initiator)
• URL des scripts suspects
• Enregistrement initial de la tâche

2. Capturer

Objectif : échantillonnage minimal de la requête cible, obtenir des exemples de paramètres, l'ordre d'appel, des preuves d'exécution.

Règles :

• Priorité à js-reverse_break_on_xhr
• Priorité à js-reverse_evaluate_script pour une observation légère en cours d'exécution
• Une fois le hit, consulter d'abord js-reverse_get_paused_info
• Si nécessaire, utiliser ensuite js-reverse_set_breakpoint_on_text

3. Reconstruire

Objectif : organiser les preuves de la page en matériel de reproduction Node local itérable.

Règles :

• Le complément d'environnement local doit être basé sur les preuves d'observation de la page
• Il est interdit de compléter window/document/navigator/crypto/storage de manière spéculative
• Enregistrer une seule décision de correctif causal minimal à chaque fois

4. Corriger

Objectif : piloter le complément d'environnement en fonction des erreurs et de la première divergence, jusqu'à ce que le script local s'exécute de manière stable et produise les paramètres cibles.

Règles :

• D'abord identifier ce qui manque, puis le corriger
• Une seule décision de correctif minimal à la fois
• Tester immédiatement après chaque correctif
• Enregistrer chaque correctif dans le journal de tâche

5. Approfondir

Objectif : une fois le script local opérationnel, procéder à la désobfuscation, à la restitution du flux de contrôle et à l'extraction de la logique métier.

Règles :

• Si la tâche ne vise qu'à obtenir une signature, cette phase peut être allégée
• Si la chaîne algorithmique doit être réutilisée à long terme, cette phase est obligatoire
• Contournement de l'obfuscation Issue #65 (U–AV §4) : JSVMP (AD) → E-js-vmp ; CFF + tableaux de chaînes (AE) → E-js-deobf ; Anti-débogage DevTools/debugger (AF) → E-js-anti-debug. Tableau complet dans ../reverse-engineering/references/nonpe-format-cookbook.md ; détails AST dans references/ast-deobfuscation.md

Exigences d'exécution

• Toutes les étapes importantes doivent être enregistrées dans un artefact de tâche local
• Si vous ne pouvez pas expliquer pourquoi vous appelez un outil, ne l'appelez pas
• Utilisez d'abord les capacités MCP existantes de js-reverse_* ou jshookmcp pour collecter directement des preuves, n'écrivez pas de script pour réinventer la roue
• En cas d'échec, suivez references/fallbacks.md
• La sortie doit respecter references/output-contract.md

Références obligatoires

• Entrée d'automatisation : references/automation-entry.md
• Valeurs par défaut des outils : references/tool-defaults.md
• Modèle d'entrée de tâche : references/task-input-template.md
• Ordonnancement de tâche MCP : references/mcp-task-template.md
• Artefacts de tâche : references/task-artifacts.md
• Reproduction locale : references/local-rebuild.md
• Complément d'environnement : references/env-patching.md
• Reproduction Node : references/node-env-rebuild.md
• Instrumentation : references/instrumentation.md
• Désobfuscation AST : references/ast-deobfuscation.md
• Recette d'obfuscation non-PE/JS U–AV : ../reverse-engineering/references/nonpe-format-cookbook.md (AD/AE/AF)
• Secours : references/fallbacks.md
• Contrat de sortie : references/output-contract.md

---

Contexte de routage

Entrée amont : skills/SKILL.md (contrôleur), routing.md Alternatives amont :

• Outils navigateur de anything-analyzer MCP (port 23816) comme alternative ou complément
• jshookmcp comme couche d'exécution plus forte pour navigateur/CDP/Hook/Network/SourceMap/AST
• reverse-engineering/SKILL.md (si la cible n'est pas du JS frontend)

Sortie aval :

• Besoin de complément d'environnement → references/env-patching.md
• Besoin de reproduction locale → references/local-rebuild.md / references/node-env-rebuild.md
• Besoin de désobfuscation → references/ast-deobfuscation.md
• En cas d'impasse → references/fallbacks.md

Modules associés au même niveau : anything-analyzer MCP (automatisation navigateur et capacités de capture HTTP complémentaires)

---

Auto-amorçage à la demande (On-Demand Bootstrap)

Les capacités MCP dont dépend ce skill peuvent être installées via le système d'auto-amorçage unifié ; l'enregistrement du client MCP doit être explicitement ciblé, par défaut aucune configuration globale du client n'est écrite.

Limites des capacités automatisables

Capacité	Enregistrement automatique	Méthode	Description
jshookmcp	✓	npm-mcp (démarrage npx)	Enregistrement après sélection explicite de Claude / Codex / Les deux
anything-analyzer	✓	local-http-mcp	Démarrage automatique du service ; enregistrement client avec sélection explicite
Node.js	✓	Installation winget	Dépendance d'exécution

Méthode d'auto-amorçage

# Installer et enregistrer jshookmcp ; remplacer Codex par Claude ou Both
powershell -File "<skill-root>\scripts\bootstrap-reverse.ps1" -Capability @('jshookmcp') -McpHostTarget Codex

# Enregistrer et démarrer anything-analyzer
powershell -File "<skill-root>\scripts\bootstrap-reverse.ps1" -Capability @('anything-analyzer') -StartServices -McpHostTarget Codex

Remarques

• jshookmcp doit encore être activé dans le client IA pour pouvoir être appelé après enregistrement
• Sans l'option -McpHostTarget, l'installation/préparation est effectuée et un message registration-required est renvoyé, sans modifier la configuration de Claude ou Codex
• anything-analyzer nécessite pnpm et le code source du projet ; l'auto-amorçage clone automatiquement et installe les dépendances
• Si Node.js n'est pas installé, l'auto-amorçage installe d'abord Node.js 22 via winget

## Auto-vérification avant complétion (MUST réussir avant de déclarer terminé)

• Ai-je exécuté chaque étape du workflow (pas seulement lu) ?
• Ai-je utilisé les chemins d'outils réels basés sur tool-index ?
• Ai-je produit des preuves reproductibles (commandes/scripts/captures d'écran/rapports) ?
• Ai-je complété et renseigné les éléments de la liste de contrôle exigés par RULES ?