Untersuchung eines unbekannten Archivs

Umzug. Neue Stadt. Jobsuche. Selbst für einen IT-Experten kann dies lange dauern. Eine Reihe von Interviews, die sich im Allgemeinen sehr ähnlich sind. Und wie es normalerweise passiert, wenn Sie bereits eine Stelle gefunden haben, wird nach einer Weile ein interessantes Büro angekündigt.

Es war schwer zu verstehen, was sie speziell tat, ihr Interessengebiet war jedoch das Studium der Software anderer Leute. Es klingt faszinierend, obwohl Sie, wenn Sie feststellen, dass dies kein Anbieter zu sein scheint, der Software für die Cybersicherheit veröffentlicht, eine Sekunde innehalten und anfangen, Ihre Rüben zu kratzen.



Kurzum: Sie warfen das Archiv ab und boten an, es als Testaufgabe zu untersuchen und zu versuchen, eine bestimmte Signatur basierend auf den präsentierten Eingabedaten zu berechnen. Es ist erwähnenswert, dass ich nur sehr wenig Erfahrung mit solchen Aktivitäten hatte und wahrscheinlich deshalb in der ersten Iteration der Lösung nur ein paar Stunden Zeit hatte - dann wurde die Motivation, dies zu tun, zunichte gemacht. Und ja, natürlich habe ich als erstes versucht, es auf dem Telefon / Emulator auszuführen - diese Anwendung ist ungültig.

Was wir haben: ein Archiv mit der Erweiterung ".apk" . Ich habe die Aufgabe selbst unter den Spoiler gestellt, damit sie nicht von Suchmaschinen indiziert wird: Was ist, wenn die Jungs es nicht mögen, dass ich die Lösung auf Habr stelle?

Ärmel hochkrempeln

Es wird gesagt, dass das Archiv die Funktionalität zum Signieren eines assoziativen Arrays enthält. Unter der Dateierweiterung verstehen wir sofort, dass es sich um eine für Android geschriebene Anwendung handelt. Zuerst packen wir das Archiv aus. Tatsächlich handelt es sich hierbei um ein reguläres ZIP-Archiv, mit dem jeder Archivierer problemlos umgehen kann. Ich habe das Dienstprogramm apktool verwendet und, wie sich herausstellte, versehentlich ein paar Rechen umgangen. Ja, es passiert (normalerweise das Gegenteil, ja?). Der Zauber ist ziemlich einfach:

 apktool d task.zip 

Es stellt sich heraus, dass der Code und die Ressourcen in der APK-Datei auch in separaten Binärdateien gespeichert sind und andere Software benötigt wird, um sie zu extrahieren. apktool hat implizit Klassenbytes und Ressourcen herausgezogen und alles in eine natürliche Dateihierarchie zerlegt. Sie können fortfahren.

 ├── AndroidManifest.xml ├── apktool.yml ├── lib │   └── arm64-v8a ├── original │   ├── AndroidManifest.xml │   └── META-INF ├── res │   ├── anim │   ├── color │   ├── drawable │   ├── layout │   ├── layout-watch-v20 │   ├── mipmap-anydpi-v26 │   ├── values │   └── values-af ├── smali │   ├── android │   ├── butterknife │   ├── com │   ├── net │   └── org └── unknown   └── org 

Wir sehen eine ähnliche Hierarchie (haben die vereinfachte Version verlassen) und versuchen herauszufinden, wo wir anfangen sollen. Es ist erwähnenswert, dass ich trotzdem einmal ein paar kleine Anwendungen für Android geschrieben habe, so dass mir die Essenz eines Teils der Verzeichnisse und im Allgemeinen die Prinzipien der Android-Anwendungen des Geräts ungefähr klar sind.

Zunächst entscheide ich mich, einfach durch die Dateien zu gehen. Ich öffne AndroidManifest.xml und beginne sinnvoll zu lesen. Meine Aufmerksamkeit wird von einem seltsamen Attribut angezogen

 android:supportsRtl="true" 

Es stellt sich heraus, dass er für die Unterstützung von Sprachen mit dem Buchstaben "von rechts nach links" in der Anwendung verantwortlich ist. Wir beginnen uns anzustrengen. Nicht gut.

Außerdem klammert sich mein Blick an den unbekannten Ordner. Darunter befindet sich eine Hierarchie des Formulars: org.apache.commons.codec.language.bm und eine große Anzahl von Textdateien mit unklarem Inhalt. Google den vollständigen Namen des Pakets und es stellt sich heraus, was hier gespeichert ist, was mit dem Suchalgorithmus für Wörter zusammenhängt, die dem angegebenen phonetisch ähnlich sind. Ehrlich gesagt begann ich mich hier stärker anzustrengen. Nachdem ich mich ein bisschen in den Verzeichnissen umgesehen hatte, fand ich tatsächlich den Code selbst und dann begann der Spaß. Ich wurde nicht von dem üblichen Java-Bytecode getroffen, mit dem ich einmal herumspielen konnte, sondern von etwas anderem. Sehr ähnlich, aber anders.

Wie sich herausstellte, hat Android eine eigene virtuelle Maschine - Dalvik. Und wie jede angesehene virtuelle Maschine verfügt sie über einen eigenen Bytecode. Es scheint, dass ich beim ersten Versuch, dieses Problem zu lösen, in diesem traurigen Ton eine Pause ankündigte, mich verbeugte, den Vorhang fallen ließ und alles 4 Monate lang warf, bis meine Neugier mich vollständig beendete.

Ärmel hochkrempeln [2]

"Aber kann es nicht so sein, dass alles einfacher ist?" - Dies ist die Frage, die ich mir gestellt habe, als ich die Aufgabe zum zweiten Mal gestartet habe. Ich begann im Internet nach einem Dekompiler von smali nach Java zu suchen. Ich habe nur gesehen, dass es unmöglich ist, diesen Prozess eindeutig durchzuführen. Mit gerunzelter Stirn ging er zu Github und fuhr ein paar Schlüsselbegriffe in die Suchzeile. Der erste kam smali2java .

 git clone gradle build java -jar smali2java.jar .. 

Fehler Ich sehe eine riesige Stapelverfolgung und Fehler auf mehreren Seiten des Terminals. Nachdem ich ein wenig über die Essenz des Inhalts gelesen habe (und Emotionen von der Größe der Stapelspur abgehalten habe), stelle ich fest, dass dieses Tool auf der Grundlage einer bestimmten beschriebenen Grammatik funktioniert und der Bytecode, den sie getroffen hat, eindeutig nicht mit dieser übereinstimmt. Ich öffne den kleinen Bytecode und sehe darin Anmerkungen, Synthesemethoden und andere seltsame Konstruktionen. In Java-Bytecode gab es so etwas nicht! Wie lange Löschen!


Hilft nicht. Er schwört sogar auf einen scheinbar nicht verdächtigen Bytecode. Ich öffne den Quellcode des Dekompilers, lese und sehe etwas sehr Seltsames: Selbst hinduistische Programmierer (bei allem Respekt) hätten dies nicht geschrieben. Ein Gedanke schleicht sich ein: nicht wirklich der generierte Code. Ich lehne die Idee für ungefähr 30 Minuten ab und versuche zu verstehen, was der Fehler ist. KOMPLIZIERT. Ich öffne Github wieder - und wirklich einen durch Grammatik generierten Parser. Und hier ist der Generator selbst. Alles weglegen und versuchen, sich von der anderen Seite zu nähern.

Es ist erwähnenswert, dass ich wenig später immer noch versuchte, die Grammatik und stellenweise sogar den Bytecode selbst zu ändern, damit der Dekompiler ihn noch verarbeiten konnte. Aber selbst als der Bytecode in Bezug auf die Dekompiler-Grammatik gültig wurde, hat das Programm einfach nichts an mich zurückgegeben. Open Source ...

Ich blättere durch den Bytecode und stoße auf mir unbekannte Konstanten. Googeln, ich treffe das gleiche im Buch über Reverse-Android-Anwendungen. Ich erinnere mich, dass dies nur die vom Compiler-Präprozessor zugewiesene ID ist, die den Ressourcen der Android-Anwendung zugewiesen ist (die Zeitkonstante für das Schreiben von Code ist R. *). In der nächsten halben Stunde werde ich kurz untersuchen, welche Register für was verantwortlich sind, in welcher Reihenfolge die Argumente übergeben werden, und mich im Allgemeinen mit der Syntax befassen.

Wie sieht es aus?

Ich habe das Layout des Hauptanwendungsfensters gefunden und daraus bereits verstanden, was in der Anwendung vor sich geht: Auf dem Hauptbildschirm (Aktivität) befindet sich eine RecyclerView (bedingt eine Ansicht, die UI-Objekte wiederverwenden kann, die derzeit nicht für die Speichernutzung angezeigt werden) mit Eingabefeldern Schlüssel / Wert-Paare, einige Schaltflächen, die für das Hinzufügen eines neuen Schlüssel / Wert-Paares zu einem bestimmten abstrakten Container verantwortlich sind, und eine Schaltfläche, die eine Signatur (Signatur) für diesen Container generiert.

Wenn ich mir die Anmerkungen ansehe und eine bestimmte Menge Code beobachte, die der generierten verdächtig ähnlich ist, beginne ich zu googeln. Das Projekt verwendet die ButterKnife-Bibliothek, mit der mithilfe von Anmerkungen () -> bind () UI-Elemente automatisch aufgeblasen werden können. Wenn die Klasse Anmerkungen enthält, erstellt der ButterKnife-Anmerkungsprozessor implizit eine weitere Binder-Klasse der Form <original_class> __ViewBinding , die die gesamte Drecksarbeit unter der Haube erledigt. Eigentlich habe ich all diese Informationen aus nur einer MainActivity-Datei erhalten, nachdem ich die Ähnlichkeit der Java-Quelle manuell daraus wiederhergestellt habe. Nach einer halben Stunde wurde mir klar, dass die Anmerkungen dieser Bibliothek auch einen Rückruf für Schaltflächenaktionen festlegen können, und ich fand die Schlüsselfunktionen, die tatsächlich für das Hinzufügen eines Schlüssel / Wert-Paares zum Container und das Generieren einer Signatur verantwortlich waren.

Natürlich musste ich mich während des Studiums mit den „Innereien“ verschiedener Bibliotheken und Plugins befassen, da selbst schöne Landos mit Cookies nicht alle Anwendungsfälle und Details abdecken, was meiner Meinung nach für jeden „Umkehrer“ eine gängige Praxis ist.

Faulheit ist ein Freund eines Programmierers

Nachdem ich mehr Zeit mit der zweiten Quelle verbracht hatte, war ich völlig müde und stellte fest, dass es nicht möglich war, Brei zu kochen. Ich klettere wieder auf Github und diesmal schaue ich genauer hin. Ich finde das Smali2PsuedoJava- Projekt - einen Dekompiler in „Pseudo-Java-Code“. Selbst wenn dieses Dienstprogramm zumindest etwas zu einem menschlichen Aussehen führen kann, dann ist der Autor für mich ein Becher seines Lieblingsbiers (na ja, oder setzen Sie Github zunächst ein Sternchen).

Und es funktioniert wirklich! Wirkung auf das Gesicht:

Treffen Sie Cipher.so

Wenig später, als ich den Java-Pseudocode des Projekts studiere und ihn ungläubig mit dem kleinen Bytecode vergleiche, finde ich eine seltsame Bibliothek im Code - Cipher.so. Beim Googeln stelle ich fest, dass es sich um die Verschlüsselung einer Reihe von Kompilierungszeitwerten im APK-Archiv handelt. Dies ist normalerweise erforderlich, wenn die Anwendung Konstanten des Formulars verwendet: IP-Adressen, Anmeldeinformationen für eine externe Datenbank, Token für die Autorisierung usw. - Was kann mit Hilfe des Reverse Engineering der Anwendung erhalten werden. Es stimmt, der Autor schreibt klar, dass dieses Projekt aufgegeben wird, sagen sie, gehen weg. Das wird interessant.

Diese Bibliothek bietet Zugriff auf Werte über die Java-Bibliothek, wobei die spezifische Methode der für uns interessante Schlüssel ist. Es weckt nur mein Interesse und ich beginne tiefer zu klettern.

Kurz gesagt, was macht Cipher.so und wie funktioniert es:

• In der Gradle-Datei unseres Projekts werden die Schlüssel und die entsprechenden Werte registriert
  
• Alle Schlüsselwerte werden automatisch in eine separate dynamische Bibliothek (.so) gepackt, die beim Kompilieren generiert wird. Ja - ja, wird generiert.
  
• Diese Schlüssel können dann von Java-Methoden bezogen werden, die von Cipher.so generiert wurden
  
• Nach dem Erstellen der APK werden die Schlüsselnamen von MD5 gehasht (für mehr Sicherheit natürlich).
  

Nachdem ich die benötigte dynamische Bibliothek im Archivordner gefunden habe, wähle ich sie aus. Als erfahrene Umkehrung (nein) versuche ich zunächst, mit einer einfachen zu beginnen - ich beschließe, den Abschnitt mit Konstanten und nach interessanten Linien in einem ELF-ähnlichen Binar zu betrachten. Leider fehlen Benutzer des Mac, die sich sofort lesen, und vor dem Beginn sagen wir das Geschätzte:

 brew install binuitls 

Und vergessen Sie nicht, den Pfad zu / usr / local in PATH zu schreiben, denn Brew schützt Sie auf Gentleman-Weise vor allem ...

 greadelf -p .rodata lib/arm64-v8a/libcipher-lib.so | head -n 15 

Wir beschränken die Ausgabe auf die ersten 15 Zeilen, da dies sonst für einen unvorbereiteten Ingenieur zu einem Schock führen kann.



In den unteren Adressen bemerken wir verdächtige Zeilen. Wie ich beim Studium der Quellen von Cipher.so herausgefunden habe, werden die Schlüssel und Werte in die übliche std :: map eingefügt : Dies gibt nur wenige Informationen, aber wir wissen, dass es im Binar neben verschlüsselten Passwörtern auch verschleierte Schlüssel gibt.

Wie ist die Verschlüsselung von Werten? Beim Studium der Quelle stellte ich fest, dass die Verschlüsselung mit AES erfolgt - dem standardmäßigen symmetrischen Verschlüsselungssystem. Wenn es also verschlüsselte Werte gibt, sollte sich der Schlüssel in der Nähe befinden ... Nachdem ich ihn eine Weile studiert hatte, stieß ich im selben Projekt auf ein Problem mit dem provokanten Titel „Unsichere Schlüsselspeicherung: Geheimnisse sind sehr leicht abzurufen“ . Darin fand ich heraus, dass der Schlüssel in klarer Form im Binar gespeichert ist, und fand den Entschlüsselungsalgorithmus. Im Beispiel befand sich der Schlüssel an der Nulladresse, und obwohl ich verstanden hatte, dass der Compiler ihn an einer anderen Stelle im Abschnitt .rodata der Binärdatei ablegen konnte, entschied ich, dass diese verdächtige Einheit an der Nulladresse der Schlüssel ist.

Versuch Nr. 1: Ich entschlüssele die Werte und glaube, dass der Verschlüsselungsschlüssel der gleiche ist. Der Fehler. OpenSSL weist darauf hin, dass etwas nicht stimmt. Nachdem ich die Quellen von Cipher.so ein wenig gelesen habe, verstehe ich, dass, wenn der Benutzer während der Assemblierung keinen Schlüssel angibt, der Standardschlüssel verwendet wird - Cipher.so@DEFAULT .

Versuch 2: Erneuter Fehler. Hmm ... Wird es durch diese Konstante wirklich neu definiert? Es ist ganz einfach, einen Fehler zu machen: verwirrender in Gradle geschriebener Code mit "weg" -Formatierung. Ich überprüfe noch einmal. Alles scheint so zu sein.

Anstelle der Schlüssel sind ihre MD5-Hashes, und dann versuche ich mein Glück zu versuchen und einen Dienst mit Regenbogentischen zu eröffnen. Voila - einer der Schlüssel ist das Wort "Passwort". Es gibt keine Sekunde. Es gibt uns natürlich nicht viel. Diese beiden Schlüssel befinden sich an den Adressen 240 bzw. 2a2. Im Prinzip ist es einfach, sie sofort zu erkennen - 32 Zeichen (MD5).

Ich habe alles noch einmal überprüft und versucht, die Entschlüsselung mit allen anderen Zeilen (die sich in den unteren Adressen befinden) als Schlüssel für die Entschlüsselung durchzuführen - alles ist vergebens.
Es gibt also einen anderen geheimen Schlüssel, der Algorithmus der Aktionen scheint korrekt zu sein. Ich werfe diese Aufgabe beiseite und versuche mich nicht zu begraben.

Nachdem ich ein bisschen im Container-Signatur-Algorithmus gestöbert habe, sehe ich immer noch Aufrufe der Cipher.so-Bibliothek und des Codes, der auch die kryptografischen Funktionen der Java-Bibliothek verwendet.

Ein Rätsel (das ich nie gelöst habe)

In der Funktion, die für die Verschlüsselung verantwortlich ist, wird ganz am Anfang nach Schlüsseln im Container gesucht.

 public byte[] a(java/util/Map p1) { v0 = p1.size() v1 = 0x0; if (v0 != 0) goto :cond_0 p1 = new byte[v1]; return p1; :cond_0 v0 = "user"; v0 = p1.containsKey(v0) if (v0 == 0) goto :cond_1 p1 = new byte[v1]; return p1; ... 

Wörtlich: Wenn es einen "Benutzer" -Schlüssel gibt, ist dieser Container nicht signiert (eine Nullsignatur wird zurückgegeben). Ein seltsames Gefühl: Es scheint, als sei das Problem gelöst, aber es scheint irgendwie verdächtig einfach. Warum dann alles andere erfinden? In die Irre führen? Warum habe ich diesen Code dann noch nicht fließend studiert? Hmm ...

Nein, nicht wahr. Ich habe die Antwort eines bestimmten Benutzers in einem blauen Messenger angegeben, dessen Kontakte mir bei der Auftragserteilung zur Verfügung gestellt wurden. Weiter graben. Vielleicht ändert sich der Eingabeschlüssel / Wertesatz irgendwie, wenn er dem Container hinzugefügt wird? Ich habe den Code sorgfältig gelesen.

Bitte beachten Sie, dass der Dekompiler Anmerkungen aus dem Smali-Code entfernt hat. Was ist, wenn er etwas Wichtiges entfernt hat? Ich überprüfe die Hauptdateien - es scheint, nichts Wesentliches. Alles Wichtige ist vorhanden, aber die Bedeutung geht nicht verloren. Ich überprüfe Rückruffunktionen, die für das Schreiben eines Schlüssel / Wert-Paares von einer bedingten TextBox in interne Container verantwortlich sind. Ich habe nichts Verbrecherisches gefunden.

Ich wurde in jeder Codezeile so skeptisch wie möglich - ich kann niemandem mehr vertrauen.

Einfache Lösung Nr. 2: Ich habe festgestellt, dass der Signaturvorgang damit beginnt, dass in der Signatur des Zertifikats, mit dem die Anwendung signiert wurde, ein Wert (Teilzeichenfolge in der Zeichenfolge) vorhanden ist.

 @OnClick //   protected void huvot324yo873yvo837yvo() { String signature = "no data"; boolean result = some_packages.isKeyInSignature(this); if result { Map map = new HashMap(); ... 

Die Bedeutung selbst liegt natürlich verschlüsselt in diesem unglücklichen Binar. Und tatsächlich, wenn dieser Wert nicht in der Signatur enthalten ist, signiert der Algorithmus nichts, sondern gibt einfach die Zeichenfolge "keine Daten" als Signatur zurück ... Wieder werden wir für Cipher genommen ...

Schlüsselentschlüsselung Endkampf

Um das Ausmaß der Tragödie zu verstehen, war ich folgendermaßen verwirrt:

Ich machte einen Hex-Dump von diesem Abschnitt und schaute in die ersten beiden Zeilen, deren Verdacht von Anfang an nicht nachließ.



Wenn Sie darauf achten, ist das Zeichen, das die Zeilen hier trennt, '0x00'. Es wird auch häufig von der Standard-C-Bibliothek in Zeichenfolgenfunktionen verwendet. Aus diesem Grund ist es nicht weniger interessant, welche Art von Leerzeichen sich in der Mitte der ersten Zeile befindet. Als nächstes beginnen verrückte Versuche, bei denen der Schlüssel ist:

• ganze erste Reihe
  
• erste Zeile vor dem Leerzeichen
  
• erste Zeile vom Raum bis zum Ende
  
• ...
  

Der Grad der Paranoia kann bereits geschätzt werden. Wenn Sie nicht verstehen, wie schwierig und gerissen die Aufgabe sein sollte, fahren Sie los. Und doch nicht das. Dann kam mir der Gedanke: "Funktioniert der Algorithmus aufgrund eines Problems auf meinem Computer korrekt?". Im Allgemeinen ist die Abfolge der Aktionen dort logisch und hat keine Fragen aufgeworfen. Die Frage lautet jedoch: Tun die Befehle auf meinem Computer, was sie von ihnen verlangen? Also, was denkst du?

Nachdem alle Schritte manuell überprüft wurden, stellte sich heraus, dass

 echo "some_base64_input" | openssl base64 -d 

Bei einigen Eingabeargumenten wird plötzlich eine leere Zeichenfolge zurückgegeben. Hmm.

Durch Ersetzen durch den ersten base64-Decoder auf dem Computer und Durchsuchen der Hauptkandidaten wurde sofort ein geeigneter Schlüssel gefunden und die Schlüssel wurden entsprechend entschlüsselt.

Abrufen von Signaturen aus einem Zertifikat

 class a { public static boolean isKeyInSignature(android.content.Context p1) { v0 = 0x0; try TRY_0{ v1 = p1.getPackageManager() p0 = p1.getPackageName() v2 = 0x40; // GET_SIGNATURES PackageInfo p0 = v1.getPackageInfo(p0, v2) android.content.pm.Signature[] p0 = p0.signatures; // Order are not guaranteed v1 = p0.length; v2 = 0x0; :goto_0 if (v2 >= v1) goto :cond_1 v3 = p0[v2]; String v3 = v3.toCharsString() String v4 = net.idik.lib.cipher.so.CipherClient.a() v3 = v3.contains(v4) }TRY_0 catch TRY_0 (android/content/pm/PackageManager$NameNotFoundException) goto :catch_0; if (v3 == 0) goto :cond_0 p1 = 0x1; return p1; :cond_0 v2 = v2 + 0x1; goto :goto_0 :catch_0 p0 = Thrown Exception p1.printStackTrace() :cond_1 return v0; } 

So sieht der generierte Pseudocode nach meinen kleinen Änderungen aus. Verwirrt ein paar Dinge:

• schlechte Kenntnisse der Kryptographie und der "Küche" der Gerätezertifikate
  
• Laut Dokumentation garantiert diese Methode nicht die Reihenfolge der Zertifikate in der zurückgegebenen Sammlung, und dementsprechend wäre es nicht möglich, in derselben Reihenfolge zu durchlaufen - was wäre, wenn die Anwendung mit mehr als einem Zertifikat signiert wäre?
  
• Mangel an Wissen darüber, wie das Zertifikat aus der APK extrahiert werden kann, da nicht klar ist, was Android Runtime in diesem Fall tut
  

Ich musste mich mit all diesen Themen befassen und das Ergebnis war wie folgt:

• Das Zertifikat selbst befindet sich im Verzeichnis original / META-INF / CERT.RSA
  
  In diesem Verzeichnis gibt es nur eine Datei mit dieser Erweiterung. Dies bedeutet, dass die Anwendung mit nur einem Zertifikat signiert ist
  
• Auf der Website über Research Engineering von Android-Anwendungen wurde eine Liste gefunden, die die Signatur extrahieren kann, die wir wie Android benötigen. Zumindest laut Autor.
  

Durch Ausführen dieses Codes kann ich die Signatur herausfinden, und in Wirklichkeit ist der Schlüssel, den wir benötigen, eine Teilzeichenfolge. Mach weiter. Einfache Lösung Nr. 2 wird weggefegt.

In der Tat befindet sich der Schlüssel im Zertifikat. Es bleibt nur zu verstehen, was als nächstes kommt, denn wenn wir den "Benutzer" -Schlüssel haben, erhalten wir alle auch eine Nullsignatur, und wie wir oben erfahren haben, ist dies die falsche Antwort.

Schreiben Sie die Dokumentation sorgfältig!

Weitere Studien zur Tatsache, dass die aus den Textfeldern eingegebenen Daten geändert werden, werden mangels Beweisen verworfen. Paranoia rollt mit neuer Kraft: Vielleicht ist der Code, der die Signatur aus dem Zertifikat gezogen hat, falsch oder handelt es sich um eine Code-Implementierung für alte Android-Versionen? Ich öffne die Dokumentation erneut und sehe Folgendes: ( https://developer.android.com/reference/android/content/pm/Signature.html#toChars () ):



Hinweis: Die Funktion codiert die Signatur als ASCII-Text. Die Ausgabe, die ich oben erhalten habe, war eine hexadezimale Darstellung der Daten. Diese API kam mir seltsam vor, aber wenn Sie der Dokumentation glauben, stellt sich heraus, dass ich erneut blockiert war und der verschlüsselte Schlüssel keine Teilzeichenfolge der Signatur ist. Nachdem ich eine Weile nachdenklich auf dem Code gesessen hatte, konnte ich es nicht ertragen und öffnete den Quellcode für diese Klasse. https://android.googlesource.com/platform/frameworks/base/+/e639da7/core/java/android/content/pm/Signature.java

Die Antwort ließ nicht lange auf sich warten. Und tatsächlich im Code selbst - ein Ölgemälde: Das Ausgabeformat ist eine gewöhnliche Hex-Zeichenfolge. Und jetzt denke: Entweder verstehe ich etwas nicht oder die Dokumentation ist "leicht" falsch geschrieben. Nachdem ich in keiner Weise gescholten hatte, machte ich mich wieder an die Arbeit.

Zusammenfassung

Die folgenden n Stunden sind vergangen:

• Überprüfen der Richtigkeit der Arbeit im Code mit RecyclerView und Ermitteln des Verhaltens durch den Quellcode seitdem , StackOverflow
  
• , , Java. , - («user») . .
  

, ( ).

Nein. , . , , , , . . — , , , .

, , . . , . , - , , « », , .

- c – arturbrsg .

Stay tuned.