Que peux-t-on mettre dans une DLL ?

Le
Zeldus
Bonjour,

Dans le cadre du développement d'un projet sous Windows avec Visual Studio
ou CodeGear C++ , est il possible d'intégrer directement des fichiers
multimédia (JPG, PNG, AVI, AAC et Flash) dans une DLL lors de sa création ?

Le but est de pouvoir réutiliser ces fichiers depuis un executable via des
fonctions tout en empêchant ou rendant difficile leur utilisation en dehors
du cadre de l'aplpli (pour les droits d'auteurs), en particulier pour la
vidéo.

Merci de vos réponse,

Pierre
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 6
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
alain
Le #19624821
"Zeldus" 4a414044$0$27809$
Bonjour,

Dans le cadre du développement d'un projet sous Windows avec Visual Studio
ou CodeGear C++ , est il possible d'intégrer directement des fichiers
multimédia (JPG, PNG, AVI, AAC et Flash) dans une DLL lors de sa création
?

Le but est de pouvoir réutiliser ces fichiers depuis un executable via
des fonctions tout en empêchant ou rendant difficile leur utilisation en
dehors du cadre de l'aplpli (pour les droits d'auteurs), en particulier
pour la vidéo.

Merci de vos réponse,



Tu peux absolument tout mettre, puisque tout est binaire, en ressources au
format binaire, et extraire par les apis ressources

(=>FU windows)
Jean-Claude BELLAMY
Le #19626071
"Zeldus" news:4a414044$0$27809$
Bonjour,

Dans le cadre du développement d'un projet sous Windows avec Visual Studio
ou CodeGear C++ , est il possible d'intégrer directement des fichiers
multimédia (JPG, PNG, AVI, AAC et Flash) dans une DLL lors de sa création
?

Le but est de pouvoir réutiliser ces fichiers depuis un executable via
des fonctions tout en empêchant ou rendant difficile leur utilisation en
dehors du cadre de l'aplpli (pour les droits d'auteurs), en particulier
pour la vidéo.




Oui, on peut mettre tout ce qu'on veut en binaire grâce aux ressources de
type RCDATA.
http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx


Par contre, laisse tomber l'idée de protéger ces données !
Avec un éditeur/extracteur de ressources tel que "Resource Hacker" (freeware
génial), on fait absolument tout ce qu'on veut !
http://www.angusj.com/resourcehacker/


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Vincent Burel
Le #19626191
"Jean-Claude BELLAMY" news:4a41dfa0$0$12660$
"Zeldus" news:4a414044$0$27809$
> Bonjour,
>
> Dans le cadre du développement d'un projet sous Windows avec Visual


Studio
> ou CodeGear C++ , est il possible d'intégrer directement des fichiers
> multimédia (JPG, PNG, AVI, AAC et Flash) dans une DLL lors de sa


création
> ?
>
> Le but est de pouvoir réutiliser ces fichiers depuis un executable via
> des fonctions tout en empêchant ou rendant difficile leur utilisation en
> dehors du cadre de l'aplpli (pour les droits d'auteurs), en particulier
> pour la vidéo.


Oui, on peut mettre tout ce qu'on veut en binaire grâce aux ressources de
type RCDATA.
http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx


Par contre, laisse tomber l'idée de protéger ces données !
Avec un éditeur/extracteur de ressources tel que "Resource Hacker"


(freeware
génial), on fait absolument tout ce qu'on veut !
http://www.angusj.com/resourcehacker/



il peut inclure des resources binaires, criptées.
et justement intégrer dans la DLL les fonctions de decriptage...
Décriptage qui peut se faire selon un mot de passe fournit par l'application
(qui utilise cette DLL).

VB
Michael Doubez
Le #19626861
On 24 juin, 10:23, "Vincent Burel" wrote:
"Jean-Claude BELLAMY"
news:4a41dfa0$0$12660$



> "Zeldus" >news:4a414044$0$27809$
> > Bonjour,

> > Dans le cadre du développement d'un projet sous Windows avec Visual
Studio
> > ou CodeGear C++ , est il possible d'intégrer directement des fichie rs
> > multimédia (JPG, PNG, AVI, AAC et Flash) dans une DLL lors de sa
création
> > ?

> > Le but est de pouvoir réutiliser ces fichiers depuis un executable  via
> > des fonctions tout en empêchant ou rendant difficile leur utilisati on en
> > dehors du cadre de l'aplpli (pour les droits d'auteurs), en particuli er
> > pour la vidéo.

> Oui, on peut mettre tout ce qu'on veut en binaire grâce aux ressource s de
> type RCDATA.
>http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx

> Par contre, laisse tomber l'idée de protéger ces données !
> Avec un éditeur/extracteur de ressources tel que "Resource Hacker"
(freeware
> génial), on fait absolument tout ce qu'on veut !
>http://www.angusj.com/resourcehacker/

il peut inclure des resources binaires, criptées.
et justement intégrer dans la DLL les fonctions de decriptage...
Décriptage qui peut se faire selon un mot de passe fournit par l'applic ation
(qui utilise cette DLL).



Ce n'est pas vraiment une bonne idée. N'importe qui peut créer une DLL
proxy qui permet une attaque "man in the middle".
Le mieux est de laisser le décryptage dans l'application.

--
Michael
Zeldus
Le #19627841
"Vincent Burel" news:4a41e381$0$17074$
il peut inclure des resources binaires, criptées.
et justement intégrer dans la DLL les fonctions de decriptage...
Décriptage qui peut se faire selon un mot de passe fournit par
l'application
(qui utilise cette DLL).




C'est exactement ce à quoi je pensais, utiliser un cryptage des fichiers
binaires directement dans la DLL avec fonctions de décryptage intégrées si
présentation des bons mots de passe par l'appli exe faisant appel aux
fonctions.

Le but n'étant pas de fournir une véritable appli cryptographique totalement
blindée mais simplement d'empêcher ou du moins freiner considérablement la
récupération des fichiers binaire de type photo / video / audio / flash
inlus dans la DLL par n'importe qui.

Merci

Pierre
Patrick 'Zener' Brunet
Le #19629161
Bonjour.

"Vincent Burel" de news 4a41e381$0$17074$
"Jean-Claude BELLAMY" message news:4a41dfa0$0$12660$
"Zeldus" news:4a414044$0$27809$

Dans le cadre du développement d'un projet sous Windows avec
Visual Studio ou CodeGear C++ , est il possible d'intégrer
directement des fichiers multimédia (JPG, PNG, AVI, AAC et Flash)
dans une DLL lors de sa création ?

Le but est de pouvoir réutiliser ces fichiers depuis un
executable via des fonctions tout en empêchant ou rendant
difficile leur utilisation en dehors du cadre de l'aplpli (pour
les droits d'auteurs), en particulier pour la vidéo.




Oui, on peut mettre tout ce qu'on veut en binaire grâce aux
ressources de type RCDATA.
http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx


Par contre, laisse tomber l'idée de protéger ces données !
Avec un éditeur/extracteur de ressources tel que "Resource Hacker"
(freeware génial), on fait absolument tout ce qu'on veut !
http://www.angusj.com/resourcehacker/



il peut inclure des resources binaires, criptées.
et justement intégrer dans la DLL les fonctions de decriptage...
Décriptage qui peut se faire selon un mot de passe fournit par
l'application (qui utilise cette DLL).




Navré d'être chiant, mais pour le principe, la culture générale et la
qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car cryptées, elles
seraient inexploitables même pour l'application légitime:
http://fr.wikipedia.org/wiki/Cryptographie

Et comme il a été dit, effectivement, l'application doit garder le contrôle
de l'opération de déchiffrement car il serait extrêmement facile de
récupérer et afficher le mot de passe avec une DLL fake.

--
Cordialement.

* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Sylvain SF
Le #19629601
Zeldus a écrit :

C'est exactement ce à quoi je pensais, utiliser un cryptage des fichiers
binaires directement dans la DLL avec fonctions de décryptage intégrées
si présentation des bons mots de passe par l'appli exe faisant appel aux
fonctions.



"intégrées" veut dire ici "à la DLL"; donc la DLL vérifie elle-même
un mot de passe qui de fait est également en clair (sauf crypto
circulaire) dans la DLL et retourne le contenu déchiffré ?!

=> des efforts pour rien et protection nulle.

vous devez mettre les ciphers et la clé (pas un mot de passe) dans
l'appli. (en essayant de dissimuler la clé autant que faire ce peux)
sinon une DLL codé à 2mn12 intercalée entre votre appli et la vraie
DLL récupérera les clés, mots de passe ou autre contenu (qui sortirait
en clair de la DLL).

Le but n'étant pas de fournir une véritable appli cryptographique
totalement blindée mais simplement d'empêcher ou du moins freiner
considérablement la récupération des fichiers binaire de type photo /
video / audio / flash inlus dans la DLL par n'importe qui.



les photos seront copiées par capture d'écran, l'audio par
rétro-enregistrement (il y a sûrement un nom plus technique),
la vidéo et le flash peuvent demander plus d'effort (un hook
sur le renderer/player que vous utilisez).

entre fr.comp.lang.c++ et fr.comp.os.ms-windows.programmation
je ne sais lequel s'applique, peut être fr.misc.cryptologie.

Sylvain.
Bertrand Lenoir-Welter
Le #19629711
Sylvain :
(...)
=> des efforts pour rien et protection nulle.



Ca me paraît un brin manichéen comme position. Il me semble que Pierre a
précisé qu'il ne cherchait pas à rendre une ressource incraquable mais
seulement limiter la casse. C'est sûr qu'un hacker un peu sérieux ne
fera qu'une bouchée d'une ressource cryptée - pardon, chiffrée - dans
une DLL, surtout si le décryptage - pardon, le déchiffrage - se fait en
local. Mais si c'est pour seulement barrer la route au vulgum pecus qui
entrave que pouic aux techniques avancées de hacking, ça me paraît pas
si stupide. Protection légère donc, mais pas protection nulle. Tout
dépend de la valeur du contenu. Enfin, c'est jamais que mon avis.
Sylvain SF
Le #19629811
Bertrand Lenoir-Welter a écrit :
Sylvain :
(...)
=> des efforts pour rien et protection nulle.



Ca me paraît un brin manichéen comme position. Il me semble que Pierre a
précisé qu'il ne cherchait pas à rendre une ressource incraquable mais
seulement limiter la casse. C'est sûr qu'un hacker un peu sérieux ne
fera qu'une bouchée d'une ressource cryptée - pardon, chiffrée - dans
une DLL, surtout si le décryptage - pardon, le déchiffrage - se fait en
local. Mais si c'est pour seulement barrer la route au vulgum pecus qui
entrave que pouic aux techniques avancées de hacking, ça me paraît pas
si stupide. Protection légère donc, mais pas protection nulle. Tout
dépend de la valeur du contenu. Enfin, c'est jamais que mon avis.



la qualité intrinsèque de la protection n'est pas le point.

il parle bien de faire l'effort de stocker des ressources
chiffrés, donc il s'oblige à les chiffrer en amont (et
sûrement en externe de son appli.) => 1 tool pour cela,
il a besoin d'une routine de déchiffrement => un algo, à
coder ou récupérer et lier à son appli, il pourra avoir
besoin de gérer différentes clés si tous ces clients n'ont
pas le même "contenu multimédia" et qu'il souhaite éviter
qu'un client pompe le contenu d'un autre => gestionnaire
de clés (compile dédié et papasserie).

je suis obligé de maintenir que s'il se condamne à tous
ces efforts pour que le contenu puisse être récupéré pour
tout collégien débutant, ce sont "des efforts pour rien".

(lire la ressource chiffrée de la DLL et la déchiffrer
dans l'appli reste une bonne solution - j'ai l'habitude
d'y ajouter une signature de cette ressource pour vérifier
via une clé publique contenue dans l'appli. que la DLL
de ressources n'est pas forgée, ce point étant optionnel).

Sylvain.
Zeldus
Le #19629901
"Sylvain SF" news:4a42653c$0$12657$

=> des efforts pour rien et protection nulle.

vous devez mettre les ciphers et la clé (pas un mot de passe) dans
l'appli. (en essayant de dissimuler la clé autant que faire ce peux)
sinon une DLL codé à 2mn12 intercalée entre votre appli et la vraie
DLL récupérera les clés, mots de passe ou autre contenu (qui sortirait
en clair de la DLL).



OK pour vos différentes remarques mais en incluant cette fois la fonction de
déchiffrage dans l'exe principal, je doute qu'il soit si simple que ça de
récupérer *en clair* une clé dans une appli compilée en code binaire
executable (que ce soit programmé au départ en C++ ou en Delphi) avec un
éditeur hexadécimal.


les photos seront copiées par capture d'écran, l'audio par
rétro-enregistrement (il y a sûrement un nom plus technique),
la vidéo et le flash peuvent demander plus d'effort (un hook
sur le renderer/player que vous utilisez).




Il existe des techniques de programmation pour avoir un écran noir à la
place de la photo visée lors d'un copie d'écran. J'en ai fait l'expérience
avec PowerDVD lors de la lecture de blu-ray sous Windows. Il était
impossible de faire des captures d'écran en Full HD via le menu du logiciel
et la copie d'écran via la touche "Impr ecran" donnait un écran noir à la
place, seul le mode SD était autorisé, pas HD. Par ailleurs, je ne vois pas
l'intérêt de faire un hook sur le player pour capturer un Flash puisqu'on
perd toute l'interactivité et le code actionscript mis en place dans le
fichier d'origine.

Pierre
Publicité
Poster une réponse
Anonyme