Vi publiserer applikasjoner på Google Play og tjener millioner. Slik bruker du appsigneringsfunksjonen på Google Play Slik signerer du en apk med en original signatur
Så du har jobbet mange dager (og kanskje til og med netter), og nå er din første hybride mobilapplikasjon klar. Det er ganske stabilt, de fleste av de kritiske feilene er lukket. Det er små igjen, men når du husker at perfeksjonisme er ondskap, tar du en viljesterk beslutning om å publisere søknaden.
En forutsetning for dette er tilstedeværelsen av en signert APK-fil. Du vil lære hvordan du signerer en apk-fil i denne artikkelen.
Et lite tilfluktssted
Da kjæledyrprosjektet mitt nærmet seg utgivelse, begynte jeg å lete etter informasjon om hvordan du raskt og smertefritt publiserte en søknad. Mange av instruksjonene som ble funnet så enkle ut. Jeg valgte instruksjonene fra forfatterne av Ionic-rammeverket, som applikasjonen ble utviklet på. Ikke alt ordnet seg første gang, det er flere særegenheter. Signeringsprosessen er beskrevet i denne artikkelen, med viktige punkter fremhevet.Innledende data
Jeg antar at du har alt satt opp for å utvikle hybrider. mobilapplikasjoner bruker Apache Cordova. Må installeres:- Apache Cordova
- Java Development Kit
- Android SDK-verktøy
Gå
Først må du lage en utgivelse av applikasjonen din. Men før det, la oss sørge for at alle unødvendige plugins er fjernet. For eksempel trenger vi ikke en plugin som sender ut feilsøkingsinformasjon til konsollen. La oss slette det:$ cordova plugin rm cordova-plugin-console
For å generere en utgivelse for Android, bruk kommandoen bygge med et flagg --utgivelse:
$ cordova build --slipp android
Denne kommandoen vil opprette usignert APK-fil i katalogen:
Plattformer/android/build/outputs/apk
For eksempel plattformer/android/build/outputs/apk/ android-release-unsigned.apk. Da må vi signere denne filen og kjøre verktøyet zipalign for å optimalisere og klargjøre filen for Google Play.
For å signere en fil trenger du et sertifikat. La oss lage det ved å bruke verktøyet nøkkelverktøy som er inkludert i JDK:
$ keytool -genkey -v -keystore lcf.keystore -alias lcf -keyalg RSA -keysize 2048 -validity 10000
Viktig
Verdien av parameteren -alias må huskes, eller enda bedre skrives ned. I eksemplet ovenfor er det lik lcf (basert på de første bokstavene i applikasjonsnavnet Loyal Client Free). Jeg vil ikke gi detaljer her, hvis du er interessert, skriv i kommentarene, jeg vil fortelle deg mer detaljert.Aliaset brukes hver gang du signerer * applikasjoner. For å gjøre det enklere å huske, bruk navnet på nøkkellagerfilen som et alias, for eksempel:
-keystore hello-world.keystore -alias hello-world -keystore weather-app.keystore -alias weather-app -keystore todo.keystore -alias todo
* Du må signere applikasjonen hver gang oppdateringer utgis
Nytte nøkkelverktøy stiller en rekke spørsmål. Det vil være 8 av dem totalt. For å ha en ide om spørsmålene og omtrentlige svar på forhånd, er de alle gitt nedenfor, under spoileren.
Keytool spørsmål og eksempler på svar på dem
1. Skriv inn passord for nøkkellager:
Her må du skrive inn et passord for filen (minst 6 tegn). Det oppgitte passordet må skrives ned på et trygt sted, det er nødvendig hver gang du signerer søknaden.
2. Skriv inn nytt passord på nytt:
Skriv inn passordet ditt på nytt.
3. Hva er ditt for- og etternavn?
: Ivan Petrov
For- og etternavnet ditt. Verdi i firkantede parenteser er standardverdien.
4. Hva er navnet på organisasjonsenheten din?
: DEN
Navnet på bedriftens avdeling. Du kan la det stå tomt, jeg angir DET.
5. Hva er navnet på organisasjonen din?
: 2 utviklere
Navnet på organisasjonen din. Angi evt.
6. Hva er navnet på byen eller lokaliteten din?
: Moskva
By Navn
7. Hva er navnet på staten eller provinsen din?
: M.O.
Områdenavn
8. Hva er landskoden på to bokstaver for denne enheten?
: RU
Kode for landet. Jeg angir RU.
: y
Bekreft om alt er riktig eller trykk Enter for å gå inn igjen.
På slutten vises en melding som indikerer vellykket nøkkelgenerering. Du vil bli bedt om å angi et passord for den private nøkkelen (hvis du vil la det være det samme som for sertifikatet, trykk Enter):
Genererer 2 048 bit RSA nøkkelpar og selvsignert sertifikat (SHA256withRSA) med en gyldighet på 10 000 dager for: CN=Ivan Petrov, OU=IT, O=2utviklere, L=Moskva, ST=MO, C=RU Enter-nøkkel passord for
En fil vil bli opprettet i gjeldende katalog lcf.nøkkellager.
Viktig
Den opprettede filen må lagres på et trygt sted. Hvis du bruker et privat depot, kan filen committeres sammen med applikasjonens kildekode. Generelt er det bedre å lagre sertifikater separat. Hvis du mister sertifikatet, vil du ikke kunne utstede appoppdateringer.
Det er to trinn igjen, og du vil ha en APK-fil klar for distribusjon. La oss gå videre til signering.
For å signere apk-filen din, bruk verktøyet jarsigner, som også er inkludert i JDK.
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore lcf.keystore android-release-unsigned.apk lcf
Sertifikatnavnet er angitt etter parameteren -nøkkellager, alias - etter filnavnet.
Til slutt, for å optimalisere apk-filen, vil vi bruke verktøyet zipalign:
$ zipalign -v 4 android-release-unsigned.apk LoyalClientFree.apk
Den siste parameteren er navnet på filen du skal laste opp til Google Play.
Viktig.
Nytte zipalign det er en del av Android SDK Tools og kan finnes her:/path/to/Android/sdk/build-tools/VERSION/zipalign
Konklusjon
Du har nå en distribusjonsklar apk-fil som kan lastes opp til Google Play. Fyll ut beskrivelsen, bestemme vurderingen av søknaden din og klikk gjerne "Publiser".Med Google Plays appsigneringsfunksjon kan Google administrere appens signeringsnøkkel, samt beskytte denne nøkkelen og bruke den til å signere APK-ene dine for distribusjon. Denne lagringsmetoden vil beskytte deg i tilfelle nøkkelen mistes eller hackes.
Viktig! For å bruke Android App Bundles (det anbefalte apppubliseringsformatet), må du registrere deg i Google Play App Signing Program før du laster opp App Bundle til Play Console.
Registrering er åpen for kontoeiere og brukere med globale produsom har akseptert vilkårene for bruk. Du kan bare registrere én app om gangen med Google Play App Signing Program.
Arbeidsprinsipper
Når du bruker Google Plays appsigneringsfunksjon, lagres nøklene dine i samme infrastruktur som lagrer Googles nøkler, og er beskyttet av en dedikert nøkkeladministrasjonstjeneste. Detaljert informasjon Googles tekniske infrastruktur finner du i dokumentasjonen for Google Cloud Security.
Android-applikasjoner er signert med en privat nøkkel. Hver slik nøkkel er knyttet til et offentlig sertifikat, som enheter og tjenester kan verifisere sikkerheten til applikasjoner og deres oppdateringer med. Bare de oppdateringene hvis signatur samsvarer med signaturen, er installert på enheter installert applikasjon. Hvis du lar Google administrere appsigneringsnøkkelen din, blir prosessen sikrere.
Merk.Å bruke Google Plays appsigneringsfunksjon er valgfritt. Du kan laste ned APK-er og administrere dine egne nøkler uten å bruke app-pakker. Men hvis du mister tilgangen til nøkkellageret eller det blir kompromittert, vil du ikke kunne oppdatere applikasjonen og må publisere den på nytt med et annet pakkenavn.
Beskrivelser av nøkler, objekter og verktøy| Forhold | Beskrivelse |
|---|---|
| Søknadssigneringsnøkkel |
Nøkkelen som brukes av Google Play for å signere APK-filer levert til brukerens enhet. Når du registrerer deg for Google Play-appsigneringsprogrammet, kan du laste opp en eksisterende signeringsnøkkel eller la Google generere en ny. |
| Last ned nøkkel |
Det er to måter å generere en nedlastingsnøkkel på:
|
| Sertifikat (.der eller .pem) |
Et sertifikat som inneholder den offentlige nøkkelen og Ytterligere informasjon om eieren. Et offentlig nøkkelsertifikat lar alle vite hvem som har signert en App Bundle eller APK-fil. Dette sertifikatet kan deles fordi det ikke inkluderer en privat nøkkel. For å registrere nøklene dine hos API-leverandører kan du laste ned det offentlige sertifikatet for appsigneringsnøkkelen fra Signering av søknader i Play-konsollen. Et offentlig nøkkelsertifikat kan deles med alle fordi det ikke inkluderer en privat nøkkel. |
| Digitalt fingeravtrykk av sertifikatet |
En kort og unik identifikator for sertifikatet. Fingeravtrykket sammen med pakkenavnet blir ofte bedt om av API-leverandører for å gi tilgang til tjenestene deres. Digitale fingeravtrykk av MD5, SHA-1 og SHA-256 nedlasting og finner du på siden Signering av søknader i Play-konsollen. Du kan også motta en annen type digitalt fingeravtrykk. For å gjøre dette, last ned det originale sertifikatet i DER-format på samme side. |
| Java Key Store (.jks eller .keystore) | Lagring av sikkerhetssertifikater og private nøkler. |
| PEPK-verktøy |
Et verktøy for å eksportere private nøkler fra Java-lagring og kryptere dem for overføring til Google Play. Når du har gitt Google appsigneringsnøkkelen din, velger du å eksportere og laste ned din egen nøkkel (og eventuelt det offentlige sertifikatet), og deretter følger du instruksjonene for å laste ned og bruke verktøyet. Du kan også laste ned, se og bruke åpen kildekode PEPK-verktøyet. |
Du kan laste ned APK-filer signert med den originale appsigneringsnøkkelen før eller etter signering av appen på Google Play.
Hvis du migrerer til Android App Bundles, kan du teste dem i testversjoner og bruke eksisterende APK-er i produksjonsversjoner. Slik fungerer det:
- Du signerer App Bundle eller APK og laster den opp til Play-konsollen.
- Appsigneringsprosessen avhenger av hva du laster ned.
- App Bundle. Google optimaliserer APK-filer fra App Bundle og signerer dem deretter med en appsigneringsnøkkel.
- APK-fil signert med nedlastingsnøkkelen. Google bekrefter signaturen din, fjerner den og signerer APK-filene på nytt med appsigneringsnøkkelen.
- En APK-fil signert med appsigneringsnøkkelen. Google bekrefter signaturen.
- Google leverer signerte APK-filer til brukere.
Slik registrerer du deg for Google Play App Signing Program
Nye applikasjonerTrinn 1: Lag en nedlastingsnøkkel
- Lag en nedlastingsnøkkel ved å følge instruksjonene.
- Signer den nye APK-filen med nedlastingsnøkkelen.
Trinn 2: Forbered utgivelsen
- , følg instruksjonene.
- Når du har valgt versjonstype, konfigurer appsigneringsinnstillingene dine under «La Google beskytte og administrere appsigneringsnøkkelen din».
- Hvis du klikker Fortsette, vil den genererte nøkkelen bli nedlastingsnøkkelen som vil bli brukt til å signere fremtidige utgivelser. Du kan også velge følgende Avanserte innstillinger:
- Bruk én nøkkel for forskjellige applikasjoner i utviklerkontoen (alternativ 2).
- Last opp signeringsnøkkelen til en eksisterende applikasjon (alternativ 2, 3 og 4), velg den mest passende eksport- og nedlastingsmetoden. Når du har lastet ned et programs signeringsnøkkel og dets offentlige sertifikat, kan du enten bruke det som programmets signeringsnøkkel.
Merk. For å fortsette må du godta vilkårene for bruk og registrere deg for appsigneringsprogrammet.
Trinn 3: Registrer appsigneringsnøkkelen hos API-leverandørene dine
Hvis applikasjonen din bruker en API, må du mest sannsynlig registrere et nøkkelsertifikat som Google bruker for å signere applikasjonen for å autentisere. Slik finner du et sertifikat:
- Logg på Play Console.
- Velg et program.
- Velg fra menyen til venstre Utgivelseshåndtering > Søknadssignaturer.
-
- Hvis API-leverandøren krever en annen type fingeravtrykk, kan du laste ned det originale sertifikatet i DER-format og konvertere det etter behov ved å bruke de riktige verktøyene.
Trinn 1: Registrer deg for Google Play App Signing Program
- Logg på Play Console.
- Velg et program.
- Velg fra menyen til venstre Utgivelseshåndtering > Søknadssignaturer.
- Les om nødvendig brukervilkårene og klikk Aksepterer.
Trinn 2: Send inn den originale nøkkelen til Google og lag en nedlastingsnøkkel
- Finn den originale applikasjonssigneringsnøkkelen.
- Logg på Play Console.
- Velg et program.
- Velg fra menyen til venstre Utgivelseshåndtering > Søknadssignaturer.
- Last opp en eksisterende applikasjonssigneringsnøkkel i den metoden som passer best for utgivelsesprosessen din.
- og last opp sertifikatet til Google Play.
- Du kan også bruke applikasjonssigneringsnøkkelen som nedlastingsnøkkel.
- Kopier de digitale fingeravtrykkene (MD5, SHA-1 og SHA-256) tilet.
- For å utføre testing må du kanskje registrere et oppstartsnøkkelsertifikat hos API-leverandøren ved å bruke sertifikatets fingeravtrykk og applikasjonssigneringsnøkkel.
Trinn 4: Signer din neste appoppdatering med nedlastingsnøkkelen
Utgitte applikasjonsoppdateringer må signeres med en nedlastingsnøkkel.
Hvordan lage en nedlastingsnøkkel og oppdatere nøkkellagre
Du kan opprette en nedlastingsnøkkel når du registrerer deg for Google Play App Signing Program, eller du kan generere en senere i Utgivelseshåndtering > Søknadssignaturer.
Følg disse trinnene for å opprette en nedlastingsnøkkel:
- Følg instruksjonene på nettstedet for Android-utviklere. Oppbevar nøkkelen på et trygt sted.
- Eksporter sertifikatet for oppstartsnøkkelen i PEM-format. Erstatt følgende argumenter med en understrek:
- $ keytool -eksport -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem
Når du blir bedt om det under utstedelsesprosessen, last ned sertifikatet for å registrere det hos Google.
Hvis du bruker en nedlastingsnøkkel:
- Nedlastingsnøkkelen er registrert hos Google kun for å autentisere identiteten til appskaperen.
- Signaturen din fjernes fra alle APK-nedlastinger før de når brukere.
- Nedlastingsnøkkelen må bruke RSA-kryptering og må være minst 2048 biter stor.
- DSA- og EC-nøkler støttes ikke, og heller ikke er RSA-nøkler mindre enn 2048 biter.
Når du har opprettet nedlastingsnøkkelen, kontroller og oppdater følgende plasseringer om nødvendig:
- lokalt system;
- beskyttet lokal server(med forskjellige tilgangskontrolllister);
- skysystem (med ulike tilgangskontrolllister);
- spesielle nøkkeladministrasjonstjenester;
- Git repositories.
Slik oppdaterer du signeringsnøkkelen for nye appinstallasjoner
I noen tilfeller kan du kanskje be om en oppdatering av applikasjonssigneringsnøkkelen. Den nye nøkkelen vil bli brukt til å signere nye installasjoner og oppdateringer av applikasjonen, og den utdaterte vil bli brukt til å oppdatere signerte versjoner som allerede er installert av brukere.
Signeringsnøkkelen kan bare oppdateres én gang for hver applikasjon. I det usannsynlige tilfellet at du bruker samme signeringsnøkkel for flere applikasjoner for å kjøre dem i samme prosess, kan ikke nøkkelen oppdateres.
Du bør be om en oppdatering av applikasjonssigneringsnøkkelen i følgende tilfeller:
- Du trenger en sikrere nøkkel.
- Programsigneringsnøkkelen er kompromittert.
Merk. Forespørselen om å oppdatere appsigneringsnøkkelen på Play-konsollen er ikke relatert til utskifting av nøkler i Android P og nyere versjoner. Denne nøkkelerstatningen støttes for øyeblikket ikke av Google Play.
Viktige merknader om oppdatering av nøklerFør du ber om en nøkkeloppdatering er det viktig å forstå hvilke endringer dette vil innebære.
- Hvis du bruker den samme signeringsnøkkelen for flere apper for å bruke samme kode eller data, må du oppdatere appene for å gjenkjenne både den nye og den eldre nøklene.
- Hvis appen din bruker en API, må du sørge for å registrere sertifikatene for de nye og eldre appsigneringsnøklene hos API-leverandøren før du oppgraderer appen. Sertifikater er tilgjengelig på siden Signering av søknader Spillekonsoll.
- Hvis mange brukere av applikasjonen din installerer oppdateringer gjennom fildelingsnettverk, vil de bare kunne installere oppdateringer signert med samme nøkkel som applikasjonen installert på enhetene deres. Hvis applikasjoner ikke kan oppdateres pga installert versjon signert med en annen nøkkel, kan brukere avinstallere og installere den på nytt for å motta oppdateringer.
- Logg på Play Console.
- Velg et program.
- Velg fra menyen til venstre Utgivelseshåndtering > Søknadssignaturer.
- I kortet "Oppdater signeringsnøkkel for nye appinstallasjoner" velger du Be om en nøkkeloppdatering.
- Velg hva du vil gjøre med enheten.
- Avhengig av alternativet du velger, må du kanskje kontakte support for å fullføre forespørselen.
- Tillat at Google Play genererer en ny appsigneringsnøkkel (anbefalt) eller last ned en.
- Etter å ha oppdatert appsigneringsnøkkelen din, hvis nøkkelen samsvarer med nedlastingsnøkkelen din, kan du fortsette å bruke den gamle appsigneringsnøkkelen som nedlastingsnøkkel eller opprette en ny.
- Hvis du også har publisert appen din utenfor Google Play eller planlegger å gjøre det, kan du generere en delt appsigneringsnøkkel og laste den opp til Google når du registrerer deg for Google Play App Signing Program.
- For å beskytte kontoen din, aktivere totrinnsverifisering for alle kontoer som har tilgang til Play-konsollen.
- Etter at App Bundle er publisert i testen eller fungerende versjon Du kan åpne App Bundle Browser og laste ned et ZIP-arkiv som inneholder alle APK-filene for en bestemt enhet. Disse APK-filene er allerede signert med appsigneringsnøkkelen. Du kan installere dem på enheten din fra et ZIP-arkiv ved å bruke verktøyet kommandolinje buntverktøy.
- For større sikkerhet, generer en ny nedlastingsnøkkel som er forskjellig fra applikasjonssigneringsnøkkelen.
- Hvis du vil teste en APK signert med en opplastingsnøkkel, registrerer du nøkkelen med en tjeneste eller API som bruker appens signatur for autentisering (som API Google Kart eller Facebook Developer Pack).
- Hvis du bruker Google API, kan du registrere opplastingssertifikatet i Google Cloud Console.
Hva skal jeg gjøre hvis nøkkelen er tapt eller hacket
Hvis du har mistet tilgangen til din private nedlastingsnøkkel eller den har blitt hacket, og spør eieren av kontoen din. Når du kontakter brukerstøtten, må kontoeieren legge ved filen upload_certificate.pem.
Når supportteamet registrerer en ny nedlastingsnøkkel, vil du motta en e-post og kan deretter oppdatere nøkkellagrene dine og registrere nøkkelen hos API-leverandører.
Viktig! Tilbakestilling av nedlastingsnøkkelen påvirker ikke appsigneringsnøkkelen, som Google Play bruker til å signere APK-filer før de sendes til brukerne.
Var denne informasjonen nyttig?
Hvordan kan denne artikkelen forbedres?
Noen ganger passer noen applikasjoner på Android ikke brukeren på en eller annen måte. Et eksempel er påtrengende reklame. Og det hender også at programmet er bra for alle, men oversettelsen i det er enten skjev eller helt fraværende. Eller, for eksempel, programmet er en prøveversjon, men det er ingen måte å få fullversjonen på. Hvordan endre situasjonen?
Introduksjon
I denne artikkelen vil vi snakke om hvordan du kan demontere en APK-pakke med en applikasjon, se på dens interne struktur, demontere og dekompilere bytekoden, og også prøve å gjøre flere endringer i applikasjonene som kan gi oss en eller annen fordel.
For å gjøre alt dette selv, trenger du minst grunnleggende kunnskap om Java-språket, som Android-applikasjoner er skrevet i, og XML-språket, som brukes overalt i Android - fra å beskrive selve applikasjonen og dens tilgangsrettigheter til lagring av strenger som vil vises på skjermen. Du trenger også muligheten til å bruke spesialisert konsollprogramvare.
Så, hva er en APK-pakke der absolutt all Android-programvare er distribuert?
Applikasjonsdekompilering
I denne artikkelen jobbet vi kun med demontert applikasjonskode, men hvis det gjøres mer alvorlige endringer i store applikasjoner, vil det være mye vanskeligere å forstå smali-koden. Heldigvis kan vi dekompilere dex-koden til Java-kode, som, selv om den ikke er original og ikke kompilert tilbake, er mye lettere å lese og forstå logikken til applikasjonen. For å gjøre dette trenger vi to verktøy:
- dex2jar er en oversetter av Dalvik bytecode til JVM bytecode, på grunnlag av denne kan vi få kode på Java-språket;
- jd-gui er en dekompiler i seg selv som lar deg få lesbar Java-kode fra JVM bytecode. Som et alternativ kan du bruke Jad (www.varaneckas.com/jad); Selv om den er ganske gammel, genererer den i noen tilfeller mer lesbar kode enn Jd-gui.
Slik skal de brukes. Først starter vi dex2jar, og spesifiserer banen til apk-pakken som et argument:
% dex2jar.sh mail.apk
Som et resultat vil Java-pakken mail.jar vises i gjeldende katalog, som allerede kan åpnes i jd-gui for å se Java-koden.
Arrangering av APK-pakker og mottak av dem
Plastpose Android-applikasjoner, faktisk er en vanlig ZIP-fil, ingen spesielle verktøy kreves for å se innholdet og pakke det ut. Det er nok å ha en arkiver - 7zip for Windows eller konsoll unzip på Linux. Men det handler om innpakningen. Hva er inni? Generelt har vi følgende struktur inne:
- META-INF/- inneholder et digitalt sertifikat for applikasjonen, som identifiserer dens skaper, og kontrollsummer for pakkefilene;
- res/ - ulike ressurser som applikasjonen bruker i sitt arbeid, for eksempel bilder, deklarativ beskrivelse av grensesnittet, samt andre data;
- AndroidManifest.xml- beskrivelse av søknaden. Dette inkluderer for eksempel en liste over nødvendige tillatelser, den nødvendige Android-versjonen og den nødvendige skjermoppløsningen;
- classes.dex- kompilert applikasjonsbytekode for virtuell maskin Dalvik;
- resources.arsc- også ressurser, men av en annen type - spesielt strenger (ja, denne filen kan brukes til russifisering!).
De oppførte filene og katalogene er, om ikke i alle, så kanskje i de aller fleste APK-er. Imidlertid er det noen flere ikke så vanlige filer/kataloger som er verdt å nevne:
- eiendeler- analog av ressurser. Hovedforskjellen er at for å få tilgang til en ressurs må du kjenne identifikatoren, men listen over eiendeler kan hentes dynamisk ved å bruke AssetManager.list()-metoden i applikasjonskoden;
- lib- innfødte Linux-biblioteker skrevet med NDK (Native Development Kit).
Denne katalogen brukes av spillprodusenter, og plasserer der spillmotoren skrevet i C/C++, så vel som av skapere av høyytelsesapplikasjoner (f.eks. Google Chrome). Vi fant ut enheten. Men hvordan får du tak i pakkefilen til applikasjonen du er interessert i? Siden det ikke er mulig å hente APK-filer fra enheten uten root (de ligger i /data/app-katalogen), og rooting ikke alltid er tilrådelig, er det minst tre måter å få applikasjonsfilen til datamaskinen din:
- APK Downloader-utvidelse for Chrome;
- Real APK Leecher app;
- ulike fil hosting og Varezniks.
Hvilken man skal bruke er en smakssak; vi foretrekker å bruke separate applikasjoner, så vi vil beskrive bruken av Real APK Leecher, spesielt siden den er skrevet i Java og følgelig vil fungere i enten Windows eller Nix.
Etter å ha startet programmet, må du fylle ut tre felt: E-post, Passord og Enhets-ID - og velge et språk. De to første er e-postadressen og passordet til Google-kontoen din som du bruker på enheten. Den tredje er enhetsidentifikatoren, og kan fås ved å skrive inn koden på oppringeren # #8255## og deretter finne enhets-ID-linjen. Når du fyller ut trenger du kun å angi ID uten android-prefikset.
Etter utfylling og lagring dukker ofte meldingen "Feil under tilkobling til server" opp. Det har ingenting med Google Play å gjøre, så ignorer det gjerne og se etter pakker som interesserer deg.
Se og endre
La oss si at du fant en pakke som interesserer deg, lastet den ned, pakket den ut... og da du prøvde å se en XML-fil, ble du overrasket over å oppdage at filen ikke var tekst. Hvordan dekompilere det og hvordan arbeide med pakker generelt? Er det virkelig nødvendig å installere SDK? Nei, det er ikke nødvendig å installere SDK i det hele tatt. Faktisk krever alle trinnene for å trekke ut, endre og pakke APK-pakker følgende verktøy:
- ZIP-arkiver for utpakking og pakking;
- smali- Dalvik virtuell maskin bytecode assembler/disassembler (code.google.com/p/smali);
- aapt- et verktøy for å pakke ressurser (som standard lagres ressurser i binær form for å optimere applikasjonsytelsen). Inkludert i Android SDK, men kan fås separat;
- underskriver- et verktøy for digital signering av en modifisert pakke (bit.ly/Rmrv4M).
Du kan bruke alle disse verktøyene separat, men dette er upraktisk, så det er bedre å bruke programvare på høyere nivå bygget på deres grunnlag. Hvis du jobber med Linux eller Mac OS X, finnes det et verktøy som heter apktool. Den lar deg pakke ut ressurser i sin opprinnelige form (inkludert binære XML- og arsc-filer), gjenoppbygge en pakke med endrede ressurser, men den vet ikke hvordan du signerer pakker, så du må kjøre signeringsverktøyet manuelt. Til tross for at verktøyet er skrevet i Java, er installasjonen ganske ikke-standard. Først må du hente selve jar-filen:
$ cd /tmp $ wget http://bit.ly/WC3OCz $ tar -xjf apktool1.5.1.tar.bz2
$ wget http://bit.ly/WRjEc7 $ tar -xjf apktool-install-linux-r05-ibot.tar.bz2
$ mv apktool.jar ~/bin $ mv apktool-install-linux-r05-ibot/* ~/bin $ eksport PATH=~/bin:$PATH
Hvis du jobber på Windows, så er det et utmerket verktøy for det kalt Virtuous Ten Studio, som også akkumulerer alle disse verktøyene (inkludert selve apktool), men i stedet for et CLI-grensesnitt gir brukeren et intuitivt GUI, som du kan utføre utpakking, demontering og dekompilering med noen få klikk. Dette verktøyet er donasjonsvare, det vil si at noen ganger vises vinduer som ber deg om å få en lisens, men til slutt kan dette tolereres. Det er ingen vits i å beskrive det, for du kan forstå grensesnittet på noen få minutter. Men apktool, på grunn av konsollens natur, bør diskuteres mer detaljert.
La oss se på apktool-alternativene. Kort fortalt er det tre grunnleggende kommandoer: d (dekode), b (bygg) og if (installer rammeverk). Hvis alt er klart med de to første kommandoene, hva gjør den tredje, betingede uttalelsen? Den pakker ut det angitte UI-rammeverket, som er nødvendig i tilfeller der du dissekerer en systempakke.
La oss se på de mest interessante alternativene til den første kommandoen:
- -s- ikke demonter dex-filer;
- -r- ikke pakke ut ressurser;
- -b- ikke legg inn feilsøkingsinformasjon i resultatene av demontering av dex-filen;
- --ramme-bane- bruk det angitte UI-rammeverket i stedet for det som er innebygd i apktool. La oss nå se på et par alternativer for b-kommandoen:
- -f- tvangsmontering uten å kontrollere endringer;
- -en- angi stien til aapt (et verktøy for å bygge et APK-arkiv), hvis du av en eller annen grunn vil bruke det fra en annen kilde.
Å bruke apktool er veldig enkelt; for å gjøre dette, spesifiser bare en av kommandoene og banen til APK, for eksempel:
$ apktool d mail.apk
Etter dette vil alle utpakkede og demonterte filer av pakken vises i e-postkatalogen.
Forberedelse. Deaktivere annonsering
Teori er selvfølgelig bra, men hvorfor er det nødvendig hvis vi ikke vet hva vi skal gjøre med den utpakkede pakken? La oss prøve å bruke teorien til vår fordel, nemlig å modifisere noe programvare slik at den ikke viser oss reklame. La det for eksempel være Virtual Torch - en virtuell fakkel. Denne programvaren er ideell for oss, fordi den er fylt til siste plass med irriterende reklame og dessuten er enkel nok til ikke å gå seg vill i jungelen av kode.
Så ved å bruke en av metodene ovenfor, last ned applikasjonen fra markedet. Hvis du bestemmer deg for å bruke Virtuous Ten Studio, åpner du bare APK-filen i applikasjonen og pakker den ut, lager et prosjekt (Fil -> Nytt prosjekt), og velg deretter Importer fil i prosjektets kontekstmeny. Hvis valget ditt falt på apktool, kjør bare en kommando:
$ apktool d com.kauf.particle.virtualtorch.apk
Etter dette vil et filtre tilsvarende det som er beskrevet i forrige seksjon vises i katalogen com.kauf.particle.virtualtorch, men med en ekstra smali-katalog i stedet for dex-filer og en apktool.yml-fil. Den første inneholder demontert kode for programmets kjørbare dex-fil, den andre inneholder tjenesteinformasjon som er nødvendig for at apktool skal sette sammen pakken tilbake.
Det første stedet vi bør se er selvfølgelig AndroidManifest.xml. Og her møter vi umiddelbart følgende linje:
Det er ikke vanskelig å gjette at det er ansvarlig for å gi applikasjonen tillatelser til å bruke Internett-tilkoblingen. Faktisk, hvis vi bare ønsker å bli kvitt reklame, vil vi mest sannsynlig bare trenge å blokkere applikasjonen fra Internett. La oss prøve å gjøre dette. Vi sletter den angitte linjen og prøver å bygge programvaren ved å bruke apktool:
$ apktool b com.kauf.particle.virtualtorch
Den resulterende APK-filen vil vises i katalogen com.kauf.particle.virtualtorch/build/. Det vil imidlertid ikke være mulig å installere den, siden den ikke har en digital signatur og filsjekksummer (den har rett og slett ikke en META-INF/-katalog). Vi må signere pakken ved å bruke apk-signer-verktøyet. Lanserte. Grensesnittet består av to faner - på den første (Key Generator) lager vi nøkler, på den andre (APK Signer) signerer vi. For å opprette vår private nøkkel, fyll ut følgende felt:
- Målfil- nøkkellager utdatafil; den lagrer vanligvis ett par nøkler;
- Passord Og Bekrefte- passord for lagringen;
- Alias- navn på nøkkelen i lageret;
- Alias passord Og Bekrefte- hemmelig nøkkelpassord;
- Gyldighet- gyldighetsperiode (i år). Standardverdien er optimal.
De resterende feltene er generelt valgfrie - men minst ett må fylles ut.
ADVARSEL
For å signere en applikasjon med apk-signer, må du installere Android SDK og spesifisere hele banen til den i applikasjonsinnstillingene.
All informasjon gis kun for informasjonsformål. Verken redaktørene eller forfatteren er ansvarlige for mulig skade forårsaket av materialet i denne artikkelen.
Nå kan du signere APK-en med denne nøkkelen. På APK Signer-fanen, velg den nylig genererte filen, skriv inn passordet, nøkkelaliaset og passordet, finn deretter APK-filen og klikk dristig på "Sign"-knappen. Hvis alt går bra, blir pakken signert.
INFO
Siden vi signerte pakken med vår egen nøkkel, vil den komme i konflikt med den originale applikasjonen, noe som betyr at når vi prøver å oppdatere programvaren gjennom markedet, får vi en feilmelding.
En digital signatur kreves bare for tredjepartsprogramvare, så hvis du endrer systemapplikasjoner, som installeres ved å kopiere til /system/app/-katalogen, trenger du ikke signere dem.
Etter det laster du ned pakken til smarttelefonen, installer den og start den. Voila, annonsen er borte! I stedet dukket det opp en melding om at vi ikke har Internett eller ikke har de nødvendige tillatelsene. I teorien kan dette være nok, men meldingen ser irriterende ut, og for å være ærlig var vi bare heldige med en dum søknad. Normalt skrevet programvare vil mest sannsynlig avklare legitimasjonen eller se etter en Internett-tilkobling og ellers bare nekte å starte. Hvordan være i dette tilfellet? Rediger selvfølgelig koden.
Vanligvis oppretter applikasjonsforfattere spesielle klasser for å vise annonser og ringemetoder for disse klassene når applikasjonen eller en av dens "aktiviteter" (forenklet sagt applikasjonsskjermer) startes. La oss prøve å finne disse klassene. Vi går til smali-katalogen, deretter com (org inneholder bare det åpne grafiske biblioteket cocos2d), deretter kauf (det er her det er, fordi dette er navnet på utvikleren og all koden hans er der) - og her er den, markedsføringskatalogen. Inni finner vi en haug med filer med smali-utvidelsen. Dette er klasser, og den mest bemerkelsesverdige av dem er Ad.smali-klassen, fra navnet som det er lett å gjette at det er den som viser reklame.
Vi kunne endre logikken i operasjonen, men det ville være mye enklere å ganske enkelt fjerne anrop til noen av metodene fra selve applikasjonen. Derfor forlater vi markedsføringskatalogen og går til den tilstøtende partikkelkatalogen, og deretter til virtualtorch. MainActivity.smali-filen fortjener spesiell oppmerksomhet her. Dette er en standard Android-klasse som er opprettet av Android SDK og installert som inngangspunkt til applikasjonen (analogt med hovedfunksjonen i C). Åpne filen for redigering.
Inne er det smali-kode (lokal montør). Den er ganske forvirrende og vanskelig å lese på grunn av dens natur på lavt nivå, så vi vil ikke studere den, men vil ganske enkelt finne alle referanser til annonseklassen i koden og kommentere dem. Vi legger inn linjen "Annonse" i søket og kommer til linje 25:
Felt privat annonse:Lcom/kauf/marketing/Ad;
Her opprettes et annonsefelt for å lagre et annonseklasseobjekt. Vi kommenterer ved å plassere et ###-tegn foran linjen. Vi fortsetter søket. Linje 423:
Ny instans v3, Lcom/kauf/marketing/Ad;
Det er her objektskapingen skjer. La oss kommentere. Vi fortsetter søket og finner på linjene 433, 435, 466, 468, 738, 740, 800 og 802 oppfordringer til metoder i Ad-klassen. La oss kommentere. Ser ut som det er det. Lagre. Nå må pakken settes sammen igjen og sjekkes for funksjonalitet og tilstedeværelse av reklame. For renheten til eksperimentet returnerer vi linjen fjernet fra AndroidManifest.xml, setter sammen pakken, signerer og installerer.
Marsvinet vårt. Reklame synlig 
Oops! Reklamen forsvant bare mens applikasjonen kjørte, men forble i hovedmenyen, som vi ser når vi starter programvaren. Så vent, men inngangspunktet er MainActivity-klassen, og annonsen forsvant mens applikasjonen kjørte, men forble i hovedmenyen, så inngangspunktet er annerledes? For å identifisere det sanne inngangspunktet, åpne AndroidManifest.xml-filen på nytt. Og ja, den inneholder følgende linjer:
De forteller oss (og enda viktigere, androiden) at en aktivitet kalt Start bør lanseres som svar på genereringen av en intent (hendelse) android.intent.action.MAIN fra kategorien android.intent.category.LAUNCHER. Denne hendelsen genereres når du trykker på applikasjonsikonet i startprogrammet, så det bestemmer inngangspunktet, nemlig Start-klassen. Mest sannsynlig skrev programmereren først en applikasjon uten hovedmeny, inngangspunktet som var standard MainActivity-klassen, og la deretter til et nytt vindu (aktivitet) som inneholder menyen og beskrevet i Start-klassen, og gjorde det manuelt til oppføringen punkt.
Åpne Start.smali-filen og se igjen etter linjen "Ad", vi finner i linje 153 og 155 en omtale av FirstAd-klassen. Den ligger også i kildekoden, og etter navnet å dømme er den ansvarlig for å vise annonser på hovedskjermen. La oss se videre, det er opprettelsen av en forekomst av FirstAd-klassen og en hensikt som, i henhold til konteksten, er relatert til denne forekomsten, og deretter etiketten cond_10, den betingede overgangen til denne utføres nøyaktig før du oppretter en forekomst av klassen:
If-ne p1, v0, :cond_10 .line 74 new-instance v0, Landroid/content/Intent; ... :cond_10
Mest sannsynlig beregner programmet på en eller annen måte tilfeldig om reklame skal vises på hovedskjermen, og hvis ikke, hopper det direkte til cond_10. Ok, la oss forenkle oppgaven hennes og erstatte den betingede overgangen med en ubetinget:
#if-ne p1, v0, :cond_10 goto:cond_10
Det er ikke flere omtaler av FirstAd i koden, så vi lukker filen og setter sammen vår virtuelle lommelykt ved hjelp av apktool. Kopier den til smarttelefonen din, installer den, start den. Voila, all reklame har forsvunnet, noe vi gratulerer oss alle med.
Resultater
Denne artikkelen er bare en kort introduksjon til metodene for å hacke og endre Android-applikasjoner. Mange problemer forble bak kulissene, for eksempel å fjerne beskyttelse, analysere skjult kode, oversette og erstatte applikasjonsressurser, samt endre applikasjoner skrevet ved hjelp av Android NDK. Men med grunnleggende kunnskap er det bare et spørsmål om tid å finne ut av alt.
Innleggsvisninger: 5.618
Android Studio gir gode muligheter både for applikasjonsutvikling og for å øke automatisering og komfort i programmering.
Hvis du bruker et byggesystem Gradle for å lage applikasjonene dine kan du også konfigurere flere alternativer for å lage signaturer for applikasjonene dine.
Du vil sannsynligvis ikke publisere signeringsnøklene, passordene og brukernavnene dine til et offentlig (eller til og med privat) depot. Derfor kan du definere nøkkel, passord og brukernavn som egenskaper i en egen fil.
Før du begynner å signere søknaden din, må du opprette en ny egenskap i gradle.properties-filen. La oss ringe ham Keys.repo og, som en verdi, spesifiser banen til mappen der nøkkellageret og filen med egenskaper senere skal ligge (f.eks. C:/Brukere/Brukernavn/.signering).
Keys.repo=C:/Brukere/Brukernavn/.signering
Deretter må du opprette denne mappen eller, hvis du spesifiserte en eksisterende, åpne den. Du må lage en fil i den YourProjectName.properties, i hvilken banen til nøkkellageret, nøkkelaliaset og passordet vil bli skrevet som egenskaper i følgende skjema.
RELEASE_STORE_FILE=/YourProjectName/KeyStoreName.jks RELEASE_STORE_PASS=******** RELEASE_ALIAS=KeyAlias RELEASE_KEY_PASS=******
Hvordan lage et nøkkelhvelv?
Hvis du ikke har et nøkkellager, kan du enkelt opprette en med bruker Android Studio. For å gjøre dette, velg menyelementet Bygge -> Generer signert APK.
I vinduet som vises, må du klikke Lag ny... Som et resultat vil et vindu åpnes der du kan spesifisere hvor nøkkellagringen skal ligge (for denne leksjonen er det bedre å umiddelbart velge banen du spesifiserte i YourProjectName.properties i eiendom RELEASE_STORE_FILE), samt nøkkelinformasjon.
Deretter må du opprette en mappe Ditt prosjektnavn og flytte den dit nødvendig fil nøkkelbutikker.
Nå kan du gå direkte til signeringsprosessen. For å gjøre dette, må du åpne filen i prosjektet ditt bygge.gradle(ligger i app-mappen). Inne i den i blokken android du må legge til følgende kode.
SigningConfigs ( debug ( /* ingen endringer her */ ) release (if (project.hasProperty("Keys.repo")) ( def projectPropsFile = file(project.property("Keys.repo") + "/YourProjectName.properties " ) if (projectPropsFile.exists()) ( Properties props = new Properties() props.load(new FileInputStream(projectPropsFile)) storeFile file(file(project.property("Keys.repo") + props["RELEASE_STORE_FILE"] ) ) storePassword-rekvisitter["RELEASE_STORE_PASS"] keyAlias-rekvisitter["RELEASE_ALIAS"] keyPassword-rekvisitter["RELEASE_KEY_PASS"] ) ) else ( println "==================== = ======================== 6 ~/. signeringskatalog" println "=========================================== ================== ==========" ) ) )
Hva er de forskjellige ordningene for å få en signatur?
Det er to ordninger for å få en APK-signatur: v1 JAR Og v2 Full APK.
I det første tilfellet er det signert KRUKKE-fil, som er tradisjonell måte signering. Signering v1 beskytter ikke enkelte deler av APK-en, for eksempel ZIP-metadata. APK-verifikatoren må håndtere mange ikke-klarerte (ennå ikke verifiserte) datastrukturer og deretter forkaste data som ikke er signert, og etterlate mye angrepsoverflate. I tillegg må APK-verifikatoren dekomprimere alle komprimerte oppføringer, noe som kaster bort mye tid og minne. For å løse disse problemene har den andre ordningen v2 Full APK blitt utviklet.
Scheme v2 ble presentert i Android 7.0 Nougat (API 25) og fungerer fra versjon Android Studio 2.2 Og Android Gradle-plugin 2.2. Denne ordningen gir raskere applikasjonsinstallasjon og god beskyttelse mot uautoriserte endringer i APK. APK-innholdet hashes og signeres, deretter det resulterende APK-signaturblokk satt inn i APK.
Under verifisering behandler v2-skjemaet APK-en som en blob og utfører signaturverifisering på hele filen. Enhver modifikasjon av APK-en, inkludert endringer i ZIP-metadata, ugyldiggjør signaturen. Denne formen for verifisering er mye raskere og kan oppdage flere uautoriserte endringer.
Det nye formatet er bakoverkompatibelt, så APK-er signert med det nye skjemaet kan installeres på eldre enheter (som ganske enkelt vil ignorere den nye signaturen) så lenge disse APK-ene også er signert med v1-skjemaet.
Som standard bruker signering begge ordningene slik at apper kan installeres på hvilken som helst enhet. Men hvis det er et slikt behov, kan du deaktivere v1- eller v2-signaturen. For å gjøre dette, i koden ovenfor i blokken utgivelse Det er nok å legge til følgende linjer.
V1SigningEnabled false
V2SigningEnabled false
Det er også viktig å merke seg at du må signere med skjema v1 før du signerer med skjema v2, siden APK-en ikke vil bestå verifisering under skjema v2 hvis den er signert med tilleggssertifikater etter signering med skjema v2.
Når koden er lagt til, inkluderer du denne koden i en blokk byggetyper innsiden utgivelse. For eksempel:
BuildTypes ( release ( minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" signingConfig signingConfigs.release ) )
Nå kan du trygt i menypunktet Bygge velge Bygg APK, har tidligere endret monteringstype fra feilsøke på utgivelse. Som du kan se, er denne metoden praktisk fordi den er automatisk, du trenger bare å konfigurere den én gang og nøkkellagringene dine kan være trygge.
