lARP64Pro: LE PROTECTEUR PROFESSIONNEL
Information générale
En cas de shareware ou besoin de protection, là, il y a lARP64Pro. Il est basé sur les mêmes principes que le compresseur mais en offrant tellement plus! C'est aussi bien un protecteur d'exécutables extrêmement fort comme un protecteur de DLL's extrêmement fort.
lARP64Pro
Pro est le système de protection pour x64 le plus puissant connu aujourd'hui mais il a été conçu pour être très facile à appliquer. Ses dispositifs de protection forts protégeront votre application contre les modifications non autorisées comme le cracking. Essayez-le et vous serez convaincu!
Notre protecteur est si fort qu'il assurera la protection totale pour votre propre système de licences. Donc, continuez simplement avec votre propre arrangement d'enregistrement. Ainsi, lARP64Pro défendra votre code sensible par son système protecteur multiple basé sur la technologie lARP64.
Limitations
Des versions illimitées en leur fonction de lARP64Pro sont disponibles pour le téléchargement. Le protecteur professionnel a été équipé de possibilités d'évaluation sans péremption. Rendez-vous compte que lARP64Pro est bien meilleur adapté si la sécurité du programme est exigé.
Les dossiers comprimés avec la version pro fonctionnent exactement comme avant. Ceci également rend vos programmes et bibliothèques plus petits et diminue le temps de téléchargement.
A part de la compression et du cryptage, lARP64Pro introduit tant de différentes défenses dans le programme protégé qu'il est très peu probable qu'un cracker réussira jamais en son but.
Fonctionnement
lARP64'ing n'affecte pas l'application original et n'exige pas de codage additionnel. Le déballage et le décryptage sont effectués automatiquement. Ce processus entier n'est pas noté par l'application emballée ou protégée. En outre, les programmes emballés ou protégés fonctionnent sans extraire des dossiers sur disque.
lARP64 soutient presque tous les types d'applications x86 64-bit compilées (pas de NET). Les programmes protégés sont compatibles avec tous les systèmes Windows en 64 bits: Windows XP jusqu'à Serveur 2008.
Continuez avec la technologie lARP64.
Aide - film
Un petit film pour vous aider à utiliser et à comprendre le fonctionnement du protecteur est disponible en anglais.
Copyright (c) 2006-2010 lARP64Tech Software All rights reserved
Facilité d'utilisation
lARP64Pro ne fournit intentionnellement aux usagers que quelques options de protection. Ceci facilite l'interaction de l'utilisateur et a toujours comme conséquence la protection la plus forte possible pour votre application.
Bien que lARP64Pro soit principalement créé pour les développeurs de software, il a été un souci spécial de fournir un outil extrêmement facile dans sa manipulation. Il suffit de cliquer quelques boutons pour lARP64'er un exécutable. En plus, vous serez étonné par la vitesse de fonctionnement! L'acte de la protection est presque instantanément, même dans le cas de fichiers assez larges!
SITE
NAVIGATION
ACCUEIL
PRODUITS
TECHNOLOGIE
TELECHARGER
VENTE
IMAGES
AIDE (en anglais)
Mesures de protection pour les développeurs
Les développeurs doivent utiliser un protecteur professionel pour protéger leurs logiciels contre le cracking. Pour la protection du logiciel de 64 bits, le premier choix est lARP64Pro. D'autre part, les développeurs devraient également apprendre à pratiquer quelques règles de base. Ce seul fait déjà empêchera votre logiciel d'être cracké par le cracker débutant. Mentionnons quelques possibilités que le développeur a pour se défendre. Sure, il n'est pas facile et il exige un peu de travail mais il n'est pas impossible de programmer une bonne protection de base dans ses propres programmes. Toujours, vous devez vous rappeler que si vous employez des méthodes de programmation typiques et connues, vous facilitez le travail du cracker. La plupart des crackers emploie plusieures méthodes bien examinées pour cracker des types particuliers de protection et, ainsi, ils peuvent enlever un grand pourcentage de l'arrangement de protection. La clef est d'employer les méthodes moins communes, qui ralentiront le cracker ou même l'arrêteront complètement.
Trouvez ici quelques règles pour une meilleure protection du code dans votre arrangement d'enregistrement.
* D'abord : si votre programme a été cracké, faites une nouvelle version. Des mises à jour fréquentes à votre programme peuvent mettre les crackers à l'abris, particulièrement quand la protection a été enlevée en changeant le code par patching. C'est également parce que la correction ne fonctionnera probablement plus dans la nouvelle version. Au cas où votre programme serait keygenné, puis récrivez votre arrangement d'enregistrement d'une manière complètement différente !
* Employez du chiffrage fort pour l'arrangement d'enregistrement et pour les autres zones délicates dans votre code. Si ceci n'arrête pas le cracker, il le ralentira au moins considérablement.
* N'employez jamais des noms auto-descriptifs. Par exemple, si vous employez les noms de fonction IsNotRegistered et IsRegistered dans votre source, le cracker saura immédiatement où focaliser son effort. Convenu, il sera légèrement plus difficile d'écrire vos programmes, mais le cracking deviendra beaucoup plus dur aussi! C'est même une bonne habitude d'employer quelques noms faux faisant allure à un arrangement d'enregistrement de leurre !
* N'employez pas les messages d'erreur inutiles. Si le programme donne un message d'erreur après qu'un sérial incorrect est introduit, le cracker peut simplement rechercher le code du message d'erreur pour dépister le procédé qui l'a appelé. Ceci peut être aussi simple que placer un point de break sur MessageBoxA pour débarquer immédiatement au bon endroit. Quand les messages d'erreur sont vraiment inévitables, cachez-les autant que possible, et créez-les (dynamiquement) en temps réel plutôt qu'en employant des ressources pour eux. C'est également une bonne idée de chiffrer les données et le procédé qui crée un message d'erreur, ce qui le rend beaucoup plus difficile de le cracker et de le trouver dans le code désassemblé.
* Ajoutez des essais aléatoires pour l'enregistrement en employant une méthode d'essai qui diffère de l'originale. Les crackers les détestent vraiment parce que cela prend habituellement beaucoup de temps pour les enlever. Comme variation sur ce thème, faites différents arrangements pour examiner l'acte de l'enregistrement et de la vérification d'enregistrement à chaque démarrage. Ceci signifie que vous ne devriez pas appeler le même code de vérification mais en effet vous devez créer des fonctions séparées pour ceci.
* N'exécutez pas la vérification d'enregistrement juste après l'entrée des données. Ceci le rendra beaucoup plus difficile pour le cracker traçant l'application dans un programme débuggeur. Encore mieux: exigez que le programme soit remis en marche avant que la vérification commence.
* Employez du checksumming partiel dans votre application. Si vous examinez vos dossiers d'EXE et de DLL pour des changements, particulièrement dans des zones délicates, les crackers seront gênés de modifier ces secteurs avec un patching simple. Sure, ils pourront toujours modifier le code directement dans la mémoire. Ainsi c'est une bonne idée de déterminer des changements au code d'application en mémoire. Rendez-vous compte qu'un cracker peut changer la valeur d'intégrité en valeur correcte après le patching du programme, ainsi, si vous exécutez du checksumming sur de plus petites sections du programme, vous rendez le travail du cracker plus dur.
* Faites des vérifications nichés sur des zones délicates pour le rendre plus dur à enlever la protection. N'importe quelle routine ne devrait examiner qu'une partie de l'exactitude de l'enregistrement, pour empêcher que l'enregistrement soit trop facile a découvrir d'un seul coup. En employant plus d'une routine de vérification, le cracking du programme sera souvent incorrecte parce que le cracker peut manquer une ou plusieures des routines de vérification.
* Codez une routine d'enregistrement de leurre dans votre programme. Cette technique avec des routines d'essai fausses confond le cracker. En plus, il y a des variations sans fin sur ce thème.
* N'employez pas simplement le premier arrangement d'enregistrement auquel vous pensez dans votre programme. L'arrangement d'enregistrement est certainement le morceau de code le plus important pour la sécurité dans votre programme. Ainsi, pensez longtemps aux possibilités et trouvez du conseil sur le sujet si nécessaire.
* Mettez votre information d'enregistrement dans un endroit non-évident. Si vous maintenez l'information d'enregistrement dans l'enregistrement de Windows, c'est trop facile à découvrir. Au lieu de cela, maintenez-le dans un dossier que personne ne suspecte qu'il contiendrait l'enregistrement, comme dans un DLL par exemple. En plaçant un tel DLL dans le répertoire du système Windows, vous rendrez la situation d'enregistrement très embrouillante pour le cracker. Même si un cracker utilise un outil de surveillance de dossier pour suivre l'accès aux dossiers, il peut prendre un bon temps avant qu'il comprenne que l'enregistrement est dans un tel dossier. Encore mieux: localisez l'enregistrement dans plus qu'un endroit.
* Construisez votre enregistrement sur une technique qui dépend du matériel d'un ordinateur particulier pour le rendre plus dur pour employer ce même dossier pour enregistrer le programme sur un autre ordinateur.
* N'ayez pas peur des longs sérials. Plus le dossier ou le chiffre d'enregistrement est long, plus il dure pour le comprendre. Si le dossier ou le nombre d'enregistrement est suffisamment long, il peut contenir une information importante dont le programme a besoin, et si un tel programme est changé par patching, il ne fonctionnera plus correctement.
* Faites le procédé de vérification du sérial de façon partielle mais examinez aléatoirement les parties restantes, pas immédiatement mais de temps en temps. C'est une mesure très forte parce qu'il est beaucoup plus dur pour le cracker si le programme soi-disant enregistréremarque soudainement et aléatoirement qu'il n'est pas enregistré correctement, ceci par une vérification sur une partie du chiffre sérial qui n'a pas été exécutée encore!
* Pour le shareware qui fonctionne un temps limité pendant la période d'essai, vous devriez examiner plusieurs données relatifs au temps telles que la date de dossier et autres. Si la date du jour ou de l'heure est la même ou plus petite que quand le programme a été lancé précédemment, il sera clair que le temps ait été ajusté. En outre, vous pouvez garder la date et l'heure après chaque lancement du programme, et puis examinez cette date et la vérifier lors d'un nouveau lancement.
* Une erreur commune est que les routines de vérification sont rendues trop longues. Quelque chose qui prend seulement une seconde à exécuter dans un programme prend déjà un temps assez long pour étudier sous débuggeur. Tout ce qui dure plus longtemps donne de nouveau des idées d'attaque aux crackers. Il est souvent vrai que les méthodes les plus simples soient les plus fortes, ceci n'est certainement pas vrai pour votre routine de vérification du sérial. Ainsi, un certain code de leurre dans votre arrangement d'enregistrement est souvent une bonne idée. Néanmoins, assurez-vous qu'il n'est pas possible que le cracker voie d'avance si un certain morceau de code est important ou pas ou ils sachent s'ils peuvent sauter le tout immédiatement.
* Envisagez de chiffrer les sections du code qui sont censées fonctionner dans une version non enregistrée, et à les décoder seulement après l'enregistrement. La clef de déchiffrage doit alors contenir l'enregistrement, de sorte que le programme ne puisse pas être déchiffré sans lui.
* Si votre application emploie un numéro sérial, faites sûre qu'il ne devient jamais visible en mémoire. Faites aussi sûre qu'il n'est jamais entièrement formé en mémoire. Vérifiez seulement des parties du sérial, détruisez cette mémoire et puis vérifiez la prochaine partie. Ceci signifie qu'il devrait être impossible de trouver le numéro du sérial de votre programme en débuggant. Ceci signifie également que la vérification périodique devrait faire autre chose que juste comparer deux données. Un chemin possible est de chiffrer le numéro introduit et le sérial correct de la même manière. De cette façon, les deux nombres peuvent être comparés sans un trop grand risque du cracker découvrant le code.
* Envisagez d'exiger l'enregistrement en ligne bien que ceci puisse avoir quelques désavantages ou soit impossible pour un logiciel particulier. Toujours, l'internet a considérablement augmenté la praticabilité de l'enregistrement en ligne et de sa vérification. Quand un programme est enregistré en ligne, ses données d'enregistrement sont envoyées à un serveur particulier. Sous sa forme la plus fondamentale, ce serveur retourne alors l'information au programme en indiquant si l'enregistrement ait réussi ou pas. L'effet secondaire important est que le serveur peut également être utilisé pour envoyer des données dont a besoin le programme afin de lancer l'application enregistrée. Ces données peuvent former des parts importants du code jusqu'à une clef requise pour déchiffrer des parties du programme. Ou le programme peut contrôler en temps-aléatoire sur le serveur si tout est encore bon. Toujours, un mot d'avertissement est nécessaire ici: tout est inutile si le cracker peut facilement trouver le code qui transmet les réponses du serveur (il est souvent vraiment facile à trouver que). Évidemment, si vous allez exiger l'enregistrement en ligne, vous devrez défendre, cacher et chiffrer ce morceau de code par tous les moyens possibles !
* Il ne faut jamais réagir tout de suite au cas qu"on détecte -pendant une vérification aléatoire- que le sérial n'est pas correcte: continuez et relevez l'enregistrement après un petit peu de temps pour continuer non-registré.
* Si vous limitez la fonctionnalité de votre programme, alors faites une vraie démo en veillant que le programme ne contient pas le code pour la fonction limitée. Beaucoup de réalisateurs font l'erreur d'inclure le code pour une fonction qui ne peut être disponible qu'après enregistrement. En ce cas, le cracker peut trop facilement modifier le code de sorte que la fonction fonctionne quand-même.
* Informez-vous. Nous savons bien qu'il est à peine possible de lire et d'étudier tout le matériel de cracking disponible. Pourtant, une certaine éducation au sujet des nouvelles techniques, au sujet de la protection et au sujet du cracking en général est une bonne idée. Au contraire: cela aidera déjà beaucoup pour éviter les erreurs de base !
Remarquez que aucune des mesures ci-dessus évitera votre logiciel d'être cracké, pas même si vous employez toutes les mesures ci-dessus ensemble dans votre programme. Votre logiciel n'a jamais encore été cracké avant? Notez alors que vous êtes ou très chanceux ou votre logiciel n'a pas encore été remarqué ou votre logiciel n'est pas assez intéressant. Toujours, il vaut mieux de protéger votre logiciel parce qu'on ne sait jamais ce que demain pourrait apporter … . Ainsi, la mesure la plus importante que tous les programmateurs de logiciels devraient prendre est … de proteger leurs logiciels avec un protecteur fort fait par des experts en techniques de cracking.
Rappelez-vous que les crackers sont souvent meilleur au courant que vous l'êtes. Les meilleurs parmis eux sont également d'excellents programmeurs, et ils ne sont pas étonnés facilement. Par conséquent, vous devriez employer un protecteur de logiciel fait professionnellement: ces personnes ont étudié le cracking et ils savent mieux que le développeur habituel comment défendre votre logiciel pour le mieux! Une remarque: construisez et employez votre propre arrangement d'enregistrement même au cas que vous n'ayez vraiment aucune idée comment faire ceci d'une manière forte. Une fois que l'arrangement de l'enregistrement du logiciel protecteur est cracké, il devient trop facile pour les crackers de pouvoir cracker le même arrangement du protecteur à nouveau et à nouveau. Il est bien plus difficile si vous avez votre propre arrangement que vous employez en addition avec les ruses de la protection supplémentaire du protecteur commercial !
Bonne chance !