lARP64Pro: DE PROFESSIONELE PROTECTOR
Algemene info
Voor shareware of bij om het even welke behoefte aan softwarebescherming, is er lARP64Pro. Het is gebaseerd op dezelfde principes als de compressor maar het biedt zo veel meer op het gebied van bescherming! Het is zowel een uiterst sterke 64 bits executable protector als uiterst sterke 64 bits dll protector.
Bestanden die met lARP64Pro worden beschermd zijn eveneens ook eerst gecompresseerd. Dit maakt ook uw programma's en dll's kleiner en vermindert laadtijden over netwerken of downloadtijden van het net.
lARP64Pro
Pro is het krachtigste protector- systeem voor x64 maar het werd ontworpen om heel gemakkelijk en werkbaar te zijn. Het is zo eenvoudig als 1-2-3. Zijn sterke beschermende eigenschappen verdedigen uw toepassingen tegen onbevoegde wijzigingen zoals cracking en reverse engineering. Geloof ons zomaar niet op ons woord: test het uit !
Onze protector is zo sterk dat het de uiteindelijke veilige bescherming voor uw eigen licentiesysteem zal brengen. Blijf dus verder uw eigen registratieschema trouw want lARP64Pro zal uw gevoelige code met zijn systeem dat op intern ontwikkelde lARP64 technologie werd gebaseerd, voor krakers verbergen en verdedigen.
Eenvoud van gebruik
Als een 64 bits programmaprotector mikt lARP64Pro hoofdzakelijk op software ontwikkelaars. Het is een speciale zorg geweest om een uiterst handelbaar product te verstrekken. U zal ook door de werkingssnelheid worden verrast: lARP64 werkt uiterst snel en de protectie verloopt bijna onmiddellijk!
lARP64Pro verstrekt opzettelijk slechts een paar opties om bepaalde beschermende eigenschappen al dan niet uit te voeren. Dit vergemakkelijkt gebruikersinteractie en resulteert altijd in de sterkst mogelijke bescherming voor uw toepassing.
Werkingsgebied
Onze beschermingssoftware ondersteunt bijna alle gecompileerde x86 toepassingen in 64 bits (niet geschikt voor .NET). De beschermde programma's zijn compatibel met om het even welk huidig 64 bits Windows systeem gaande van XP tot de meeste recente versie van Server 2008 (alle versies in 64 bits). De protector krijgt updates om te voorzien in verenigbaarheid met alle nieuwe versies van Windows in x64.
Lees verder over lARP64 technologie.
Copyright (c) 2006-2010 lARP64Tech Software All rights reserved
Beperkingen
Volledig functionele versies zijn beschikbaar voor download. De professionele compressor-protector is voorzien van evaluatiemogelijkheden zonder tijdsbeperking. Als u twijfelt tussen de compressor of de protector, bedenk dan dat lARP64Pro aangewezen is als programmaveiligheid wordt vereist.
SITE
NAVIGATION
HOME
PRODUCTS
TECHNOLOGY
DOWNLOAD
ORDER
SCREENSHOTS
HELP (in Engels)
Beschermingsmaatregelen voor ontwikkelaars
Een protector is de sterkste defensie tegen cracking maar de software ontwikkelaars zelf kunnen ook veel doen om het kraken te belemmeren. Ontwikkelaars zouden altijd een aantal basisregels op hun registratieschemas moeten toepassen. Dit zou al verhinderen dat de software door de beginnende cracker kan gekraakt worden. Een paar mogelijkheden die de ontwikkelaar heeft, worden hieronder vermeld. Het is zelfs niet moeilijk en vereist slechts een beetje werk want het is zeker niet onmogelijk om goede bescherming in uw eigen programma's te programmeren die de job van de cracker al vrij uitdagend maakt. Maar let op want als u typische programmeringsmethodes gebruikt, maakt u het de cracker gemakkelijker. Zoek dus naar nieuwe methoden en vermijd de al te bekende systemen. De meeste crackers gebruiken verscheidene goed geteste methodes om te kraken waardoor ze een groot percentage van de bescherming kunnen verwijderen. De sleutel is om minder evidente methodes te programmeren die de cracker vertragen of zelfs volledig tegenhouden.
Hieronder volgen een paar regels om goede bescherming voor uw registratieschema te schrijven.
* Eerst en vooral: geef een nieuwe versie vrij zodra uw programma werd gekraakt. Frequente updates aan uw programma kunnen crackers moe maken, vooral indien uw software door patchen werd gekraakt. Dit is ook omdat de patch waarschijnlijk niet in de nieuwe versie zal werken. Herschrijf uw registratieregeling op een volledig verschillende manier in het geval dat een key generator voor uw programma werd gemaakt!
* Gebruik sterke encryptie voor de registratieroutine en andere gevoelige gebieden in uw code. Als dit de cracker niet tegenhoudt, zal het hem/haar minstens aanzienlijk vertragen.
* Gebruik nooit zelf-beschrijvende namen. Bijvoorbeeld, als u de functienamen IsNotRegistered en IsRegistered in uw code gebruikt, weet de cracker onmiddellijk waar in de code hij zijn inspanningen moet concentreren. Zonder zelf-beschrijvende namen zal het enigszins moeilijker zijn om uw programma's te schrijven, maar kraken zal ook beduidend moeilijker worden! Het is zelfs een goede gewoonte om elders een paar "fake" namen -die een registratieschema aangeven- als valstrik te gebruiken!
* Gebruik geen foutmeldingen in het registratieschema (zij zijn waarschijnlijk hoe dan ook onnodig). Als het programma een foutmelding geeft nadat een onjuist registratienummer werd ingegeven, kan de cracker de programmacode van de foutmelding heel eenvoudig opzoeken. Dit kan voor hem/haar zelfs zo eenvoudig zijn als een breakpoint plaatsen op MessageBoxA om onmiddellijk in de juiste plek te landen. Wanneer de foutmeldingen werkelijk onvermijdelijk zijn, verberg hen zoveel mogelijk en creëer hen dynamisch ipv via resources. Het is ook een goed idee om de gegevens en de procedure die tot een foutmelding leidt, te coderen (cryptie), wat het voor de cracker moeilijker maakt om het schema in de gedemonteerde code terug te vinden.
* Voer de verificatie op correcte registratie niet onmiddellijk uit na input van de serial. Dit zal het voor de cracker moeilijker maken om deze verificatie in debugger terug te vinden. Beter nog, start het programma opnieuw alvorens te testen op correcte registratie.
* Voeg extra tests voor de registratie random in de tijd bij door een testmethode te gebruiken die van de originele verschilt. Die controles zijn zeer ergerlijk voor crackers omdat het gewoonlijk heel wat tijd neemt om hen te vinden en te verwijderen. Als variatie op dit thema, kunt u verschillende schema's maken om de handeling van het registreren en de registratiecontrole bij iedere nieuwe opstart te testen. Zo betekent dit dat u niet dezelfde call zou moeten doorlopen maar hiervoor inderdaad afzonderlijke functies maken.
* Gebruik gedeeltelijke checksumming (CRC) in uw toepassing. Als u uw EXE en Dll dossiers test op veranderingen, vooral in gevoelige gebieden, zullen de crackers worden belemmerd om die gebieden te wijzigen door eenvoudig te patchen. Zeker, zij kunnen de code in het geheugen nog wijzigen, zodat het eveneens een goed idee is om op veranderingen in de code in het geheugen te testen. Een cracker kan de controlesom naar de correcte waarde veranderen na het patchen van het programma, maar als u controle CRC's op kleinere secties van het programma uitvoert, maakt u het werk van de cracker heel wat uitdagender.
* Gebruik genestelde controleroutines op gevoelige gebieden in de code om het moeilijker te maken om de bescherming te verwijderen. Elk deel van de routine zou slechts een deel van de juistheid van de registratie mogen verifiëren, niet het geheel van de registratie, om zo te verhinderen dat de registratie te gemakkelijk te begrijpen is wanneer een cracker deze ontdekt. Door meer dan één controleroutine te gebruiken, zal het kraken van het programma vaak mislopen omdat de cracker één of meer van de controleroutines kan gemist hebben.
* Codeer een "valstrikregistratieroutine" in uw programma. Deze techniek met valse testende routines verwart de cracker aangezien er eindeloze variaties op het thema zijn en het moeilijk is om te ontdekken welke routine uiteindelijk de belangrijke is.
* Gebruik in uw programma niet zomaar het eerst mogelijke registratieschema waar u aan denkt. Het registratiesysteem is zeker het belangrijkste stuk code in uw programma, zodat u best lang nadenkt over de mogelijkheden. Vraag indien nodig raad over het onderwerp.
* Codeer uw registratieschema gebruik makend van een techniek die afhankelijk is van de computerhardware. Dat maakt het moeilijker of onmogelijk om dezelfde serial te registreren op een andere computer.
* Zet uw registratieinformatie in een niet evidente plaats. Als u de registratieinformatie in de register van Windows houdt, kan het gemakkelijk worden ontdekt. Een mogelijkheid is het in een plaats of dossier onder te brengen waarvan niemand zou verdenken dat het de registratie kan bevatten. Bijvoorbeeld in een DLL. Door zulk een DLL in de systeemfolder van Windows te plaatsen, maakt u de registratiesituatie zeer verwarrend voor de cracker. Zelfs als een cracker een dossier controlehulpmiddel gebruikt om de toegang tot dossiers op te volgen, kan het nog een tijdje duren alvorens hij begrijpt dat de registratie in zulk een dossier gebeurt. Beter nog, leg de registratie per gedeelte vast op afzonderlijke plaatsen om het waarschijnlijk te maken dat de bescherming verkeerd zal worden verwijderd.
* Wees niet bang om een lange serial op te stellen. Hoe langer de serial, hoe langer het duurt om zijn samenstelling te begrijpen. Als de serialnummer voldoende lang is, mag en kan die belangrijke informatie bevatten die het programma vereist voor zijn geregistreerde werking, en als zulk een programma gepatcht wordt, zal het niet meer correct werken.
* Maak een controleproces op de serialroutine dat periodiek delen van de serial test. Dit is een zeer sterke maatregel omdat het veel moeilijker is voor de cracker als het zogenaamd geregistreerde programma plotseling en tijdswillekeurig opmerkt dat het in feite nog niet correct geregistreerd was. Doe dit als controle op een extra deel van de serial waarp geen andere verificatie wordt uitgevoerd!
* Voor tijdsbeperkte trial-shareware, zou u verscheidene tijdsgerelateerde gegevens zoals dossierdatum enz. moeten testen. Ook kunt u de datum en de tijd na elke lancering van het programma opslaan, en dan deze datum en tijd testen tijdens een nieuwe opstart. Als de huidige datum of de tijd hetzelfde of kleiner zijn dan toen het programma eerder in werking werd gesteld, is het duidelijk dat de tijd werd aangepast.
* Een veel voorkomende fout is dat de test routines te lang worden gemaakt. Iets dat slechts één seconde vergt wanneer een programma loopt, vergt reeds een voldoend lange tijd om dit onder debugger niet zomaar te kunnen bestuderen. Alles dat langer duurt brengt extra punten tot aanval aan de cracker. Het is vaak waar dat de eenvoudigste methodes het moeilijkst te verslaan zijn hoewel dit zeker niet het geval voor uw serial controleroutine is. Zo is één of andere valstrikcode in uw registratieregeling vaak ook een goed idee. Niettemin, zorg ervoor dat de cracker niet dadelijk kan merken of een stuk code onbelangrijk is of zij beseffen dat zij het kunnen overspringen.
* Codeer geen secties van de code die niet functioneren in een niet geregistreerde versie, en decodeer die stukken slechts na registratie. De decrypterende sleutel moet dan de registratie bevatten, zodat het programma niet zonder deze sleutel kan worden gedecodeerd.
* Als uw toepassing een registratienummer gebruikt, dan zou dat nummer nooit in het geheugen zichtbaar mogen zijn, noch zou de correcte serial ooit volledig in het geheugen mogen worden gevormd. Dus, verifieer delen van de serial, vernietig dat geheugen en verifieer dan het volgende deel van de serial. Dit betekent dat het onmogelijk zou moeten zijn om een compleet gevormd registratienummer van uw programma terug te vinden onder debugger. Dit betekent ook dat de periodieke controle iets zou moeten doen dat ingewikkelder is dan enkel twee strings te vergelijken. Een mogelijke maar nog te gemakkelijke weg is om het ingegeven registratienummer en het correcte registratienummer op de zelfde manier te coderen (cryptie). Op deze wijze kunnen de twee serials zonder een te groot risico op cracking worden vergeleken. Maar gebruik uw verbeelding want u zou ook een controlesom van het ingegeven registratienummer met een controlesom van het correcte registratienummer kunnen vergelijken. Programmeer ook in dit geval altijd meerdere controles om zeker te zijn dat het correcte registratienummer werd ingegeven.
* Programmeer een eenvoudige extra controle in een aparte thread die periodiek een stukje van de serial vergelijkt. Dit is zeer moeilijk te vinden als deze controle op een extra stukje van de serial wordt uitgevoerd dat voorheen nog nergens geverifieerd wordt.
* Denk na om via online registratie te werken hoewel dit ook nadelen kan hebben en het ook af te raden is voor bepaalde software. Internet heeft de haalbaarheid van online registratie wel een duw in de goede richting gegeven. Wanneer een programma online wordt geregistreerd, worden de registratiegegevens verzonden naar een bepaalde server. Deze server stuurt deze informatie dan naar het programma terug, vertellend of de registratie wel of niet succesvol was. De belangrijke bijwerking is dat de server ook kan worden gebruikt om gegevens te verzenden die het programma nodig heeft om de toepassing als geregistreerd te lanceren. Dit maakt dat de server ook een sleutel kan verstrekken, nodig om delen van het programma te decoderen. Of het programma kan tijd-willekeurig op de server controleren of alles nog goed is. Toch is een woord van waarschuwing hier op zijn plaats: als de cracker de code voor het antwoord van de server vindt (dat vaak werkelijk gemakkelijk te vinden is), dan is alle moeite nutteloos. Dus, als u voor online registratie gaat, zult u dit stuk van code moeten verdedigen, verbergen en coderen op alle mogelijke manieren!
* Handel nooit onmiddellijk als een registratieprobleem wordt ontdekt. Laat de cracker denken dat alles goed gaat en maak de definitieve actie zeer onduidelijk: geen waarschuwing over wat verkeerd gaat, enkel de registratie opheffen en in deze niet geregistreerde staat verder werken.
* Als u de functionaliteit van uw programma beperkt, maak dan een echte demo door ervoor te zorgen dat het programma de code voor die beperkte functie nog niet bevat. Vele ontwikkelaars maken de fout om de code voor een functie die slechts na registratie in het geregistreerde programma beschikbaar zal zijn, toch al te programmeren. Anders kan de cracker de code wijzigen zodat de functie toch al zou werken.
* Blijf bij en informeer u. Wij weten dat het nauwelijks mogelijk is om al het cracking materiaal te lezen en te bestuderen. Maar wat lezen over nieuwe technieken, over bescherming en over het kraken in het algemeen, hindert nooit. Integendeel: het zal reeds een stukje helpen in het vermijden van basisfouten!
Merk op dat het gebruik van geen enkele maatregel hierboven kan vermijden dat uw software wordt gekraakt, zelfs niet als u alle bovengenoemde maatregelen samen in uw programma gebruikt. Werd uw software nog nooit voordien gekraakt? Merk dan op dat u of zeer veel geluk heeft of uw software nog niet opgemerkt werd of uw software niet interessant genoeg is. Nog is het beter om uw software te beschermen omdat men nooit weet wat morgen zou kunnen brengen. De laatste maar zeker niet de minst belangrijke maatregel die alle softwareontwikkelaars zouden moeten toepassen: bescherm uw software met een sterke protector die door professionele mensen met sterke kennis van het kraken en zijn technieken wordt gemaakt.
Merk op dat de crackers vaak beter geïnformeerd zijn dan uzelf. De besten van hen zijn ook uitstekende programmeurs, en zij kunnen niet gemakkelijk worden verrast. Nogmaals daarom zou u een professioneel gemaakte protector moeten gebruiken: die mensen hebben het kraken bestudeerd en beter dan de doorsnee ontwikkelaar weten zij hoe uw software het best te verdedigen! Één opmerking: construeer en gebruik uw eigen registratieschema, zelfs als u werkelijk geen idee hebt hoe dit op een sterke manier te doen. Van zodra het registratieschema van een protector is gekraakt, wordt het anders te gemakkelijk voor crackers datzelfde schema van de protector steeds opnieuw te kunnen kraken. Het is veel moeilijker als u uw eigen schema hebt dat u samen met de toegevoegde bescherming van de commerciële protector gebruikt!
Veel geluk!