Hem › Internet › Vi publicerar appar på Google Play och tjänar miljoner. Hur man använder appsigneringsfunktionen på Google Play Hur man signerar en apk med en originalsignatur

Vi publicerar appar på Google Play och tjänar miljoner. Hur man använder appsigneringsfunktionen på Google Play Hur man signerar en apk med en originalsignatur

Så du har jobbat många dagar (och kanske till och med nätter) och nu är din första hybridmobilapplikation klar. Det är ganska stabilt, de flesta av de kritiska buggarna är stängda. Det finns små kvar, men med tanke på att perfektionism är av ondo fattar du ett viljestarkt beslut att publicera ansökan.

En förutsättning för detta är närvaron av en signerad APK-fil. Du kommer att lära dig hur du signerar en apk-fil i den här artikeln.

En liten reträtt

När mitt husdjursprojekt närmade sig release började jag leta efter information om hur man snabbt och smärtfritt publicerar en ansökan. Många av instruktionerna som hittats såg enkla ut. Jag valde instruktionerna från författarna till det joniska ramverket, på vilket applikationen utvecklades. Allt fungerade inte första gången, det finns flera egenheter. Signeringsprocessen beskrivs i den här artikeln, med viktiga punkter framhävda.

Inledande data

Jag antar att du har allt inrett för att utveckla hybrider. mobilapplikationer använder Apache Cordova. Måste installeras:

Apache Cordova
Java Development Kit
Android SDK-verktyg

Projektets och ansökans namn är lcf. Ersätt med ditt projektnamn vid behov.

Gå

Först måste du skapa en version av din applikation. Men innan dess, låt oss se till att alla onödiga plugins tas bort. Till exempel behöver vi inte ett plugin som matar ut felsökningsinformation till konsolen. Låt oss ta bort det:

$ cordova plugin rm cordova-plugin-console
Använd kommandot för att generera en version för Android bygga med en flagga --släpp:

$ cordova build --släpp android
Detta kommando kommer att skapa osignerad APK-fil i katalogen:

Plattformar/android/build/outputs/apk
Till exempel, platforms/android/build/outputs/apk/ android-release-unsigned.apk. Då måste vi signera den här filen och köra verktyget zipalign att optimera och förbereda filen för Google Play.

För att signera en fil behöver du ett certifikat. Låt oss skapa det med hjälp av verktyget nyckelverktyg som ingår i JDK:

$ keytool -genkey -v -keystore lcf.keystore -alias lcf -keyalg RSA -nyckelstorlek 2048 -validity 10000
Viktig

Värdet på parametern -alias måste komma ihåg, eller ännu hellre skrivas ner. I exemplet ovan är det lika med lcf (baserat på de första bokstäverna i applikationsnamnet Loyal Client Free). Jag kommer inte att ge detaljer här, om du är intresserad, skriv i kommentarerna, jag kommer att berätta mer detaljerat.
Aliaset används varje gång du signerar * applikationer. För att göra det lättare att komma ihåg, använd namnet på nyckellagringsfilen som ett alias, till exempel:

-keystore hello-world.keystore -alias hello-world -keystore väder-app.keystore -alias väder-app -keystore todo.keystore -alias todo
* Du måste signera applikationen varje gång uppdateringar släpps

Verktyg nyckelverktyg ställer en rad frågor. Det kommer att finnas 8 av dem totalt. För att ha en uppfattning om frågorna och ungefärliga svar i förväg ges de alla nedan, under spoilern.

Nyckelverktygsfrågor och exempelsvar på dem

1. Ange nyckellagringslösenord:
Här måste du ange ett lösenord för filen (minst 6 tecken). Det angivna lösenordet måste skrivas ned på ett säkert ställe, det behövs varje gång du signerar ansökan.

2. Ange nytt lösenord:
Ange ditt lösenord igen.

3. Vad är ditt för- och efternamn?
: Ivan Petrov
Ditt för- och efternamn. Värde i hakparentesär standardvärdet.

4. Vad heter din organisationsenhet?
: DEN
Namnet på ditt företags division. Du kan lämna det tomt, jag anger DET.

5. Vad heter din organisation?
: 2 utvecklare
Namnet på din organisation. Ange om någon.

6. Vad heter din stad eller ort?
: Moskva
Stadens namn

7. Vad är namnet på din stat eller provins?
: M.O.
Områdesnamn

8. Vilken är landskoden på två bokstäver för denna enhet?
: RU
Koden för landet. Jag anger RU.

: y

Bekräfta om allt är korrekt eller tryck på Enter för att gå in igen.

I slutet visas ett meddelande som indikerar framgångsrik nyckelgenerering. Du kommer att bli ombedd att ange ett lösenord för den privata nyckeln (om du vill lämna det samma som för certifikatet, tryck på Enter):

Genererar 2 048 bitars RSA-nyckelpar och självsignerat certifikat (SHA256withRSA) med en giltighetstid på 10 000 dagar för: CN=Ivan Petrov, OU=IT, O=2utvecklare, L=Moskva, ST=MO, C=RU Enter-nyckel lösenord för (RETURNERA om samma som nyckellagringslösenord):
En fil kommer att skapas i den aktuella katalogen lcf.nyckellager.

Viktig

Den skapade filen måste sparas på en säker plats. Om du använder ett privat arkiv kan filen committeras tillsammans med applikationens källkod. I allmänhet är det bättre att lagra certifikat separat. Om du tappar bort certifikatet kommer du inte att kunna utfärda appuppdateringar.

Det finns två steg kvar och du kommer att ha en APK-fil redo för distribution. Låt oss gå vidare till signering.

För att signera din apk-fil, använd verktyget jarsigner, som också ingår i JDK.

$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore lcf.keystore android-release-unsigned.apk lcf
Certifikatnamnet anges efter parametern -nyckellager, alias - efter filnamnet.

Slutligen, för att optimera apk-filen, kommer vi att använda verktyget zipalign:

$ zipalign -v 4 android-release-unsigned.apk LoyalClientFree.apk
Den sista parametern är namnet på filen du laddar upp till Google Play.

Viktig.

Verktyg zipalign det är en del av Android SDK Tools och kan hittas här:
/path/to/Android/sdk/build-tools/VERSION/zipalign

Slutsats

Du har nu en distributionsklar apk-fil som kan laddas upp till Google Play. Fyll i beskrivningen, bestäm betyget för din ansökan och klicka gärna på "Publicera".

Med Google Plays appsigneringsfunktion kan Google hantera din apps signeringsnyckel, samt skydda nyckeln och använda den för att signera dina APK-filer för distribution. Denna lagringsmetod kommer att skydda dig om nyckeln tappas bort eller hackas.

Viktig! För att använda Android AAB-arkiv (rekommenderat apppubliceringsformat) måste du registrera dig för Google Plays appsigneringsprogram innan du laddar upp AAB-arkivet till Play Console.

Registreringen är öppen för kontoinnehavare och användare med globala produktionshanteringsbehörigheter som har accepterat användarvillkoren. Du kan bara registrera en app åt gången med Google Play App Signing Program.

Arbetsprinciper

När du använder Google Plays appsigneringsfunktion lagras dina nycklar i samma infrastruktur som lagrar Googles nycklar och skyddas av en dedikerad nyckelhanteringstjänst. Detaljerad information Googles tekniska infrastruktur finns i dokumentationen för Google Cloud Security.

Android-applikationer är signerade med en privat nyckel. Varje sådan nyckel är associerad med ett offentligt certifikat, med vilket enheter och tjänster kan verifiera säkerheten för applikationer och deras uppdateringar. Endast de uppdateringar vars signatur matchar signaturen installeras på enheter installerad applikation. Om du låter Google hantera din appsigneringsnyckel blir processen säkrare.

Notera. Att använda Google Plays appsigneringsfunktion är valfritt. Du kan ladda ner APK-filer och hantera dina egna nycklar utan att använda AAB-arkiv. Men om du förlorar åtkomsten till nyckelarkivet eller om det äventyras kommer du inte att kunna uppdatera din applikation och måste publicera den igen med ett annat paketnamn.

Beskrivningar av nycklar, objekt och verktyg

Betingelser	Beskrivning
Nyckel för applikationssignering	Nyckeln som används av Google Play för att signera APK-filer som levereras till användarens enhet. När du registrerar dig för Google Plays appsigneringsprogram kan du ladda upp en befintlig signeringsnyckel eller låta Google skapa en ny.
Ladda ner nyckel	Det finns två sätt att generera en nedladdningsnyckel: Använd nyckeln för applikationssignering. Om du tillät Google att generera en appsigneringsnyckel när du registrerade dig för programmet, kommer uppladdningsnyckeln att vara nyckeln du använde för att signera den första versionen av appen. Använd en separat nedladdningsnyckel. Om du angav din egen appsigneringsnyckel när du registrerade dig för programmet, kan du skapa en ny nedladdningsnyckel för säkerheten. Om du inte vill göra detta, använd appsigneringsnyckeln som nedladdningsnyckel för att signera nya versioner.
Certifikat (.der eller .pem)	Ett certifikat som innehåller den publika nyckeln och Ytterligare information om sin ägare. Ett offentligt nyckelcertifikat låter vem som helst veta vem som har signerat ett AAB- eller APK-fil. Det här certifikatet kan delas eftersom det inte innehåller en privat nyckel. För att registrera dina nycklar hos API-leverantörer kan du ladda ner det offentliga certifikatet för din appsigneringsnyckel från Signering av ansökningar i Play Console. Ett offentligt nyckelcertifikat kan delas med alla eftersom det inte innehåller en privat nyckel.
Digitalt fingeravtryck av certifikatet	En kort och unik identifierare för certifikatet. Fingeravtrycket tillsammans med paketnamnet efterfrågas ofta av API-leverantörer för att ge tillgång till deras tjänster. Digitala fingeravtryck av MD5, SHA-1 och SHA-256 nedladdnings- och applikationssignaturcertifikat finns på sidan Signering av ansökningar i Play Console. Du kan också få en annan typ av digitalt fingeravtryck. För att göra detta, ladda ner originalcertifikatet i DER-format på samma sida.
Java Key Store (.jks eller .keystore)	Lagring av säkerhetscertifikat och privata nycklar.
PEPK-verktyg	Ett verktyg för att exportera privata nycklar från Java-lagring och kryptera dem för överföring till Google Play. När du har försett Google med din appsigneringsnyckel, välj att exportera och ladda ner din egen nyckel (och eventuellt dess offentliga certifikat), följ sedan instruktionerna för att ladda ner och använda verktyget. Du kan också ladda ner, visa och använda PEPK-verktyget med öppen källkod.

Processen att underteckna ansökan

Du kan ladda ner APK-filer signerade med den ursprungliga appsigneringsnyckeln före eller efter signering av appen på Google Play.

Om du migrerar till Android AAB-arkiv kan du testa dem i testversioner och använda befintliga APK-filer i produktionsversioner. Så här fungerar det:

Du signerar AAB-arkivet eller APK-filen och laddar upp det till Play Console.
Appsigneringsprocessen beror på vad du laddar ner.
- App Bundle. Google optimerar APK-filer från AAB-arkivet och signerar dem sedan med en appsigneringsnyckel.
- APK-fil signerad med nedladdningsnyckeln. Google verifierar din signatur, tar bort den och signerar om APK-filerna med appsigneringsnyckeln.
- En APK-fil signerad med appsigneringsnyckeln. Google verifierar signaturen.
Google levererar signerade APK-filer till användare.

Hur man registrerar sig för Google Play App Signing Program

Nya applikationer

Steg 1: Skapa en nedladdningsnyckel

Skapa en nedladdningsnyckel genom att följa instruktionerna.
Signera den nya APK-filen med nedladdningsnyckeln.

Steg 2: Förbered releasen

, följ instruktionerna.
När du har valt versionstyp konfigurerar du inställningarna för appsignering under "Låt Google skydda och hantera din appsigneringsnyckel".
Om du klickar Fortsätta, kommer den genererade nyckeln att bli nedladdningsnyckeln som kommer att användas för att signera framtida utgåvor. Du kan också välja följande Avancerade inställningar:
- Använd en nyckel för olika applikationer i utvecklarkontot (alternativ 2).
- Ladda upp signeringsnyckeln för en befintlig applikation (alternativ 2, 3 och 4), välj den mest lämpliga export- och nedladdningsmetoden. När du har laddat ner ett programs signeringsnyckel och dess offentliga certifikat kan du antingen använda det som programmets signeringsnyckel.

Notera. För att fortsätta måste du acceptera användarvillkoren och registrera dig för appsigneringsprogrammet.

Steg 3: Registrera din appsigneringsnyckel hos dina API-leverantörer

Om din applikation använder ett API behöver du sannolikt registrera ett nyckelcertifikat som Google använder för att signera din applikation för att autentisera. Så här hittar du ett certifikat:

Logga in på Play Console.
Välj ett program.
Välj i menyn till vänster Releasehantering > Ansökningssignaturer.
- Om API-leverantören kräver en annan typ av fingeravtryck kan du ladda ner originalcertifikatet i DER-format och konvertera det efter behov med lämpliga verktyg.

Publicerade Applications

Steg 1: Registrera dig för Google Play App Signing Program

Logga in på Play Console.
Välj ett program.
Välj i menyn till vänster Releasehantering > Ansökningssignaturer.
Om det behövs, läs användarvillkoren och klicka Acceptera.

Steg 2: Skicka in den ursprungliga nyckeln till Google och skapa en nedladdningsnyckel

Hitta den ursprungliga applikationssigneringsnyckeln.
Logga in på Play Console.
Välj ett program.
Välj i menyn till vänster Releasehantering > Ansökningssignaturer.
Ladda upp en befintlig applikationssigneringsnyckel med den metod som bäst passar din releaseprocess.

och ladda upp certifikatet till Google Play.
- Du kan också använda nyckeln för programsignering som nedladdningsnyckel.
Kopiera de digitala fingeravtrycken (MD5, SHA-1 och SHA-256) från programmets signeringscertifikat.
- För att utföra testning kan du behöva registrera ett startnyckelcertifikat hos API-leverantören med hjälp av certifikatets fingeravtryck och applikationssigneringsnyckel.

Steg 4: Signera din nästa appuppdatering med din nedladdningsnyckel

Utgivna programuppdateringar måste signeras med en nedladdningsnyckel.

Hur man skapar en nedladdningsnyckel och uppdaterar nyckellager

Du kan skapa en nedladdningsnyckel när du registrerar dig för Google Play App Signing Program, eller så kan du skapa en senare i Releasehantering > Ansökningssignaturer.

För att skapa en nedladdningsnyckel, följ dessa steg:

Följ instruktionerna på webbplatsen för Android-utvecklare. Förvara nyckeln på en säker plats.
Exportera certifikatet för startnyckeln i PEM-format. Ersätt följande argument med ett understreck:
- $ keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

När du uppmanas under utfärdandeprocessen laddar du ned certifikatet för att registrera det hos Google.

Om du använder en nedladdningsnyckel:

Nedladdningsnyckeln registreras hos Google endast för att autentisera identiteten för appskaparen.
Din signatur tas bort från alla APK-nedladdningar innan de når användarna.

Restriktioner

Nedladdningsnyckeln måste använda RSA-kryptering och måste vara minst 2048 bitar stor.
DSA- och EC-nycklar stöds inte, inte heller är RSA-nycklar mindre än 2048 bitar.

Uppdatering av nyckellager

När du har skapat din nedladdningsnyckel, kontrollera och uppdatera följande platser om det behövs:

lokalt system;
skyddad lokal server(med olika åtkomstkontrollistor);
molnsystem (med olika åtkomstkontrollistor);
särskilda nyckelhanteringstjänster;
Git repositories.

Så här uppdaterar du signeringsnyckeln för nya appinstallationer

I vissa fall kan du begära en uppdatering av en applikationssigneringsnyckel. Den nya nyckeln kommer att användas för att signera nya installationer och uppdateringar av programmet, och den föråldrade kommer att användas för att uppdatera signerade versioner som redan är installerade av användare.

Signeringsnyckeln kan endast uppdateras en gång för varje applikation. I det osannolika fallet att du använder en enda signeringsnyckel för flera applikationer för att köra dem i samma process, kan nyckeln inte uppdateras.

Du bör begära en uppdatering av en applikationssigneringsnyckel i följande fall:

Du behöver en säkrare nyckel.
Programsigneringsnyckeln har äventyrats.

Notera. Begäran om att uppdatera appsigneringsnyckeln på Play Console är inte relaterad till ersättning av nycklar i Android P och senare versioner. Denna nyckelersättning stöds för närvarande inte av Google Play.

Viktiga anmärkningar om uppdatering av nycklar

Innan du begär en nyckeluppdatering är det viktigt att förstå vilka förändringar detta kommer att innebära.

Om du använder samma signeringsnyckel för flera appar för att använda samma kod eller data, måste du uppdatera apparna för att känna igen både de nya och äldre nycklarna.
Om din app använder ett API, se till att registrera certifikaten för de nya och äldre appsigneringsnycklarna hos API-leverantören innan du uppgraderar din app. Certifikat finns på sidan Signering av ansökningar Spelkonsol.
Om många användare av din applikation installerar uppdateringar via fildelningsnätverk, kommer de bara att kunna installera uppdateringar signerade med samma nyckel som applikationen installerad på deras enheter. Om applikationer inte kan uppdateras pga installerad version signerad med en annan nyckel kan användare avinstallera och installera om den för att få uppdateringar.

Begär en nyckeluppdatering för nya installationer. För att göra detta, följ dessa steg:

Logga in på Play Console.
Välj ett program.
Välj i menyn till vänster Releasehantering > Ansökningssignaturer.
I kortet "Uppdatera signeringsnyckel för nya appinstallationer" väljer du Begär en nyckeluppdatering.
Välj vad du vill göra med enheten.
- Beroende på vilket alternativ du väljer kan du behöva kontakta support för att slutföra din förfrågan.
Tillåt Google Play att generera en ny appsigneringsnyckel (rekommenderas) eller ladda ner en.
- Efter att du har uppdaterat din appsigneringsnyckel, om nyckeln matchar din nedladdningsnyckel, kan du fortsätta att använda den gamla appsigneringsnyckeln som din nedladdningsnyckel eller skapa en ny.

Om du också har publicerat din app utanför Google Play eller planerar att göra det kan du skapa en delad appsigneringsnyckel och ladda upp den till Google när du registrerar dig för Google Plays appsigneringsprogram.
För att skydda ditt konto, aktivera tvåstegsverifiering för alla konton som har åtkomst till Play Console.
Efter att App Bundle har publicerats i testet eller fungerande version Du kan öppna App Bundle Browser och ladda ner ett ZIP-arkiv som innehåller alla APK-filer för en specifik enhet. Dessa APK-filer är redan signerade med appsigneringsnyckeln. Du kan installera dem på din enhet från ett ZIP-arkiv med hjälp av verktyget kommandorad buntverktyg.
För större säkerhet, generera en ny nedladdningsnyckel som skiljer sig från applikationssigneringsnyckeln.
Om du vill testa en APK signerad med en uppladdningsnyckel, registrera nyckeln med en tjänst eller API som använder appens signatur för autentisering (som API Google kartor eller Facebook Developer Pack).
Om du använder Google API kan du registrera ditt uppladdningscertifikat i Google Cloud Console.

Vad ska man göra om nyckeln tappas bort eller hackas

Om du har förlorat åtkomsten till din privata nedladdningsnyckel eller den har blivit hackad, och fråga ägaren av ditt konto. När du kontaktar support måste kontoägaren bifoga filen upload_certificate.pem.

När supportteamet registrerar en ny nedladdningsnyckel får du ett e-postmeddelande och kan sedan uppdatera dina nyckellager och registrera nyckeln hos API-leverantörer.

Viktig! Att återställa nedladdningsnyckeln påverkar inte appsigneringsnyckeln, som Google Play använder för att signera APK-filer innan de skickas till användarna.

Var denna information användbar?

Hur kan den här artikeln förbättras?

Ibland passar vissa applikationer på Android inte användaren på något sätt. Ett exempel är påträngande reklam. Och det händer också att programmet är bra för alla, men översättningen i det är antingen snett eller helt frånvarande. Eller, till exempel, programmet är en testversion, men det finns inget sätt att få den fullständiga versionen. Hur ändrar man situationen?

Introduktion

I den här artikeln kommer vi att prata om hur man demonterar ett APK-paket med en applikation, tittar på dess interna struktur, demonterar och dekompilerar bytekoden och försöker också göra flera ändringar i applikationerna som kan ge oss en eller annan fördel.

För att göra allt detta själv behöver du åtminstone grundläggande kunskaper i Java-språket, som Android-applikationer skrivs i, och XML-språket, som används överallt i Android - från att beskriva själva applikationen och dess åtkomsträttigheter till att lagra strängar som kommer att visas på skärmen. Du behöver också förmågan att använda specialiserad konsolmjukvara.

Så, vad är ett APK-paket där absolut all Android-programvara distribueras?

Applikationsdekompilering

I den här artikeln arbetade vi bara med demonterad applikationskod, men om mer allvarliga ändringar görs i stora applikationer blir det mycket svårare att förstå smali-koden. Lyckligtvis kan vi dekompilera dex-koden till Java-kod, som, även om den inte är original och inte kompilerad tillbaka, är mycket lättare att läsa och förstå applikationens logik. För att göra detta behöver vi två verktyg:

dex2jar är en översättare av Dalvik bytecode till JVM bytecode, på basis av vilken vi kan erhålla kod på Java-språket;
jd-gui är en dekompilerare i sig som låter dig få läsbar Java-kod från JVM bytecode. Som ett alternativ kan du använda Jad (www.varaneckas.com/jad); Även om den är ganska gammal, genererar den i vissa fall mer läsbar kod än Jd-gui.

Så här ska de användas. Först startar vi dex2jar och anger sökvägen till apk-paketet som ett argument:

% dex2jar.sh mail.apk

Som ett resultat kommer Java-paketet mail.jar att dyka upp i den aktuella katalogen, som redan kan öppnas i jd-gui för att se Java-koden.

Arrangering av APK-paket och mottagande av dem

Plastpåse Android-applikationer, i själva verket är en vanlig ZIP-fil, inga speciella verktyg krävs för att se innehållet och extrahera det. Det räcker med att ha en arkiverare - 7zip för Windows eller console unzip på Linux. Men det handlar om omslaget. Vad finns inuti? I allmänhet har vi följande struktur inuti:

META-INF/- innehåller ett digitalt certifikat för applikationen, som identifierar dess skapare, och kontrollsummor för paketfilerna;
res/ - olika resurser som applikationen använder i sitt arbete, såsom bilder, deklarativ beskrivning av gränssnittet, samt annan data;
AndroidManifest.xml- beskrivning av ansökan. Detta inkluderar till exempel en lista över nödvändiga behörigheter, den nödvändiga Android-versionen och den nödvändiga skärmupplösningen;
classes.dex- kompilerad applikationsbytekod för virtuell maskin Dalvik;
resources.arsc- även resurser, men av ett annat slag - i synnerhet strängar (ja, den här filen kan användas för russifiering!).

De listade filerna och katalogerna finns, om inte alla, så kanske i de allra flesta APK-filer. Det finns dock några fler inte så vanliga filer/kataloger värda att nämna:

tillgångar- Analog av resurser. Den största skillnaden är att för att komma åt en resurs måste du känna till dess identifierare, men listan över tillgångar kan erhållas dynamiskt med metoden AssetManager.list() i applikationskoden;
lib- Inbyggda Linux-bibliotek skrivna med NDK (Native Development Kit).

Den här katalogen används av speltillverkare som placerar spelmotorn skriven i C/C++ där, såväl som av skapare av högpresterande applikationer (till exempel, Google Chrome). Vi kom på enheten. Men hur får du paketfilen för den applikation du är intresserad av? Eftersom det inte är möjligt att hämta APK-filer från enheten utan root (de finns i /data/app-katalogen), och att roota inte alltid är tillrådligt, finns det minst tre sätt att få applikationsfilen till din dator:

APK Downloader-tillägg för Chrome;
Real APK Leecher app;
olika filhosting och Varezniks.

Vilken man ska använda är en smaksak; vi föredrar att använda separata applikationer, så vi kommer att beskriva användningen av Real APK Leecher, särskilt eftersom den är skriven i Java och följaktligen kommer att fungera i antingen Windows eller Nix.

Efter att ha startat programmet måste du fylla i tre fält: E-post, Lösenord och Enhets-ID - och välja ett språk. De två första är e-postadressen och lösenordet för ditt Google-konto som du använder på enheten. Den tredje är enhetsidentifieraren och kan erhållas genom att skriva in koden på uppringaren # #8255## och sedan hitta enhets-ID-raden. När du fyller i behöver du bara ange ID utan android-prefix.

Efter att ha fyllt i och sparat dyker ofta meddelandet "Fel vid anslutning till servern" upp. Det har inget med Google Play att göra, så ignorera det gärna och leta efter paket som intresserar dig.

Visa och ändra

Låt oss säga att du hittade ett paket som intresserar dig, laddade ner det, packade upp det... och när du försökte visa någon XML-fil blev du förvånad över att upptäcka att filen inte var text. Hur dekompilerar man det och hur man arbetar med paket i allmänhet? Är det verkligen nödvändigt att installera SDK? Nej, det är inte nödvändigt att installera SDK alls. Faktum är att alla steg för att extrahera, ändra och paketera APK-paket kräver följande verktyg:

ZIP-arkiv för uppackning och packning;
smali- Dalvik virtuell maskin bytecode assembler/disassembler (code.google.com/p/smali);
aapt- ett verktyg för att paketera resurser (som standard lagras resurser i binär form för att optimera applikationsprestanda). Ingår i Android SDK, men kan erhållas separat;
undertecknare- ett verktyg för digital signering av ett modifierat paket (bit.ly/Rmrv4M).

Du kan använda alla dessa verktyg separat, men detta är obekvämt, så det är bättre att använda programvara på högre nivå byggd på deras bas. Om du arbetar på Linux eller Mac OS X finns det ett verktyg som heter apktool. Det låter dig packa upp resurser i sin ursprungliga form (inklusive binära XML- och arsc-filer), bygga om ett paket med ändrade resurser, men det vet inte hur man signerar paket, så du måste köra signerarens verktyg manuellt. Trots att verktyget är skrivet i Java är installationen ganska ostandard. Först måste du hämta själva 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 $ export PATH=~/bin:$PATH

Om du arbetar på Windows, så finns det ett utmärkt verktyg för det som heter Virtuous Ten Studio, som också samlar alla dessa verktyg (inklusive själva apktoolen), men istället för ett CLI-gränssnitt ger användaren ett intuitivt GUI, med vilken du kan utföra uppackning, demontering och dekompilering med några få klick. Det här verktyget är donationsprogram, det vill säga ibland dyker det upp fönster som ber dig att skaffa en licens, men i slutändan kan detta tolereras. Det är ingen idé att beskriva det, för du kan förstå gränssnittet på några minuter. Men apktool, på grund av dess konsolkaraktär, bör diskuteras mer i detalj.

Låt oss titta på apktool-alternativen. Kort sagt, det finns tre grundläggande kommandon: d (avkoda), b (bygga) och if (installera ramverk). Om allt är klart med de två första kommandona, vad gör det tredje, villkorliga uttalandet? Den packar upp det specificerade UI-ramverket, vilket är nödvändigt i de fall du dissekerar ett systempaket.

Låt oss titta på de mest intressanta alternativen för det första kommandot:

-s- ta inte isär dex-filer;
-r- packa inte upp resurser;
-b- infoga inte felsökningsinformation i resultaten av demonteringen av dex-filen;
--frame-path- använd det angivna UI-ramverket istället för det som är inbyggt i apktool. Låt oss nu titta på ett par alternativ för b-kommandot:
-f- tvångsmontering utan kontroll av ändringar;
-a- ange sökvägen till aapt (ett verktyg för att bygga ett APK-arkiv), om du av någon anledning vill använda det från en annan källa.

Att använda apktool är väldigt enkelt; för att göra detta, specificera bara ett av kommandona och sökvägen till APK, till exempel:

$ apktool d mail.apk

Efter detta kommer alla extraherade och demonterade filer av paketet att visas i e-postkatalogen.

Förberedelse. Inaktivera reklam

Teori är naturligtvis bra, men varför behövs det om vi inte vet vad vi ska göra med det uppackade paketet? Låt oss försöka tillämpa teorin till vår fördel, nämligen modifiera någon programvara så att den inte visar oss reklam. Låt det till exempel vara Virtual Torch - en virtuell ficklampa. Den här programvaran är idealisk för oss, eftersom den är fylld till yttersta gränsen med irriterande reklam och dessutom är den enkel nog att inte gå vilse i koddjungeln.

Så, med någon av ovanstående metoder, ladda ner applikationen från marknaden. Om du bestämmer dig för att använda Virtuous Ten Studio, öppna helt enkelt APK-filen i applikationen och packa upp den, skapa ett projekt (Arkiv -> Nytt projekt), välj sedan Importera fil i projektets snabbmeny. Om ditt val föll på apktool, kör bara ett kommando:

$ apktool d com.kauf.particle.virtualtorch.apk

Efter detta kommer ett filträd liknande det som beskrivs i föregående avsnitt att dyka upp i katalogen com.kauf.particle.virtualtorch, men med en extra smali-katalog istället för dex-filer och en apktool.yml-fil. Den första innehåller demonterad kod för programmets körbara dex-fil, den andra innehåller serviceinformation som krävs för att apktool ska kunna montera tillbaka paketet.

Det första stället vi bör leta är naturligtvis AndroidManifest.xml. Och här möter vi omedelbart följande rad:

Det är inte svårt att gissa att det är ansvarigt för att ge applikationen behörighet att använda internetanslutningen. Faktum är att om vi bara vill bli av med reklam kommer vi sannolikt bara att behöva blockera applikationen från Internet. Låt oss försöka göra det här. Vi tar bort den angivna raden och försöker bygga programvaran med apktool:

$ apktool b com.kauf.particle.virtualtorch

Den resulterande APK-filen kommer att visas i katalogen com.kauf.particle.virtualtorch/build/. Det kommer dock inte att vara möjligt att installera det, eftersom det inte har en digital signatur och filkontrollsummor (den har helt enkelt ingen META-INF/-katalog). Vi måste signera paketet med hjälp av apk-signer-verktyget. Lanserades. Gränssnittet består av två flikar - på den första (Key Generator) skapar vi nycklar, på den andra (APK Signer) signerar vi. För att skapa vår privata nyckel, fyll i följande fält:

Målfil- keystore utdatafil; den lagrar vanligtvis ett par nycklar;
Lösenord Och Bekräfta- lösenord för lagringen;
Alias- namnet på nyckeln i förrådet;
Alias lösenord Och Bekräfta- hemligt nyckellösenord;
Giltighet- Giltighetstid (i år). Standardvärdet är optimalt.

De återstående fälten är i allmänhet valfria - men minst ett måste fyllas i.

VARNING

För att signera en applikation med apk-signer måste du installera Android SDK och ange den fullständiga sökvägen till den i applikationsinställningarna.

All information tillhandahålls endast i informationssyfte. Varken redaktörerna eller författaren är ansvariga för eventuell skada orsakad av materialet i denna artikel.

Nu kan du signera APK-filen med denna nyckel. På fliken APK Signer väljer du den nyskapade filen, anger lösenordet, nyckelaliaset och lösenordet, leta reda på APK-filen och klickar djärvt på "Sign"-knappen. Om allt går bra kommer paketet att signeras.

INFO

Eftersom vi signerade paketet med vår egen nyckel kommer det att komma i konflikt med den ursprungliga applikationen, vilket innebär att när vi försöker uppdatera programvaran via marknaden får vi ett felmeddelande.

En digital signatur krävs bara för programvara från tredje part, så om du ändrar systemapplikationer, som installeras genom att kopiera till /system/app/-katalogen, behöver du inte signera dem.

Efter det, ladda ner paketet till din smartphone, installera det och starta det. Voila, annonsen är borta! Istället dök dock ett meddelande upp att vi inte har internet eller att vi inte har rätt behörighet. I teorin kan det här räcka, men meddelandet ser irriterande ut, och för att vara ärlig hade vi bara tur med en dum ansökan. Normalt skriven programvara kommer med största sannolikhet att förtydliga sina referenser eller söka efter en internetanslutning och annars helt enkelt vägra att starta. Hur ska man vara i det här fallet? Självklart, redigera koden.

Vanligtvis skapar applikationsförfattare speciella klasser för att visa annonser och anropsmetoder för dessa klasser när applikationen eller en av dess "aktiviteter" (enkelt uttryckt applikationsskärmar) startas. Låt oss försöka hitta dessa klasser. Vi går till smali-katalogen, sedan com (org innehåller bara det öppna grafiska biblioteket cocos2d), sedan kauf (det är här det är, eftersom det här är namnet på utvecklaren och all hans kod finns där) - och här är den, marknadsföringskatalogen. Inuti hittar vi ett gäng filer med tillägget smali. Det här är klasser, och den mest anmärkningsvärda av dem är Ad.smali-klassen, från vars namn det är lätt att gissa att det är den som visar reklam.

Vi skulle kunna ändra logiken i dess funktion, men det skulle vara mycket lättare att helt enkelt ta bort anrop till någon av dess metoder från själva applikationen. Därför lämnar vi marknadsföringskatalogen och går till den intilliggande partikelkatalogen och sedan till virtualtorch. Filen MainActivity.smali förtjänar särskild uppmärksamhet här. Detta är en standard Android-klass som skapas av Android SDK och installeras som ingångspunkt till applikationen (analogt med huvudfunktionen i C). Öppna filen för redigering.

Inuti finns smali-kod (lokal montör). Den är ganska förvirrande och svår att läsa på grund av dess lågnivåkaraktär, så vi kommer inte att studera den, utan hittar helt enkelt alla referenser till annonsklassen i koden och kommenterar dem. Vi anger raden "Annons" i sökningen och kommer till rad 25:

Fält privat annons:Lcom/kauf/marketing/Ad;

Här skapas ett annonsfält för att lagra ett annonsklassobjekt. Vi kommenterar genom att placera ett ###-tecken framför raden. Vi fortsätter sökandet. Linje 423:

Ny instans v3, Lcom/kauf/marketing/Ad;

Det är här objektskapandet sker. Låt oss kommentera. Vi fortsätter sökningen och hittar på raderna 433, 435, 466, 468, 738, 740, 800 och 802 anrop till metoder i klassen Ad. Låt oss kommentera. Ser ut som det är det. Spara. Nu ska paketet sättas ihop igen och kontrolleras för funktionalitet och förekomst av reklam. För experimentets renhet returnerar vi raden borttagen från AndroidManifest.xml, sätter ihop paketet, signerar och installerar.

Vårt marsvin. Reklam synlig

hoppsan! Reklamen försvann bara medan applikationen kördes, men fanns kvar i huvudmenyn, som vi ser när vi startar programvaran. Så, vänta, men ingångspunkten är MainActivity-klassen, och annonsen försvann medan applikationen kördes, men förblev i huvudmenyn, så ingångspunkten är annorlunda? För att identifiera den verkliga ingångspunkten öppnar du filen AndroidManifest.xml igen. Och ja, den innehåller följande rader:

De berättar för oss (och, ännu viktigare, androiden) att en aktivitet som heter Start bör lanseras som svar på genereringen av en avsikt (händelse) android.intent.action.MAIN från kategorin android.intent.category.LAUNCHER. Den här händelsen genereras när du trycker på programikonen i startprogrammet, så den bestämmer startpunkten, nämligen Start-klassen. Troligtvis skrev programmeraren först en applikation utan huvudmeny, vars ingångspunkt var standardklassen MainActivity, och lade sedan till ett nytt fönster (aktivitet) som innehåller menyn och beskrivs i klassen Start, och gjorde det manuellt till ingången punkt.

Öppna filen Start.smali och leta igen efter raden "Ad", vi hittar på raderna 153 och 155 ett omnämnande av FirstAd-klassen. Den finns också i källkoden och, av namnet att döma, ansvarar den för att visa annonser på huvudskärmen. Låt oss titta vidare, det finns skapandet av en instans av FirstAd-klassen och en avsikt som, enligt sammanhanget, är relaterad till denna instans, och sedan etiketten cond_10, den villkorliga övergången till vilken utförs exakt innan en instans skapas av klassen:

If-ne p1, v0, :cond_10 .line 74 new-instance v0, Landroid/content/Intent; ... :cond_10

Troligtvis beräknar programmet på något sätt slumpmässigt om reklam ska visas på huvudskärmen, och om inte, hoppar det direkt till cond_10. Ok, låt oss förenkla hennes uppgift och ersätta den villkorliga övergången med en ovillkorlig:

#if-ne p1, v0, :cond_10 goto:cond_10

Det finns inga fler omnämnanden av FirstAd i koden, så vi stänger filen och sätter ihop vår virtuella ficklampa med apktool. Kopiera den till din smartphone, installera den, starta den. Voila, all reklam har försvunnit, vilket vi gratulerar oss alla till.

Resultat

Den här artikeln är bara en kort introduktion till metoderna för att hacka och ändra Android-applikationer. Många problem kvarstod bakom kulisserna, som att ta bort skydd, tolka obfuskerad kod, översätta och ersätta programresurser, samt modifiera program skrivna med Android NDK. Men med grundläggande kunskaper är det bara en tidsfråga att ta reda på allt.

Visningar av inlägg: 5 618

Android Studio ger stora möjligheter både för applikationsutveckling och för att öka automatisering och komfort i programmering.

Om du använder ett byggsystem Gradle för att skapa dina applikationer kan du också konfigurera flera alternativ för att skapa signaturer för dina applikationer.

Du vill förmodligen inte publicera dina signeringsnycklar, lösenord och användarnamn till ett offentligt (eller ens privat) arkiv. Därför kan du definiera nyckel, lösenord och användarnamn som egenskaper i en separat fil.

Innan du börjar signera din ansökan måste du skapa en ny egenskap i filen gradle.properties. Låt oss ringa honom Keys.repo och, som ett värde, ange sökvägen till mappen där nyckellagret och filen med egenskaper senare kommer att finnas (till exempel, C:/Users/UserName/.signing).

Keys.repo=C:/Users/UserName/.signing

Då måste du skapa den här mappen eller, om du har angett en befintlig, öppna den. Du måste skapa en fil i den YourProjectName.properties, i vilken sökvägen till nyckellagret, nyckelaliaset och lösenordet kommer att skrivas som egenskaper i följande formulär.

RELEASE_STORE_FILE=/Ditt projektnamn/KeyStoreName.jks RELEASE_STORE_PASS=****** RELEASE_ALIAS=KeyAlias RELEASE_KEY_PASS=******

Hur skapar man ett nyckelvalv?

Om du inte har ett nyckellager kan du enkelt skapa ett med använder Android Studio. För att göra detta, välj menyalternativet Bygga -> Generera signerad APK.

I fönstret som visas måste du klicka Skapa ny... Som ett resultat kommer ett fönster att öppnas där du kan ange var nyckellagringen ska finnas (för den här lektionen är det bättre att omedelbart välja sökvägen som du angav i YourProjectName.properties i fastighet RELEASE_STORE_FILE), samt nyckelinformation.

Sedan måste du skapa en mapp Ditt projektnamn och flytta dit nödvändig fil nyckelbutiker.

Nu kan du fortsätta direkt till signeringsprocessen. För att göra detta måste du öppna filen i ditt projekt bygga.gradle(finns i app-mappen). Inuti den i blocket android du måste lägga till följande kod.

SigningConfigs ( debug ( /* inga ändringar här */ ) 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 props["RELEASE_STORE_PASS"] keyAliasprops["RELEASE_ALIAS"] keyPassword props["RELEASE_KEY_PASS"] ) ) else ( println "===================== = ==============================org ~/. signeringskatalog" println "============================================ =============================" ) ) )

Vilka är de olika systemen för att få en signatur?

Det finns två scheman för att erhålla en APK-signatur: v1 JAR Och v2 Full APK.

I det första fallet är det undertecknat BURK-fil, vilket är traditionellt sätt signering. Signering v1 skyddar inte vissa delar av APK-filen, till exempel ZIP-metadata. APK-verifieraren måste hantera många opålitliga (ännu ej verifierade) datastrukturer och sedan kassera data som inte är signerad, vilket lämnar en hel del attackyta. Dessutom måste APK-verifieraren dekomprimera alla komprimerade poster, vilket slösar mycket tid och minne. För att lösa dessa problem har det andra schemat v2 Full APK utvecklats.

Schema v2 presenterades i Android 7.0 Nougat (API 25) och fungerar från version Android Studio 2.2 Och Android Gradle-plugin 2.2. Detta schema ger snabbare applikationsinstallation och bra skydd mot obehöriga ändringar av APK. APK-innehållet hashas och signeras, sedan resultatet APK-signaturblock infogas i APK.

Under verifiering behandlar v2-schemat APK-filen som en blob och utför signaturverifiering på hela filen. Alla ändringar av APK:n, inklusive ändringar av ZIP-metadata, ogiltigförklarar signaturen. Denna form av verifiering är mycket snabbare och kan upptäcka fler obehöriga ändringar.

Det nya formatet är bakåtkompatibelt, så APK-filer signerade med det nya schemat kan installeras på äldre enheter (som helt enkelt ignorerar den nya signaturen) så länge som dessa APK-filer också är signerade med v1-schemat.

Som standard använder signering båda scheman så att appar kan installeras på vilken enhet som helst. Men om det finns ett sådant behov kan du inaktivera v1- eller v2-signaturen. För att göra detta, i ovanstående kod i blocket släpp Det räcker att lägga till följande rader.

V1SigningEnabled false

V2SigningEnabled false

Det är också viktigt att notera att du måste signera med schema v1 innan du signerar med schema v2, eftersom APK:n inte kommer att klara verifiering enligt schema v2 om den signeras med ytterligare certifikat efter signering med schema v2.

När koden har lagts till, inkludera denna kod i ett block byggtyper inuti släpp. Till exempel:

BuildTypes ( release ( minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" signingConfig signingConfigs.release ) )

Nu kan du säkert i menyalternativet Bygga välja Bygg APK, efter att tidigare ha ändrat monteringstypen från felsöka på släpp. Som du kan se är den här metoden bekväm eftersom den är automatisk, du behöver bara konfigurera den en gång och dina nyckellagringar kan vara säkra.

Populär i kategorin: