Protectie tegenover cracking
Laat dit vanaf het begin duidelijk zijn: alles kan, ten minste vanuit een theoretisch standpunt, gekraakt worden. Geloof die mensen niet die proberen om u van het tegengestelde te overtuigen. Wij hebben lang genoeg cracking bestudeerd om beter te weten. Nochtans, er bestaan manieren om cracking uiterst moeilijk te maken. lARP64Pro maakt het dan ook zo hard en tijdrovend dat tot dusver nog geen enkel lARP64Pro beschermd bestand werd gekraakt!
te vinden. Bovendien kan men zeker zijn dat in het andere geval, en geen kwestie hoe moeilijk het ook is, het schema vroeg of laat gekraakt zal worden. Daarom richtten wij de lARP64 technologie doelbewust naar het beschermen van uw eigen vergunningssysteem! Coderen gebeurt meestal in hogere programmeertalen maar cracking gebeurt onder debuggers en disassemblers in assembleertaal. Assembler biedt veel mogelijkheden die niet of nauwelijks mogelijk zijn in hogere programmeertalen. Daarom werd de beschermende code in lARP64Pro ook volledig gecodeerd in assembler. Dit heeft onze protector in een verfijnde anti-cracking machine veranderd. Enkel om volledig te zijn: de GUI is gecodeerd in .NET waardoor men eventueel de .NET runtimes moet downloaden en installeren om met lARP64Free en lARP64Pro te werken. De gecompresseerde en/of beschermde bestanden hebben die niet nodig.
Copyright (c) 2006-2010 lARP64Tech Software All rights reserved
SITE
NAVIGATION
HOME
PRODUCTS
TECHNOLOGY
DOWNLOAD
ORDER
SCREENSHOTS
HELP (in Engels)
"Software Reverse Engineering" of ook "Reverse Code Engineering" (RCE) is het ontleden en het bestuderen van binaire toepassingen zonder het ter beschikking hebben van hun broncode. De redenen voor reverse engineering zijn verscheiden. Één van de belangrijkste functies van RCE moet ingenieurs kwaadwillige code zoals computervirussen, wormen, trojans, addware en spyware laten bestuderen. Reverse engineering wordt ook beoefend omdat de documentatie van een bepaald apparaat is verloren of nooit geschreven, en de persoon die het bouwde is niet meer beschikbaar. De enige manier om functionaliteit op te nemen of te bestuderen in nieuwe technologie kan reverse engineering van een bestaande hardware zijn om die dan opnieuw te ontwerpen. Er is ook productanalyse om te onderzoeken hoe een product binnenin werkt, uit welke componenten het bestaat, enz. Er is veiligheidscontrole en vergeet niet dat in de anti-virus softwareindustrie, er „slechts“ reverse engineering is en nauwelijks iets anders. Anderzijds is er ook de illegale verwijdering van bescherming, ontwijking van toegangsbeperkingen en de ongeoorloofde verwezenlijking van duplicaten. In tegenstelling tot open bron software die theoretisch niet van veiligheid moet worden voorzien, stelt de gesloten bron software de gebruiker voor een „zwarte“ doos. Historisch is RCE uitgevoerd op de Windows platformen, maar er is nu eveneens een groeiende behoefte aan deskundigen voor alle andere platformen. De term reverse engineering heeft namelijk een dubbele betekenis aangezien het ook een goed en legitiem ding kan zijn! Anderzijds heeft het woord "cracking" bijna altijd de betekenis van iets onwettig, van een frauduleuze actie.
Als teaser: wie heeft gezegd dat een virusschepper geen rechten op zijn/haar werk zou moeten hebben? En waar de lijn trekken of het wettelijk of niet is om de code van een virus te kraken?
RCE staat u toe om binnenin de zwarte doos te zien. Door een binaire toepassing te demonteren, kunt u de programmauitvoering op zijn laagste niveaus waarnemen. Zodra de toepassing in assembler wordt opgesplitst, kan een deskundige de werking van om het even welke binaire toepassing bekijken, om het even hoe goed de softwareschrijver probeerde om daartegen te beschermen.
Waarom zou een veiligheidsdeskundige RCE moeten leren? Zoals al aangestipt, de duidelijkste reden is reverse engineering van malware zoals virussen of trojaanse paarden. De antivirus industrie hangt af van de capaciteit om binaire data te ontleden, te diagnostiseren, te desinfecteren en te verhinderen. Bovendien brengen bijvoorbeeld de proliferatie van immorele commerciële spyware en de bescherming van softwareantipiracy die „naar huis“ telefoneren ernstige privacyzorgen mee. En fundamenteel is zelfs het debuggen van uw eigen code een vorm van reverse engineering.
Wetten
De wettigheid van RCE is nog op vele gebieden in vraag. De meeste freeware en shareware is vergezeld van een overeenkomst van de eindgebruiker of een EULA, net zoals bij lARP64Free en lARP64Pro. Volgens lARP64Tech en die andere softwarefabrikanten, is men door te klikken op „Ik ga akkoord“ bij het installeren van software, contractueel verbonden om de termen van deze EULA te respecteren. De meeste EULAs omvatten een clausule die aan de eindgebruiker verbiedt om reverse engineering toe te passen op het product om de intellectuele eigendom van de fabrikant te beschermen. Er is geen twijfel dat in deze gevallen waar de auteur reverse engineering uitdrukkelijk verbiedt, mensen die nog reverse engineering doen op dergelijke toepassingen, de wet breken. In feite voorziet de Digital Millennium Copyright Act (DMCA) harde sancties voor sommige instanties van reverse engineering. Men zou de vraag kunnen stellen waarom zo vele mensen deze sancties riskeren en schijnen niet te kunnen stoppen met die misdadige acties. Zie eerst een weinig geschiedenis om op deze dringende vraag te kunnen beantwoorden.
Pro en contra
Door autoriteiten op dit gebied wordt gezegd dat crackers en de ontwikkelaars van beschermingsmechanismen niet alleen tegenstanders zijn … zij zijn ook collega's. Als men stelt dat de crackers parasieten zijn die het onvermogen van programmeurs om beschermingsmechanismen van uitstekende kwaliteit te bouwen, exploiteren, dan moet men zich realiseren dat de programmeurs ook parasieten zijn die het onvermogen van gebruikers om programma's te schrijven, exploiteren!
Reverse engineering met de nadruk op de onwettige acties en de programmering met de nadruk op de wettelijke gerechtvaardigheid, hebben veel overeenkomsten. Het creëren van hoogstaande en betrouwbare beschermingsmechanismen vereist top programmeervaardigheden en de capaciteit om met het werkende systeem, de drivers, het materiaal en de kennis van de architectuur van processors, de specifieke eigenschappen van codegeneratie typisch voor specifieke compilers, en de biologie van de bibliotheken, te werken. Op dit niveau van programmeren wordt het onderscheid tussen programmeren en het kraken zo dun dat het nauwelijks mogelijk is om een lijn tussen beide te trekken. Men kan een cracker die zijn hulpmiddelen gebruikt vergelijken met een inbreker die een stethoscoop gebruikt. Een stethoscoop zou door de inbreker kunnen worden gebruikt om het slotmechanisme van een brandkast te beluisteren en om de tuimelschakelaars op hun plaats te horen vallen. Maar dezelfde stethoscoop zou door een arts kunnen worden gebruikt om hart of gezondheidsproblemen te ontdekken. Het hulpmiddel is niet inherent goed of slecht, noch hij of zij die het hulpmiddel gebruikt. De kwestie doet zich voor met het gebruik dat voor het hulpmiddel wordt gekozen. En het is vrij duidelijk dat de stethoscoop niet moet worden verboden noch worden vernietigd omdat men het ook voor minder bewonderenswaardige redenen kan gebruiken.
Elke bescherming vereist het zorgvuldige en grondige testen op zijn bruikbaarheid, net zoals elke andere softwarecomponent wordt geevalueerd. In deze context, wordt de bruikbaarheid geïnterpreteerd als zijn capaciteit om pogingen te weerstaan om het te kraken door gekwalificeerde crackers die gewapend zijn met alle mogelijke hulpmiddelen. De kwaliteit van de bescherming wordt niet door zijn sterkte maar door het verband tussen de manuren geëvalueerd die nodig zijn om het te programmeren en de manuren die worden vereist om het te kraken. Uiteindelijk kan elk beschermingssysteem gekraakt worden omdat het kraken slechts een kwestie is van tijd, geld, crackercapaciteiten, hulpmiddelen en inspanning. Nochtans, de deskundig ontworpen bescherming mag geen gemakkelijke mogelijkheden bieden aan het kraken. En dit is precies waar lARP64Pro in het spel komt: wij hebben lARP64Pro zo sterk en tijdrovend om te kraken gemaakt dat het nauwelijks „kraakbaar“ is. Maar verder zullen wij nog meer argumenten van het standpunt van de cracker bekijken.
Om beschermingsmechanismen te ontwikkelen, moet de programmeur minstens een algemeen idee over de werkmethoden en de technische hulpmiddelen hebben die door zijn of haar tegenstander worden gebruikt. Dit technische arsenaal minstens op het niveau van de tegenstander beheersen, is nog beter. De praktische ervaring (in het kraken van programma's) is hoogst wenselijk omdat het iemand toestaat om de tactiek en de strategie van de aanvallende partij zorgvuldig te bestuderen, waarbij de organisatie van een optimale defensie wordt uitgewerkt. Het staat de programmeur eenvoudig toe om de waarschijnlijkste doelwitten te ontdekken en deze dan te versterken tegen crackeraanvallen. Dit betekent dat de ontwikkelaar van beschermingsmechanismen door de psychologie van de cracker moet worden geïnspireerd en als een cracker moet kunnen denken.
Aldus veronderstelt het beheersen van de technologie van de informatie-bescherming het beheersen van de cracker technologie. Als u niets weet over hoe de beschermingsmechanismen gekraakt worden, onbewust bent over hun kwetsbaarheid, en geen informatie over het arsenaal van de cracker heeft, zal u geen sterk beschermingsmechanisme kunnen maken dat goedkoop en gemakkelijk in gebruik is. De boeken over veiligheid die uitsluitend dit onderwerp van het beschermingsstandpunt onderzoeken hebben het nadeel dat die informatie slechts beschrijft maar geen praktische toepassing geeft. Het bestuderen van slecht maakt het goede beter. En het kennen van de vijand maakt de defensie beter. Zo inderdaad hebben wij bij lARP64Tech het kraken, zijn hulpmiddelen en zijn technieken, jarenlang bestudeerd. Wij zijn vrij bekwaam in het denken als een cracker om altijd één stap voor de tegenstander te kunnen blijven. Slechts door uitgebreide studie en het leren om als een cracker te denken met de enige reden om hen voor te blijven, hebben ons bekwaam gemaakt om de lARP64 technologie te ontwikkelen!
Wanneer de crackers wordt gevraagd waarom zij software kraken, is één van de meest voorkomende antwoorden dat zij het voor de uitdaging en de adrenaline bij succes doen. Ook wordt kraken gedaan om te leren en slimmer met software te worden. Meestal, zijn de crackers zeer slimme mensen die bij het verwijderen van softwarebescherming voor dagen, en in extreme gevallen zelfs voor weken, aan de uitdaging werken. Het succes van de cracker hangt bijna altijd van zijn motivatie af. Het kan u verrassen om te horen dat het grootste deel van de motivatie van de cracker niet financieel is. Crackers posten hun cracks en informatie immers gratis. Zij maken geen geld van uw software, hoewel de mensen die hun cracks gebruiken, geld besparen. Eerder dan om software voor financiële winst te kraken, nemen de crackers aan een soort informele concurrentie deel. Een cracker die een nieuwe en zeer ingewikkelde bescherming kan verwijderen wordt als eerbiedwaardige persoon binnen de crackergemeenschap beschouwd.
Er is een mening dat de publicaties over gaten in veiligheidssystemen meer kwaad dan goed doen en dat zij moeten worden verboden. Met andere woorden, de verdedigers van deze mening zeggen dat zij geen waardig beschermingsmechanisme kunnen maken en hun fouten willen verdoezelen. Kan dat de oplossing zijn?
Kunnen de wetten helpen?
Het is zeer moeilijk om lijnen te trekken maar de lijnen moeten toch ergens worden getrokken. Zoals voordien genoteerd, heeft reverse engineering ook een gewettigde reden van bestaan. Maar er bestaan wetten, dus stelt de vraag zich of die wetten bekwaam zijn om het kwaad terzijde te schuiven wanneer het zich voordoet. Het antwoord is niet zo duidelijk. Laat ons eerst bekijken wat de verdedigers van het kraken zeggen.
De verdedigers van de auteursrechtwet moeten begrijpen dat hoe intenser beschermingsmechanismen gekraakt worden, hoe meer vooruitgang op het gebied van hun ontwikkeling wordt geboekt! In dergelijke omstandigheden hebben de ontwikkelaars een sterke motivatie om hoogstaande en concurrerende beschermingspakketten tot stand te brengen. Er is geen behoefte om de dingen te verbergen die elke cracker met gebruik van debugger en disassembler kan onthullen. Met het gewetensvolle onderzoek van het beschermingsmechanisme moet worden ingestemd. Toch is er het concept van de volledigheid van informatie van de goederen. De pogingen om duidelijke tekorten en nadelen te verbergen zijn onwettig. De goede dingen winnen onder onderzoek maar de slechte dingen vrezen openheid zoals de plaag.
De Digital Millennium Copyright Act verbiedt de propagatie van technologieën, apparaten, en de diensten die aan mechanismen van de bestaande bescherming worden veranderd, hetgeen logisch schijnt te zijn. De advocaten proberen om de wereld tegen duidelijke misdadigers en vandalen te beschermen. Nochtans is het noodzakelijk om het kraken en onderzoekactiviteiten op het gebied van informatietechnologie te onderscheiden. Iemand die kraakt met kwaadwillige bedoeling is minstens laakbaar, en hij verdient misschien om te worden veroordeeld of zelfs opgesloten. Maar de sanctie moet met de schade die door te kraken wordt veroorzaakt evenredig zijn. Er is geen noodzaak om crackers te vergelijken met terroristen!
lARP64Tech
Na de hierboven beschreven bespreking pro en contra, wat is het uiteindelijke besluit? Voor lARP64Tech, is het antwoord duidelijk: reverse engineering heeft inderdaad een recht tot bestaan. Crackers mogen mijn software bestuderen. Maar dit recht tot bestaan gaat slechts zover als „maar zij mogen mijn software niet gratis verspreiden“! En wij zijn zeer duidelijk en gedeciseerd in dit: niemand heeft het recht om software te kraken om het dan kosteloos te verdelen! Crackers kunnen ook hun eigen programma's („crackme“) schrijven en die kraken. Er is absoluut geen behoefte om het inkomen van anderen af te nemen en die mensen hebben zeker geen behoefte om uw opbrengsten van uw hard werk te vernietigen. Punt! Vraag om het even welke ontwikkelaar die heeft geleden onder kraken wat hij erover denkt! Hij zal onmiddellijk zeggen dat hij/zij geld heeft verloren, soms een klein bedrag maar vaak werd ook een hele grote partij geld verloren! Is zoiets te verantwoorden?
Maar als de wetten u niet in de voldoende mate kunnen helpen … wat dan? Er is duidelijk slechts één oplossing: de ontwikkelaars zelf moeten hun werk beschermen. Maar hoe?
Het antwoord is dubbel: enerzijds, zouden de ontwikkelaars een professioneel gemaakte combinatie van compressor en protector moeten gebruiken om hun software tegen crackers te verdedigen. Voor 64 bit softwarebescherming is lARP64Pro uw eerste keus. Anderzijds, zouden de ontwikkelaars altijd bepaalde basisregels op hun registratieschema moeten toepassen. Zie beschermingsmaatregelen voor ontwikkelaars.
Reversing of cracking?
Een weinig geschiedenis
Reverse engineering is een ontdekkingsproces en reeds lang gekend. Wanneer wij code bekijken die hetzij door ons of anderen werd ontwikkeld, onderzoeken wij en leren wij en we zien dingen we misschien niet verwachtten. Niet alleen is het interessant om te zien hoe de meester het gedaan heeft, het verstrekt ook een snelle manier om te leren.
Het „moderne“ RCE begon met programmeurs die bescherming op klassieke computerspelen in de vroege jaren '80 bestudeerden. Hoewel deze tendens snel een manier werd om gecopieerde computersoftware te verdelen, bleef een kern van deskundigen het RCE-gebied om zuiver academische redenen ontwikkelen. Men kan inderdaad niet verklaren dat die mensen verkeerde doelstellingen met hun werk hadden.
Enkele legendarische karakters van die vroege dagen waren geniale reverse engineers van software alsook productieve auteurs en leraars in de kwestie. Hun klassieke teksten worden vandaag nog beschouwd als verplichte lezing voor studenten RCE. Een nieuwe generatie van reverse engineers heeft de oude teksten herontdekt en begonnen de wetenschap nogmaals vooruit te drijven. Weer werd reverse engineering van software rond de vroege jaren '90, beter. Sedertdien is er een breed en groeiend onderzoek bij reverse engineering van technieken, softwareanalyse, programma begrip, softwarevisualisatie, gegevens reverse engineering en al zijn verwante hulpmiddelen en benaderingen, geweest.
De crack tools
Tegenwoordig, is er een stijgende trend in reverse engineering bij de migratie van steunplatform, interoperabiliteit, malware opsporing en probleembepaling. Vandaag nog meer dan voordien is de software reverse engineer slechts zo goed als zijn/haar hulpmiddelen. Maar RCE heeft heel wat van die tools. Vroeger waren de hex editors veel gebruikte hulpmiddelen. Tegenwoordig is er geen hex editor meer nodig om binaire gegevens in hexadecimaal te wijzigen (ook gekend als patchen). Namelijk, nu is dit ook mogelijk vanuit de debugger zelf. Een debugger is in feite een geavanceerde disassembler die ook de mogelijkheden aanbiedt om de code uit te voeren en te controleren. Een disassembler probeert om een binair getal te ontleden en weer te geven in voor mensen leesbare assembleertaal. De disassembler software leest de ruwe output van de bytestroom van de processor en ontleedt het in groepen instructies. Deze instructies worden dan vertaald in assembleertaalinstructies. Disassembler maakt een "beste" gissing bij de assembleertaalcode, vaak met veranderlijke resultaten. Niettemin is het het basishulpmiddel voor een softwarecracker. Nochtans en zoals voordien gezegd, moderne debuggers hebben ingebouwde disassembleermogelijkheden en bijna alles kan met dit éne hulpmiddel reeds worden gedaan. Men kan ook decompilers vermelden als hulpmiddel van een cracker maar decompilers zijn zelden het hoofdhulpmiddel.
Vele softwareprogramma's worden samengeperst met commerciële compressoren of „pakkers“ om schijfruimte te besparen of om het disassembleren moeilijk te maken. Een goed voorbeeld van een 64 bit freeware pakker is lARP64Free. Het hoogste niveau in het belemmeren van reverse engineering bestaat uit de protectors. Naast samenpersen beschermt die eveneens door allerlei truukjes toe te voegen om de reverse engineer of de cracker te verslaan. Gebruikte truukjes door een protector kunnen zeer verscheiden zijn en onder vele verschillende vormen voorkomen. Een goed voorbeeld van zo een gecombineerde compressor-protector is lARP64Pro.
De wetenschap van het uitpakken van samengeperste en beschermde uitvoerbare bestanden is zeer complex en neemt een volledige subspecialty van RCE in.
Aangezien het door copyrights onwettig is de bescherming in software te veranderen, programmeren reverse engineers nu hun eigen beschermingsprogramma's voor onderwijsdoeleinden. Deze crackmes zijn kleine programma's die de kern van een registratieschema, en weinig anders, bevatten.
Wat het onwettige kraken betreft, is de vraag: en wie zal de discussie winnen, of is het een oorlog die gewonnen moet worden?
Laat dit vanaf het begin duidelijk zijn: alles kan, ten minste vanuit een theoretisch standpunt, gekraakt worden. Geloof die mensen niet die proberen om u van het tegengestelde te overtuigen. Wij hebben lang genoeg cracking bestudeerd om beter te weten. Nochtans, er bestaan manieren om cracking uiterst moeilijk te maken. lARP64Pro maakt het dan ook zo hard en tijdrovend dat tot dusver nog geen enkel lARP64Pro beschermd bestand werd gekraakt! Hoewel natuurlijk: zeg nooit nooit! Behalve door compressie en encryptie verdedigt lARP64Pro uw registratieregeling door de lARP64 technologie die een som is van verduisterde code en allerlei geavanceerde technieken zoals bijvoorbeeld antidumping, anti-debugging en anti-disassembling. Elk van deze zijn vernieuwend en een resultaat van eigen onderzoek. In het kort gezegd brengt dit zo vele verschillende defensies in uw programma, dat het zeer onwaarschijnlijk is dat een cracker in zijn doel slaagt. Bovendien moedigt lARP64Pro u zelfs aan om uw eigen schema van het verlenen van vergunningen verder te blijven gebruiken. Dat is omdat het eerder stom zou zijn om slechts de „lARP64Pro registratieregeling“ aan te bieden. Want zelfs als deze regeling met variaties op het thema zou kunnen worden uitgevoerd, hebben wij geconstateerd dat dit inderdaad slechts gemak voor de krakers zou brengen. Zodra zij een bepaalde regeling hebben uitgedokterd, wordt het veel gemakkelijker steeds opnieuw dezelfde registratieregeling van de zelfde protector te kunnen kraken. Het is namelijk veel moeilijker om een nieuw systeem in elk nieuw programma
