Question:
Comment puis-je m'assurer que ma DLL n'a pas été modifiée?
Vallo
2015-04-21 16:36:58 UTC
view on stackexchange narkive permalink

J'ai un ancien projet en VB qui a créé un code pc unique à partir de l'adresse MAC et de l'identifiant du disque. Cela a été utilisé pour identifier un PC afin que les informations d'identification ne puissent pas être utilisées entre les PC.

Ce projet a migré vers C #, et j'ai encapsulé cette logique dans une DLL qui appelle simplement une méthode qui renvoie le pc_id.

Le problème que j'ai maintenant est qu'il est très facile de créer simplement une nouvelle DLL qui a le même nom de classe et la même signature de méthode et de renvoyer tout pc_id qu'ils souhaitent.

Comment puis-je m'assurer la DLL référencée par mon programme est en fait la mienne?

J'ai pensé à comparer le hachage de ma DLL avec une DLL codée en dur, mais est-ce sûr entre différents OS? Le hachage du fichier changera-t-il entre les systèmes de fichiers?

Ou quelle méthode est préférée pour garantir l'intégrité / l'origine des fichiers?

Vous pouvez utiliser un hachage ou signer le fichier avec une clé privée. Vous pouvez ensuite stocker la clé publique codée en dur et vérifier que la DLL est la vôtre.
Comment vous assurez-vous que le programme en cours d'exécution est bien le vôtre? Si vous ne pouvez pas faire cela, vous devez vous assurer que la DLL vous appartient.
Qui essayez-vous de protéger avec un hasch? Un hachage est utile pour protéger l'utilisateur en détectant si une DLL a été falsifiée par une autre partie (par exemple si la DLL a été téléchargée de quelque part). Cependant, si l'utilisateur essaie lui-même activement de remplacer la DLL, tous les paris sont désactivés. L'utilisateur pourrait probablement aussi simplement modifier le programme principal pour vérifier contre un hachage différent ou pour ignorer complètement la validation.
Veuillez modifier votre question pour expliquer votre modèle de menace. Contre quels types de menaces essayez-vous de vous défendre? Quels types d'attaquants ou de scénarios? Quels sont vos objectifs, c'est-à-dire qu'essayez-vous d'empêcher? Essayez-vous de vous assurer que l'utilisateur dispose d'une copie sous licence valide de votre logiciel? Essayez-vous de faire des DRM? Comment répondriez-vous à @bdsl? Veuillez lire les commentaires sur http://security.stackexchange.com/help/on-topic et modifier votre question en conséquence (par exemple, "Quel contexte dois-je donner dans ma question?").
Imaginez si vous pouviez. Alors, comment vous assurez-vous qu'ils ne modifient pas simplement votre programme pour supprimer la vérification de modification DLL?
Si la DLL est vraiment petite, ne pourriez-vous pas simplement encoder ses octets dans une variable statique dans votre programme principal et le charger à partir de là et non à partir du système de fichiers?
Étant donné que votre nouveau programme est en C #, il est trivial de le modifier et de supprimer la vérification. Les décompilateurs comme ILspy vous permettent de comprendre facilement le code à modifier. [1] http://ilspy.net/
Cela ressemble au problème de DRM impossible à résoudre.
Je comprends qu'il existe toujours une solution de contournement pour ignorer toute validation. La sécurité n'est pas un gros problème ici (et je suis très sous-qualifié dans ce sujet), mais au moins j'essaie de ne pas rendre très facile le saut de cette validation. De plus, ce pc_id est juste pour empêcher un utilisateur d'utiliser le même compte sur des PC, ce n'est pas le vrai DRM. Merci à tous pour vos réponses!
Cinq réponses:
Marcos Zolnowski
2015-04-21 23:54:41 UTC
view on stackexchange narkive permalink

Pour les binaires Windows, je suggérerais de signer numériquement le fichier.

Lorsque vous utilisez des certificats, presque la même technologie que HTTPS.

Introduction à la signature de code

SignTool

Vous devez alors utiliser les API cryptographiques Windows pour vérifier la signature de DLL chargées.

Je sais que pour y parvenir, vous avez besoin de beaucoup de travail. Mais, pour Windows, c'est le chemin le plus sûr . Si les hachages SHA ne suffisent pas, c'est l'alternative.

Je suis confus.Je conviens qu'une signature numérique soutenue par une autorité de confiance est la meilleure voie, mais tous les commentaires dans le message d'origine ne tiennent-ils pas toujours?L'attaquant ne peut-il toujours pas modifier l'assembly pour ignorer la vérification de la signature?Ou par «Pour les binaires Windows», voulez-vous dire du code non managé (qui est plus difficile à modifier)?
Avant de charger la DLL, vous vérifiez sa signature.La signature détient la somme de contrôle du contenu.Si vous en modifiez un seul élément (géré ou non), ils ne correspondront pas.
Bien sûr, cela a du sens.Je suppose que cela dépend vraiment du modèle de menace.Par exemple: ASSUMEZ qu'ils ont accès à la DLL qui effectue le chargement et valide la signature.Ils peuvent simplement supprimer ce code défensif lors de la validation de la signature.(assez facilement, cela m'a pris quelques minutes).J'espère que mes outils d'obscurcissement le maintiendront, je suppose ...
Oui, l'étape suivante consiste à supprimer la vérification de l'EXE.Donc, vous devez également signer le fichier EXE.Configurez Windows pour vérifier le fichier EXE avant l'exécution.Ils sont appelés Stratégie de groupe - Stratégies de restriction logicielle.Cela signifie que Windows n'exécutera que les fichiers signés avec votre certificat.Pour Windows, c'est le meilleur que vous puissiez obtenir en matière de sécurité.
Ces stratégies de restriction logicielle de stratégie de groupe s'appliquent-elles uniquement à un fichier EXE (ou plutôt à un processus?).Par exemple, j'essaie vraiment de protéger seulement quelques DLL gérées, serait-ce encore possible?Ou êtes-vous en train de dire que je dois introduire un exe dans le mix, par exemple en demandant à l'un de mes assemblys de charger l'exe qui a été signé numériquement?"Cela signifie que Windows n'exécutera que les fichiers signés avec votre certificat" Ce fichier peut-il être une dll plutôt qu'un exe?
Le fait est que quelqu'un doit charger vos DLL.Si le processus (instance) est compromis, avoir une DLL signée ne vous aidera pas beaucoup.Quiconque contrôle le système peut contourner le système.
Simon Richter
2015-04-21 22:11:33 UTC
view on stackexchange narkive permalink

Avec le faible niveau de protection qu'offre l'adresse MAC, cela ne me dérangerait pas. Changer l'adresse MAC demande moins d'effort que d'échanger votre DLL.

AlexH
2015-04-21 16:42:23 UTC
view on stackexchange narkive permalink

Les hachages ne changent pas entre les systèmes de fichiers. Vérifiez le hachage SHA1 du fichier par rapport à la "bonne" valeur connue dans votre code et vous devriez être absent!

Ce qui est également simple à travailler avec un [shim] (https://technet.microsoft.com/en-us/library/dd837644%28v=ws.10%29.aspx). Ce n'est pas une mauvaise réponse, remarquez, mais vous devez comprendre la limitation
Et pourtant, vous pouvez simplement supprimer la fonction qui vérifie le hachage et la contourner. Vous ne pouvez pas garantir à 100% que la DLL est la bonne.
À mon humble avis, ce sont de mauvaises réponses tant que cela ne ** également ** explique que ** la question est fausse **.
alex
2015-04-22 02:00:38 UTC
view on stackexchange narkive permalink

Si votre objectif est d'empêcher l'utilisation des informations d'identification sur d'autres PC, jetez un œil à l ' API de protection des données Windows. Avec lui, vous pouvez crypter vos informations d'identification, ou toute autre donnée, et elles ne seront décryptables que sur cet ordinateur (ou uniquement sous le compte utilisateur Windows actuel, si vous en avez besoin).

Loren Pechtel
2015-04-23 07:18:37 UTC
view on stackexchange narkive permalink

Non seulement l'adresse MAC n'est pas très protectrice, mais la saisir sur un ID de disque est une mauvaise chose - tous les "disques" ne renvoient pas un ID de disque cohérent. Le problème est que certains contrôleurs RAID répondent à une demande d'ID de disque en l'obtenant à partir de n'importe quel lecteur disponible.

Sans parler de ce qui se passe si quelqu'un met à niveau du matériel.

S'ils mettent à niveau leur matériel, ils demandent simplement une réinitialisation de leur pc_id. Cette validation est juste pour éviter d'utiliser le même identifiant dans plusieurs PC. Je ne savais pas cela à propos du RAID, car aucun de nos utilisateurs avait un RAID. Nos clients utilisent généralement du matériel et des ordinateurs portables anciens, nous n'avons donc jamais eu de problèmes avec ce sujet.
@Vallo J'ai vu une matrice RAID dans une machine du milieu des années 2000 - certes une machine haut de gamme lorsqu'elle a été achetée. J'ai également possédé des ordinateurs portables compatibles RAID depuis à peu près (mais je n'ai jamais utilisé les capacités RAID.)


ⓘ
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...