Warum JNI und ABI vor der SO-Härtung abgebildet werden müssen

Schlussfolgerungen und Entscheidungsbedingungen

Erfassen Sie für jede SO-Datei direkte und transitive Abhängigkeiten, Ladeeinstiegspunkte, Initialisierungszeitpunkte, minimale Ziel-APIs und Aufrufer.
Die statische Erkennung von JNI-Namen und die dynamische Registrierung über RegisterNatives unterliegen unterschiedlichen Einschränkungen; verifizieren Sie die tatsächliche Bindungsmethode, bevor Sie Namen verarbeiten.
arm64-v8a, armeabi-v7a und x86_64 stellen distinkte Artefakte und Kompatibilitätsmatrizen dar; ein Erfolg auf einer Architektur lässt sich nicht auf andere übertragen.
Die Akzeptanz der Schutzstärke und der Laufzeitstabilität muss an dasselbe finale APK, dieselbe Signatur und denselben SO-Satz gebunden sein.

Zuerst den ELF-Abhängigkeitsgraphen und die tatsächliche Ladezeitachse abbilden

Eine Android-Anwendung kann aus Hauptbibliotheken, Geschäftslogik-Bibliotheken, Algorithmus-Bibliotheken, Drittanbieter-SDKs und Systembibliotheken bestehen. Java- oder Kotlin-Code kann System.loadLibrary direkt aufrufen, während Hauptbibliotheken weitere Bibliotheken über ELF-Abhängigkeiten oder zur Laufzeit laden können. Der eigentliche Absturzpunkt kann außerhalb der geschützten Bibliothek liegen, da die Symbolauflösung und die Initialisierungsreihenfolge von der gesamten Abhängigkeitskette bestimmt werden.

Der Abhängigkeitsgraph muss pro ABI Bibliotheksdateien, DT_NEEDED-Beziehungen, minimale System-API-Level, Ladeeinstiegspunkte, Initialisierungsfunktionen, exportierte Schnittstellen und Aufrufer erfassen. Kennzeichnen Sie zudem, ob Bibliotheken eigenentwickelt, Open-Source-Abhängigkeiten oder Closed-Source-SDKs sind, da dies die Grenzen für Modifikationen und die Verantwortung für Regressionstests definiert.

Die Android NDK-Dokumentation besagt, dass native Symbole typischerweise beim Laden der Bibliothek aufgelöst werden. Referenziert Code eine auf dem Zielsystem fehlende API, kann dlopen sofort fehlschlagen, selbst wenn Runtime-Verzweigungen nahelegen, dass dieser Codepfad nicht ausgeführt würde. Daher müssen das NDK-API-Minimum und die Geräte-Systemversion im Abhängigkeitsgraphen enthalten sein.

Minimale Felder für einen nativen Abhängigkeitsgraphen
Feld	Was zu erfassen ist	Auswirkung auf die Härtung	Verifizierungsmethode
Bibliothek & Quelle	Hauptbibliothek, transitive Abhängigkeiten, Drittanbieter- und Systembibliotheken	Bestimmt den modifizierbaren Bereich und die Verantwortung für Regressionstests	Entpacken und gegen jede ABI im finalen APK verifizieren
Ladeeinstieg	Statische Abhängigkeiten, System.loadLibrary oder runtime-dlopen	Bestimmt das früheste Fehlerstadium und den Speicherort der Logs	Startzeitachse und Ladeergebnisse protokollieren
API-Minimumversion	Build-APP_PLATFORM und verwendete System-Symbole	Fehlende Symbole können beim Laden auftreten, wenn sie höher als die Geräte-API sind	Start auf Realgeräten mit Zielsystemen und Symbolverifizierung
Initialisierungsreihenfolge	JNI_OnLoad, Konstruktoren und Geschäftsinitialisierung	Änderungen im Code-Layout oder Timing können implizite Abhängigkeiten verstärken	Zeitachsen zwischen ungeschützten Builds und Release Candidates vergleichen
Exceptions & Threads	C++-Exceptions, Thread-Zugehörigkeit, JNIEnv-Nutzung	Bibliotheks- und thread-übergreifende Fehler verursachen oft sofortige Abstürze	CheckJNI, symbolisierte Stack-Traces und geschäftliche Regressionstests

Statische vs. dynamische Registrierung definiert die Grenzen der Symbolverarbeitung

JNI kann native Methoden über Namenskonventionen entdecken oder während der Initialisierung mittels RegisterNatives Zuordnungen zwischen Java-Methoden und Funktionsadressen herstellen. Die statische Registrierung basiert auf vorhersagbaren exportierten Namen; die dynamische Registrierung erfordert typischerweise nur die Freigabe weniger Initialisierungseinstiegspunkte, hängt jedoch von Klassen-Lookup, Methodensignaturen, Registrierungszeitpunkt und dem ladenden Thread ab.

Wenn Hardening oder Symbolverarbeitung statische Registrierungsnamen ändert, kann das System die native Implementierung nicht finden. Ebenso können Änderungen an Methodensignaturen, Regeln zur Beibehaltung von Klassennamen oder der Initialisierungsreihenfolge in der dynamischen Registrierungstabelle zu Fehlern vor dem ersten Funktionsaufruf führen. Die reine Prüfung der Anzahl exportierter Symbole beweist nicht, dass JNI-Bindungen korrekt bleiben.

Offizielle Android-JNI-Richtlinien warnen zudem, dass JNIEnv thread-spezifischen Einschränkungen unterliegt; ausstehende Exceptions, ungültige Referenzen und nutzerübergreifende Verwendung können zu Abstürzen führen. Regressionstests nach dem Hardening müssen echte Threads und Exception-Pfade abdecken, nicht nur eine parameterlose Demo-Methode aufrufen.

Wichtige Prüfpunkte für zwei JNI-Registrierungsmethoden
Registrierungsmethode	Abhängigkeiten	Kritische Punkte beim Hardening	Mindestverifikation
Statische Namenermittlung	Java-Klassenname, Methodenname, Signatur und exportierte Symbole	Umbenennung, versteckte Symbole und Signaturinkonsistenzen	Jeden kritischen Einstiegspunkt aufrufen und auf Linker-Fehler prüfen
RegisterNatives	Klassensuche, Methodensignaturen, Registrierungstabelle und Initialisierungszeitpunkt	Verarbeitung von Klassennamen, Registrierungsreihenfolge, Änderungen an Funktionsadressen	Abschluss der Registrierung bestätigen und reale Eingabe-/Ausgabeszenarien ausführen
Wrapper von Drittanbietern	Interne SDK-Regeln und Closed-Source-Implementierungen	Selbstvalidierung, implizite Exporte und Versionsunterschiede	Gegen Support-Matrizen des Herstellers und reale Szenarien verifizieren

Wichtige Java-zu-Native-Zuordnungen auflisten
Statische oder dynamische Registrierungsmethode bestätigen
Erforderliche Regeln für Klassennamen und Signaturen beibehalten
Exceptions, Threads und Lebenszyklen von Referenzen verifizieren

ABI muss als unabhängiges Release-Artefakt akzeptiert werden

ABI ist mehr als ein Verzeichnislabel. Die offizielle Android-NDK-Dokumentation legt fest, dass ABI den Befehlssatz, die Byte-Reihenfolge, Aufrufkonventionen, Stack- und Registernutzung, das ausführbare Dateiformat und das C++-Name-Mangling definiert. arm64-v8a und armeabi-v7a unterscheiden sich im Maschinencode und den Abhängigkeiten; ein erfolgreicher Test auf einem x86_64-Emulator stellt keinen Erfolg auf echten ARM-Geräten dar.

Pro ABI ist zu bestätigen, dass alle direkten und transitiven Abhängigkeiten vorhanden sind, die API-Mindestversion der Bibliothek mit dem Zielsystem kompatibel ist und Packaging-Tools keine Dateien für eine spezifische Architektur fälschlich gelöscht haben. Wenn nur die Hauptbibliothek arm64-v8a enthält, eine Drittanbieter-Abhängigkeit jedoch das entsprechende Artefakt fehlt, schlägt das Laden der Anwendung dennoch fehl.

Wenn das Produkt nur eine Teilmenge von ABIs unterstützen soll, ist dies explizit in den Release-Hinweisen, den App-Store-Konfigurationen und den Testumfang zu dokumentieren. Architekturen, die nicht buildbar sind, nicht installiert werden oder bei denen kritische JNI-Pfade nicht ausgeführt wurden, müssen als nicht abgedeckt markiert werden; ein erfolgreicher Compile-Vorgang kann keine Laufzeitnachweise ersetzen.

Beispielhafte ABI-Akzeptanzmatrix
Prüfpunkt	arm64-v8a	armeabi-v7a	x86_64	Entscheidungsregel
Alle Abhängigkeiten vorhanden	Pro Bibliothek verifizieren	Pro Release-Umfang verifizieren	Nur bei Bedarf verifizieren	Blockieren, wenn eine erforderliche Abhängigkeit fehlt
Ladbar auf Mindestsystem	Ziel-API auf realem Gerät	Ziel-API auf realem Gerät	Emulator oder Gerät	Nicht ausschließlich auf dem neuesten System validieren
Kritische JNI-Pfade	Reale Eingabe/Ausgabe	Reale Eingabe/Ausgabe	Kann ARM-Ergebnisse nicht ersetzen	Unabhängig für jedes freigegebene ABI dokumentieren
Zuordenbarkeit von Abstürzen	Passende Symbole beibehalten	Passende Symbole beibehalten	Passende Symbole beibehalten	Symbole müssen zum gleichen Release Candidate gehören

Welche nativen Laufzeitbedingungen betrifft der Schutz?

Symbol-Hiding reduziert statische Hinweise, String-Verarbeitung senkt die Exposition von Klartext und Control-Flow- oder Funktionsvirtualisierung verändert die Ausführungsform ausgewählten Codes. Diese Techniken beeinflussen exportierte Symbole, Funktionsgrenzen, Exception-Unwinding, indirekte Aufrufe, Alignment und Performance unterschiedlich. Weniger Symbole nach der Verarbeitung stellen keinen vollständigen nativen Schutz dar, ebenso wenig widerlegt die Lesbarkeit der Bibliothek alle Schutzwirkungen.

Startinitialisierung, Signalbehandlung, C++-Ausnahmen, Callbacks, thread-lokaler Zustand, reflektive Symbolauflösung und Selbstvalidierung von Drittanbieter-SDKs sind hochsensible Bereiche. Priorisieren Sie bei der Scope-Auswahl Geschäftsfunktionen mit klar definierten Ein-/Ausgaben, messbarer Aufrufhäufigkeit und isolierbaren Fehlern. Vermeiden Sie es, die gesamte Initialisierungskette im ersten PoC zu verarbeiten.

Schutzkonfigurationen müssen für jede Funktion oder Funktionsgruppe die Begründung, Aufrufphase, ABI, Abhängigkeiten, das Performance-Budget und die Rollback-Gruppe dokumentieren. Das Folgende zeigt lediglich das Format einer öffentlichen, sicheren Verifizierungs-Checkliste ohne interne Symbole oder Produktkonfigurationssyntax.

Öffentliches, sicheres Record-Format für native Schutzgruppen

native_group: protocol-core-v1
abis: [arm64-v8a, armeabi-v7a]
load_phase: post-authentication
jni_registration: dynamic
execution:
  frequency: bounded
  main_thread: false
dependencies:
  - business-runtime
  - system-crypto
acceptance:
  - dependency-resolution
  - jni-registration
  - exception-path
  - output-parity
  - latency-budget
rollback: native-group-v0

Lokalisierung von Abstürzen nach SO-Hardening anhand der frühesten Differenz

Bei der Fehlerbehebung sollten zunächst die Dateiidentität, Signatur, Gerät, System, Installationsmethode und Geschäftseingabe sowohl für die ungeschützte Basislinie als auch für den Release-Kandidaten korrigiert werden. Anschließend sollte die Zeitleiste nach der frühesten Differenz durchsucht werden: Prozesserstellung, Anwendungsstart, Bibliotheksladen, JNI_OnLoad, Registrierungsabschluss, erster nativer Aufruf oder Schlüsselgeschäftsrückgabe. Der letzte Absturzprotokolleintrag könnte lediglich eine Kettenreaktion sein.

UnsatisfiedLinkError weist meist auf fehlende Bibliotheken, ABI-Inkompatibilitäten, Abhängigkeitsprobleme oder Fehler bei der Symbolauflösung hin; Registrierungsfehler können sich als fehlende native Methoden äußern. Falsche JNIEnv, Referenzen oder ausstehende Exceptions können während Business-Aufrufen zu Abstürzen führen. Bewahren Sie native Symbole, die mit dem Release Candidate übereinstimmen, für die interne Zuordnung auf, geben Sie jedoch keine echten Symbole oder Adressen in öffentlichen Berichten preis.

CheckJNI hilft bei der Erkennung einiger JNI-Fehlverwendungen, ist jedoch ein Diagnosewerkzeug, bildet keinen Produktions-Laufzeitstatus ab und deckt nicht alle Probleme mit nativem Speicher oder Nebenläufigkeit ab. Nach Korrekturen müssen kritische Pfade unter der Ziel-Release-Konfiguration erneut ausgeführt werden.

Häufige Symptome und nächste Schritte zur Beweissicherung
Frühestes Symptom	Prioritätsprüfungen	Erforderliche Beweise	Was nicht als Erstes getan werden sollte
dlopen-Fehler	ABI, DT_NEEDED, API-Mindestversion und Symbole	Bibliotheksliste und Ladefehler passend zum Release Candidate	Wiederholtes Umschalten von nicht zusammenhängenden Schutzschaltern
Native Methode nicht gefunden	Registrierungsmethode, Klassenname, Methodensignatur und Timing	Registrierungstabelle, Retention-Regeln und Aufruf-Einstiegspunkte	Ausschließliche Betrachtung exportierter Symbolanzahlen
Absturz beim ersten Aufruf	Parameter, Referenzen, Threads, Exceptions und Funktionsverarbeitung	Symbolisierter Stack, Inputs und Baseline-Vergleich	Erklärung mittels Symbol-Dateien einer anderen Version
Fehler auf bestimmten Geräten	System-API, Herstellerunterschiede, ABI und Drittanbieter-Bibliotheken	Geräte-System-Matrix und früheste Differenzen	Ersetzen von Realgerät-Ergebnissen durch Emulator-Erfolg

Release-Fazit muss Stärke, Kompatibilität und Wartbarkeit abdecken

Die Beobachtung der statischen Stärke kann Änderungen an Symbolen, Strings, Code-Struktur und der Angriffsfläche wichtiger Einstiegspunkte dokumentieren; die Runtime-Abnahme verifiziert Laden, JNI, kritische Geschäftslogik, Exceptions und Ziel-ABIs. Diese beiden Beweisarten ergänzen sich gegenseitig; keine kann die andere ersetzen.

Der finale Release Candidate muss zudem Installations-Upgrades, Signaturprüfungen, Channel-Checks, Starttests, Crash-Monitoring, Archivierung nativer Symbole und Rollback-Drills abschließen. Symbol-Archive müssen das Auffinden der passenden Version über die Dateiidentität ermöglichen; andernfalls können native Online-Crashes nicht korrekt symbolisiert werden.

Dieser Artikel bietet einen Engineering-Inspektionsrahmen, keine Testergebnisse für ein spezifisches SO oder eine Schutzkonfiguration. Ohne Zielpaket, Ziel-ABI und reale Aufrufpfade lässt sich nur beurteilen, ob die Vorbereitungsarbeiten abgeschlossen sind, nicht jedoch Kompatibilität oder Performance garantieren.

Jedes veröffentlichte ABI verfügt über Laufzeitnachweise
Kritische JNI-Einstiegspunkte decken Normal- und Exception-Pfade ab
Native Symbole stimmen mit der Identität des finalen Candidates überein
Ergebnisse für Laden, Business-Logik und Rollback sind reproduzierbar
Nicht abgedeckte Geräte und Systeme sind explizit eingeschränkt

Evidenz- und Anwendbarkeitsgrenzen

In diesem Abschnitt werden dokumentierte Plattformfakten, technische Beurteilungen und Grenzwerte getrennt, die nicht in unbestätigte Produktaussagen verallgemeinert werden können.

Artikel Urteil	Fakt oder technische Grundlage	Anwendbarkeitsgrenze
ABI muss als unabhängige Artefakt-Dimension akzeptiert werden.	Das offizielle Android NDK definiert ABI hinsichtlich Befehlssätzen, Aufrufkonventionen, Registern, Stack, ELF-Format und Name-Mangling.	Dokumentationsdefinitionen beweisen nicht, dass die Anwendung vollständige Abhängigkeiten enthält oder auf Zielgeräten erfolgreich läuft.
Native-API-Referenzen, die höher sind als das Gerätesystem, können zur Ladezeit fehlschlagen.	Die Dokumentation zu häufigen NDK-Problemen besagt, dass Symbole typischerweise beim Laden der Bibliothek aufgelöst werden; das Referenzieren nicht existierender APIs lässt sich nicht durch Runtime-Branching umgehen.	Spezifische Fehler müssen weiterhin über Build-Parameter, Abhängigkeiten und Geräte-Logs bestätigt werden.
JNI-Fehler erfordern eine Validierung auf Thread-, Referenz- und Ausnahmeebene.	Die Android-JNI-Richtlinien listen Probleme wie ungültige JNIEnv, Referenzen, ausstehende Exceptions und Methodenregistrierungen auf, die zu Abstürzen führen können.	CheckJNI unterstützt nur die Erkennung einer Teilmenge von Problemen und kann keine umfassenden Tests für Geschäftslogik und Speichersicherheit ersetzen.
Ergebnisse eines einzelnen x86_64-Emulators lassen sich nicht auf reale ARM-Geräte extrapolieren.	Verschiedene ABIs nutzen unterschiedliche Befehlssätze und Aufrufkonventionen; auch die finalen Kombinationen aus Bibliotheken und Abhängigkeiten können variieren.	Wenn das Produkt explizit keine bestimmte ABI ausliefert, kann diese als nicht anwendbar markiert werden, statt sie zwangsweise zu testen.
Schutzstärke und Kompatibilität müssen im selben Release Candidate abgeschlossen werden.	Das Neubauen oder Ersetzen von SO-Dateien verändert Code, Symbole, Abhängigkeiten und potenzielles Laufzeitverhalten.	Dies ist ein Prinzip der Artefakt-Governance und impliziert nicht, dass ein spezifisches Schutzniveau bestanden wurde.

Technische Fragen

Ist bei nur einer Haupt-SO noch ein Abhängigkeitsgraph erforderlich?

Ja. Die Haupt-SO kann weiterhin von Systembibliotheken, C++-Laufzeiten oder Drittanbieter-Bibliotheken abhängen und über JNI mit der Java-Ebene interagieren. Der Abhängigkeitsgraph bestätigt den frühesten Ladepunkt und die Verantwortungsgrenzen.

Muss armeabi-v7a noch getestet werden, wenn arm64-v8a bestanden hat?

Wenn das Release-Paket armeabi-v7a enthält und unterstützt, ist eine unabhängige Verifizierung erforderlich. Die Befehlssätze, Aufrufkonventionen und Abhängigkeits-Artefakte der beiden ABIs unterscheiden sich und sind nicht austauschbar.

Ist das Verbergen aller exportierten Symbole sicherer?

Nicht unbedingt. Notwendige statische JNI-Einstiegspunkte, Aufrufe von Drittanbietern und Systemkonventionen können auf exportierte Symbole angewiesen sein. Prüfen Sie zunächst Registrierung und Aufrufmethoden, minimieren Sie dann die Exposition.

Kann ich freigeben, wenn CheckJNI keine Fehler meldet?

Nein, dies allein reicht für eine Freigabe nicht aus. Sie müssen zudem die tatsächliche Zielkonfiguration, Geschäftseingaben, Ausnahme-Pfade, ABI, Systemumfang, Installations-Upgrades und Rollback-Fähigkeiten verifizieren.

Sollte ich den gesamten Schutz sofort nach einem Crash bei der SO-Härtung deaktivieren?

Fixieren Sie zunächst die Identität des Kandidaten und finden Sie die früheste Differenz. Sie können binär nach Schutzgruppen suchen oder einen Rollback durchführen, ändern Sie jedoch jeweils nur eine protokollierbare Variable, um die Entstehung neuer nicht zuordenbarer Artefakte zu vermeiden.

Möchten Sie dies in Ihrer eigenen App testen?

Reichen Sie den Release Candidate, die Zielsysteme und kritischen Geschäftspfade für eine Yudun PoC- und Kompatibilitätsbewertung ein.

Weiter mit: SO Checkliste für Härtung und native Kompatibilität

Fordern Sie einen App-Härtungstest an Senden Sie Projektdetails