Jump to content
Equimania

Protection D'une Application

Recommended Posts

Bonsoir à tous,

Je suppose que le sujet à été maintes fois traité, bien que comme tout un chacun de nous n'avons eu une réponse efficiente et concrète.

Le programmeur étant, je suis sûr l'être protégeant le mieux ses solutions (malheureusement)! Espérant, comme tout un chacun en tirer un profit quelconque.

Je propose ici de traiter et de proposer des solutions concrètes ou du moins d'indiquer des axes d'application à une question que tout développeurs débutants ou autres se posent lorsque leur application est en passe de ce terminer. "Comment protéger au mieux cette foutue application que nous aimerions distribuer, et éviter ainsi de ce la faire piquer"

J'ai l'espoir que ce forum, est comme il semble et devrait l'être! Un forum d'entraide et non pas un lieux de promotion, ou l'étalage des connaissances se faisant à petites couches, laissant transparaître les possibilités sans réellement donner de solutions applicables, afin de ne pas en dévoiler de trop, et de s'en garder la primauté et aussi l'intérêt que la solution pourrait éventuellement rapporter !

Je crois que nous en sommes tous et toutes au même points et je sais que la conjoncture actuelle n'aide pas, mais ne serait-il pas possible de mettre les connaissances en commun afin d'arriver à un 'modus operandi' expliquant point par point comment arriver à un résultat efficace et rassurant du moins dans ce cas? Je sais également qu'en donnant des pistes, plutôt qu'en donnant des solutions poussent le débutant à explorer et à en apprendre plus! Mais ne pourrions nous également prévoir au sein de ce forum un topic proposant des solutions concrètes et applicables, dont celui-ci?

Share this post


Link to post
Share on other sites

Sur le plan de la sécurité, j'ai deux "quasi" certitudes :

  1. Un fichier qui a été "bindé" en solution autonome et dont on a retiré les comptes avec le jeu de privilèges [Accès intégral], ne peut pas récupérer de compte avec un tels privilèges, quelque soit l'outil de crack utilisé. J'aimerais bien au passage que des utilisateurs de ce types d'outils me le confirme.
  2. Un fichier hébergé sur un serveur inaccessible est un fichier "consultable" mais non crackable puisqu'on ne peut pas possèder le fichier - CQFD.

En conclusion :

  1. Utiliser FileMaker Pro 11 Advanced pour créer une solution autonome et retirer les comptes "admin".
  2. Utiliser les services d'un hébergeur sécurisé (pléonasme).

:ninja:

Share this post


Link to post
Share on other sites

Je trouve ta démarche un peu paradoxale Equimania :blink:

Je m'explique :

D'un côté tu souhaiterais (et moi le premier) que la communauté FMP partage ses connaissances avec le même état d'esprit que celui qui règne dans le monde de l'open source et du logiciel libre, d'un autre côté tu cherches à protéger ta propre réalisation pour éviter les piratages, la rendant de fait inaccessible à ceux qui voudraient en apprendre un peu de ton propre travail.

FileMaker Pro n'est pas un logiciel open source, c'est bien un outil commercial que les développeurs professionnels qui s'en servent doivent rentabiliser dans le cadre de leur activité, et c'est tout-à-fait normal.

Cette logique commerciale fait que chacun tente de perfectionner sa propre expertise et qu'il est parfois difficile de leur demander de la partager sans aucune forme de contrepartie, c'est dommage pour nous les débutants, mais c'est un peu la règle du jeu.

Je pense tout-de-même que des nombreux pro, sur ce site du moins, ne sont pas avares dans le partage de leur savoir-faire, évidemment, chacun a sûrement quelques secrets de fabrication qui souhaite garder et protéger, mais dans l'ensemble je trouve qu'ils jouent bien le jeu de l'échange ici.

Après, comme toi, je suis parfois un peu frustré de ne pas trouver de solutions et des exemples plus complets et aboutis en accès libre, mais je pense que la dimension commerciale du produit induit un peu cet état de faits.

Bon, sinon, pour les questions relatives à la sécurité, je ne suis pas assez calé pour te donner mon avis, les pistes évoqués par Olivier me semblent très intéressantes pour ma part.

@+ ;)

Share this post


Link to post
Share on other sites

Il est vrai que ma démarche peut sembler paradoxale au yeux de la communauté FMP, et j'aimerais clarifier celle-ci.

Je n'ai rien contre le fait de partager mes (petites connaissances) avec mes "pairs" qui nous cassons le c.. pour arriver à quelque choses.

Et je REMERCIE les membres de ce forum sans qui j'aurais ramé de longues années sans l'aide qu'ils m'ont fournis !

Mais je ne suis pas d'accord que le résultat de mon travail puisse être copié et distribué sans mon consentement et je tiens donc à rendre la chose difficile, sinon impossible, ce qui je crois est notre cas à tous.

FMP permet de créer des solutions autonomes et c'est extra, les privilèges permettent de gérer et de protéger l'accès à l'application... d'accord.

Mais rien n'empêche le client de fourguer la solution complète avec ses pwd. Et c'est ce point que j'aimerais que nous discutions, comment rendre le produit 'in-copiable'.

Share this post


Link to post
Share on other sites

La question est très pertinente, et revêt une nouvelle importance avec FIleMaker Go, très propice à la distribution de solutions clefs en main.

Malheureusement, FileMaker ne propose pas de solution intégrée. Toute personne qui aura un accès intégral au fichier, même s'il est passé par un crack, pourra décrypter ta solution de verrouillage. A ce propos, c'est un fait méconnu que la suppression du compte Admin n'est pas réservé aux runtimes.

Dès lors, il est pratiquement impossible de dévoiler ce genre de secrets de fabrication, car à défaut de pouvoir verrouiller complètement une solution, il est possible de rendre très difficile les contournements, mais encore une fois, celui qui aura accès aux "sources" pourra toujours, moyennant une somme de travail qu'on essaiera de rendre disproportionnée, contourner les protections.

Quelques pistes tout de même :

- la vérification peut se faire dans un fichier hébergé. Par exemple un utilisateur doit se connecter tous les x jours au moins, et on lui redonne un crédit de x jours.

- on peut noter les adresses NIC, afin de repérer des utilisations anormales d'une même licence sur des postes différents.

Mais quoiqu'il arrive, si la personne arrive à contourner le script côté client qui demande cette vérification, c'est mort.

Share this post


Link to post
Share on other sites

Salut Equimania :)

Au fait, je crois hélas que la solution parfaite n'existe pas -_-

Tous les plus importants éditeurs de logiciels se sont penché sur cette question, il en résulte, à ce jour, que l'équilibre entre protection absolue et respect des clients est très difficile à trouver.

Certains éditeurs ont essayé des procédures assez fiables mais finalement très contraignantes pour les "vrais" clients, qui devaient respecter un certain nombre de procédures pour pouvoir utiliser "tranquillement" leur logiciel, le plus souvent chèrement acquis.

Certains clients se sont même vu passer des heures au téléphone, avec les services techniques de tel ou tel éditeur, pour réinstaller et activer en toute légalité leur logiciel dans un autre poste que celui qui venait de rendre l'âme :wacko:

La question que nous devrions nous poser serait :

Jusqu'au où peut-on embêter un client avec des systèmes de protection sans risquer de le faire fuir ? :blink:

La plupart des éditeurs ont tranché : il vaut mieux avoir des clients satisfaits du produit et de leur expérience utilisateur, et tant pis s'il y a quelques copies "illégales" dans la nature, qu'avoir un logiciel inviolable mais que personne n'achète car trop contraignant à utiliser.

Gagner des clients et les fidéliser semble commercialement plus important pour eux (et ça se comprend) que de trouver la parade imparable à toute tentative de piratage.

Les vraies réponses peuvent sûrement venir d'une sensibilisation (éducation) des utilisateurs et, peut-être aussi, d'une implication des pouvoirs publics en concertation avec tous les pays, sans solution politique globale, les actions locales ne donneront finalement pas grand résultat (Hadopi par exemple).

Bref, le piratage a encore des beaux jours devant lui et les protections les plus sûres n'y pourront hélas pas grand chose si elles dissuadent même (surtout) les potentiels clients.

Ceci dit, je suis d'accord qu'il faille continuer à s'interroger sur les moyens de limiter ces pratiques, en cherchant et expérimentant toutes les solutions qui pourraient garantir protection du produit et respect du client, mais la tâche s'avère assez ardue tout-de-même... je le crains.

Enfin, c'est mon point de vue en tout cas...

@+ :)

Share this post


Link to post
Share on other sites

2 exemples qui peuvent aussi faire réfléchir :

  1. Apple a abandonné les numéros de licence sur sa suite iWork (bien qu'ils vendent encore le CD d'installation)
  2. FileMaker a abandonné l'activation en ligne de la version 9 à l'arrivée de la version 10

Share this post


Link to post
Share on other sites

J'en rajoute une (grosse) couche :P

Sans chercher (ni pouvoir plutôt) être exhaustif, voici un petit résumé des techniques utilisées (pour les logiciels en général, pas particulièrement concernant les solutions Fmp) :

  • Numéro de série
    C'est la technique la plus ancienne. Elle était assez fiable à l'époque où on vendait des logiciels en boîtes dans les boutiques, mais aujourd'hui avec leur diffusion sur le Web, la protection par numéro de série est devenue très facile à contourner (surtout pour les logiciels commerciaux de renom).
    De plus, cette protection n'empêche nullement d'installer autant de copies qu'on le souhaite avec le même numéro ainsi que la diffusion privée (et parfois même commerciale comme on peut la trouver dans certains pays).
  • Enregistrement
    Ceci ne fait pas vraiment partie des protections à proprement parler, mais les éditeurs ont rapidement compris tout l'intérêt, et pas de sécurité uniquement, d'encourager les clients (et parfois de les contraindre même) à enregistrer leur licence. Cette pratique existe toujours, mais elle est de moins en moins suivie car cet enregistrement n'a jamais généré un quelconque bénéfice ou avantage pour le client, autre peut-être qu'une soit disant assistance technique (souvent très limitée et surtout très lente, notamment chez les éditeurs qui proposent des assistances payantes par ailleurs).
  • Identification ordinateur
    Cette technique consiste à enregistrer, lors de l'installation du logiciel, ou lors de son tout premier lancement, un identifiant unique de l'ordinateur avec, le plus souvent, la fameuse "adresse MAC". Mais ce système a très vite montré ses limites : changement de poste, remplacement de la carte mère, nouveau matériel, utilisation nomade compliquée (quand ce n'était tout simplement impossible), etc. Aujourd'hui cette technique est quasi abandonnée, seuls quelques rares logiciels s'en servent encore (notamment dans certaines applications serveur).
  • Vérification online
    Impossible au début de l'informatique et même de l'internet, aujourd'hui, avec la démocratisation des connexions haut débit, elle est devenue presque courante, la plupart des grands éditeurs ont des systèmes de vérification en ligne des numéros de licences. Le principe est relativement simple, lorsqu'on lance un logiciel, celui-ci envoi à un serveur privé (géré par l'éditeur) un certain nombre d'informations (version, numéro de série, configuration système, etc.), qui sont stockés et analysés par les éditeurs.
    C'est une technique relativement efficace pour peu que la connexion internet de l'utilisateur soit active.
  • Activation online
    C'est un peu la suite logique des deux techniques précédentes, au lieux seulement d'enregistrer un "achat" ou de récupérer des informations, l'utilisateur est obligé d'activer sa licence sur internet tout en fournissant un certain nombre d'infos. Il s'agit, disons-le, de l'une des techniques les plus intéressantes pour l'éditeur (enregistrement et activation en une seule opération pour un coût très faible), mais pas forcément très agréable pour le client, au point que, comme l'a rappelé Olivier, certains éditeurs l'abandonnent tout simplement.
  • Support physique
    Cette technique a surtout été utilisée par les éditeurs de jeux. Elle consiste (ou consistait plutôt, tellement elle commence à être abandonnée à son tour) à obliger l'utilisateur à introduire le support physique (Cd-rom ou Dvd-rom de nos jours) pour que le programme puisse se lancer et fonctionner. Cette protection pouvait parfois être simplement contournée en créant un disque virtuel du support, mais en général elle s'avérait assez efficace. Sauf que, les lecteurs tombant en panne, les ordinateurs vendus sans lecteur, la faible durée de vie de certains supports, etc., ont conduit les éditeurs à revoir l'utilisation systématique de cette technique qui, à mon avis, sera purement et simplement abandonnée à l'avenir.
  • Clé physique
    C'est sûrement la technique la plus efficace de toutes. Il s'agit de vendre une licence qui ne peut s'utiliser qu'en présence d'une clé physique extérieure (clé Usb aujourd'hui en général). Mais c'est certainement une de plus contraignantes aussi pour le client. On ne compte plus les longs appels à des services clients parfois impuissants face à une perte, destruction ou vol de la clé physique, sans parler des énervements causés chez les clients par des simples oublis. Bref, très sûr mais aussi très chiant.

Évidemment, il y a des éditeurs qui ont multiplié et combiné certaines de ces techniques, mais le fait est qu'ils n'ont jamais pu contrôler totalement le piratage, même avec les systèmes le plus fiables, sans causer des désagréments, parfois rédhibitoires, auprès de leur clientèle.

Bien-sûr, il y a sûrement bien d'autres techniques, sans compter toutes les nouvelles idées à venir, mais une chose semble claire à ce stade, aucun de ces systèmes n'a donné à ce jour entière satisfaction, que ce soit côté éditeur et/ou côté client.

Après, rien n'interdit de s'interroger sur la manière de protéger ses propres réalisations, c'est même une préoccupation plutôt légitime et compréhensible, mais peut-être qu'il faut voir les choses sur un autre angle, et se dire que finalement le piratage n'est que la rançon du succès... plus un logiciel est vendu et, fatalement, plus il sera piraté (et vice-versa).

@+ :)

PS. Comme je ne maîtrise absolument pas tous les aspects de la protection des logiciels, excusez-moi d'avance si certains de mes propos sont trop approximatifs ou même carrément erronés, l'idée était juste de montrer, sans vouloir en faire une quelconque démonstration, à quel point la problématique de la protection des logiciels était complexe et que, à l'heure actuelle, il n'y a pas de solution 100 % efficace et satisfaisant pour tous et pour tous les cas de figure.

Share this post


Link to post
Share on other sites

Non je pense pas que c'est possible de l'adapter pour FMP, essaye KeyCodeMaker mais je sais pas s'ils ont une version pour >= 7, c'etais pour FM6 sinon il y a aussi USB Sentry plug-in (la securite avec une cle usb)ou 24U SimpleHASP plug-in. Mais avec les comptes utilisateurs, les jeux de privilèges, les privilèges étendus et les nouvelles fonctions de gestion de la sécurité (Obtenir(NomCompte), Obtenir(NomPrivileges), Obtenir(PrivilegesEtendus), Obtenir(AdresseNICSysteme) et Obtenir(AdresseIPSysteme)) il y a pas mal de possibilite pour securiser ou non!

Share this post


Link to post
Share on other sites

Les logiciels surprotégés sont morts, ou leurs éditeurs ont décidé d'abandonner toute protection.

Je me souviens de l'époque ou je devais insérer la disquette de Xpress à chaque fois que je lançais le logiciel, c.a.d au moins 10 fois par jour.

Adobe a connu un développement mondial en ne protégeant ni ses logiciels ni ses fontes. Seul le postscript était vendu sous licence aux fabricants d'imprimantes.

Pour les "solutions filemaker", plus qu'un logiciel, c'est un ensemble : hardware, connectique, développement (avec ou sans plugin), installation, documentation, formation, maintenance et bien sûr évolution... une solution qui engage toute la gestion d'exploitation, donc la survie d'une entreprise. On envisage mal comment on pourrait pirater ça sans prendre d'énormes risques.

Si l'on ajoute la publication web (une base de données qui alimente et interagit avec un site web), ça devient tout à fait impossible à pirater.

En tant qu'acheteur de développement, je mets systématiquement à la poubelle tous les devis qui ne me garantissent pas un accès aux sources (Flash, Java, et tous les développements encapsulés). Et je cède systématiquement à mes client la co-propriété des sources, je n'ai jamais eu à le regretter.

Avec Filemaker, on fait pour un seul client la plupart du temps, des solutions personnalisées qui ne conviennent qu'à lui. Alors pourquoi perdre du temps à protéger le bazar ?

Pour ma part je me contente de préciser dans ma documentation que toute modification des sources entraine l'annulation de la maintenance.

Il faut se réveiller, l'open source a complètement changé la donne.

Share this post


Link to post
Share on other sites

Avec Filemaker, on fait pour un seul client la plupart du temps, des solutions personnalisées qui ne conviennent qu'à lui. Alors pourquoi perdre du temps à protéger le bazar ?

Ne confonds-tu pas la cause et la conséquence ?

Si FileMaker permettait ce genre de protections, ainsi que des systèmes de mise à jour décents, on verrait peut être ça d'un autre œil.

Share this post


Link to post
Share on other sites

Bonjour,

La reflexion de Tarik me concerne. Les applications que je développe sont auto protégées par leur personnalisation. Je dirai même plus, ça en devient un problème pour moi !

Revendre la même application à une autre société qui a exactement la même activité est un leurre: les besoins sont différents et il faut à nouveau tout reprendre. très gros boulot en perspective !!!

Le vrai savoir-faire ne réside pas dans les scripts ou les calculs d'une application mais dans la connaissance métier que l'on a acquis auprès du client.

Alors, quant à le pirater... il faut déjà avoir une connaissance qui maîtrise FMP et qui accepte d'y passer du temps et tout lui reexpliquer. Bon courage...

De toute façon, j'utilise le mot de passe administrateur plus comme sécurité d'usage, éviter que l'utilisateur lambda se ballade dans les menus natif de FMP que comme verrouillage. Le client connait le compte et le mot de passe et si je disparais du circuit ou si on s'engueule trop, il pourra toujours confier la suite à un autre.

Pour les vraies protections, les solutions d'Olivier me semblent être les plus pertinentes.

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...