Hvordan undgår man reverse engineering af din Android-app?

Android-apps kan omvendt konstrueres ved hjælp af nogle specielle reverse engineering-værktøjer. Derfor er det meget vigtigt for en udvikler at sikre en Android-app sikker ved at bruge nogle trin, der forhindrer dekompilering af kode. Ved at sætte vigtig kode på serveren, bruge Proguard, tilføje multifaktor-godkendelse, kan en udvikler gøre en Android-app mere sikker.

Hvordan undgår man reverse engineering af din Android-app?

Ifølge en rapport udgivet af Cvedetails (den ultimative datakilde for sikkerhedssårbarhed) så det ud til, at Android havde et samlet antal af 322 sikkerhedsfejl i 2017. Heraf var 23% af de fejl, der blev offentliggjort i 2018, kritiske, og 13% af dem tilladte ondsindet kode til at udføre. Det er klart, at dette er en dårlig nyhed for Android-appudviklere, for de fleste af deres kunder er sikkerhedskritiske som f.eks. Finansielle og sundhedsmæssige. I denne artikel diskuterer vi den bedste praksis for at beskytte en Android-app mod reverse engineering. Vi vil se på nogle faktorer, der gør en Android-app tilbøjelig til kodedekompilering og en løsning på, hvordan du forhindrer din Android-app i reverse engineering.

Hvad vi vil lære her:

  • Hvad er Reverse Engineering i Android
  • Hvordan Reverse Engineering kan bruges til at dekompilere Android-appkode
  • Hvad er nogle trusler mod en dekompileret Android-kode
  • Sådan undgås dekompilering af Android-apper for at forhindre omvendt konstruktion

Hvad er Reverse Engineering i Android

Folk omfavner ofte Android's åbne natur, da det er noget, der giver innovatører mulighed for at bygge banebrydende produkter. Men kun nogle få kender den mørke side af denne åbenhed - Sårbarhed. Når det er sagt, tilbyder Android appudviklere en stor fordel, som de fleste mobile OS ikke gør. Som en open source-ramme er det relativt let for en appudvikler eller reverse engineer at studere dens kildekode i Android Open Source Project (AOSP) og ændre det, som de vil. Den teknik, hvorigennem de fleste reverse-ingeniører genvinder kildekoden, enten med det formål at genskabe programmet, at bygge noget, der ligner det, eller til at identificere en app's svaghed eller styrke dets sikkerhed er kendt som Reverse Engineering i Android.

Hvordan Reverse Engineering kan bruges til at dekompilere Android-appkode

Android-apps er altid sårbare over for angreb, da koden ikke gengives til maskinkode, hvilket efterlader den udsat for ekstraktion og omvendt konstruktion. Den sårbare kode kan derefter bruges af forskellige årsager, hvilket kan være afskrækkende for enhver seriøs mobilapp-forretning, såsom:

  • Genbrug af koden til egen fordel
  • Find sårbarheder i koden
  • Søg efter følsomme data, der er hardkodet i koden
  • Malware fiskeri
  • Ændring af en eksisterende applikations funktionalitet

Hvad er nogle trusler mod en sårbar Android-kode?

Problemer med Android-malware og sikkerhed

Android-apps har alvorlige trusler fra forskellige typer malwares såsom spywares, trozan, ad-ware osv. Selvom nogle af malwares ikke er beregnet til at forårsage nogen skade, er der dog nogle malware, der kan føre til uventede og uønskede problemer som lokaliseret nægtelse af service, unormal batteriafløb osv. Desuden kan malwares som Spywares få adgang til en smartphones kamera eller mikrofonmodul for at sende data tilbage til angribere. Adware er en anden type malware, der bruger de eksisterende forskellige kommunikationskanaler som e-mail, IM, MMS, Bluetooth eller SMS osv. Til at overføre skadelige reklamer til bestemte antal mennesker.

Sikkerhedstrusler på grund af afkompilering af kode i Android

En udpakket kode kan resultere i nedsat sikkerhed, frit tilgængelige køb i appen og kan føre til vildledende brugerdata, der kan resultere i dårlig priselasticitet. Dette er nogle af de almindelige grunde til, at nogen de-kompilerer din kode, og du kan nu forstå lidt af den skade, de kan sætte dig igennem.

I Enterprise Mobile-applikationsudvikling er sikkerhed endnu mere bekymret, da de fleste af apps er datatunge, såsom Finansielle apps eller Healthcare-apps.

Vi støder ofte på tråde som denne,

Et godt firma vil aldrig gå bag deres klienter og udvikle en lignende app til en rival, og de fleste udviklere vil ikke efterlade deres navn inden for appens kode. Imidlertid efterlader nogle få udviklere deres navn i kommentarerne, som derefter kan bruges til at udtrække agenturet eller freelancer, der udviklede det. Men det er ikke det, jeg vil have, at du tager fra denne tråd. I øjeblikket skal du forstå og bemærke, at folk aktivt prøver at dekompilere dine apps, og du er nødt til at gøre noget ved det.

For yderligere at illustrere alvoret skitserer denne tråd tydeligt, hvor let man kan dekompilere din APK, selvom den er krypteret. Brendan var i stand til at dekompilere en TwoFish-krypteret betalt app ved hjælp af kun et par værktøjer.

Så hvordan forhindrer du nogen i at få adgang til kildekoden?

Sådan undgås dekompilering af Android-apper for at forhindre omvendt konstruktion

I ovenstående afsnit så vi, hvor let det er at dekompilere en Android-app. I tekniske termer kræver en hacker kun at omdanne DEX-filer til JAR-filer og disse JAR-filer tilbage til kildekoden. Dermed bliver det muligt at udtrække en apps kildekode. Der er mange værktøjer, der bruges til at reverse engineering af en Android-app, såsom dex2jar, Apktool, jd-gui, JAD osv.

Det er dog stadig muligt at forhindre reverse-engineering af Android-appen ved at tage sig af få punkter. Lad os se på disse punkter for at sikre det højeste sikkerhedsniveau for at forhindre dekompilering af koden i Android-apps:

1) Læg vigtig kode på en server

Du kan stole på eksterne procedureopkald til en godt beskyttet server. Dette reducerer risikoen for, at dine koder bliver stjålet, da koden altid vil forblive på serveren, og intet andet end resultaterne kan ses. Dette har dog en mangel, hvis din app skal bruges af mange brugere (millioner), skal du have en enorm servergård.

En servergård er en enorm udgift, og det meste af tiden er ikke en levedygtig løsning. I tilfælde af lav netværksforbindelse forlader den desuden din kode skrøbelige og tilføjer frustration for dine brugere.

100% kodesikkerhed er dyrt, men den gode nyhed er, at du sandsynligvis ikke har brug for den. En bedre løsning er at opbevare den kode, du ikke ønsker at komme ud, i en hardware, du kontrollerer. Når du holder op med at distribuere de vigtigste dele, gør det angriberens arbejde meget mere smertefuldt. At forsøge at beskytte alle klient-apps betyder også en tung investering og mindre ROI. Mens beskyttelsen af ​​en server er meget lettere - både elektronisk og fysisk.

For at tilføje mere sikkerhed kan du også tilføje dobbelt tilsløring for at tackle enhver "mand i midten" -angreb. Appen sender desuden altid det modtagne token til serveren for at anmode om handlinger, der skal udføres. Google Wallet er et sådant eksempel, de er meget afhængige af symboler til at behandle anmodninger.

Hvad kan du ellers gøre?

Brug Proguard

Det er et tilsløret værktøj, der hjælper med at beskytte applikationer ved hjælp af en licenseret server. Det øger vanskeligheden med at 'vende' din kode. DexGuard, en kommerciel version af Proguard, går en ekstra kilometer og hjælper lidt mere. Men din kode kan altid konverteres til samli, som kan bruges af udviklere til at lære, hvad du gør med den. Igen, hvis du ikke ønsker, at andre skal se din kode, skal du ikke gemme den på deres enhed.

2) Debugger-påvisningsteknikker

Der er nogle andre kreative måder at beskytte din kode fra at dekompilere. De involverer brug af debugger-detekteringsteknikker, som du kan bruge til at forhindre køretidsanalyse og kombinere den med kryptering af dele af binære koder. Men enhver entusiastisk angriber kan finde en måde at omgå det på. Hvis du leder efter mere information om en bestemt debugger-detektionsmetode, skal du se på OpenRCE Anti Reverse Engineering Techniques Database. Det giver analyse og beskrivelser for forskellige anti-debugging, demontering og dumping-tricks. Mange af teknikkerne er anført i forbindelse med et specifikt mål, men de kan være tilpasningsdygtige til andre mål.

3) Skriv vigtige dele af koden i C / C ++

Du kan også skrive de vigtige dele af din kode i C / C ++ og tilføje dem som et samlet bibliotek. Selvom det kan adskilles i samlingskode, er reverse engineering et stort bibliotek fra samling ekstremt tidskrævende. Java er lettere at dekompilere i sammenligning med C / C ++.

4) Skriv filer oprindeligt i .so filer

Ved hjælp af NDK kan du skrive filerne indfødt i .so filer, som meget mindre sandsynligt vil blive dekompileret end APK'er. Der er et par gode dekompilatorer tilgængelige, men det kræver, at angriberen er dygtig til ARM-processorarkitektur, assemblersprog, JNI-konventioner og Compiler ABI. Du giver den dygtige angriber et par søvnløse nætter.

5) Tilslør værdier, når du gemmer dem på mobilen

For ikke at beskytte din apps ressourcer, når du gemmer værdier på enheden, skal du ikke gemme dem i et råt format. Opbevar dem i form af en eller anden algoritme, dvs. 50 belønningspunkter i din app kan være (x * (x² + 1 - neutraliseringsfaktor)) / (x + 1). Du skal dog optimere din algoritme, så du ikke ender med at gå på kompromis, mens du afretter værdier.

6) Tilføj multifaktorsikkerhed

Det er ekstremt vigtigt at forhindre angriberen i at få adgang fra brugerens enhed selv. Du kan også gøre angriberne arbejde vanskelige ved at tilføje multifaktorsikkerhed ved at huske oplysningerne om enhederne og give yderligere kanaler til at identificere et loginforsøg fra en ukendt enhed.

Nogle foreslår endda brug af værktøjer som HoseDex2Jar, men det er meget let at besejre. Faktisk fungerer værktøjer som smali og apktools fint med disse APK'er.

Hvordan Matlab forhindrede deres Android-app i Reverse Engineering

En inspirerende anti-piratkopiering foranstaltning kommer fra Matlab, en desktopbaseret software. Matlab beskytter kilden til en implementeret applikation ved at 'Distribuere som P-kode' eller 'Kompilere i binært format' Dette gælder dog ikke for Android, da det er åbent og rodbar. Angriberen kan nemt finde nøglen fra selve systemet. At have adgang til systemet indebærer at have adgang til nøglerne.

Tanken er at stoppe angriberen så meget som muligt. Desværre kan en bestemt hacker altid få adgang til dine koder, nå din server, se dine anmodninger og finde nøgleordene.

Vær opmærksom på nedenstående tekst, der stammer fra principperne om fundamentet for informationsteknologi sikkerhed:

  1. Hver gang nogen får fysisk eller elektronisk adgang til maskinen, tilhører maskinen angriberen.
  2. En angriber kan ikke trænge ind i koden i dine systemer, men angriberen kan trænge ind i koden, når den forlader de uigennemtrængelige fysiske grænser.
  3. Når information forlader utilgængelige grænser, kan en angriber altid få disse oplysninger.

7) Vær forsigtig, mens du implementerer SSL

Udviklere implementerer ofte SSL-certifikater for bedre sikkerhed for deres kode over serveren. På Android gøres det ofte ved at definere flere metoder i en klasse, der implementerer SSLSocketFactory-interface. Et problem med disse typer metoder er, at de kan acceptere alle former for certifikater, der gør en Android-kode sårbar overfor mellemangreb (MitM). Der er også et stort omfang af tab af fortrolighed for data, der overføres via SSL / TLS-protokoller. En angriber kan nemt bryde forbindelsen og få værdifulde data ved blot at give selvsigneret certifikat. Her er hvorfor du skal være forsigtig, mens du implementerer et SSL-certifikat på Android.

8) Sikker brugeroplysning med ekstra omhu

Det anbefales at sikre dine brugeroplysninger med et ekstra sikkerhedslag for at undgå reverse engineering af applikationen. Som tommelfingerregel skal legitimationsoplysninger ikke genbruges på mange steder. Dette vil forhindre sandsynligheden for, at en app kan konstrueres omvendt. Derudover skal legitimationsoplysninger ikke gemmes på enheden. Hvor det er muligt, skal du bruge et kortvarigt autorisationstoken til at beskytte din kontotilgang.

9) Brug hash-funktioner såsom PBKDF2, bcrypt, scrypt

Størstedelen af ​​hashfunktioner såsom MD2, MD5, SHA1 er ikke sikre og tilbøjelige til malware-angreb på Android. Når det er sagt, hvis de bruges til at gemme fortrolige oplysninger, kan sikkerhed let kompromitteres. Brug i stedet sikre funktioner såsom SHA-2. En typisk hashfunktion skal være modstandsdygtig over for kollisioner og ikke for hurtig. Hvis en hash-funktion er for hurtig, komplicerer den angrebet ved udtømmende søgning. Til dette specifikke formål udvikles specialiserede hashfunktioner såsom PBKDF2, bcrypt, scrypt.

10) Krypter din database for at forbedre Mobile Security

Mobilsikkerhed i Android kan også forbedres ved at sikre databasefiler. Hvis du bruger SQLite, anbefales det at bruge SQLCipher-udvidelse, som er fuldstændig open source. Skønt SQlite er ret populær blandt iOS-udviklere, kan Android-udviklere også bruge fordelene ved kryptering og dermed drage de største fordele ved det med hensyn til sikkerhed.