Enquête dans mon PC

Comme le dit la troisième loi de Clarke :

Toute technologie suffisamment avancée est indiscernable de la magie.

Un corollaire personnel serait

C'est de la magie surtout si ceux qui l'ont créée pensaient connaître mes besoins mieux que moi.

Voici ci-dessous une de mes aventures informatiques qui l'illustre, façon Agatha Christie.

Etape 1 : le décor

Je travaille sous OS de Redmond dans sa septième réincarnation (quelques applis nécessaires que je n'ai pas tenté de faire fonctionner sous Wine). Mais mes besoins penchent plutôt vers un environnement de développement pour l'embarqué, sans les environnements intégrés pleins de boutons à cliquer. Résultat des courses, j'ai installé une couche de POSIX sur mon poste sous forme de MinGW, celui-ci permettant une meilleure prise en charge des utilitaires natifs. J'ai donc un environnement de base, le shell avec les commandes les plus usuelles qui vont appeler des programmes windows natifs.

Etape 2 : Usual suspects

Pour clarifier, mon objectif est de générer un binaire exécutable bare-bones (pas sur un OS) sur une architecture ARM. Pour ce faire, on compile et on link du C avec un gcc arm. Puis on passe le fichier elf obtenu dans une moulinette pour le mettre à la sauce du fondeur.

Jusqu'à il y a peu, la compilation se faisait par makefile tandis qu'on m'avait montré la conversion finale via un outil clickodrome fourni par le fondeur. Il s'avère que cet outil est un amalgame de dlls et de scripts autour d'un moteur lua. Après avoir eu plusieurs déboires avec cet outil (perte de configuration, oubli de l'utiliser et flashage d'une version obsolète de binaire, ...), j'ai cherché et trouvé un utilitaire en ligne de commande disponible pour réaliser en automatique la conversion. Cet utilitaire réutilise l'infrastructure lua.

Etape 3 : le crime

Plein de confiance dans l'avenir automatisé qui s'ouvrait devant, j'ai donc forgé une recette supplémentaire dans le makefile, recette permettant de créer automatique le binaire à partir du elf. Avec en guest star la commande en ligne flanquée de sa floppée d'options idoines. Tout fier de ma trouvaille, je lance le make, qui va au bout de son exécution sans protester. Mais las, point de fichier bin...

Etape 4 : l'enquête

D'entrée de jeu, je dédouane make. Il a effectivement lancé la commande, et de toute manière, c'est un fainéant qui utilise le shell dès qu'il a quelque chose à faire. Rapidement le lancement de la même commande en direct sur le shell me confirme le comportement.

Première chose, simplifier les choses. Je mets de côté le chemin original vers les fichiers pour travailler directement sous la racine. Pas mieux.

Bon, le shell modifie peut-être l'environnement de la commande (réécriture des chemins à la mode POSIX, pollution des variables d'environnement). C'est possible bien que peu probable, lua comme la plupart des langages de script multiplateformes doit avoir une forme de gestion unifiée des chemins de fichier. On lance ce bon vieux command.com pour refaire les essais et après moults tergiversations avec la manière d'accéder aux scripts et fichiers, on confirme que sh n'y est pour rien : le satané fichier est toujours absent.

Question flottante : mais au fait, ce script, il fait quelque chose ? Recherche et activations des options de debug de lua. Le script lancé en mode verbal raconte toute sa vie et finit par une trace qui me nargue :

writing to file test.bin
86624 bytes written

Argh ! Mais ils ne sont pas là, ces 86624 octets ! La recherche de cette chaîne dans le script m'amène à une fonction d'écriture de fichier tout à fait bien sous tout rapport, avec toutes les gestions et les messages d'erreur qu'on peut espérer...

Je commence à lancer en surveillant un cran plus bas, par l'intermédiaire de l'antivirus. A chaque lancé du script, l'antivirus indique bien qu'il a scanné un fichier test.bin, sans y trouver de virus. Le fichier existe bien à un moment, vu que l'antivirus a même pu le tester. Mais au final, il n'y a rien dans le système de fichier. Le fichier a été "tué" dans l'intervalle.

En fait, c'est à ce moment que la magie s'est opéré. Dans l'interface de l'antivirus, une entrée m'interpelle. Celle-ci s'appelle "Sandbox". Elle permet, quand on n'est pas sûr de l'origine d'un programme, par l'entremise du menu contextuel de l'exploreur de le lancer dans un bac à sable, pour s'assurer qu'il ne commettra pas de dégât irréparable au système.

Mais sous cette entrée, une autre, bien plus inquiétante allume une alarme : "AutoSandbox". Mmmmh, les trucs auto, je me méfie. La fenêtre de paramétrage de cette "fonction" confirme mes pires doutes :  elle est activée et une entrée "mode autosandbox" est associé à une liste déroulante dont la valeur actuelle est "Automatique". Damned, ce système se permet de décider si un programme est dangereux et l'isole de lui-même silencieusement.

La désactivation de l'option permet effectivement la persistence du fichier tant attendu... Auparavant, celui-ci a bien existé, mais dans les limbes évanescentes créées par l'antivirus.

Epilogue

Affaire réglée. Que nenni, mon ami ! Moins de dix minutes après avoir désactivé l'autosandbox, je me suis retrouvé avec les mêmes symptomes. Vérification dans l'antivirus, l'option est à nouveau active. Bug ou fonctionnalité, l'autosandbox refuse de rester désactivé plus de quelques minutes. Résultat actuel, j'ai abandonné le lutte, et activé le mode "Demander". Au final, à chaque compilation, l'antivirus persiste à me demander si je veux virtualiser lua.