Bonjour,
 
Je suis encore newbie avec les Dlls, et c'est pourquoi j'ai encore quelques questions conceptuelles, en particulier concernant la sécurité !
 
Voilà, je fais principalement du code en VB, mais force est de constater que lorsque l'on veut rentrer dans le détail, ce langage s'avère vite incomplet !
 
Donc, il m'est venue l'idée de faire appel à C++, grace à l'utilisation de dlls !
 
Mais voila j'ai donc des questions :
J'aierais savoir si il est possible qu'une appli tierce puisse intercepter mes appels à la Dll, et voir ainsi le contenu de mes variables d'entrée et sortie?
 
D'autre part, si par exemple, j'utilise une dll nommée test.dll, ayant deux fonctions externes, est ce qu'l est possible pour quelqu'un de facilement remplacer cette Dll par une autre ayant le meme nom et la meme interface (si bien sur, il ne connait pas de maniere directe l'interface, mais qu'il utilise un outil "lambda"?
 
En fait, voila, ce sont principalement les questions de sécurité que je me pose quant à l'utilisation de dll externes par mon programme !
 
Merci pour vos réponses,
 
Yoyo*

A mon avis avec un bon debugger c'est piece of cake.  Il y a toujours moyen d'arriver à ses fins.  Si ton appli n'est utilisée que par ton entreprise par exemple, c'est peut-être un peu fort de vouloir protéger ton contenu à ce point.
 
Et puis la meilleure manière d'hacker une application ou un réseau, c'est le social hacking, comme l'a démontré en son temp un certain Kevin Mitnick.  C'est à dire abuser des humains pour obtenir l'information voulue (un mot de passe, un login, code d'accès ou assimilé).  Ton application ne peut pas être protégée contre cela.

C'est techniquement faisable et ca s'appel du hijacking, tu as un exemple ici :
 
http://www.codeguru.com/dll/apihijack.shtml

Punaise, mais c'est fou ça !
 
En fait, je vous explique quel était mon but !
 
Mon but est d'utiliser une dll quue j'aurais programmé en C++, dans mon programme VB ! Cette dll est une Dll de cryptage ou de hachage : elle recoit en entrée une chaine de caractere, et me ressort en sortie la chaine cryptée ou la signature du message !
 
Alors bien sur, si les personnes utilisant mon appli ont la possibilté de "hacker" tout ca, ou de détourner tout ca, je suis dans de beaux draps....
 
Voyez vous, je pensais utiliser C++ pour combler, en terme de possibilité, aux lacunes de VB, et ainsi de concevoir mes modules de sécurité en C++ et les utiliser en VB... Mais justement, le but de mes mdoules de sécurité, c'est la sécurité, et si le fait de faire des dll n'est intrinsèqument pas sécuritaire, tout cela est finalement peine perdue...
 
Vous confirmez?

tu le ferais en VB, le problème resterait le même, à partir du moment où la chaîne est décryptée, il suffit d'un bon programme pour la voir directement en mémoire, mais ce n'est pas donné au premier venu

 
oui, mais je pense qu'il est toujours plus facile de voir les transferts entre deux composants "indépendants" qu'au sein du meme programme, nan?
 
Est ce que je suis en train d'etre parano pour rien, ou j'ai raison de m'inuiéter un peu?

 
exactement si ton code vérification est une dans une DLL séparée, ça sera beaucoup plus facile que si c'est éclaté un peu partout dans l'exe lui-même....

 
Microsoft diffuse une bibliothèque très puissante à ce sujet ...
 

 
Tout à fait ...
 

 
C'est même sûrement le moyen le plus simple de réaliser ce que tu dis + haut.
 

 
Ca vient pas de VB, ni de C++, ou quoique ce soit. La sécurité est un problème à part, et un métier aussi. Et ça coûte cher.
Réaliser une appli de cryptage sécurisée, c'est très très très dur. Seuls de très grands spécialistes savent le faire. Il y a tant de paramètres. En analysant la pile après le calcul, en chronométrant le temps de calcul de ton algo, certains arrivent à trouver la clé ...
Apparement tu veux quelque chose de très sécurisé. Je te conseille vivement d'utiliser des bibliothèques qui ont fait leur preuve et de suivre les conseilles donnés.
Crypter un fichier ou une chaine, c'est pareil. Pour un cryptage efficace, tu peux dans ton cas utiliser une clé de longueur égale à celle de ta chaîne.
Pour sécurisé l'utilisation d'une dll, tu peux utiliser un mécanisme de signature. Les systèmes de clés publiques / privées sont très pratiques pour cela (par exemple, tu génère un checksum sur ta dll, tu le crypte avec ta clé secrète, et tu le fout à la suite dans ta dll. Ton programme qui charge la dll calcule le cheksum de ta dll, décrypte avec la clé publique (qui peut être stockée en dur sans crainte dans ton exe) celle fournie dans la dll et compare les 2, S'ils sont égaux, ta dll est bien à toi).
Tu peux ainsi sécuriser ta dll, mais il faut aussi sécuriser l'exe ... car un gars peut le déplomber ... faut alors le crypter ... et tout cela ne sera sûrement pas suffisant si une équipe de professionnels acharnés s'attaque à ton prog.
Commence par définir le niveau de sécurité que tu souhaites, et les conditions d'utilisation de ton programme.

Nan, mais ce que je voulais dire, c'est qu'en cherchant à externaliser mes foonctions de sécurité (cad les faire dans une Dll en C++) au lieu de les faire directement en VB (ce qui est presque impossible, vu le peu de fonctionnalités binaires du langage, je réduis finalement à n'éant mes efforts, vu qu'on peut intercepter les messages envoyés par VB aux dll et inversement !
 

Là, je ne saisis pas quelque chose... Tu voudrais que je programme ma dll comme si de rien n'était, donc, ca ferait un fichier dll avec un certain checksum, et ensuite, tu veux que j'introduise la valeur de ce checksum (en crypté) à l'intérieur de ma dll... mais le probleme, c'est que réintroduire ce checksum à lintérieur de ma dll, ca va changer le checksum original... Un poisson qui se mord la queue là ! Donc, je ne comprends pas comment je peux faire pour introduire le checksum d'une dll dans le dll meme    
D'autre part, pourquoi passer par des clefs publiques/secrètes (algo asymétique) au lieu de passer par des clés privées? (algo symétrique)? pour ne pas avoir à coder une clé privée en dur dans le dll, c'est ca?
 

 
Ce qui m'inquiete le plus, c'est surtout la dll et le passage de parametres entre la dll et l'exe, mais pas l'exe lui meme qui sera tout de meme assez gros !
 
Merci pur ta participation,
 
Yoyo*

bah le mieux, c'est de foutre la protection dans l'exe, éclatée un peu partout, avec des pièges
 
histoire que si un cracker passe, il pête la première protection simple qu'il voit (celle qui fait: vous n'avez pas donné le mot magique   ), mais qu'il y en ai une qui soit bien planquée et qui fasse planter l'appli de temps en temps...
 
genre cdrwin qui gravait des conneries de temps en temps quand on passait par un mauvais keygen

Juste un petit lien qui essaie de recenser les meilleurs moyens de protéger des logiciels : http://www.searchlores.org/protec/protec.htm
 
Le contenu est assez intéressant et le tout semble relativement bien réflechi.

Pour le checksum, je disais de le rajouter à la fin de la dll, et biensûr le déduire au moment du calcul.
Pour la clé publique oui, c'est pour ne pas stocker dans l'exe la clé qui sert au cryptage, auquel cas, une fois trouvée, on peut signer n'importe quoi ...
Après, sécuriser l'appel à la dll, ça c'est une colle. Ca me parrait difficile. Il existe des softs (payant) qui embarquent une dll dans un exe. Tu peux regarder de ce côté là ...

Déja, merci à Gatorette pour son site, c'est tresintéressant, meme si ca me fout un peu les "boules" car bon, c'est certain, je ne pourrais me permettre de sécuriser mon appli avec tout ce qu'ils préconisent ! Mais bon, c'est toujours bon à savoir
 

Hmmmm, là je ne suis pas sur de comprendre/savoir faire ! La rajouter à la fin, c'est à dire? J'ouvre mon fichier.dll avec un fopen et un append, et je rajoute le code de la checksum au bout? Code que j'aurais calculé auparavant?  
Ca ne risque pas de corrompre la dll? (désolé, je viens à peine de découvrir ce monde de la dll )
 

 
Ca veut dire que je stockerai dans la ll la clef publique de cryptage, et dans l'exe la clef privéeptage, on est d'accord? (là aussi, je ne suis pas trop sur de moi, il y avait encore une semaine, je ne savais pas vraiment ce qu'était la sécurité dans un soft)
 

D'accor, je voulais juste savoir !
 
Bon, de toute facon, mon soft n'a pas de vrais enjeux, il est juste destiné à quelques personnes et à la base, je voulais assurer un service de sécurité minimal, mais bon, si à "moindres" efforts, je peux faire quelque chose de plus avancé, je veux bien En plus, tout celà est intéressant !
 
Pour ce qui est du cryptage de ma chaine par la dll, je voulais utiliser RC4, mais c'est un algo symétrique! Donc, a priori, il vo mieux que je 'oriente vers un algo asymétrique? Vous en connaissez des efficaces libres de droit?

 
non, ce principe est utilisé par pas mal de prog qui génèrent des installeurs (sauf que c'est avec des exe, mais c'est pareil).
 

 
non, ta clé privée est stockée nul part, du moins, pas dans la dll ni dans l'exe.
la dll :
- tu caclcules le checksum de ta dll
- tu le crypte avec la clé privée
- tu l'ajoute à la fin de ta dll
c'est fini pour ta dll (elle est signée)
l'exe :
- tu calcules le checksum de la dll
- tu récupère le checksum crypté
- tu le décryptes avec la clé publique stockée en dur dans l'exe
- tu compares
 
donc, si tu veux, tu as un 3° soft qui contient la clé privée et s'en sert pour calculer le checksum de la dll, le crypter et le fouttre à la suite dans la dll.
Mais, comme souvent en sécurité, ça repousse le problème un peu plus loin ... si le mec trouve la clé publique de ton exe et la remplace par sa propre clé publique, il pourra signer correctement des dll ...

 
Là, pour l'ajouter, je peux le faire à la main? Genre j'ouvre ma dll avec Notepad, je vais à la fin et j'ajoute mon code de checksum? Ou est ce qu'il faut que je le fasse à travers un code quelconque? D'autre part, je dois utiliser quoi comme checksum? Genre quelque chose du genre MD5?
 

Donc, ici, je suppose que je récupère le checksum de ma dll MOINS la place prise par le checksum crypté? Comment faire pour ne récupérer que la partie du fichier qui m'intéresse? Ca veut dire que je connais la longueur du checksum a priori? Et apres, je dois tronquer une copie de mon fichier?

Bah déja, un tel systeme me rassure, je préfère que les données sensibles se retrouvent dans mon "gros" exe, que dans ma petite dll...  
 
Maintenant, c'est vrai que je me pose une question... Tout ce processus pourrait bien marcher, mais pour cela, il fodrait que mon appli (écrite en VB) soit capable de calculer le checksum de ma dll... Car c'est sur que si je fais faire le travail encore une fois par le dll externe, alors je ne suis pas sorti de l'auberge... Tu crois que c'est possible de faire ca en VB? En tout cas, le principe gééral me plait bien !
 
Sinon, quels sont les bons algos asymétriques que je pourrais trouver? (dont je pourrais utiliser l'algo?)

J'avais pas pensé à ça ... comment décrypter le checksum de la dll depuis VB. Bon ben va pour une signature maison alors.
Pour ajouter ta signature à la dll, faut faire un petit soft à toi (c'est pas la mort ...). Oublie notepad, il va souvegarder ça en texte (retours chariots ...) et ç ava tout bousiller.
A la rigueur, un éditeur hexa.
Si tu veux un niveau de sécurité moyen, c'est à dire prévoir des mécanismes pour mettre des battons dans les roues du curieux, ça peut être fait simplement. Le plus important, c'est que quand le mec se dit "ah mais j'ai qu'a faire ça" il se trouvé bloqué par une protection ... il tente 2 minutes à déssassembler le code, puis il abandonne "bah c'est trop balaize".
C'est un des principes général de la sécurité, la dissuation (c'est comme peindre en jaune fluo les antivols).
Apres, que ce soit fait de manière parfaite, c'est utile que si tu penses que quelqu'un, un pro, peut réellement en vouloir à tes infos.
Dans ce genre de cas, rien de mieux qu'un bon gros algo, bien long, même s'il est con, pour dissuader toute tentative de dessassemblage. Les algos de cryptages sont nickels pour cela, et en plus ils sont fiables. Mais une bosse grosse routine VB qui ne fait que des aditions, qui multiplie tous les X lectures, qui ajoute, divise ... ça suffit à bluffer la plupart des curieux et à les décourager.
J'avais lu des conseils pour les protections de logiciels : "une bonne protection est une protection qui résiste 10 minutes".
Donc tu signes la dll, tu peux utiliser une interface un peu complexe pour l'appeler (du genre une seule fonction exportée qui remplit un tableau de fonctions que l'on va appeler pour filer un callback que la dll va appeler pour récupérer les infos à crypter depuis l'exe...). Tu ne peux pas, à mon avis, sécuriser un appel à une dll, mais tu peux établir un protocole compliqué avec cryptage des buffers transmis etc ... pour fouttre la merde.
Mais est-ce que tous ces efforts sont plus efficaces que de traduire en VB une routine de cryptage ? Car déssassembler du VB, c'est pas la fête ...

Lol, je l'ai attendue longtemps ta réponse !!!
 
Avant tout, j'ai oublié de préciser... C'est meme pas du VB en tant que tel que je fais, mais du VBA! Est ce que à tes yeux c'est plus ou moins la meme chose? Surtout quand tu dis que désassembler du VB, c'est pas la fete?
 
Apres, j'ai absolument besoin du'tiliser une dll, pour aller chercher le numéro de série du disque dur, donc, je ne peux pas y couper => je vais donc passer par cette méthode de checksum !
 
Donc, résumons, je crée ma dll, la compile, etc... Tout marche! Ensuite, à l'aide d'un algo qu'il me faut encore trouver, vais calculer le checksum de ma dll (je vais devoir utiliser un algo de calcul de checksuèm assez siimple, car il doit marcher égaklement en VB dans l'exe), et ensuite, à l'aide d'un algo que je ne possède pas encore, je vais crypter ce checksum avec une clef Privée, à l'aide d'un logiciel "tiers". Enfin, je mettrai ce cryptogramme au bout de la dll (je pense que je vais utiliser un simple fOpen en VBA, avec ouverture en Binaire, ca doit marcher?)
 
Ensuite, à l'utilisation de la dll, mon appli (mon exe) va devoir extraire la clef cryptée à la fin de mon fichier dll, la décrypter avec la clef publique corresposant à la clef PV qui a permis de crypter le checksum, et va comparer ce ckecksum décrypté avec le checksum réel du fichier dll auquel j'aurai enlevé le cryptomgramme du checksum !  C'est ca?
 
Conclusion, il faut que je sois capable en VB d'écrire un algo de chiffrement asymétrique, ainsi qu'un algo de calcul de checksum sur ma dll ! J'espere que tout celà est possible, te que je ne serai pas bloqué par les capacités du langage.
 
Bon, j'arrete avec mes questions, car sinon, on ne s'en sort pas !
 
Ah oui, je suis d'accord avec ta vision de la séurité, la dissuasion, etc... Pour ma part, je ne cherche pas non plus à faire un truc ultra sécurisé, mais un truc qui puisse résister à 99.9% de la population qui aurait des idées malveillantes! Je suis bien conscient que si je me mets bille en tete de faire un truc ultra sécurisé, alors je ne suis pas sorti de l'auberge, bien loin de la, et que j'aurais besoin de quelques années d'expérience !

VBA ... c'est à dire, dans quel context, sous quelle forme ?
Précise aussi le public auquel s'adresse ton soft : les secrétaires, ou des informaticiens ...

 
mon soft est un SGBD !
 
Je le fis pour l'instant sous VBA poour Access, et il est plutot destiné à des secrétaires

Donc en fait on peut lire ton code source ? je connais pas le VBA, comment ça se passe, c'est compilé dans Access ?

 
Alors, je pense qu'avec VBA, tu as plus ou moins les memes fonctionnalités en terme de code que VB, et sinon, tu as le choix :
 
- Soit distribuer ton appli au format .mdb ou tout est éditable, rien n'est compilé
- Soit distribuer ton appli au format .mde où tout est compilé en p-code interprété à la volée
- Soit, avec la version Developer d'Office, tu peux distribuer ton appli en Runtime, compilée en .exe  
 
Pour ma part, j'utilise le .mde, donc, mon appli est compilée en pCode, donc, le code est protégé
 
Pour répondre à mes questions, tu peux donc considérer que je fais du VB

Vu qu'on s'adresse à des secrétaires, je me demande si c'est la peinde crypter ton checksum ... Génères-en un bien long, du genre tous les 1Ko de ta dll, tu génères un Integer qui est la somme des multiplications des différences etc ... (à ta guise) et tu l'ajoutes à la fin de ta dll.
AMHA, ça devrait largement suffire, surtout que la faille n'est pas trop là, mais plutôt du côté de l'appel des fonctions de la dll.
Pour emmerder le gars, fait la passer par Aspack aussi avant de calculer son checksum. Il pourra pas bisouiller les exports, il pourra pas mettre sa dll à la place de la tienne (du moins, sans y passer pas mal de temps). Reste la possibilité de hooker au runtime.

Salut !
 
Meme si mon appli est destinée à des "secrétaires", vu qu'il y a un enjeu derrière, rien ne les empêcherait d'aller voir le frere informaticien ! C'est pour ca que je me dosi de mettre un minimum de sécurité !
 
Sinon, n'oublie pas que tu t'aderesses à un débutant en sécurité, donc, a priori, AMHA et Aspack sont des termes que je ne connais pas (mais je vais faire une recherche dessus).
 
Qaunf tu me dis que la faille est plutot du coté de l'appel des fonctions, tu sous entends que je ferais bien de crypter les variables entrantes et ortantes de ces memes fonctions?

AMHA = A Mon Humble Avis
Aspack : c'est un soft gratuit qui compresse les dll/exe. L'avantage aussi c'est que ça complique bien le boulot du gars qui veut désassembler.
Pour les appels, tu peux en effet crypter les données transmises. Mais je pense que ce qui compte c'est que ce ne soit pas directement visible. Là aussi, je jouerais la carte du bluff en faisant un pseudo-cryptage tout con, genre simple XOR.
Tu peux aussi faire une interface d'appels assez complexe, à base de callback. Je sais pas comment on file un callback VB à une dll C++. Mais si tu sais le faire, ça peut être utile pour brouiller les pistes.
Pour terminer le grand bluff en beauté, exporte des fonctions de cryptage dans ta dll, que tu appels quelque part dans ton prog VB, mais qui en fait ne servent à rien. Ca s'appelle un piège à cons ...

il existe un mot clé AddressOf qui permet de filer l'adresse d'une fonction.  Ca ouvre grand la porte à pas mal de techniques de programmation qu'on ne pouvait mettre en application jusqu'à au moins VB4.

 
De quelle manière pourrais je m'en servir? J'utilise ca dans VB ou dans ma Dll?

Faut voir comment filer un callback VB (donc depuis VB) à une fonction C++ d'une dll. Cherche comment subclasser une fenêtre en VB (SetWindowLong), il faut filer une callback ...

J'ai du voir ca dans mon passé, mais je ne m'en rappelle pas assez précisément... En quelques mots, c'est quoi une callBack? Pour moi, mais c'est peut etre faux, c'est une fonction (ou plutot son adresse), qui est renvoyée au retour d'une fonction appelée à la fonction appelée, de maniere à ce que cette fonction appelante exécute cette fonction renvoyée?

J'ai pas trop suivi ta phrase, mais une callback c'est une fonction que tu n'appelles pas toi, mais que tu files à quelqu'un pour qu'il l'appelle à ta place. Tu lui files généralement en paramètre d'une autre fonction.

 
D'accord, donc, le principe sécuritaire serait d'avoir dans ma dllune unique fonction d'entrée acceptant comme paramètre une callback donnée par la fonction VB appelante, plus un tas de parametre que la dll se charegra de transmettre à la Dll, c'est ca?

C'est pas vraiment sécuritaire, c'est à but d'emmerder.
Y'aurais plusieurs méthodes. Celle-ci me plaît bien :
- ta dll exporte les méthodes utiles : Crypt, Decrypt, Init
- Crypt et Decrypt sont utilisées de manière direct dans ton code VB, dans des fonctions "piège à con", qui font semblant de faire ce que tu souhaites
- Init accepte en paramètre une structure qu'elle remplit. Cette structure est en fait un tableau de pointeurs de fonctions qui sont les réelles fonctions Crypt, Decrypt (qui ne sont pas exportées par la dll).
- Ces fonctions peuvent accepter en paramètre un callback VB  qu'elles vont appeler pour récupérer les données  / renvoyer les données à (dé)crypter

 
joli noyage de poisson
 
 
 

Merci
 
Je ne suis pas dur d'avoir tout compris donc je quote :
 

Jusqu'ici tout va bien

En fait, ceci permettra à VB, grace au tableau qu'elle aura passé à la dll, d'avoir une mainmise sur les réelles fonctions de cryptage/décryptage de la dll (qui ne sont pas exportées)

Alors là, je n'ai pas compris par compris? Ma dll disposera de l'adresse (le callback) de mes fonctions VB pour leur demander de lui envoyaer le message à crypter ou laors pour renvoyer le message crypté?

oui.

oui.
Pour commencer, tu peux faire des fonctions qui acceptent en paramètre directement le buffer à (dé)crypter.
Après, tu lui passe à la place une fonction callback VB qu'elle va appeler pour récupérer les données, et une autre qu'elle va utiliser pour écrire le résultat. Tu peux encore ensuite mettre une couche en cryptant maison les buffers, genre un XOR avec addition etc ...

Je fais toutes ces opérations les unes à la suite des autres? Je n'aurais pas de probleme de synchronisme? En tout cas, ca me parait un peu compliqué, mais bon, je pense que si j'arrive à faire tout ca, lol, j'aurai appris beaucoup de choses ! Y a une semaine, je ne savais meme pas encore faire une dll utilisée par VB

En tout cas, merci pour cette foule de petits renseignements (surtout HelloWorld   ) ! Je vous tiendrai au courant de l'évolution de tout ca!