Discussion :

[Coflix]

Bonjour,

j'ai une question au sujet de l'édition de fichier exécutables compilés. Comme vous devez le savoir, il est possible avec des éditeurs hexadécimaux (Strings, voire des outils d'édition de texte actuels comme Notepad++) d' "ouvrir" un programme/fichier exécutable et d'y "lire" des informations de type ASCII (string fixes, messages, noms de fonctions définies dans l'exe). Justement ma question porte sur le nom des fonctions que l'on peut ainsi lire: est-il possible de les masquer/cacher? Vous comprendrez que rien que le nom des fonctions peut renseigner un probable lecteur sur le comportement global d'un programme ou sur une implémentation particulière (en vrac: protocole de transfert utilisé, technique de chiffrage, fonction mathématique implémentée...), chose que je souhaite éviter idéalement.

Je sais que la façon la plus simple consiste à -avant compilation- renommer les fonctions (déclaration et définition) et ainsi de générer un exe plus "obscur" au lecteur potentiel ("LireMotdePasse" deviendrait "LMDP" ou "titi" mais le comportement serait identique), mais je veux éviter ceci pour des raisons de maintenance et de lisibilité du code. Peut-être qu'un traitement de texte particulier avant compilation ou l'utilisation de macros (préprocesseur) pourrait résoudre l'affaire...

Donc, j'attends vos suggestions sur cette affaire et vous remercie à l'avance.

[CSKi_]

Effectivement, un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define LireMotdePasse titi

pourrait bien résoudre le problème. Ceci dit, pour ma part je n'ai jamais eu à utiliser une bidouille de ce genre et je m'interroge sur l'intérêt de la manip.

[TheGzD]

Dans cas d'une DLL tu peux te contenter de mettre des adresses sur les points d'entrée, après tu peux faire un exécutable qui se contente d'appeler la DLL en montant ces adresses. Toi tu sais ce que tu fais (même si niveau maintenabilité attention!) mais un guignol lambda aura du mal.
Ça répond à ta question ?

[gangsoleil]

Bonjour,

Je te conseille de faire des recherches sur les differentes techniques d'obfuscation de code.

Pour le protocole, sache qu'il est extremement facile de le connaitre, via un simple analyseur de trames reseau.

[Coflix]

Je tiens à remercier CSKi, TheGzD et gangsoleil pour leur aide rapide et pertinente: c'est sympa!

Si je peux me permettre de faire une réponse groupée:

* CSKi: en effet, c'est la solution que j'avais en tête. Je pensais même être en mesure de passer à gcc durant la compil un argument du type -DSHOWFUNC qui afficherait/masquerait les noms, genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#if defined(SHOWFUNC)
int LireMotDePasse(char*);
#else
int titi(char*);
#endif

=> avantage: permet de générer un exe masqué ou pas (en fonction de l'utilisation de -DSHOWFUNC)
=> inconvénient: il faut se taper les déclarations, définitions et appels (macro supplémentaire par fonction masquée) des N fonctions à masquer (pas toutes les fonctions de l'exe mais un bon quart). La maintenance devient aussi plus compliquée.

* TheGzD: je ne connaissais pas cette intéressante particularité des DLLs, mais le problème reste entier puisque le quidam qui veut éditer l'exe peut tout aussi bien éditer la DLL et retrouver ce que l'on cherche à cacher. De plus, le programme en question est un standalone multi-plates-formes (au moins Linux, Windows), ce qui -je présume- complexifie l'utilisation des DLL.

* gangsoleil: en effet, on peut appeler ça de l'obfuscation de code (de niveau élémentaire), bien que je ne cherche pas à rendre le code incompréhensible à la décompilation (juste à décourager des petits malins). Bien entendu, si une personne avait du temps et de l'argent à mettre pour décompiler l'exe (encore faudrait-il que cette personne soit), la simple modification du nom de certaines fonctions ne tiendrait pas longtemps.

Je pensais à la base qu'il y aurait pu exister une option gcc qui aurait pu faire le travail, mais ça ne semble pas exister. Je vais peser le pour et le contre (certains avantages, beaucoup d'inconvénients) et prendre a priori la technique des macros. Je vous remercie quand même beaucoup!

[TheGzD]

Que veux-tu exactement cacher ?
Il nous en faudrait la liste exhaustive pour t'en dire plus je pense.

[diogene]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#if defined(SHOWFUNC)
int LireMotDePasse(char*);
#else
int titi(char*);
#endif

Si tu utilises cette méthode des macros, il va falloir remplacer aussi les noms dans tous les appels des fonctions dans le code.
Peut-être avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#if defined(SHOWFUNC)
#define  LireMotDePasse LireMotDePasse
#define  AutreFonction  AutreFonction
#else
#define  LireMotDePasse f000001
#define  AutreFonction  f000002
#endif

Ceci n'affecterait pas la lisibilité du source.

[Coflix]

Je confirme: après test, la méthode proposée initialement par CSKi et récemment par diogene est parfaite (simple "#define LireMotdePasse titi", attention à bien prendre soin de ne définir que le nom de la fonction, pas les arguments).

L'idée originelle que j'avais (inspirée de ma gestion multiplateforme) m'obligeait en effet à tout redéclarer et renommer (les noms des fonctions en tout cas). Avec ceci, je n'ai plus qu'un #define à coder par fonction à masquer (quelque soit le nombre d'arguments). C'est simple, suffisant et élégant (puissant le prepro lorsqu'on sait l'utiliser!).

Merci à tous, je considère ce sujet comme résolu!

[Obsidian]

Pour les options de GCC, on va dire également que ce genre de chose n'est pas vraiment la philosophie du projet GNU.

Avant de clore complètement le sujet, tu peux aussi déclarer comme « static » toutes les fonctions internes à un seul fichier *.c . De cette façon, le symbole du nom de fonction ne sera plus du tout exporté.

[Médinoc]

Et pourquoi pas simplement générer l'exe sans les infos de débogage?
Ainsi, seuls les imports de bibliothèques dynamiques seraient encore visibles...

[Obsidian]

Attention, les symboles contenus dans un exécutable ne sont pas forcément des infos de déboguage. Avec GCC, par exemple, il faut passer « -g » pour les avoir explicitement, mais on a quand même les symboles des différents objets qui s'y trouvent.

Par contre, avec « -s » ou « strip exécutable », tous les symboles disparaissent bien comme attendu.

[PIC16F877A]

salut

ce que tu viens cherche c'est impossible, c'est tu veux masquer les noms des fonctions de ton exécutable en langage C, sachez bien qu'elles doit se masquer automatiquement d'après un clic sur le button "build" et le compilateur les traduire en langage machine et pour n'importe quel développeur de la langage assembleur il peut facilement afficher ton exécutable dans un éditeur hexadécimal et le réécrire en langage C, le fichier source exact comme celui que tu as pour ton exécutable et la meme chose avec les dlls impossible de masquer les mots machine parce que sont collé au CPU mais tu peux mais sauf si tu utilise un CPU unique


désolé pour la langue

[olivieram]

Bonjour,
Je me permets d'ajouter une réponse qui ne va pas forcément vous plaire, je crois. J'espère juste que vous me comprendrez.

Vous développez un programme que vous connaissez et que vous maîtrisez. D'un point de vue cognitif, lorsque vous lisez vos noms de fonctions, cela vous parle. Ce n'est pas le cas pour quelqu'un d'autre parce qu'il lui manque votre connaissance.
L'apprentissage, avec le temps, c'est graçe à notre mémoire cognitive que l'on se rappelle et que l'on comprend comment faire.
Donc, un pirate qui souhaite utiliser les fonctions que vous avez développé peut se rappeller, qu'elles soient nommées n'importe comment cela n'est pas grave. Et je dirais même qu'il risque de rigoler doucement. Appeler une fonction "zzddtfdfgdv" ne changera rien.

Je prends comme exemple, les fonctions de Microsoft dans les DLLs c:\windows\system32. Par exemple, une fonction, de mémoire, comme NtConnectNetwork. Eh bien, elle a un nom et on comprend qu'elle se connecte au réseau. Le nom de la fonction n'en dit pas plus. Et la fonction, simplement par son nom, elle a une certaine beauté mystérieuse. Cela n'empêche pas que toutes ces fonctions restent "obscures" et opaques pour un inconnu. Je n'ai jamais rencontré un développeur qui sache comment Microsoft a fait son OS sans y avoir jamais mis les pieds.

En revanche, pour les strings et les lectures de données, il y a toujours moyen de les modifier, de les crypter. Et vous pouvez même crypter votre dll et la charger en mémoire lorsque c'est nécessaire à l'aide d'une autre DLL qui la décrypte au passage.

Quant aux noms des fonctions que l'on voit dans les DLL, ce sont des fonctions exportées, donc visibles depuis l'extérieur. Les noms des fonctions non exportées ne sont pas visibles dans le fichier de la DLL.

Je conclus pour dire que votre programme, vous êtes le seul à bien le connaître. Personne d'autres que vous ne pourra même avec le nom des fonctions savoir comment il est fait. Et un jour, vous proposerez votre programme à quelqu'un d'autre pour partager votre savoir et qu'il développe avec vous.

C'est ça ce que vous souhaitez ? supprimer la beauté mystérieuse de votre code ?

Très sincèrement

[PIC16F877A]

re ++

tous ce que vous raconte ici est faut et complètement contre la logique de la machine et ca n'existe que dans vos imagination, la machine ne connait plus de ce que vous parlez ici "nom de fonction/des define/ou de cryptage /" la machine connait que le jeu d'instructions réservé par les fabriquent de "CPU" ce que vous parle ici n'ajoute plus ni moins au jeu d'instruction que tous les développeurs en langage machine le connaissait et un l'instruction = (un mot de 32bis = OPCODE) et je vais essayer de traduire en assembleur l'appelle d'une fonction C exemple "cacherlenomdelafonction();" en assemble on utilise l'instruction CALL ou JUMP ou GOTO depond de l'emplacement variable de la fonction "cacherlenomdelafonction();" c'est elle'est globale ou local et exemple que OPCODE de l'instruction CALL égal 0x45 en hexadécima quand le registre "PC" =(programme counter ) s'arrive a l'adresse de l'instruction "(CALL cacherlenomdelafonction" le CPU recevra 0x45 comme code d'opération "(sauver l'ancien adresse de registre PC dans la pile et initial le PC par la nouvelle adresse pointu avec l'instruction CALL(l'adresse de la variable cacherlenomdelafonction) )" et en saute directement aux instructions de la fonction appelé , c'est la meme chose avec l'instruction return exemple que son OPCODE égal 0x27 en hexadécima quand le PC arrive sur l'adresse de l'istruction return le CPU vider la pile par la restauration de l'ancien valeur de (PC) et le conteur d'adresse retourne a la ligne suivante de "cacherlenomdelafonction();" pour exécuter les autres instruction et pas a des fonctions car ça n'existe que dans le C et pour l'instructions "return" ce n'est pas équivalent a l'instruction return de l'angage C mais est équivalent a "}" en langage C et l'instruction "return 0;" en C est équivalent a (cacherlenomdelafonction = 0 en assembleur mais si la fonction avec le paramètre retour et qui n'est pas constant "void"

En revanche, pour les strings et les lectures de données, il y a toujours moyen de les modifier, de les crypter. Et vous pouvez même crypter votre dll et la charger en mémoire lorsque c'est nécessaire à l'aide d'une autre DLL qui la décrypte au passage.

le cryptage ne change rien au jeu d'instruction que'au niveau de code c'est tous, meme c'est le cryptage fait exemple de coupé un exécutable en quatre morceau le développeur s'il veut peut facilement localiser les trois CALL par leurs valeurs hex de OPCODE


je parle pas de moi mais je parle de ce que je croire qui est possible de le faire en informatique et désolé pour la langue

[ailonn]

Bonjour,

Mon fragment de solution risque d'etre a cote de la plaque mais pour etre sur je le propose quand meme, excusez moi:

Pour ton executable sous linux tu peux utiliser la commande strip pour suprimer des portions de l'executable comme la table des symboles.
Ce qui peut ralentir la personne qui tente de comprendre le fonctionnement des fonctions.
Je crois qu'elle existe aussi sous windows.
Tu peux l'employer a la compilation via ton makefile.

Bonne journee!

[souviron34]

Obsidian a donné la réponse :

• d'une part déclarer toutes les fonctions non d'usage externe en static
• d'autre part compiler sans le "-g" (et éventuellement avec un "-O2")
• enfin faire un "strip" sur le binaire

[yoby's]

Bonjour.
Malgré le topic marqué résolu, ce sujet m'intéresse beaucoup et je n'ai pas trouvé de solution qui me convienne. Je me permets donc de répondre.

Il est vrai que la visibilité des chaines fixes peut vraiment être dérangeant.

Admettons un programme qui vérifie un mot de passe à l'execution (envoyé ici en paramètre du programme pour simplifier), on peut imaginer un code de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
#include <string.h>
#define PASSWORD "qwertyuiop"
 
int main(int argc, char* argv[])
{
    if (strcmp(argv[1], PASSWORD)) == -1)
    {
        /* Suite du programme */
    }
    return 0;
}

L'édition du fichier compilé précédemment avec gcc, affiche qwertyuiop en clair, ce qui est assez désagréable.
La compilation avec -s ou -O2 ne m'a apporté aucun progrès ni même le passage de strip -s sur le fichier compilé.

Bien sur, on pourrait hasher PASSWORD et argv[1] et vérifier leurs images, mais ceci n'est qu'un exemple parmis tant d'autres de données qu'on ne souhaite pas divulguer.

Si quelqu'un a une autre réponse à m'apporter, cela m'aiderait beaucoup !
Merci.

[Coflix]

@ailonn et PIC16F877A: prenons le code d'un petit exécutable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <stdio.h>
int Fonction_A_Cacher(int);
 
int main()
{
    int i=0;
 
    printf("%d\n", Fonction_A_Cacher(i));
    return 0;
}
int Fonction_A_Cacher(int input)
{
    printf("salut!\n");
    return ++input;
}

- en compilant ce code sans l'option "-s", la taille de l'exe est de 25KB: on peut retrouver à l'intérieur (édition héxa) plein de données y compris le nom de la fonction "Fonction_A_Cacher".
- en compilant ce code avec l'option "-s" (strip all symbols from binary), la taille de l'exe passe de 25KB à 6KB: on ne retrouve plus grand chose à l'intérieur et le nom de la fonction "Fonction_A_Cacher" est invisible.

Maintenant remplaçons la syntaxe du

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf("salut!\n");

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf("%s: salut!\n", __func__);

=> la 2ème syntaxe fait appel au preprocesseur qui remplace la variable __func__ par le nom de la fonction en cours (notation très intéressante si l'on veut par exemple retrouver une erreur dans la log ainsi que le nom de la fonction dans laquelle elle se produit).
=> quelque soit l'option de compilation (-s ou pas) le nom de la fonction "Fonction_A_Cacher" est toujours présent (car codé en dur par le préprocesseur).

Personnellement, j'utilise beaucoup la 2ème syntaxe du printf: les noms de mes fonctions se retrouvent codées en dur et visibles même avec Notepad. Le seul moyen de cacher ceci est de:
- ne plus utiliser la variable __func__ et compiler avec l'option -s
- ajouter au début du programme la ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define Fonction_A_Cacher FAC

Bien entendu, je choisis l'option #define.


@olivieram: mon code reste complètement clair, commenté et possédant des noms de fonctions/variables intelligents. Les seules choses qui changeront seront:
- on ne verra plus "Fonction_A_Cacher" mais "FAC" lors de l'édition du binaire (remplacement effectué par le preproc avant la compilation, donc sans modification de code et sans altération du fonctionnement du binaire),
- si une erreur survenait dans la fonction "Fonction_A_Cacher", la log indiquerait juste "FAC: erreur" au lieu de "Fonction_A_Cacher: erreur", mais ceci reste compréhensible (pour le développeur) et acceptable (d'un point de vue de la sécurité du processus implémenté).
Il s'agit bien d'une obfuscation basique, sans impact sur le code mais tout en restant nécessaire et suffisante à mon avis dans le cadre de mon projet.


@Yobi's: au lieu de coder ton mdp en dur essaie de créer une boucle sur ton argv[1], genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
len = strlen(argv[1]);
for (i=0; i<len; ++i)
{
    if (i==0)      pEncrString[i]=113;	//code ascii de 'q'
    else if (i==1) pEncrString[i]=119;	//code ascii de 'w'
    else if (i==2) pEncrString[i]=101;	//code ascii de 'e'
    //...
}

Ça sera déjà beaucoup mieux, l'idéal étant de forcer ton prog à toujours recalculer la valeur de chaque lettre du mot de passe (en gros que la valeur de chaque lettre ne soit pas codée en dur mais toujours réévaluée), genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=10;
...
    if (i==0)       pEncrString[i]=pow(a, 2)+13;
...

mais bon, qui sait, il y a peut-être mieux!

En vous remerciant de vos nombreux messages et votre précieuse aide, je vous salue bien.

[yoby's]

Effectivement, cela reste une solution abordable et dans le cas d'un mot de passe, cela rejoint beaucoup celle d'un eventuel hashage. (surement un peu plus léger pour le processeur cela dit)

Pourtant, j'ai du mal a croire que le compilateur ne comporte pas une option permettant de n'afficher, par exemple, que la conversion binaire des caractère ascii et non pas directement leur représentation ascii..

Dans de nombreux cas, il est vrai que le fait de pouvoir afficher avec un éditeur de texte tel ou tel message d'erreur provenant d'un puts() n'a rien d'inquiétant, mais si l'on peut éviter de crypter-decrypter tout ce qu'on veut rendre non visible, ca reste un problème qui me semblait pourtant simple a résoudre.

(Cela reste objectif, mais j'aime que les choses ne soient visible qu'en fonctionnement normal )

[ZiGoM@r]

Pourtant, j'ai du mal a croire que le compilateur ne comporte pas une option permettant de n'afficher, par exemple, que la conversion binaire des caractère ascii et non pas directement leur représentation ascii..

Tes caractères sont tous écrits en binaire. Comment pourrait-il en être autrement ?!
Leurs "représentations" (ce que tu vois à l'écran) ne dépendra toujours que du programme qui lit ton exécutable (éditeur hexadécimal etc..).

En résumé : Haches ou cryptes, cela reste ce qu'il y à de plus simple.