Is het echt onmogelijk om Android-apps te beschermen tegen reverse-engineering?

Zoals we weten, zijn Android-apps geschreven in Java. In Java maakt het niet uit wat u doet , is het onmogelijk om gecompileerde code te beschermen tegen decompilatie of reverse-engineering, zoals de Stack Overflow-vraag Hoe gecompileerde Java-klassen vergrendelen om decompilatie te voorkomen?suggereert.

Hoe zou je een app die algoritmische handelsgeheimen bevat beschermen tegen reverse-engineering?

Met “hoe” bedoel ik niet alleen softwaretechnieken, maar ook andere creatievebenaderingen.


Antwoord 1, autoriteit 100%

De eerste stop voor mij zou zijn om de code te optimaliseren en te verdoezelen met ProGuardwaarvan bekend is dat het werkt met bytecode gericht op Android’s DalvikVM (via Dex). Het is echt een geweldig hulpmiddel en kan de moeilijkheid van het ‘omkeren’ van uw code vergroten terwijl de voetafdruk van uw code wordt verkleind (in sommige gevallen dramatisch: een recente applet van mij ging van ongeveer 600 KB naar ongeveer 50 KB).

Zoals anderen zeggen, krijgt u nooit 100% beveiliging van de details van uw algoritme terwijl de implementatie ervan naar klanten wordt gedistribueerd. Daarvoor moet u de code alleen op uw servers bewaren. Pogingen tot bijna 100% procent beveiliging voor klantcode komen in feite neer op DRMen kunnen uw klantcode maken kwetsbaar in het licht van netwerkstoringen en frustreert over het algemeen (legitieme) gebruikers.

De blog van Android-ontwikkelaars bevat enkele nuttige artikelenover deze kwestie van ‘manipulatiebestendige’ Android-apps (en ze raden het gebruik van ProGuard aan als onderdeel van de algemene aanpak).

Met betrekking tot ‘creatieve’ benaderingen: sommige ontwikkelaars gebruiken debugger-detectie techniekenom runtime-analyse te voorkomen en dit te combineren met codering van delen van binaire code (om statische analyse af te schrikken), maar om eerlijk te zijn, een vastberaden genoeg aanvaller kan omzeiltdeze, terwijl het legitieme gebruikersfrustratie kan veroorzaken, zoals geïllustreerd door het Windows KB-artikel Games: Foutmelding: Er is een debugger gedetecteerd: verwijder de debugger en probeer het opnieuw. De dvd-software ‘Leren rijden’ van mijn vriendin werkt om deze reden niet onder VirtualBox, maar zij geeft Linux natuurlijk de schuld!

OpenRCEen Wikipedia’s artikel over verduisterde codekan een goed uitgangspunt zijn als je dit verder wilt onderzoeken. Maar wees gewaarschuwd, u kunt meer verliezen door overijverig gebruik van deze technieken die uw gebruikers frustreren dan door het verlies van handelsgeheimen door reverse engineering. Zoals Anton S zegt, misschien ligt de meest ‘creatieve’ benadering bij het aanpassen van het bedrijfsmodel in plaats van de technologie.

De nieuwste Android SDK-update op 6 december 2010 (samenvallend met Android 2.3 Gingerbread-release):

Geïntegreerde ProGuard-ondersteuning: ProGuard wordt nu geleverd met de SDK Tools. Ontwikkelaars kunnen hun code nu verdoezelen als een geïntegreerd onderdeel van een release-build.


Antwoord 2, autoriteit 19%

Als het mogelijk is: externe procedure roept een goed beveiligde server op (de server heeft de code die u wilt beschermen).


Antwoord 3, autoriteit 10%

Maak het zo goedkoop om je druk over te maken en bouw je bedrijfsmodel niet op geheimen die aan de kant van de klant worden uitgevoerd. Met andere woorden, deel je geheimen niet.


Antwoord 4, autoriteit 7%

Het is onmogelijk om een ​​client-side code te beschermen tegen reverse engineering. U kunt gewoon meer of minder efficiënte manieren gebruiken om uw code te verdoezelen. En een geoptimaliseerde x86-assembler is een behoorlijk goede verduistering.

Dus als je algoritmische geheimen hebt, plaats ze dan aan de serverzijde.


Antwoord 5, autoriteit 4%

Gecompileerde Java-klassen vergrendelen om decompilatie te voorkomen

Dat kan niet. Elk plan kan worden verslagen door iemand met voldoende vaardigheden, tijd en motivatie.

(Overigens geldt dit ook voor software die naar binair is gecompileerd. Het enige verschil is de hoeveelheid inspanning die het decompileren kost.)

Mijn vraag is hoe je een app die algoritmische handelsgeheimen bevat, zou beschermen tegen reverse-engineering?

Installeer de app gewoon niet op de telefoon van de gebruiker. Of (handiger), voer de code uit die de handelsgeheimen bevat op een externe (goed beveiligde) server.


Antwoord 6, autoriteit 3%

Je kunt je applicatie niet volledig beschermen, omdat er altijd iemand zal zijn die hem zal kraken…

Je zou ze echter kunnen hinderen door je applicatie gratis te maken, of in ieder geval spotgoedkoop, zodat mensen er geen last van hebben.

Als alternatief, probeer je Android-applicatie “dom” te houden, zoals in het bewaren van alle geheime bedrijfslogica op een backend-server, en laat je app gegevens weergeven met behulp van een of andere vorm van blootgestelde service.


Antwoord 7

Wat je ook doet, je kunt het in ieder geval heel moeilijk maken om te decompileren, maar: als iets wordt uitgevoerd/berekend in een programma, moet de informatie over het algoritme aanwezig zijn, en er zal altijd een mogelijkheid zijn om erachter te komen hoe je dat kunt krijgen (genoeg vaardigheid en motivatie van je tegenstanders verondersteld). Altijd.


Antwoord 8

Ik heb mijn algoritme op een server en ik roep die service op via mijn smartphone-app. Een dader kan mijn smartphone-app reverse-engineeren om mijn protocol met mijn server te zien. Ik kan mijn algoritme beschermen, maar ik kan niet beschermen tegen ongeoorloofd gebruik van mijn service. Ik moet deze realiteit accepteren zonder een oplossing. Ik moet tevreden zijn dat zolang ik geld verdien met mijn eigen service, ik moet leven met het potentieel van anderen die mijn service overhevelen.


Antwoord 9

U wilt een creatieve aanpak, hier is er een.

Wat is het hoofdprogramma op telefoons die vandaag niet zijn gedecompileerd? Radio-firmware. Waarom? Het draait niet op de ARM-chipset van de telefoon, maar op een aparte Qualcomm Hexagondat steeds meer aanwezig is in smartphones. Het is geen x86, het is geen ARM, het gebruikt een eigen architectuur en instructies van Qualcomm.

  • Java-decompilatie is eenvoudig.

  • ARM-decompilatie is moeilijker (Hex-Rays Decompiler-licenties)
    begin bij 1129 USD… en de mix tussen duimcode en standaard ARM-code in binaire bestanden is lastig) => je zou kunnen proberen te compileren met de Android
    NDK.

  • Er zijn momenteel geen Hexagon-decompilers! En QDSP-specificaties zijn niet publiekelijk beschikbaar, zelfs niet illegale versies.

De vraag is of een onafhankelijke softwareleverancier de Hexagon-firmware kan gebruiken die is opgenomen in de telefoons voor de massamarkt? Het lijkt de richting te zijn die Qualcomm inslaat. Bekijk hun website en de SnapDragon-producten.

NB: ik ben niet pro-Qualcomm noch pro-closed-source. Maar dit draadje spreekt dit soort oplossingen aan.


Antwoord 10

Je kunt je Android-code niet 100% beveiligen tegen reverse-engineering.
Als u een sleutel wilt beveiligen, kunt u hulp gebruiken door een server te integreren die u een versleutelde sleutel geeft terwijl u de webservice aanroept en die sleutel in uw code gebruikt.

Other episodes