Version imprimable
Entièrement plussoyer ! Si c'est pour du "long terme", ça sert vraiment à rien >< ! C'est dans le JV qu'on trouve le plus de protection "grand public", et là, tous les indus te diront que ce sont des protections courtes... Qui en plus te font généralement mauvaise presse...Citation:
Envoyé par Mac LAK
Citation:
Envoyé par Mac LAK
Je suis d'accord avec vous, mais je vois mal dtcSearch dire au commercial ou au client "C'est pas possible".Citation:
Envoyé par Lavock
La solution idéale n'existe pas, mais il doit bien y avoir un compromis.
Si le demande du client final est vague, une simple protection UPX devrait lui suffire, si les détails de la protection sont donnés (chiffrés) c'est qu'il doit avoir une idée derrière la tête, mais je pencherai plutôt pour la première solution.
La solution idéale c'est comme l'a dit mac_lak d'avoir des cpu qui intégrent des technologies qui permettent de mettre en oeuvre ce genre de sécurité. (instruction chiffré etc). C'est le cas de l'architecture de la PS3 il me semble. Tout est codé...
S'il est CP, c'est pourtant bien son problème de le dire au client... S'il n'est que le pauvre dév à qui l'on a balancé la patate chaude, alors il y a quelqu'un de mieux payé que lui dont c'est le boulot... Au pire, tu renvoie le responsable initial, c'est à dire celui qui a dit "oui, on va le faire".Citation:
Envoyé par mabu
Au moins, l'OP a les billes pour pouvoir dire pourquoi ce n'est pas possible. Le reste, c'est l'affaire du client qui devra expliciter son besoin réel, et du CP qui négociera une dérogation.
Ceci étant dit, vu les sommes qui seront englouties par une protection un minimum décente, je n'ai pas beaucoup de doutes sur le fait que le client se contentera d'un exécutable strippé... :twisted:
Ce n'est d'ailleurs pas neuf : l'architecture [ame="http://fr.wikipedia.org/wiki/CPS2"]CPS2[/ame] fonctionnait également ainsi. La protection a tenu le coup pendant sept ans, avant d'être complètement déplombée... Tout ça parce qu'il y avait un accès physique aux machines, bien sûr.Citation:
Envoyé par Goten
Le problème, c'est que ce sont systématiquement des fabrications spécifiques (on ne peut pas acheter de processeur codé dans le commerce). Et étant donné que la fiabilité de la protection réside dans le fait de ne PAS expliquer l'algo de codage, il est évident qu'en fabriquer un soi-même impose de repartir de zéro ou peu s'en faut.
On peut en partie utiliser des CPU codés virtuels implantés sur des ASIC/FPGA, mais c'est pas très reluisant côté perfs par rapport à un processeur "fondu"... Et l'accès par JTAG n'aide pas à rendre le machin inviolable, en plus.
C'est marrant que certains croient encore au secret du code comme assurance de sécurité. Le principe Kerckhoffs existe depuis les années 1880 et pourtant, il y en a encore qui n'ont pas tilté.Citation:
Envoyé par Mac LAK
mabu > Je ne vois pas pourquoi ce serait à dtcsearch de supporter les conneries du commercial. Qui plus est, si tu ne remet jamais le commercial en face de ses anneries, il continuera à te vendre n'importe quoi et faudra assurer des truc impossible derrière.
Il a vendu un truc impossible, faut assumer maintenant.
Et si jamais c'est dtcsearch qui se pose cette contrainte lui-même, bah faut assumer quand on fait des conneries.
Dans un monde logique, je suis d'accord.Citation:
Envoyé par deadalnix
Mais imagine qu'un un commercial ai lu magazine parlant de ça sans le comprendre ou qu'il soit très haut placé dans la boite... (oui c'est du vécu).
En réponse au post initial, tu peux effectivement regarder du coté des "packers" genre Armadillo ou autre....
Ces packers permettent de crypter l'exécutable, protéger le fichier avec un checksum (entre autre) il est ensuite décrypté lors de l'exécution (en mémoire).
Il faut cependant savoir que comme dit plus haut, il est toujours possible de l'exécuter avec un debugger (genre ollydbg) et la on voit tout le code assembleur (donc le décryptage... jusqu'à l'exécution du programme réel). Le principal intérêt étant finalement de protéger le code orignal de toutes modifications (pour faire des cracks par exemple).
Cependant même avec ce genre de protection, toujours avec ollydbg par exemple, un mec avec un peu de cerveau peu arriver à trouver le point d'entré du programme réel et donc du coup faire un dump et arriver a reconstruire le fichier exécutable non crypté et du coup facilement modifiable.... on trouve même des outils tout prêt pour faire ce genre de choses...
En expérant avoir un peu éclairé ta lanterne :)
Perso je le fais. Je t'avoue que ça ne s'est pas toujours bien passé, mais je préfère encore ça.Citation:
Envoyé par mabu
Je vous remercie tous, je pense que la demande du client sera tout simplement refusé pour non faisabilité.
J'en ai appris pas mal sur le sujet grâce à vous, je laisse le sujet ouvert au cas où ;)
merci
Heu... Ai-je dit le contraire ?? Bien entendu que ce n'est pas une assurance de sécurité, c'est simplement un facteur de ralentissement avant désassemblage et reverse. Je l'ai dit, sans matériel de support non dumpable, c'est impossible à effectuer. Pour citer ce principe, c'est un des (très rares) moyens de sévèrement ralentir la connaissance du système, de préférence bien au delà de la limite de validité des données protégées. Jusqu'à l'arrivée des système quantiques, on n'a pas mieux en stock à proposer.Citation:
Envoyé par deadalnix
La seule chose qu'une protection "soft" peut permettre, c'est d'exploser l'utilité du reverse : sur un programme spécifique, dont les sources ne sont pas disponibles, plomber l'exécutable permet de rendre plus coûteux le fait de le cracker que de l'acheter... A condition que le prix de la licence soit bien sûr adapté au niveau de la protection, et que la protection soit adaptée aux enjeux liés au programme (financiers, politiques, voire militaires). Il est évident que c'est très difficile à équilibrer correctement, comme équation...
A noter que ceci n'est plus vrai dès qu'il y a diffusion de masse : le nombre de cracks / hacks disponibles pour les jeux et autres programmes vastement diffusés en est la preuve la plus flagrante.
Bien sur que non, c'était pour plussoyer dans ton sens.Citation:
Envoyé par Mac LAK
OK, je me disais aussi... ;)Citation:
Envoyé par deadalnix