Kaip išvengti atvirkštinio apk failo?

Sukuriu „Android“ mokėjimo apdorojimo programą ir noriu, kad įsilaužėlis nesinaudotų jokiais ištekliais, turtu ar šaltiniu iš APK failo.

Jei kas nors pakeis .apk plėtinį į .zip, jie gali išpakuoti ir lengvai pasiekti visus programų išteklius ir turtą, taip pat naudoti dex2jar ir Java decompiler, jie taip pat gali gauti prieigą prie šaltinio kodo. Labai paprasta perkelti „Android“ APK failą - daugiau informacijos žr. „Stack Overflow“ problema. Atnaujinkite projektą nuo APK failo iki projekto .

Naudojau „Proguard“ įrankį, kuris buvo pateiktas su „Android SDK“. Kai perdirbsiu APK failą, sukurtą naudojant pasirašytą klaviatūrą ir „Proguard“, gaunu kodą.

Tačiau „Android“ komponentų pavadinimai lieka nepakitę, o kai kurie kodai, pvz., Pagrindinės reikšmės, naudojamos programoje, lieka nepakitę. Remiantis „Proguard“ dokumentais, įrankis negali užfiksuoti manifesto faile nurodytų komponentų.

Dabar mano klausimai yra:

  1. Kaip galiu visiškai užkirsti kelią „Android“ APK atvirkštinės inžinerijos projektavimui? Ar tai įmanoma
  2. Kaip apsaugoti visus išteklius, išteklius ir programos pradinį kodą, kad įsilaužėliai negalėtų įsilaužti APK failo?
  3. Ar yra būdas padaryti įsilaužimą griežtesnį ar net neįmanoma? Ką dar galiu padaryti, kad apsaugotumėte šaltinio kodą APK faile?
657
13 дек. nustatė sachin003 13 dec. 2012-12-13 09:42 '12 at 9:42 2012-12-13 09:42
@ 32 atsakymai
  • 1
  • 2

1. Kaip galiu visiškai išvengti „Android“ APK atvirkštinio projektavimo? Ar tai įmanoma?

AFAIK, nėra jokio triuko visiškai išvengti atvirkštinės inžinerijos.

Ir taip pat @inazarukas labai gerai pasakė: kad ir ką darytumėte su savo kodu, potencialus užpuolikas gali jį bet kuriuo atveju pakeisti, nes jis mano, kad tai įmanoma. Iš esmės negalite apsaugoti savo programos nuo pakeitimų. Ir bet kokia jūsų įvesta apsauga gali būti išjungta / pašalinta.

2. Kaip apsaugoti visus išteklius, išteklius ir programos pradinį kodą, kad įsilaužėliai bet kokiu būdu negalėtų įsilaužti APK failo?

Jūs galite padaryti skirtingus gudrybės, kad įsilaužimai taptų sudėtingesni. Pavyzdžiui, naudokite „obfuscation“ (jei tai „Java“ kodas). Tai paprastai lėtina žymiai sumažinimą.

3. Ar yra būdas padaryti įsilaužimą sunkesnį ar net neįmanomą? Ką dar galiu padaryti, kad apsaugotumėte šaltinio kodą APK faile?

Kaip visi sako, ir, kaip tikriausiai žinote, nėra 100% saugumo. Tačiau „Android“ vieta, kurią sukūrė „Google“, yra „ProGuard“. Jei turite galimybę įtraukti bendras bibliotekas , galite įtraukti reikalingą C + + kodą, kad galėtumėte patikrinti failo dydį, integraciją ir kt. Jei jums reikia pridėti savo išorinę biblioteką prie kiekvieno „APK“ bibliotekos aplanko, galite jį naudoti taip, kaip siūloma toliau.

Įdėkite biblioteką į šaltinio bibliotekos kelią, numatytasis yra „libs“ jūsų aplanke. Jei sukūrėte savo „armeabi“ tikslui skirtą kodą, įdėkite jį į libs / armeabi . Jei jis buvo pastatytas naudojant armeabi-v7a , tada libs / armeabi-v7a.

 <project>/libs/armeabi/libstuff.so 
327
13 дек. Atsakymą pateikė Bhavesh Patadiya gruodžio 13 d. 2012-12-13 10:03 '12 - 10:03 2012-12-13 10:03

AFAIK, jūs negalite apsaugoti failų, esančių / res kataloge, daugiau nei dabar saugomi.

Tačiau yra priemonių, kurių galite imtis, kad apsaugotumėte šaltinį, arba bent jau tai, ką ji daro, jei ne viskas.

  • Naudokite tokius įrankius kaip „ProGuard“. Jie suklaidins jūsų kodą ir apsunkins nuskaitymą dekompiliavimo metu, jei ne neįmanoma.
  • Perkelkite svarbiausias paslaugos dalis iš programos prie žiniatinklio paslaugos, paslėptos už kalbos serverio pusėje, pvz., PHP. Pvz., Jei turite algoritmą, už kurį parašėte milijoną dolerių. Akivaizdu, kad nenorite, kad žmonės ją pavogtų iš jūsų paraiškos. Perkelkite algoritmą ir apdorokite duomenis nuotoliniame serveryje ir naudokite programą, kad tiesiog pateiktumėte duomenis. Arba naudokite „NDK“, kad galėtumėte juos parašyti .so failams, kurie yra daug mažiau linkę dekompiliuoti nei „apks“. Nemanau, kad šiuo metu .so failų dekompiliatorius net egzistuoja (ir net jei jis būtų, jis nebūtų toks pat geras kaip „Java“ dekompiliatoriai). Be to, kaip minėta @nikolay pastabose, ryšiui tarp serverio ir įrenginio turite naudoti SSL.
  • Saugodami prietaiso vertes, neišsaugokite jų neapdorotu formatu. Pavyzdžiui, jei turite žaidimą ir išsaugote sumą žaidimo valiuta, kurią naudotojas turi „SharedPreferences“. Tarkime, tai yra 10000 monetų. Vietoj to, kad išsaugotumėte 10000 tiesiogiai, išsaugokite jį naudodami tipo algoritmą ((currency*2)+1)/13 . Todėl vietoj 10000 įrašote „ 1538.53846154 1538.53846154. Tačiau aukščiau pateiktas pavyzdys nėra tobula, ir jūs turite dirbti, kad pasiektumėte lygtį, kuri nepraranda valiutos užapvalinimo klaidų ir pan.
  • Panašią užduotį galite atlikti serverio pusėje. Pavyzdžiui, leiskite man iš tikrųjų sutikti su jūsų mokėjimo apdorojimo programa. Tarkime, kad vartotojas turi sumokėti $200 . Vietoj to, kad serveriui būtų siunčiama neapdorota $200 vertė, atsiųskite mažesnių iš anksto nustatytų verčių, kurios yra iki $200 seriją. Pavyzdžiui, serveryje yra failas arba lentelė, kuri prilygsta žodžiams su reikšmėmis. Todėl sakome, kad Charlie atitinka $47 , o John - $3 . Taigi vietoj siuntimo $200 Čilę galite siųsti keturis kartus ir John keturis kartus. Serveryje interpretuokite, ką jie reiškia, ir pridėkite. Tai neleidžia įsilaužėliui siųsti savo serveriui savavališkų verčių, nes jie nežino, kuris žodis atitinka tai, kuri vertė. Kaip papildomą saugumo priemonę galite naudoti lygtį, panašią į 3 dalį, ir keisti raktinius žodžius kas n dienų skaičius.
  • Galiausiai, galite įterpti nenaudingą šaltinio kodą į savo paraišką, kad įsilaužėlis ieško adatos šieno. Įterpkite atsitiktines klases, kuriose yra fragmentų iš interneto, arba tiesiog veikia atsitiktinių dalykų, tokių kaip Fibonacci seka, apskaičiuoti. Įsitikinkite, kad šios klasės yra sukompiliuotos, bet nenaudojamos tikrosios programos funkcijos. Pridėkite pakankamai šių klaidingų klasių, o įsilaužėliui bus sunku rasti jūsų tikrąjį kodą.
border=0

Apskritai jūsų prašymas negali būti apsaugotas 100%. Jūs galite padaryti jį sunkiau, bet ne neįmanoma. Jūsų žiniatinklio serveris gali būti nulaužtas, įsilaužėlis gali atpažinti jūsų raktinius žodžius, sekti sandorių skaičių ir raktinius žodžius, kuriuos siunčiate jam, įsilaužėlis gali kruopščiai eiti per šaltinį ir išsiaiškinti, kuris kodas yra manekenas.

Jūs galite atsispirti, bet niekada nugalėti.

118
13 дек. Atsakymą pateikė Raghav Sood 13 d. 2012-12-13 10:07 '12 - 10:07 2012-12-13 10:07

Kompiuterijos istorijoje niekada nebuvo įmanoma užkirsti kelią programinės įrangos atvirkštinės inžinerijos kūrimui, kai jūs pateikiate darbo kopiją užpuolikui. Be to, greičiausiai niekada nebus įmanoma .

Turint tai omenyje, yra akivaizdus sprendimas: neduokite savo paslapčių savo užpuolikui. Nors negalite apsaugoti savo APK turinio, galite apsaugoti viską, ką neplatinate. Paprastai tai yra serverio programinė įranga, naudojama tokioms operacijoms kaip aktyvinimas, mokėjimai, taisyklės ir kiti sultingi kodų bitai. Jūs galite apsaugoti savo vertingą turtą neplatindami jų APK. Vietoj to, sukonfigūruokite serverį, kuris reaguoja į jūsų paraiškos užklausas, „naudoja“ turtą (nepriklausomai nuo to, ką reiškia), o tada siunčia rezultatą atgal į programą. Jei šis modelis neveikia turint omenyje turimą turtą, galite pagalvoti apie savo strategiją.

Be to, jei jūsų pagrindinis tikslas yra užkirsti kelią taikomųjų programų piratavimui : nesijaudinkite. Jūs jau sudeginote daugiau laiko ir pinigų šiai problemai, nei bet kokia kovos su piratavimu priemonė galėjo tikėtis taupyti jus. Investicijų grąža siekiant išspręsti šią problemą yra tokia maža, kad nėra prasmės net galvoti apie tai.

103
13 дек. Atsakymas, kurį pateikė tylerl 13 gruodis 2012-12-13 11:28 '12 11:28 2012-12-13 11:28

Pirmasis „Application Security“ taisyklė: bet kuris kompiuteris, į kurį užpuolikas pasiekia neribotą fizinę ar elektroninę prieigą, dabar priklauso jūsų užpuolikui, nesvarbu, kur jis iš tikrųjų yra arba už kurį mokėjote.

Antroji „Application Security“ taisyklė: bet kokia programinė įranga, kuri palieka fizines ribas, per kurias užpuolikas negali įsiskverbti, priklauso jūsų užpuoliui, nesvarbu, kiek laiko praleidžiate koduojant.

Trečioji taisyklė: bet kokia informacija, kuri palieka tas pačias fizines ribas, kurias užpuolikas negali įsiskverbti dabar, priklauso jūsų užpuolikui, nesvarbu, kokia vertinga tai jums.

Informacijos saugumo pagrindai grindžiami šiais trimis pagrindiniais principais; vienintelis tikrai apsaugotas kompiuteris yra tas, kuris yra užrakintas į saugų vidų Farraday narve, esančiame plieno narve. Yra kompiuterių, kurie didžiąją savo gyvenimo dalį praleidžia tik šioje būsenoje; kartą per metus (arba mažiau) jie sukuria slaptus raktus patikimoms šaknų sertifikavimo institucijoms (prieš daugelį liudytojų, turinčių kamerų, kuriose įrašomos kiekvienos patalpos, kurioje jie yra, colių).

Dabar dauguma kompiuterių nėra naudojami tokiose aplinkose; jie yra fiziškai viešai prieinami, prijungti prie interneto belaidžiu būdu. Trumpai tariant, jie yra pažeidžiami, kaip ir jų programinė įranga. Todėl jie neturėtų pasitikėti. Yra tam tikrų dalykų, kuriuos kompiuteriai ir jų programinė įranga turi žinoti ar daryti, kad būtų naudingi, tačiau reikia pasirūpinti, kad jie niekada nežinotų ar nepakankamai padarytų žalą (bent jau ne nuolatinė žala už šios ribos). vienintelis automobilis).

Jau visa tai žinojote; kodėl bandote apsaugoti savo paraiškos kodą. Bet tai yra pirmoji problema; Obfuscation įrankiai gali padaryti kodą asmeniui nenaudingu pabandyti paslysti, tačiau programa vis dar turi dirbti; Tai reiškia, kad faktinis loginis programos ir jos naudojamų duomenų srautas neatskleistas. Nedidelis atkaklumas, užpuolikas gali paprasčiausiai neužslėpti kodo, o kai kuriais atvejais net nebūtina, kai jis atrodo, negali būti kažkas kita, išskyrus tai, ko jis ieško.

Vietoj to, jūs turite būti tikri, kad užpuolikas negali nieko daryti su jūsų kodu, nesvarbu, kaip lengva jam gauti aiškią kopiją. Tai reiškia, kad neužkoduotos paslaptys, nes šios paslaptys nėra slaptos, kai tik kodas išeina iš pastato, kuriame jį sukūrėte.

Šios pagrindinės reikšmės, kurias sugalvojote, turi būti visiškai pašalintos iš programos šaltinio kodo. Vietoj to, jie turėtų būti vienoje iš trijų vietų; nepastovi prietaiso atmintis, kuri yra sudėtingesnė (bet vis dar neįmanoma) užpuolikui gauti neprisijungusią kopiją; nuolat serverių grupėje, su kuria jūs valdote prieigą su geležine kumščiu; arba antroje duomenų saugykloje, nesusietoje su jūsų prietaisu ar serveriais, pvz., į fizinę kortelę ar vartotojo atmintį (tai reiškia, kad galiausiai jis bus nepastovioje atmintyje, tačiau jis neturi trukti ilgai).

Apsvarstykite šią schemą. Naudotojas, naudodamas atmintį, į savo įrenginį įveda savo duomenis. Deja, turite pasitikėti, kad keylogger ar trojanas dar nepažeidė vartotojo įrenginio; Geriausias dalykas, kurį galite padaryti šiuo atžvilgiu, yra daugiafunkcinio saugumo įgyvendinimas, turint omenyje sunkią identifikavimo informaciją apie prietaisus, kuriuos naudojo vartotojas (MAC / IP, IMEI ir tt), ir pateikdamas bent vieną papildomą kanalą, kuris galima patikrinti, kai bandote prisijungti prie nepažįstamo įrenginio.

Įvedus kredencialus, kliento programinė įranga (naudojant saugų maišą) yra paini, o paprastieji tekstai yra atmesti; jie tarnavo savo tikslui. Užblokuoti kredencialai siunčiami per saugų kanalą į autentifikuotą serverį, kuris vėl ištrina juos, kad gautų duomenis, naudojamus prisijungimo galiojimo patvirtinimui. Taigi, klientas niekada nežino, kas iš tikrųjų lyginama su duomenų bazės verte, taikomųjų programų serveris niekada nežino paprasto teksto kredencialų už tai, ką jis tikrina, duomenų serveris niekada nežino, kaip duomenys saugomi patikrinimai, o viduryje esantis asmuo mato tik nesąmonę, net jei saugomas kanalas buvo pažeistas.

Po patikrinimo, serveris siunčia žetoną atgal per kanalą. Ženklas yra naudingas tik saugioje sesijoje, susidedančioje iš atsitiktinio triukšmo arba užšifruoto (ir todėl patikrinamo) sesijos identifikatorių kopijos, o kliento programa turi siųsti šį ženklą tame pačiame kanale serveriui kaip dalį bet kokio prašymo atlikti kažką. Kliento programa tai padarys daug kartų, nes ji negali daryti nieko, įskaitant pinigus, konfidencialius duomenis ar ką nors, kas gali pakenkti sau; jis turėtų paprašyti serverio atlikti šią užduotį. Kliento taikomoji programa niekada neperrašys konfidencialios informacijos į pačią prietaiso nuolatinę atmintį, bent jau ne paprasto teksto forma; klientas gali paprašyti serverio per saugų kanalą, skirtą simetriniam raktui užšifruoti visus vietinius duomenis, kuriuos serveris prisimins; vėlesnėje sesijoje klientas gali paprašyti serverio tuo pačiu raktu iššifruoti duomenis, skirtus naudoti nepastovioje atmintyje. Šie duomenys nebus vienintelė kopija; viskas, ką klientas saugo, taip pat turi būti perduota tam tikra forma į serverį.

Akivaizdu, kad jūsų paraiška labai priklauso nuo interneto prieigos; Kliento įrenginys negali atlikti jokių pagrindinių funkcijų be tinkamo ryšio su serveriu ir autentifikavimo. Nieko, tik „Facebook“.

Dabar kompiuteris, kurį nori užpuolikas, yra jūsų serveris, nes jis, o ne klientas / prietaisas, gali padaryti jį pinigais arba pakenkti kitiems žmonėms dėl jo malonumo. Tai normalu; gausite daug daugiau štampų, kad išleistumėte pinigus ir pastangas užtikrinti serverį, nei bandyti apsaugoti visus klientus. Serveris gali būti už visų ugniasienių ir kitų elektroninių saugos tipų, taip pat gali būti fiziškai prijungtas prie plieno, betono, klaviatūros / kaiščio prieigos ir visą parą veikiančios vaizdo stebėjimo. Jūsų užpuolikas turi būti labai sudėtingas, kad galėtumėte tiesiogiai patekti į serverį, ir jūs turite tai nedelsiant žinoti.

Geriausias dalykas, kurį gali padaryti užpuolikas, yra pavogti vartotojo telefoną ir kredencialus ir prisijungti prie serverio su ribotomis klientų teisėmis. Jei taip atsitiks, taip pat praradus kreditinę kortelę, teisėtas vartotojas turėtų būti paskambintas skambinti 800 (pageidautina lengva prisiminti, o ne kortelės gale, kurį jie turės savo piniginėje, piniginėje ar portfelyje, kurie gali būti pavogti kartu su mobiliuoju prietaisu) iš bet kurio telefono, prie kurio jie gali prisijungti, \ t Jie teigia, kad jų telefonas buvo pavogtas, pateikti tam tikrą pagrindinį unikalų identifikatorių, o paskyra užblokuota, bet kokie veiksmai, kuriuos užpuolikas galėjo apdoroti, grįžta atgal ir užpuolikas grįžta į aikštę.

77
13 дек. KeithS atsakymas gruodžio 13 d 2012-12-13 22:39 '12, 10:39 pm 2012-12-13 22:39

1. Kaip galiu visiškai išvengti „Android“ APK atvirkštinio projektavimo? Ar tai įmanoma?

Tai neįmanoma

2. Kaip apsaugoti visus išteklius, išteklius ir programos pradinį kodą, kad įsilaužėliai bet kokiu būdu negalėtų įsilaužti APK failo?

Kai kas nors pakeis .apk plėtinį į .zip, po išpakavimo kažkas gali lengvai gauti visus išteklius (išskyrus „Manifest.xml“), tačiau su APKtool galite gauti tikrąjį manifesto failo turinį. Vėlgi, ne.

3. Ar yra būdas padaryti įsilaužimą sunkesnį ar net neįmanomą? Ką dar galiu padaryti, kad apsaugotumėte šaltinio kodą APK faile?

Vėlgi, ne, bet jūs galite užkirsti kelią tam tikram lygiui, ty

  • Atsisiųskite išteklių iš interneto ir atlikite šifravimo procesą.
  • Naudoti iš anksto sukompiliuotą šaltinio biblioteką (C, C ++, JNI, NDK)
  • Visada atlikite keletą problemų ( MD5 / SHA arba bet kokia kita logika)

Net su Smali žmonės gali žaisti su jūsų kodu. Apskritai tai nėra įmanoma.

65
13 дек. Atsakymą pateikė Azhar Shaikh . 2012-12-13 10:11 '12 10:11 2012-12-13 10:11

100% „Android“ APK išvengimas yra neįmanomas, tačiau jūs galite naudoti šiuos metodus, kad išvengtumėte daugiau duomenų, pvz., Šaltinio kodo, APK ir išteklių:

  • Naudokite „ProGuard“, kad užblokuotumėte programos kodą.

  • Naudokite „NDK“ su „C“ ir „C ++“, kad įdėtumėte savo programos branduolį ir pateiktumėte kodą .so failuose

  • Jei norite apsaugoti išteklius, į visas APK turinio aplanko neįtraukite visų svarbių išteklių. Atsisiųskite šiuos išteklius pirmą kartą paleidę programą.

35
13 дек. atsakymą pateikė ρяσсρєя K 13 d 2012-12-13 10:07 '12 - 10:07 2012-12-13 10:07