Par exemple, dans le cas de Rémi, je vois mal quelqu'un payer un pro pour craquer un soft vendu 5 €. Un soft à ce prix, en un sens c'est même la protection parfaite.
À mon sens, la protection parfaite c'est le prix. Si Photoshop (simple exemple) valait 250 euros, personne ne le craquerait.
Arnold, tu devrais nettoyer ton clavier de temps en temps, il doit y traîner des monceaux de rats crevés. Ou alors tape moins vite. Je n'ose croire que tes inversions sont un dispositif subtil de cryptage.
Clair que mon clavier commence à fatiguer et ne suit plus ma vitesse de saisie. Je vais faire des efforts.
Je me suis mal expliqué.
...
Pas d'appel de fonction, donc. Seulement des lignes de code disséminées.
OK.
Le talon d'Achille de ce truc, c'est que le hacker peut bloquer le moteur d'incrémentation. Il est donc nécessaire que ce moteur utilise beaucoup de possibilités parallèles et beaucoup de variables (globales ou autres) pour en noyer le mécanisme. Quand je dis "beaucoup", ça veut dire des dizaines. Pour noyer encore un peu, c'est amusant de bricoler inutilement ces variables ça et là dans le code quand elles ne sont pas actives, histoire de rendre la jungle encore plus touffue. Par exemple, j'utilise une variable entière V qui change d'état tout le temps, sauf qu'elle n'est prise en compte par le moteur d'incrémentation que sa valeur est impaire, ou un truc du genre. Je peux m'acharner sur V tant que je fais attention à sa parité. Ou alors, le moteur change de variables à mesure qu'il avance, de nouvelles variables prenant le relais des anciennes, mais on continue de bricoler au passage sur les variables devenues obsolètes, juste pour le fun. Du code inutile, ça brouille encore la piste.
Oui, c'est pas mal. Ta méthode est un procédé classique. Cela dit c'est efficace. Par contre pénible à mettre correctement en place.
En résumé, imaginons qu'on ait un algo à 3 lignes L1 L2 et L3, et trois variables globales int V1, char V2[10] et void* V3. Au lancement, on initialise V1000, V2="MX4HZAODC1" et V3 à une adresse quelconque, par exemple celle d'une autre variable globale. Dans la fonction qui traite EV_WM_MOUSEMOVE, on divise V1 par la position Y de la souris. Dans celle qui traite EV_WM_LBUTTONDOWN, si V1==0, on exécute L1 et on fait passer V2[6] à '0' (zéro à la place de O majuscule). Dans la fonction qui traite EV_WM_MOUSEMOVE, à nouveau, si V2[i]<64 (avec i comme par hasard arrivé à 6), on exécute L2 et on fait V3=NULL. Enfin, dans la fonction qui traite EV_WM_KEYDOWN, si on a V3==NULL, on exécute L3. Etc.
Aucun appel de fonction de protection, et si les lignes L1 L2 L3 sont toutes exécutées, ce sera en séquence. Patience et longueur de temps... Evidemment, dans la pratique, je fais beaucoup plus compliqué pour l'incrémentation et pour les tests sur les variables, avec un maximum d'intrications.
Certes, certes. toutefois, on peut tracer systématiquement une variable pour voir son utilisation concrète... Mais bon, dans un code de plusieurs dizaines de milliers de lignes, je te le dis de suite, je lâcherai vite l'affaire :-). Là, j'essaierai plutôt une autre voie, chopper des numéros de licences. Il faut adapter les méthodes au coût/temps que coûte un hack...
Je vois toujours pas l'intérêt d'un code recompilé en mémoire par rapport à un cryptage.
C'est simple. Si je chiffre un code, à un moment donné il va falloir le déchiffrer. Même si la clé est le checksum de 250 lignes d'opcodes précédent, ça se voit toujours un peu. Et puis, en étudiant le désassemblage... Enfin, tu repères vite l'embrouille. Xor, clés, boucles avant tests, etc. tu te doutes bien de ce que fait le code. Surtout dans le cas de clés publiques/secrètes ou la clé doit être lue/entrée quelque part...
Imagine maintenant que tu désassembles et vois x = x + d; super te dis-tu. Mais au run-time, imagine qu'en fait l'instruction réelle soit z = b *a; Là, le hacker va pas tout à fait piger de suite. Si le code du fichier de l'exécutable de ton appli n'est pas le même que celui qui est exécuté, ça complexifie un peu le boulot des hackers... Et si la recompil est noyé dans 50 layers d'obfuscation, bon courage !
Tiens, dans le sud-ouest, on ponctue les phrases avec "cong" (par exemple "y fait beau, cong"). Mais dans ma région - qu'est la plus belle du monde - c'est plutôt "y fait beau, putaing". Ce qui veut dire qu'à Marseille, on a le cul entre deux chaises et on dit "y fait beau, putaing-cong".
Lol, moi, je dis "con" une fois par an, et encore. Faut pas confondre le Sudiste des villes et celui des champs :-).
Ah marrant, comme M. Jourdain faisait de la prose sans le savoir, j'ai donc fait de l'obfuscation sans même savoir que ça existait. Et moi qui croyais avoir inventé quelque chose...
Allez tiens, je vais faire un petit article (de base !) sur la chose, rendez-vous dans quelques jours.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Bertrand Lenoir-Welter wrote:
Par exemple, dans le cas de Rémi, je vois mal quelqu'un payer un pro
pour craquer un soft vendu 5 €. Un soft à ce prix, en un sens c'est
même la protection parfaite.
À mon sens, la protection parfaite c'est le prix. Si Photoshop (simple
exemple) valait 250 euros, personne ne le craquerait.
Arnold, tu devrais nettoyer ton clavier de temps en temps, il doit y
traîner des monceaux de rats crevés. Ou alors tape moins vite. Je
n'ose croire que tes inversions sont un dispositif subtil de cryptage.
Clair que mon clavier commence à fatiguer et ne suit plus ma vitesse de
saisie. Je vais faire des efforts.
Je me suis mal expliqué.
...
Pas d'appel de fonction, donc. Seulement des lignes de code
disséminées.
OK.
Le talon d'Achille de ce truc, c'est que le hacker peut bloquer le
moteur d'incrémentation. Il est donc nécessaire que ce moteur utilise
beaucoup de possibilités parallèles et beaucoup de variables (globales
ou autres) pour en noyer le mécanisme. Quand je dis "beaucoup", ça
veut dire des dizaines. Pour noyer encore un peu, c'est amusant de
bricoler inutilement ces variables ça et là dans le code quand elles
ne sont pas actives, histoire de rendre la jungle encore plus
touffue. Par exemple, j'utilise une variable entière V qui change
d'état tout le temps, sauf qu'elle n'est prise en compte par le
moteur d'incrémentation que sa valeur est impaire, ou un truc du genre. Je
peux m'acharner sur V tant
que je fais attention à sa parité. Ou alors, le moteur change de
variables à mesure qu'il avance, de nouvelles variables prenant le
relais des anciennes, mais on continue de bricoler au passage sur les
variables devenues obsolètes, juste pour le fun. Du code inutile, ça
brouille encore la piste.
Oui, c'est pas mal. Ta méthode est un procédé classique. Cela dit c'est
efficace. Par contre pénible à mettre correctement en place.
En résumé, imaginons qu'on ait un algo à 3 lignes L1 L2 et L3, et
trois variables globales int V1, char V2[10] et void* V3. Au
lancement, on initialise V1000, V2="MX4HZAODC1" et V3 à une
adresse quelconque, par exemple celle d'une autre variable globale.
Dans la fonction qui traite EV_WM_MOUSEMOVE, on divise V1 par la
position Y de la souris. Dans celle qui traite EV_WM_LBUTTONDOWN, si
V1==0, on exécute L1 et on fait passer V2[6] à '0' (zéro à la place
de O majuscule). Dans la fonction qui traite EV_WM_MOUSEMOVE, à nouveau,
si V2[i]<64 (avec i comme par
hasard arrivé à 6), on exécute L2 et on fait V3=NULL. Enfin, dans la
fonction qui traite EV_WM_KEYDOWN, si on a V3==NULL, on exécute L3. Etc.
Aucun appel de fonction de protection, et si les lignes L1 L2 L3 sont
toutes exécutées, ce sera en séquence. Patience et longueur de
temps...
Evidemment, dans la pratique, je fais beaucoup plus compliqué pour
l'incrémentation et pour les tests sur les variables, avec un maximum
d'intrications.
Certes, certes. toutefois, on peut tracer systématiquement une variable pour
voir son utilisation concrète... Mais bon, dans un code de plusieurs
dizaines de milliers de lignes, je te le dis de suite, je lâcherai vite
l'affaire :-). Là, j'essaierai plutôt une autre voie, chopper des numéros de
licences. Il faut adapter les méthodes au coût/temps que coûte un hack...
Je vois toujours pas l'intérêt d'un code recompilé en mémoire par
rapport à un cryptage.
C'est simple. Si je chiffre un code, à un moment donné il va falloir le
déchiffrer. Même si la clé est le checksum de 250 lignes d'opcodes
précédent, ça se voit toujours un peu. Et puis, en étudiant le
désassemblage... Enfin, tu repères vite l'embrouille. Xor, clés, boucles
avant tests, etc. tu te doutes bien de ce que fait le code. Surtout dans le
cas de clés publiques/secrètes ou la clé doit être lue/entrée quelque
part...
Imagine maintenant que tu désassembles et vois x = x + d; super te dis-tu.
Mais au run-time, imagine qu'en fait l'instruction réelle soit z = b *a; Là,
le hacker va pas tout à fait piger de suite. Si le code du fichier de
l'exécutable de ton appli n'est pas le même que celui qui est exécuté, ça
complexifie un peu le boulot des hackers... Et si la recompil est noyé dans
50 layers d'obfuscation, bon courage !
Tiens, dans le sud-ouest, on ponctue les phrases avec "cong" (par
exemple "y fait beau, cong"). Mais dans ma région - qu'est la plus
belle du monde - c'est plutôt "y fait beau, putaing". Ce qui veut dire
qu'à
Marseille, on a le cul entre deux chaises et on dit "y fait beau,
putaing-cong".
Lol, moi, je dis "con" une fois par an, et encore. Faut pas confondre le
Sudiste des villes et celui des champs :-).
Ah marrant, comme M. Jourdain faisait de la prose sans le savoir, j'ai
donc fait de l'obfuscation sans même savoir que ça existait. Et moi
qui croyais avoir inventé quelque chose...
Allez tiens, je vais faire un petit article (de base !) sur la chose,
rendez-vous dans quelques jours.
Par exemple, dans le cas de Rémi, je vois mal quelqu'un payer un pro pour craquer un soft vendu 5 €. Un soft à ce prix, en un sens c'est même la protection parfaite.
À mon sens, la protection parfaite c'est le prix. Si Photoshop (simple exemple) valait 250 euros, personne ne le craquerait.
Arnold, tu devrais nettoyer ton clavier de temps en temps, il doit y traîner des monceaux de rats crevés. Ou alors tape moins vite. Je n'ose croire que tes inversions sont un dispositif subtil de cryptage.
Clair que mon clavier commence à fatiguer et ne suit plus ma vitesse de saisie. Je vais faire des efforts.
Je me suis mal expliqué.
...
Pas d'appel de fonction, donc. Seulement des lignes de code disséminées.
OK.
Le talon d'Achille de ce truc, c'est que le hacker peut bloquer le moteur d'incrémentation. Il est donc nécessaire que ce moteur utilise beaucoup de possibilités parallèles et beaucoup de variables (globales ou autres) pour en noyer le mécanisme. Quand je dis "beaucoup", ça veut dire des dizaines. Pour noyer encore un peu, c'est amusant de bricoler inutilement ces variables ça et là dans le code quand elles ne sont pas actives, histoire de rendre la jungle encore plus touffue. Par exemple, j'utilise une variable entière V qui change d'état tout le temps, sauf qu'elle n'est prise en compte par le moteur d'incrémentation que sa valeur est impaire, ou un truc du genre. Je peux m'acharner sur V tant que je fais attention à sa parité. Ou alors, le moteur change de variables à mesure qu'il avance, de nouvelles variables prenant le relais des anciennes, mais on continue de bricoler au passage sur les variables devenues obsolètes, juste pour le fun. Du code inutile, ça brouille encore la piste.
Oui, c'est pas mal. Ta méthode est un procédé classique. Cela dit c'est efficace. Par contre pénible à mettre correctement en place.
En résumé, imaginons qu'on ait un algo à 3 lignes L1 L2 et L3, et trois variables globales int V1, char V2[10] et void* V3. Au lancement, on initialise V1000, V2="MX4HZAODC1" et V3 à une adresse quelconque, par exemple celle d'une autre variable globale. Dans la fonction qui traite EV_WM_MOUSEMOVE, on divise V1 par la position Y de la souris. Dans celle qui traite EV_WM_LBUTTONDOWN, si V1==0, on exécute L1 et on fait passer V2[6] à '0' (zéro à la place de O majuscule). Dans la fonction qui traite EV_WM_MOUSEMOVE, à nouveau, si V2[i]<64 (avec i comme par hasard arrivé à 6), on exécute L2 et on fait V3=NULL. Enfin, dans la fonction qui traite EV_WM_KEYDOWN, si on a V3==NULL, on exécute L3. Etc.
Aucun appel de fonction de protection, et si les lignes L1 L2 L3 sont toutes exécutées, ce sera en séquence. Patience et longueur de temps... Evidemment, dans la pratique, je fais beaucoup plus compliqué pour l'incrémentation et pour les tests sur les variables, avec un maximum d'intrications.
Certes, certes. toutefois, on peut tracer systématiquement une variable pour voir son utilisation concrète... Mais bon, dans un code de plusieurs dizaines de milliers de lignes, je te le dis de suite, je lâcherai vite l'affaire :-). Là, j'essaierai plutôt une autre voie, chopper des numéros de licences. Il faut adapter les méthodes au coût/temps que coûte un hack...
Je vois toujours pas l'intérêt d'un code recompilé en mémoire par rapport à un cryptage.
C'est simple. Si je chiffre un code, à un moment donné il va falloir le déchiffrer. Même si la clé est le checksum de 250 lignes d'opcodes précédent, ça se voit toujours un peu. Et puis, en étudiant le désassemblage... Enfin, tu repères vite l'embrouille. Xor, clés, boucles avant tests, etc. tu te doutes bien de ce que fait le code. Surtout dans le cas de clés publiques/secrètes ou la clé doit être lue/entrée quelque part...
Imagine maintenant que tu désassembles et vois x = x + d; super te dis-tu. Mais au run-time, imagine qu'en fait l'instruction réelle soit z = b *a; Là, le hacker va pas tout à fait piger de suite. Si le code du fichier de l'exécutable de ton appli n'est pas le même que celui qui est exécuté, ça complexifie un peu le boulot des hackers... Et si la recompil est noyé dans 50 layers d'obfuscation, bon courage !
Tiens, dans le sud-ouest, on ponctue les phrases avec "cong" (par exemple "y fait beau, cong"). Mais dans ma région - qu'est la plus belle du monde - c'est plutôt "y fait beau, putaing". Ce qui veut dire qu'à Marseille, on a le cul entre deux chaises et on dit "y fait beau, putaing-cong".
Lol, moi, je dis "con" une fois par an, et encore. Faut pas confondre le Sudiste des villes et celui des champs :-).
Ah marrant, comme M. Jourdain faisait de la prose sans le savoir, j'ai donc fait de l'obfuscation sans même savoir que ça existait. Et moi qui croyais avoir inventé quelque chose...
Allez tiens, je vais faire un petit article (de base !) sur la chose, rendez-vous dans quelques jours.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
JM
Arnold McDonald (AMcD) a écrit :
Pour la petite histoire, ces dernières années j'ai proposé à des éditeurs d'écrire une sorte d'encyclopédie du hacking sous Windows, non, pas un truc de boutonneux hein, LE truc, avec algos détaillées, techniques, exemples, code... Le truc encyclopédique; du buffer overrun au virus métamorphique avec code recompilé en mémoire. Le pavé exhaustif quoi. Ben personne n'en a voulu. Alors, les vendeurs d'huile de serpent ont encore de beaux jours devant eux...
Dommage, cela aurait été certainement très intéressant. Il n'y a pas des sites où ils donneraient quelques idées de base?
Arnold McDonald (AMcD) a écrit :
Pour la petite histoire,
ces dernières années j'ai proposé à des éditeurs d'écrire une sorte
d'encyclopédie du hacking sous Windows, non, pas un truc de boutonneux hein,
LE truc, avec algos détaillées, techniques, exemples, code... Le truc
encyclopédique; du buffer overrun au virus métamorphique avec code recompilé
en mémoire. Le pavé exhaustif quoi. Ben personne n'en a voulu. Alors, les
vendeurs d'huile de serpent ont encore de beaux jours devant eux...
Dommage, cela aurait été certainement très intéressant.
Il n'y a pas des sites où ils donneraient quelques idées de base?
Pour la petite histoire, ces dernières années j'ai proposé à des éditeurs d'écrire une sorte d'encyclopédie du hacking sous Windows, non, pas un truc de boutonneux hein, LE truc, avec algos détaillées, techniques, exemples, code... Le truc encyclopédique; du buffer overrun au virus métamorphique avec code recompilé en mémoire. Le pavé exhaustif quoi. Ben personne n'en a voulu. Alors, les vendeurs d'huile de serpent ont encore de beaux jours devant eux...
Dommage, cela aurait été certainement très intéressant. Il n'y a pas des sites où ils donneraient quelques idées de base?
Moi, en ressource, je n'ai que la triple icône associé à l'application et des bitmaps (chiffrés) dont je tire des listes d'images, d'icônes. etc. Tout le reste c'est auto-généré comme dirait PB. C'est sûr qu'à coup de copie d'écran un gars peu piquer les icônes, tout ça, mais bon, l'essentiel et qu'il ne puisse rien extraire de l'exe, sinon à grand coup de nuits blanches.
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Moi, en ressource, je n'ai que la triple icône associé à l'application
et des bitmaps (chiffrés) dont je tire des listes d'images, d'icônes.
etc. Tout le reste c'est auto-généré comme dirait PB. C'est sûr qu'à
coup de copie d'écran un gars peu piquer les icônes, tout ça, mais
bon, l'essentiel et qu'il ne puisse rien extraire de l'exe, sinon à
grand coup de nuits blanches.
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va
pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Moi, en ressource, je n'ai que la triple icône associé à l'application et des bitmaps (chiffrés) dont je tire des listes d'images, d'icônes. etc. Tout le reste c'est auto-généré comme dirait PB. C'est sûr qu'à coup de copie d'écran un gars peu piquer les icônes, tout ça, mais bon, l'essentiel et qu'il ne puisse rien extraire de l'exe, sinon à grand coup de nuits blanches.
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Arnold McDonald \(AMcD\)
Thierry wrote:
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Ter-repetita. Si ta's 250 icônes, 100 curseurs, 1.500 bitmaps, 250 listes d'images et 12.000 chaînes de caractères, il est pas arrivé le gars à coups de copie d'écran...
C'est un concours de "je fais tout ce qui est en mon possible pour pas comrpendre", c'est pas possible...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Thierry wrote:
Ben le but c'est de copier et si le mec peut faire une copie d'ecran
il va pas se faire chier a extraire de l'exe. J'ai du mal a
comprendre l'interet.
Ter-repetita. Si ta's 250 icônes, 100 curseurs, 1.500 bitmaps, 250 listes
d'images et 12.000 chaînes de caractères, il est pas arrivé le gars à coups
de copie d'écran...
C'est un concours de "je fais tout ce qui est en mon possible pour pas
comrpendre", c'est pas possible...
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Ter-repetita. Si ta's 250 icônes, 100 curseurs, 1.500 bitmaps, 250 listes d'images et 12.000 chaînes de caractères, il est pas arrivé le gars à coups de copie d'écran...
C'est un concours de "je fais tout ce qui est en mon possible pour pas comrpendre", c'est pas possible...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Arnold McDonald \(AMcD\)
JM wrote:
Il n'y a pas des sites où ils donneraient quelques idées de base?
Tu cherches quoi exactement ?
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
JM wrote:
Il n'y a pas des sites où ils donneraient quelques idées de base?
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Ter-repetita. Si ta's 250 icônes, 100 curseurs, 1.500 bitmaps, 250 listes d'images et 12.000 chaînes de caractères, il est pas arrivé le gars à coups de copie d'écran...
Si un éditeur a les moyens de faire un prog qui a besoin de tout cela il aura les moyens de se payer un graphiste.
Et j'ai jamais vu de progs avec autant de ressources.
Et pour les chaines de caracteres l'interet est tres limité : quasiment impossible de reutiliser exactement les même chaines (trop dependant du programme et du contexte).
Bref, a part la beauté de l'art, l'interet de l'obfuscation de resource me parait très limité.
C'est un concours de "je fais tout ce qui est en mon possible pour pas comrpendre", c'est pas possible...
Ben le but c'est de copier et si le mec peut faire une copie d'ecran
il va pas se faire chier a extraire de l'exe. J'ai du mal a
comprendre l'interet.
Ter-repetita. Si ta's 250 icônes, 100 curseurs, 1.500 bitmaps, 250
listes d'images et 12.000 chaînes de caractères, il est pas arrivé le
gars à coups de copie d'écran...
Si un éditeur a les moyens de faire un prog qui a besoin de tout cela il
aura les moyens de se payer un graphiste.
Et j'ai jamais vu de progs avec autant de ressources.
Et pour les chaines de caracteres l'interet est tres limité : quasiment
impossible de reutiliser exactement les même chaines (trop dependant du
programme et du contexte).
Bref, a part la beauté de l'art, l'interet de l'obfuscation de resource
me parait très limité.
C'est un concours de "je fais tout ce qui est en mon possible pour pas
comrpendre", c'est pas possible...
Ben le but c'est de copier et si le mec peut faire une copie d'ecran il va pas se faire chier a extraire de l'exe. J'ai du mal a comprendre l'interet.
Ter-repetita. Si ta's 250 icônes, 100 curseurs, 1.500 bitmaps, 250 listes d'images et 12.000 chaînes de caractères, il est pas arrivé le gars à coups de copie d'écran...
Si un éditeur a les moyens de faire un prog qui a besoin de tout cela il aura les moyens de se payer un graphiste.
Et j'ai jamais vu de progs avec autant de ressources.
Et pour les chaines de caracteres l'interet est tres limité : quasiment impossible de reutiliser exactement les même chaines (trop dependant du programme et du contexte).
Bref, a part la beauté de l'art, l'interet de l'obfuscation de resource me parait très limité.
C'est un concours de "je fais tout ce qui est en mon possible pour pas comrpendre", c'est pas possible...
J'ai pas que ça a foutre de tout lire...
JM
Arnold McDonald (AMcD) a écrit :
Tu cherches quoi exactement ?
Quelques principes de bases sur les protections, même bateau. Histoire de pas mourir idiot et, si besoin est, d'avoir une base si un jour je veux faire une protection pourrie.
Arnold McDonald (AMcD) a écrit :
Tu cherches quoi exactement ?
Quelques principes de bases sur les protections, même bateau.
Histoire de pas mourir idiot et, si besoin est, d'avoir une base si un
jour je veux faire une protection pourrie.
Quelques principes de bases sur les protections, même bateau. Histoire de pas mourir idiot et, si besoin est, d'avoir une base si un jour je veux faire une protection pourrie.
Arnold McDonald \(AMcD\)
Thierry wrote:
Si un éditeur a les moyens de faire un prog qui a besoin de tout cela il aura les moyens de se payer un graphiste.
D'où l'interêt de protéger, les graphistes sont pas donnés !
Et j'ai jamais vu de progs avec autant de ressources.
Moi j'en vois beaucoup. Des softs avec des milliers de ressources t'en as des tas. Ya pas que le démineur dans la vie...
Et pour les chaines de caracteres l'interet est tres limité : quasiment impossible de reutiliser exactement les même chaines (trop dependant du programme et du contexte).
Pourquoi limité ? Quelqu'un qui veut localiser ton appli, récupérer les chaînes pour deviner les fonctionnalités, activer des options dsactivées, etc.
Bref, a part la beauté de l'art, l'interet de l'obfuscation de resource me parait très limité.
C'est à réserver à des cas précis. Et encore une fois, on fait pas de l'obfuscation de ressource, mais de code ! Les ressources, on les chiffre...
J'ai pas que ça a foutre de tout lire...
On t'oblige pas non plus à participer au débat.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Thierry wrote:
Si un éditeur a les moyens de faire un prog qui a besoin de tout cela
il aura les moyens de se payer un graphiste.
D'où l'interêt de protéger, les graphistes sont pas donnés !
Et j'ai jamais vu de progs avec autant de ressources.
Moi j'en vois beaucoup. Des softs avec des milliers de ressources t'en as
des tas. Ya pas que le démineur dans la vie...
Et pour les chaines de caracteres l'interet est tres limité :
quasiment impossible de reutiliser exactement les même chaines (trop
dependant du programme et du contexte).
Pourquoi limité ? Quelqu'un qui veut localiser ton appli, récupérer les
chaînes pour deviner les fonctionnalités, activer des options dsactivées,
etc.
Bref, a part la beauté de l'art, l'interet de l'obfuscation de
resource me parait très limité.
C'est à réserver à des cas précis. Et encore une fois, on fait pas de
l'obfuscation de ressource, mais de code ! Les ressources, on les chiffre...
Si un éditeur a les moyens de faire un prog qui a besoin de tout cela il aura les moyens de se payer un graphiste.
D'où l'interêt de protéger, les graphistes sont pas donnés !
Et j'ai jamais vu de progs avec autant de ressources.
Moi j'en vois beaucoup. Des softs avec des milliers de ressources t'en as des tas. Ya pas que le démineur dans la vie...
Et pour les chaines de caracteres l'interet est tres limité : quasiment impossible de reutiliser exactement les même chaines (trop dependant du programme et du contexte).
Pourquoi limité ? Quelqu'un qui veut localiser ton appli, récupérer les chaînes pour deviner les fonctionnalités, activer des options dsactivées, etc.
Bref, a part la beauté de l'art, l'interet de l'obfuscation de resource me parait très limité.
C'est à réserver à des cas précis. Et encore une fois, on fait pas de l'obfuscation de ressource, mais de code ! Les ressources, on les chiffre...
