Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Environnement Microsoft Que peux-t-on mettre dans une DLL ?

Que peux-t-on mettre dans une DLL ?

52 réponses
Avatar
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
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
2 3 4 5 6
Avatar
robert
Vincent Burel a écrit :
"robert" wrote in message
news:4a48a4fc$0$10236$
Vincent Burel a écrit :



Est-ce qu'il y aura qqn pour relever le défit et me dire quel message
contient ce fichier ? En combien de temps ?



Si tu utilise un masque jetable c'est évidemment impossible de
déchiffrer le message...



il s'agit simplement de faire apparaitre le signal qui se cache dans le
bruit, c'est l'enfance de l'art pour un casseur de code non ?

VB




Le problème c'est que si la clé est aussi longue que le message chiffré,
on peut alors trouver n'importe quel message qui a du sens, a condition
de bien choisir la clé.
Avatar
Bertrand Lenoir-Welter
Glav :

Attention, ça c'est l'argument des éditeurs pour dissuader d'utiliser
des cracks. Et la dissuasion "virus", elle a disparue depuis un bail,
maintenant qu'équiper son PC contre les malwares est gratuit et à la
porté de tous.



Je peux témoigner que la menace n'est pas inexistante. Non que j'en ai
été victime, mais effectivement j'ai eu des mails d'insultes de la part
de gens qui avaient récupéré sur Emule une version pseudo-crack de mon
soft qui avait ratiboisé leur disque. Je précise que 1/ je n'y suis pour
rien, 2/ la version en question était une classique démo même pas
craquée et 3/ j'ai dû ajouter une fonction de vérification de
l'intégrité du code pour ne pas ruiner la réputation du soft. L'avantage
du peer-to-peer, c'est que le malware n'a même pas besoin de code
d'auto-reproduction pour se diffuser et, n'étant pas contaminant, il
arrive à passer sous le radar des anti-virus.


Il y a ça, et il y a aussi la philosophie Mac. La communauté Mac a
choisi de payer plus cher; un prix élevé serait gage de qualité. Les
utilisateurs sont beaucoup moins portés sur le crack.



Hmm. La "philosophie Mac", même un peu usée, ça reste une solide ficelle
marketing. Mais c'est un autre sujet.


J'en profite pour demander si quelqu'un connaît un bon programme
d'obfuscation de code au niveau assembleur (x86). Pas les classiques
bouzins pour .NET, mais de ces trucs qui rendent le travail du hacker
vraiment pénible. Merci pour tout lien.

Il serait peut-être temps de fiche la paix sur fr.comp.lang.c++ ?
Avatar
Michael Doubez
On 29 juin, 18:08, (Marc Espie) wrote:
Attendez, faudrait un peu arreter de delirer par rapport au contexte orig inal.

Il ne s'agit pas de *chiffrer* des informations en les protegeant par une
cle connue de l'utilisateur et protegeant contre un tiers, il s'agit de
proteger des donnees dans un cadre ou celles-ci seront extraites et
exploites "sous controle" par un tiers.  Ce qui veut dire qu'a un momen t ou
un autre, ces donnees existent en clair. Ce qui veut dire aussi que le ti ers
possede toutes les pieces du puzzle, en particulier la cle.



C'est ce que je disais. Il n'empèche qu'il y a des moyens de protéger
un minimum les données et .

On n'a pas parle
de dispositif materiel, comme un lecteur blue-ray avec sa cle "protegee" de
l'utilisateur, il s'agit d'une DLL sur un PC ouvert.



Il existe d'autres protections (comme des cles USB de license) ou
encore des services (lourdingues) de license réseau ...

Je ne dit pas que c'est ce qu'il faut ici. Juste qu'un niveua minimum
inclus de ne pas mettre le chiffrement dans la dll.

Si c'était un logiciel libre, je dirais d'utiliser une lib de
compression avec chiffrement intégré comme lib7z compilée en statique .
Pour un logiciel payant, il est possible d'utiliser la même lib en
dynamique avec peut être une verification de hash sur la dll.

Il est beaucoup plus difficile/long de désassembler un code que de
faire une dll fake. Je pourrais même faire un générateur automatique
(si j'étais dans ce business).

Deja qu'avec du materiel prevu pour, le DRM ne marche "que" si toute
la chaine est sure (et pose generalement plus de souci aux utilisateurs
legaux, comme par exemple ma xbox qui refuse de discuter avec mon projo e n
hdmi)---ce qui va etre dur, vu que mes yeux et mes oreilles ne sont pas
encore directement branchees sur le matos---avec du materiel ouvert,
bonne chance...



De toutes façon, comme tu le dis, il y a un moment où le flux passe en
clair mais le but est que le qualité soit moins bonne ou difficilement
exploitable (d'où l'idée du logo citée plus haut).

Il y a quelques années, la boite dans laquelle je travaillais, avait
essayé de répondre à un appel d'offre de sécurisation des vidéos
enregistrées sur un service replay + VOD. La solution envisagée était
une incrustation dans le flux son/image à différentes fréquences avec
code correcteur d'erreur (pour tenir la compression par perte) des
informations de l'utilisateur et le poursuivre en cas de diffusion.
Il me semble avoir lu un article en ce sens il y a quelques mois.

Personnellement, je pense que c'est une bonne idée.

--
Michael
Avatar
Zeldus
"Michael Doubez" a écrit dans le message de
news:

Le logiciel sera gratuit, le but est de diffuser le contenu artistique d'une
association photo / video. Par contre, on ne souhaite évidément pas que les
médias contenus dans le logiciel soient utilisés dans d'autres projets sans
autorisation.

J'étais parti sur l'idée d'une DLL afin d'obtenir le maximum de fexibilité
(possibilité d'écrires d'autres EXE qui font appel aux différents fichiers
multimédia contenus dedans) mais s'il y a d'autres possibilité plus
pratiques dans ce même esprit, je suis tout aussi preneur.

Merci à tous pour vos différentes idées ! Je pense que la situation a été
assez bien résumée dans ce fil.

Pierre
Avatar
espie
In article <4a49f45f$0$405$, Zeldus wrote:

"Michael Doubez" a écrit dans le message de
news:



Le logiciel sera gratuit, le but est de diffuser le contenu artistique d'une
association photo / video. Par contre, on ne souhaite évidément pas que les
médias contenus dans le logiciel soient utilisés dans d'autres projets sans
autorisation.



Dans ce cas, assure-toi surtout que toutes les mentions legales sont
correctes, et qu'il n'y a aucune ambiguite sur le fait qu'on ne peut utiliser
ce contenu sans autorisation...
Avatar
Falk Tannhäuser
J'ai enfin trouvé 2-3 heures à consacrer au challenge (bon, je ne suis pas un casseur de code chevronné après tout...)
Vincent Burel schrieb:
"Patrick 'Zener' Brunet" wrote in
message news:h28qcu$r8p$
L'humain a cette caractéristique presque unique: le goût du jeu, de la
futilité.
Le simple fait de tenter de protéger un truc lance automatiquement un défi
que quelqu'un va tenter de relever.
Il y a aussi des gens qui sont intimement convaincus que toute forme de
secret est illégitime et doit être cassé.
Et plus ça résiste, plus il est motivant d'être celui qui va signer et
publier l'exploit.



Ha ouai ! Alors faisons un test et voyons si les humains dont vous parlez
sont nombreux !

voici un lien vers un fichier binaire (1040 octets) :
http://vincent.burel.free.fr/misc/SimpleAsciiText.bin
ce fichier contient un texte ASCII tout à fait normal, encodé avec une clef
symétrique :
char(n) = char(n) XOR f(n) avec f(n) clef d'encodage.

Est-ce qu'il y aura qqn pour relever le défit et me dire quel message
contient ce fichier ? En combien de temps ?



Quelques lois chipées sur le site de Mr Werber...
-La logique est un moyen systématique d'arriver à la mauvaise conclusion avec confiance.
-Chaque fois qu'un système est complètement défini, un fichu crétin découvre quelque chose qui soit abolit le système, soit
l'étend au-delà des connaissances actuelles.
-Si les maçons bâtissaient comme un programmeur programme, alors le premier pivert venu détruirait notre civilisation.
-La largeur d'esprit d'un ordinateur est aussi grande que son câble d'alimentation.
-Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins de choses, jusqu'à ce qu'il connaisse absolument tout
à propos de rien.
-Dites à quelqu'un que l'univers compte 300 milliards d'étoiles et il vous croira. Dites-lui qu'un banc vient d'être repeint et
il devra le toucher pour en être convaincu.
-Toutes les grandes découvertes sont faites par erreur.
-Un objet ne tombe jamais en panne avant d'avoir passé le dernier contrôle de qualité.
-Les nouveaux systèmes génèrent de nouveaux problèmes.

Avec une clé de longueur 21, l'analyse fréquentielle devient possible, sachant que les caractères ' ' et 'e' sont les plus
fréquents en français. Bizarrement, les trois premiers caractères du fichier ont été encodés différemment.
Pour ne pas être complètement hors sujet : std::map convient très bien pour compter les caractères :-)

Pour un petit peu plus de sécurité, je conseille l'AES - une bibliothèque utilisable depuis le C et C++ est disponible par
exemple ici : <http://gladman.plushost.co.uk/oldsite/AES/index.php>

Falk
Avatar
Vincent Burel
"Falk Tannhäuser" wrote in message
news:4a66b6b5$0$414$
J'ai enfin trouvé 2-3 heures à consacrer au challenge (bon, je ne suis pas


un casseur de code chevronné après tout...)
Vincent Burel schrieb:
> "Patrick 'Zener' Brunet" wrote in
> message news:h28qcu$r8p$
>> L'humain a cette caractéristique presque unique: le goût du jeu, de la
>> futilité.
>> Le simple fait de tenter de protéger un truc lance automatiquement un


défi
>> que quelqu'un va tenter de relever.
>> Il y a aussi des gens qui sont intimement convaincus que toute forme de
>> secret est illégitime et doit être cassé.
>> Et plus ça résiste, plus il est motivant d'être celui qui va signer et
>> publier l'exploit.
>
> Ha ouai ! Alors faisons un test et voyons si les humains dont vous


parlez
> sont nombreux !
>
> voici un lien vers un fichier binaire (1040 octets) :
> http://vincent.burel.free.fr/misc/SimpleAsciiText.bin
> ce fichier contient un texte ASCII tout à fait normal, encodé avec une


clef
> symétrique :
> char(n) = char(n) XOR f(n) avec f(n) clef d'encodage.
>
> Est-ce qu'il y aura qqn pour relever le défit et me dire quel message
> contient ce fichier ? En combien de temps ?




Quelques lois chipées sur le site de Mr Werber...
-La logique est un moyen systématique d'arriver à la mauvaise conclusion


avec confiance.
-Chaque fois qu'un système est complètement défini, un fichu crétin


découvre quelque chose qui soit abolit le système, soit
l'étend au-delà des connaissances actuelles.
-Si les maçons bâtissaient comme un programmeur programme, alors le


premier pivert venu détruirait notre civilisation.
-La largeur d'esprit d'un ordinateur est aussi grande que son câble


d'alimentation.
-Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins


de choses, jusqu'à ce qu'il connaisse absolument tout
à propos de rien.
-Dites à quelqu'un que l'univers compte 300 milliards d'étoiles et il vous


croira. Dites-lui qu'un banc vient d'être repeint et
il devra le toucher pour en être convaincu.
-Toutes les grandes découvertes sont faites par erreur.
-Un objet ne tombe jamais en panne avant d'avoir passé le dernier contrôle


de qualité.
-Les nouveaux systèmes génèrent de nouveaux problèmes.



Bravo !

Avec une clé de longueur 21, l'analyse fréquentielle devient possible,


sachant que les caractères ' ' et 'e' sont les plus
fréquents en français. Bizarrement, les trois premiers caractères du


fichier ont été encodés différemment.
Pour ne pas être complètement hors sujet : std::map convient très bien


pour compter les caractères :-)

Combien de temps cela prend de faire un tel décodage ?
vous avez des outils spécifiques ou bien a t'il fallu programmer qqc de
spécial ?

Par contre, votre remarque sur les 3 premiers caractères, me font constater
que j'ai fait une erreur quand j'ai programmé (trop vite) la fonction
d'encodage. Il n'était pas prévu qu'une séquence se répète... :-)

VB
Avatar
Falk Tannhäuser
Vincent Burel schrieb:
"Falk Tannhäuser" wrote in message
news:4a66b6b5$0$414$
J'ai enfin trouvé 2-3 heures à consacrer au challenge (bon, je ne suis pas


un casseur de code chevronné après tout...)


[...]
Avec une clé de longueur 21, l'analyse fréquentielle devient possible,
sachant que les caractères ' ' et 'e' sont les plus
fréquents en français. Bizarrement, les trois premiers caractères du
fichier ont été encodés différemment.
Pour ne pas être complètement hors sujet : std::map convient très bien
pour compter les caractères :-)


Combien de temps cela prend de faire un tel décodage ?
vous avez des outils spécifiques ou bien a t'il fallu programmer qqc de
spécial ?



GCC et Emacs sont suffisants comme outils :-) Un petit programme comme celui-ci fait l'affaire :
____________________________________________________________________________________
#include <fstream>
#include <iostream>
#include <iomanip>
#include <map>
#include <algorithm>
#include <vector>
#include <iterator>

struct cmp_second
{
template<typename T>
bool operator()(T const& a, T const& b) const { return a.second < b.second; }
};

template<typename KeyT, typename MappedT>
void print_sorted_by_second(std::map<KeyT, MappedT> const& m)
{
typedef std::vector<std::pair<KeyT, MappedT> > VecT;
VecT v(m.begin(), m.end());
std::sort(v.begin(), v.end(), cmp_second());
for(typename VecT::const_iterator it = v.begin(); it != v.end(); ++it)
std::cout << ' ' << std::hex << std::setfill('0') << std::setw(2) << +it->first
<< '-' << std::dec << std::setfill(' ') << it->second;
}

int main()
{
std::ifstream in("SimpleAsciiText.bin", std::ios::binary);
std::vector<unsigned char> data(std::istreambuf_iterator<char>(in),
(std::istreambuf_iterator<char>()));

// Find global character statistics and key length
std::map<unsigned char, unsigned> stat;
for(std::vector<unsigned char>::const_iterator it = data.begin(); it != data.end(); ++it)
{
++stat[*it];
std::cout << (*it >> 7 & 1); // Print bit 7
}
std::cout << "nFound " << data.size() << " chars, " << stat.size() << " different chars.n";

// Find character statistics per key byte
unsigned const key_length = 21; // Value found during preceding step
std::vector<std::map<unsigned char, unsigned> > key_stat(key_length);
for(unsigned i = 0; i < data.size(); ++i)
++key_stat[i % key_length][data[i]];
for(unsigned i = 0; i < key_length; ++i)
{
std::cout << std::setw(2) << i << ": ";
print_sorted_by_second(key_stat[i]);
std::cout << 'n';
}

// Find key bytes and plaintext
unsigned char const key[key_length] { // To be completed
0x89 ^ ' ', 0x97 ^ 'e'
};
for(unsigned i = 0; i < data.size(); ++i)
{
std::cout << char(data[i] ^ key[i % key_length]);
if(i % key_length == key_length - 1)
std::cout << 'n';
}
return 0;
}
____________________________________________________________________________________

En regardant le bit 7 des caractères du fichier crypté, on s'aperçoit qu'il y a des fortes régularités ; les irrégularités sont
dûs à la présence des caractères accentués (relativement rares) dans le texte clair. Si on exécute le programme dans une fenêtre
Emacs, on peut faire varier la largeur de la fenêtre à la souris pour reconnaître la régularité du dessin des 0 et 1 et ainsi
déduire que la longueur de la clé est de 21.
Ceci veut dire que dans un fichier de 1040 caractères, respectivement 49 ou 50 caractères ont été encodés avec le même octet de
la clé. Maintenant il suffit de faire des statistiques de caractères pour chacun des 21 octets de la clé.
Pour le premier octet, on voit que les valeurs 0x89 et 0xCC sont les plus fréquentes (10 respectivement 8 apparitions) et comme
par hasard, 0x89^0xCC == 0x45 == 0x20^0x65 == ' ' ^ 'e' - il est donc hautement probable que ces 2 valeurs correspondent à la
lettre 'e' et à l'espace (voir aussi <http://fr.wikipedia.org/wiki/Fr%C3%A9quence_d%27apparition_des_lettres_en_fran%C3%A7ais>)
et il ne reste qu'à essayer de décrypter avec les 2 valeurs (0x89 ^ ' ') et (0x89 ^ 'e') pour le premier octet de la clé pour
voir laquelle est la bonne.
C'est pareil pour le deuxième octet et les valeurs 0x97 et 0xD2, puis pour les 19 octets restants ça fonctionne de façon similaire.
On aurait probablement pu automatiser davantage cette dernière phase du décryptage, mais l'approche "semi-manuelle" avec mise à
jour successive et recompilation du programme marche suffisamment bien dans le cas présent.

Falk
Avatar
James Kanze
On Jul 30, 12:27 am, Falk Tannhäuser
wrote:
GCC et Emacs sont suffisants comme outils :-) Un petit programme comme
celui-ci fait l'affaire :



[...]

// Find global character statistics and key length
std::map<unsigned char, unsigned> stat;



Seulement curiosité, mais est-ce qu'il y a une raison pour
std::map, plutôt que :
std::vector< unsigned > stat( UCHAR_MAX + 1 ) :
(ce que j'aurais fait). En fin de compte, ton « indice », c'est
bien un petit entier non-négatif, ce qui correspond à
l'utilisation classique de vector (voire même un tableau de type
C :
unsigned stat[ UCHAR_MAX + 1 ] = {} ;
. Ou un boost::array, si tu l'as.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
Falk Tannhäuser
James Kanze schrieb:
On Jul 30, 12:27 am, Falk Tannhäuser
// Find global character statistics and key length
std::map<unsigned char, unsigned> stat;



Seulement curiosité, mais est-ce qu'il y a une raison pour
std::map, plutôt que :
std::vector< unsigned > stat( UCHAR_MAX + 1 ) :
(ce que j'aurais fait). En fin de compte, ton « indice », c'est
bien un petit entier non-négatif, ce qui correspond à
l'utilisation classique de vector (voire même un tableau de type C



Non, pas de raison particulière, sauf que je n'avais pas envie de me
prendre le choux :-) La version avec std::vector ou tableau doit bien
être plus performant (moins d'allocations dynamiques, temps d'accès O(1)
contrairement à O(log N) pour std::map) et prendre moins de mémoire, mais
vu la faible quantité de données à traiter la différence reste
imperceptible.

Falk
2 3 4 5 6