Question:
Comment empêcher l'utilisation des éditeurs de ressources
Mellowcandle
2013-03-30 13:03:52 UTC
view on stackexchange narkive permalink

Il existe une variété d'outils qui permettent d'éditer les ressources des exécutables Windows.Ces outils permettent une interface très simple pour changer l'apparence des programmes.Le remplacement des icônes, du texte, des menus peut être facilement fait sans aucune connaissance en inversant.

Ma question est la suivante: quelle option ai-je pour éviter que les ressources soient si facilement modifiées?

Trois réponses:
#1
+15
Remko
2013-03-31 02:25:26 UTC
view on stackexchange narkive permalink

Une solution élégante et simple serait de signer votre exécutable et de vérifier la signature au démarrage (tout changement invalidera la signature). Même si quelqu'un corrige votre vérification de signature, la signature sera toujours invalide, ce qui indique clairement que l'exe n'est pas le même que celui que vous avez livré.

Mes autres pensées seraient d'utiliser un packer exe ou de prendre une somme de contrôle sur les ressources (les deux ont déjà été suggérées dans la réponse @angealbertine).

#2
+11
waliedassar
2013-04-03 17:56:05 UTC
view on stackexchange narkive permalink

De plus, nous pouvons exploiter les bogues dans les éditeurs eux-mêmes pour éviter de falsifier nos ressources. La partie intéressante ici est que la plupart des éditeurs de ressources n'ont aucune idée de la façon d'analyser des fichiers PE non typiques (pas très inhabituels). Par exemple, certains éditeurs supposent que le nom de la section de ressources doit toujours être .rsrc . Exemples:

  1. Resource Hacker

    • Insertion d'une ressource spéciale pour amener Resource Hacker à aller dans un infini boucle. Démo ici: http://code.google.com/p/ollytlscatch/downloads/detail?name=antiResHacker.exe

    • Insertion d'un spécial RT_STRING pour provoquer le plantage de Resource Hacker.

    • Elle suppose que la taille de la structure IMAGE_OPTIONAL_HEADER est supposée être sizeof (IMAGE_OPTIONAL_HEADER) , actuellement 0xE0 en hexadécimal, alors qu'il peut même être plus grand. Si la taille est d'une valeur supérieure, Resource Hacker rejette l'intégralité du fichier PE.

  2. Restorator

    • Identique à 1c.
    • Utilise le champ NumberOfRvaAndSizes , qui peut facilement être forgé pour être 0xFFFFFFFF . Cela oblige Restorator à supprimer tout le fichier PE.
    • Suppose que le nom de la section de ressources doit être .rsrc . Changez rien d'autre. Cela oblige Restorator à rejeter tout le PE.
    • Toute section de ressources avec le champ Caractéristiques défini sur IMAGE_SCN_CNT_UNINITIALIZED_DATA parmi d'autres caractéristiques sera rejetée par Restorator.

    Démos ici: http://pastebin.com/ezsDCaud

Intelligent! Question cependant: certaines de nos suggestions semblent ne pas être conformes aux spécifications des définitions pertinentes. Cela peut provoquer l'échec du chargeur ou provoquer l'échec des fonctions de ressources (par exemple, loadstring) dans les versions actuelles ou futures de Windows?
Il est peu probable que Microsoft modifie le comportement fondamental de son code de chargement et de parcours PE. Je ne les ai jamais vus faire ça. La seule variation dans les comportements était de retour lorsque le noyau win9x était utilisé, et il variait du noyau NT. Microsoft est bien conscient que les éditeurs de liens de tous types génèrent des interprétations si différentes du format de fichier PE, que je suis sûr qu'ils savent qu'il ne faut rien toucher. En fait, le format de fichier PE est si étonnamment varié, la seule constante est la compatibilité avec le code de Windows. Bien sûr, testez bien après avoir créé des mods comme ceux-ci.
Le lien vers antiResHacker.exe est mort
#3
+10
Ange
2013-03-30 13:33:47 UTC
view on stackexchange narkive permalink

Les ressources ne sont qu'une structure standard avec des constantes définies, mais en fin de compte, ce n'est qu'une structure récursive vers un tampon, peu importe ce qu'il contient ( voici la disposition standard).

Il peut théoriquement contenir n'importe quoi - n'importe quelle profondeur, boucles, types non valides, etc ... mais alors les API standard ne fonctionneront pas avec eux.

Donc, vous devez vous assurer que, si vous chiffrer ou compresser les ressources, elles doivent être restaurées (à la fois la structure du répertoire des ressources et leur contenu) avant d'utiliser l'une de ces API, ce qui peut ne pas être évident.

En particulier, certaines ressources seront utilisées par le système d'exploitation avant même que le fichier ne soit exécuté, comme les premières icônes, le manifeste et les informations de version - vous voudrez probablement les garder intacts.

Un moyen simple d'éviter une modification triviale des ressources serait d'exécuter un flux chiffrer sur les ressources sélectionnées, sur le binaire final (après que l'éditeur de liens les a mis en place et généré l'entrée de ressource dans le DataDirectory), et pour restaurer ces ressources sur dem et / ou lors de l'initialisation du programme.

Si vous recherchez une solution toute faite, de nombreux bons packers tels que PECompact prennent en charge la compression des ressources, empêchant ainsi l'édition de ressources externes.

Je me demande cependant, une sorte de décompression / décryptage au moment du chargement pourrait-elle fonctionner ici? Les éditeurs de ressources travaillent vraisemblablement avec les données sur disque, pas en mémoire.
tu as raison, j'ai édité ma réponse.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...