Sharing IT Best Practices with youSharing IT Best Practices with you
Reverse engineering
Als je besluit om met Reverse Engineering een SaaS applicatie te ontleden, lees dan eerst zorgvuldig de Algemene Voorwaarden. De meeste SaaS-leveranciers hebben een duidelijke regel die reverse-engineering van de software verbiedt. Dit geldt niet alleen voor de SaaS oplossing waarop je geabonneerd bent, maar ook als er een proefperiode is afgesproken. Zelf bij gratis downloads is dit verbod vaak van toepassing.
Men wil namelijk voorkomen dat je de software zal nabouwen en zelf een vergelijkbare dienst op de markt zal brengen.
Reverse engineering is een methode voor het dupliceren van bestaande software, ontrafeling van een product, zonder de hulp van ontwerpen, documentatie of modellen. Je kunt stellen dat reverse engineering het ontwikkelproces in tegenovergestelde richting is om tot de requirements te komen.
Reverse engineering kunnen we beschouwen als het proces van het analyseren van een systeem om:
Een andere reden om reverse engineering toe te passen is om ontwikkelingstijd te verkorten. In een competitieve markt zoeken leveranciers voortdurend naar nieuwe manieren om ontwikkeltijden te verkorten om een nieuwe SaaS applicatie op de markt te brengen.
Hieronder volgen redenen voor de toepassing van reverse engineering op SaaS applicaties:
Reverse Engineering maakt duplicatie van bestaande software mogelijk door de (scherm) interfaces, gedrag en andere eigenschappen te analyseren. Dit worden dan de requirements voor het duplicaat. Vooraf moeten we een applicatie lifecycle analyse en een kosten/baten analyse uitvoeren om het reverse engineering project te rechtvaardigen. Reverse engineering is meestal alleen kosteneffectief als de software een hoge investering weerspiegelt of als er een hoge omzet uit voortvloeit. Reverse engineering passen we verder alleen toe als de software absoluut vereist en bedrijfskritisch is.
Stel dat we software aanbieden volgens een SaaS model. Wat nu als onze reseller besluit om onze software te reverse engineeren zodat ze een concurrerende service kunnen lanceren? En wat nu als we nooit een contract hebben getekend met die reseller? Er is alleen een mondelinge afspraak over de vertrouwelijkheid en de rechten betreffende de software.
Hoewel de reseller geen toegang heeft tot de broncode heeft hij wel adminrechten op het hoogste niveau en daarom een breder inzicht in de opbouw, functionaliteit en structuur van de software.
Via gerechtelijke procedures zullen we ontdekken dat zulke kwesties neerkomen op bescherming van Intellectueel eigendom en bedrijfsgeheimen. De rechter maakt een onderscheid tussen de broncode van de software (die een bedrijfsgeheim kan zijn) en de werking en “look and feel” van de software. Deze laatsten kunnen we niet als bedrijfsgeheim beschermen, aangezien deze eigenschappen voor iedere gebruiker gemakkelijk te herkennen zijn. Als we echter geen geheimhoudingsovereenkomst zijn aangegaan wijst de rechter onze claim af. Maar kunnen we als oorspronkelijke SaaS leverancier wel bewijzen dat er een Reverse Engineering is uitgevoerd?
Een duidelijke schriftelijke overeenkomsten verdient altijd de voorkeur boven handshake deals en mondelinge afspraken over vertrouwelijkheid.
Een vastberaden software engineer kan ieder stukje software op de locale servers reverse-engineeren. Het is de kunst om dit zo moeilijk te maken dat het niet loont om het te proberen.
Als we een gecompileerd programma openen in een editor, zullen we zien dat het onleesbaar is. Het zijn de binaire gegevens van het uitvoerbare bestand. De kunst van het lezen en schrijven van dit soort programmacodes is grotendeels verloren gegaan omdat iedereen in een voor mensen leesbare programmeertaal (zoals C, Java, PHP, etc.) schrijft.
Proberen om erachter te komen wat een programma doet louter door naar de uitvoer te kijken (het zogenaamde black-box testen), kunnen we niet goed bij Reverse Engineering toepassen. De software kan oneindig complex zijn, en er is geen garantie dat een programma dezelfde werking heeft in alle omgevingen.
De andere tool voor een locale omgeving is een goede debugger. Vrijwel alle besturingssystemen ondersteunen een zekere mate van foutopsporing. Tijdens het debuggen van de software krijgt de debugger de volledige controle over de applicatie. Met de debugger kunnen we op ieder moment zien wat er in de variabelen en in het geheugenruimte staat en welke programmacode er wordt uitgevoerd. De debugger kan het programma willekeurig starten of pauzeren, de data wijzigen of instellen om te pauzeren als aan bepaalde voorwaarden wordt voldaan.
Met een debugger kunnen we bijvoorbeeld kijken naar de API-aanroepen. Telkens als de software data van het geheugen naar disk wil schrijven, toegang tot internet wil krijgen, iets wil afdrukken of iets anders wil doen is dit met de debugger te achterhalen.
Het beschermen van de broncode van een SaaS applicatie heeft verschillende redenen. Moderne applicaties zijn het resultaat van een dure, ontwikkeltrajecten en moeten we beschermen tegen concurrenten. Naast de economische factor is het ook een probleem van de beveiliging. Hackers zoeken naar de broncode als ze het authenticatieproces willen omzeilen. Een eerste stap kan een On premise Cloud omgeving zijn.
De bescherming tegen Reverse Engineering is niet een volledig uitvoerbaar, maar een goed hanteerbaar probleem. Aanvallers zitten altijd met een belangrijke vraag: “Is de inspanning, die ik moet doen, voldoende t.o.v. de winst die ik eruit haal?”. Het is zaak om de aanvaller zo veel mogelijk te vertragen, in het ideale geval denkt hij dat geen businesscase heeft en het zijn inspanningen niet waard is. Er zijn verschillende oplossingen tegen reverse engineering die een ontwikkelaar kan inzetten, waarvan obfuscatie de belangrijkste is.
Obfuscators transformeren perfecte, door mensen leesbare broncode naar een moeilijk leesbaar formaat. De broncode blijft 100% syntactisch en semantisch correct. Deze strategie resulteert in zeer moeilijk leesbare broncode. Er is echter een tekortkoming, als de software openbare API´s gebruikt, is deze communicatie niet versleuteld. Het kan enige tijd duren, maar de hacker komt er uiteindelijk uit. We moeten wel opmerken dat dit een enorme hoeveelheid tijd kost en veel inzicht vereist in de versleutelde broncode.
Runtime Guards zijn stukjes broncode die op strategische plaatsen zijn ingevoegd. Deze controleren de runtime-omgeving. Enkele veel voorkomende controles die guards kunnen uitvoeren zijn:
Guards kunnen de software afsluiten als een van deze controles een onregelmatigheid bevat.
Dit beschouwd men echter als iets voor experts, omdat het niet eenvoudig is om succesvol te implementeren.
Het moet duidelijk zijn dat het beschermen van code een zeer serieuze en belangrijke taak is. Het moet een standaard stap zijn in de releasecyclus.
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.