En tant que Freelance, vous développez des applications flash pour des clients : SSII, PME, TPE. Dans la majorité des cas, vous êtes payés après avoir développé le produit fini.
Problème
Il arrive (très rarement heureusement) qu’un de vos client décide de ne pas vous payer pour le travail rendu. Il utilise pour cela des prétextes plus ou moins crédibles…
Pour éviter de ce genre de problème, j’utilise une astuce toute simple à mettre en place avec Flash ActionScript 1, 2 ou 3 ou haXe également.
Protection du swf
Il suffit de fournir comme convenu l’application terminée et entièrement fonctionnelle à votre client. Mais vous ne lui livrez le code source uniquement après le paiement.
Et vous protégez votre code de la façon suivante :
- Sur la 1ère frame, vous testez si l’application est autorisée ou non à se lancer. Si oui, elle fonctionne correctement, si non elle affiche un message à votre convenance (par exemple : problème d’utilisation de la licence non valide…).
var bAutorize:Boolean = Protect.isAllow(2009, 5, 17); if(bAutorize) { // votre code d'exécution de l'application } else { // afficher un texte expliquant la situation et bloquer l'application // var sTxt : String = "Problème sur la licence d'utilisation!"; }
Dans la classe de gestion de l’autorisation de lancement de l’application, vous fixez une date limite au delà de laquelle l’application flash se bloque. C’est à dire, jusqu’au 17 mai 2009, l’application flash fonctionne correctement. Puis après cette date, elle se bloque en affichant votre message d’erreur.
Si votre client ne vous paye pas, il va être bien ennuyé avec une application flash qui ne fonctionne pas et qui lui affiche de surcroit un problème de paiement de licence.
Le client n’a aucune possibilité de faire fonctionner l’application s’il ne possède pas le code source!
La seule solution pour que le flash s’affiche est que l’internaute modifie la date de son ordinateur en la reculant de quelques années. Mission irréaliste dans le cas d’une agence web…
Avec cette astuce, je peux vous assurer que vous serez payé à chaque livraison et en cas de retard de paiement, j’espère que dans votre contrat, vous avez prévu des pénalités que vous n’aurez aucun mal à réclamer à votre client vu l’urgence de la situation.
Code source AS3
Et voici le code source de la classe AS3 que j’utilise régulièrement :
package com.utils { /** * Use to protect your application with a limit date for usage. * * @usage : var bAutorize:Boolean = Protect.isAllow(2008, 9, 21); * * * @class Protect * @author Matthieu * @version 0.1 */ public class Protect { /** * CONSTRUCTOR * @usage * @return */ public function Protect() {} /** * Stop execution of the application flash if date isn't correct. * * @see * @param * @return */ public static function isAllow(nYear:int, nMonth:int, nDay : int) : Boolean { var oDate:Date = new Date(); if(nYear < oDate.getFullYear()) return false; if(nMonth < (oDate.getMonth()+1) ) return false;// 0 pour janvier, 1 pour fevrier if(nDay < oDate.getDate() && nMonth==oDate.getMonth()+1) return false; return true; } /** * Returns the string representation of this instance. * @return the string representation of this instance */ public function toString() : String { return "[object Protect]"; } }// end of class }
Conclusion
Je trouve cette astuce simple à mettre en ouvre et très pratique.
Et vous comment protégez vous vos applications en tant que freelance ?
Attention : cette astuce n’empêche aucunement la décompilation de votre swf.
Articles sur le même sujet :
salut,
excellente initiative de mettre ce genre de code en ligne. de nombreux clients de payent pas ! ou barratine une fois le travail terminé.
néanmoins, pour le code as2, je n’arrive pas du tout à le mettre en place.
var bAutorize:Boolean = Protect.isAllow(2009, 5, 17);
if(bAutorize)
{
// votre code d’exécution de l’application
}
else
{
sTxt.text = “Expiration de la licence d’utilisation!”;
}
tel quel, dans la 1ere image de la timeline, c’est toujours expiré. pourrais tu m’aider a faire fonctionner tout ca? ou pourrais tu y joindre un fla?
merci.
f
Salut,
Voici le code source de la classe Protect pour la version AS2, le fonctionnement est identique à la version AS3.
Tu as juste à utiliser le code de l’exemple sur la 1ère image de la timeline dans un fla.
Vérifie si tu importes bien ta classe au moment de la compilation du fla.
Vérifie si l’heure de ton pc est correcte. Effectue un trace de la date (var oDate:Date = new Date();) pour vérifier ce que te renvoie flash.
class com.utils.Protect
{
/**
* CONSTRUCTOR
* @usage
* @return
*/
private function Protect()
{}
/**
*
*
* @see
* @param nYear : year limit
* @param nMonth : month limit
* @param nDay : day limit
* @return true if it’s good
*/
public static function isAllow(nYear:Number, nMonth:Number, nDay:Number):Boolean
{
var oDate:Date = new Date();
if(nYear > oDate.getFullYear()) return true;
if(nMonth < (oDate.getMonth()+1) ) return false;// 0 pour janvier, 1 pour février
if(nDay < oDate.getDate() && nMonth==oDate.getMonth()+1) return false;
return true;
}
/**
* Returns the string representation of this instance.
* @return the string representation of this instance
*/
public function toString() : String
{
return “[object Protect]“;
}
}
Bonjour ,
merci pour votre code très sympa mais pour question de décompilation du .swf il y a pas un astuce pour que quand ca décompile le fichier et illisible ????!! Ça serait bien ça!
Bonjour,
A ma connaissance, il n’existe pas de solution 100% fiable et optimisée pour empêcher la décompilation des swf.
Ensuite plus les projets sont développés avec une analyse poussée (séparation des éléments graphiques, audio, xml… dans des swf différents) plus il est difficile de tout décompiler pour récupérer le code source.
Il devient plus facile de développer l’application soit même.
Hey, Salut.
Je viens de tomber sur ton post avec retard et après tout c’est pas bête à la base comme astuce…
Malheureusement comme tu le dit Matthieu, avec ce tour de main, une agence malhonnête (et renseignée !) peut aisément décompiler ton code via sothink décompiler ou autre en moins de 50s. (Période de licence expirée ou non)… Et dans ce cas bye bye le paiement. Essaye ce maudit soft sur tes productions ! Tu vas voir il fait froid dans le dos. Il y a même une extension FF afin de “grabber” plus facilement les fichiers.
Bref : Aïe Aïe Aïe !!
La seule alternative presque sérieuse dans la protection des travaux swf reste l’obfuscation afin de rendre ton code plus délicat à déchiffrer et à suivre en cas de reverse engineering… Des softs sont même spécialisés en ce domaine, le leader est SecureSWF.
Dur dur d’être un honnête programmeur AS
++
Heu… lol ta parfaitement raison Julien c’est pour ça je suis déçus mais bon on pourra j’aimai protéger a 100% son code mais on peut crée des difficulté pour les gents qui de bosse pas!! et qui vole simplement…
Merci quand même lol!!! Pour ton lien je vais le voir et te dirais ca @++
Merci pour le code ! c’est un bon début de protection. Je me demandais si il était possible d’utiliser un systeme de clé, avec une authorisation sur un server distant. Vous avez deja vu quelque chose de similaire ?
Sinon si l’on ajoute un mot de passe au swf, un décompilateur peut-il tout de meme acceder au code ?
Bonjour Mika,
Pour le système de clé sur un serveur distant, je ne l’ai jamais mis en place. A étudier…
En utilisant une architecture de type Modèle Vue Controler avec de multiples swf qui se chargent au fur et à mesure, cela limite grandement les risques de décompilation de votre application flash.
Hello,
pas sur que ce type de blocage soit vraiment une bonne solution…
ca s’appelle se faire justice soit meme, ce qui n’est pas bien vu dans la loi francaise…
en effet, si une agence traine pour payer, mais distribue ton application; ses clients vont se retourner contre elle quand le message apparaitra, et l’agence se retourner alors contre toi, pretextant que tu n’as pas fourni une appli viable et conforme au cahier des charges. et qu’en plus tu as porté atteinte à son image aupres de ses cleints. elle dira aussi que elle n’a jamais refusé de te payer, mais qu’elle a juste demandé du temps (la crise patati patata…). et la c’est alors elle qui denoncera le contrat entre vous, avec une faute de ta part.
c’est un procédé classique, comme l’artisan qui va récupérer le portail qu’un client ne lui aurait pas payé. c’est clairement l’artisan qui est en tord. en france on ne se fait pas justice soit meme. si quelqu’un ne paie pas, ca se regle devant un juge, pas autrement…
bref attention a ce genre de fausse bonne idée…
En effet hb, ton message m’a fait réfléchir.
Et ce matin sous la douche naquit une idée.
Pourquoi ne pas servir le swf via un script php ?
Le php pourrai recuperer le swf sur une partie non accessible du server (fopen ?) et le servir dynamiquement dans la page.
Il est tres simple de sécuriser l’acces à une page php, pour empecher une requete indésirable au swf.
Qu’en pensez-vous ? Par contre le swf risqe de toujours se retrouver dans le cache navigateur, mais cela permettrait sans doute d’eviter un telechargement direct avec downloadhelper et consoeur.
Bonne idée ?
en fait il faut surtout se demander pourquoi on veut proteger une appli, de qui, quelles parties, etc…
si c’est pour cacher une partie de code, alors on veut la cacher a des gens capables de comprendre ce code, donc des informaticiens, donc des gens tout a fait capables de chercher le swf dans le cache, capable de décompiler etc.. donc contre eux le flash n’est pas sur, d’aucune facon. si il faut juste protéger une fonction, autant la faire dans une page php sur le serveur et l’appeler du flash. le code source sera invisible de l’exterieur.
si tu veux proteger du quidam, une simple offuscation du code peut suffir (en sachant que c n’est pas une “vraie” sécurité du coup).
Une solution “batarde” (dont tu vois toi meme deja une faille) me parait sans interet en fait. non ?