Hintergrund
Nachdem Bruder Ma erklärt hatte, wie man mit Winscope verschiedene Flash-Black-, Black-Screen- und andere Probleme analysiert, begannen viele Studenten, die den Kurs kauften, dieses Tool für tatsächliche Unternehmensprojekte zu verwenden, aber viele Studenten begannen, ein anderes Problem zu finden, nämlich Es wurde gefunden dass das entsprechende Winscope auf der Benutzerversion des Mobilgeräts nicht erfasst werden konnte. Selbst wenn es erfasst werden konnte, wurde festgestellt, dass es nicht zur Analyse exportiert werden konnte. Bitten Sie Bruder Ma in der Gruppe um Hilfe für dieses Problem. Hier finden Sie heute einige entsprechende Lösungen.
Für eine detaillierte Nutzung von Winscope zur Behebung von Flash-Ausfällen usw. schauen Sie sich bitte mein B-Site-Video oder kostenpflichtiges Video an. Sie können das Video direkt ansehen und mich kontaktieren:
https://www.bilibili.com/video/BV14M411M7Pu/
1. Winscope konnte nicht von der Webseite auf dem Mobiltelefon des Benutzers abgerufen werden
Die Auswirkung von Winscope auf das Mobiltelefon des Benutzers ist wie folgt:
Es ist ersichtlich, dass immer ein Fehler angezeigt wird, aber was ist der konkrete Grund für den Fehler?
Schauen Sie sich die tägliche Protokollausgabe des Python-Programms auf der Serverseite an:
Es ist offensichtlich, dass der Server nur den entsprechenden ADB-Shell-Befehl ausführt, dieser Befehl erfordert jedoch Berechtigungen auf hoher Ebene wie su root. Auf dem Mobiltelefon des Nutzers ist es natürlich nicht verfügbar.
2. Es kann auf dem Mobiltelefon erfasst werden, es besteht jedoch keine Berechtigung zum Abrufen der Datei.
Die Verknüpfungstaste kann in den Einstellungen freigegeben werden
Nach Abschluss des Crawlings liegen relevante Trace-Dateien vor:
Sie können sehen, dass die Trace-Datei in den Ordner „data/misc/wmtrace“ exportiert wurde. Versuchen Sie dann, sie zu entfernen,
und finden Sie die folgenden Berechtigungsprobleme.
Es ist ersichtlich, dass dieser WMTrace-Ordner überhaupt keine Berechtigungen hat und daher nicht entfernt werden kann.
3. Versuchen Sie, nach Lösungen zu suchen
Verwenden Sie den Befehl bugreoport:
test@test:~$ adb bugreport
/data/user_de/0/com.android.shell/files/bugreports/bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-12-21-13.zip: 1 file pulled. 27.7 MB/s (11790205 bytes in 0.406s)
test@test:~$ adb pull /data/user_de/0/com.android.shell/files/bugreports/bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-12-21-13.zip
/data/user_de/0/com.android.shell/files/bugreports/bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-12-21-13.zip: 1 file pulled. 27.7 MB/s (11790205 bytes in 0.406s)
Sehen Sie sich die zugehörigen Dateien an, die mit diesem Bugreport-Befehl exportiert wurden:
Ich habe festgestellt, dass sich unter dem FS-Ordner ein Datenordner sowie „misc“ befinden. Da „misc“ selbst keine Berechtigung zum Anzeigen der ADB-Shell hat, sieht es vielversprechend aus. .
Die Situation ist jedoch wie folgt:
Es betrifft nur die Wiederherstellung und es werden keine wmtrace-bezogenen Ordner angezeigt.
Aber es ist offensichtlich der Pfad /data/misc/wmtrace, warum wird er nicht exportiert?
Wenn Sie den Grund wissen möchten, müssen Sie sich den Quellcode ansehen.
Zunächst müssen Sie verstehen, dass Bugreport höchstens Shell-Berechtigungen haben kann, da es sich auch um einen von der ADB-Shell gestarteten Prozess handelt,
aber warum kann er exportiert werden? die relevanten Ordner unter data/misc/
Um dies zu entschlüsseln, können wir einen Blick auf den entsprechenden Quellcode „
frameworks/native/cmds/bugreport/bugreport.cpp“ werfen
int main() {
fprintf(stderr,
"=============================================================================\n");
fprintf(stderr, "WARNING: Flat (text file, non-zipped) bugreports are deprecated.\n");
fprintf(stderr, "WARNING: Please generate zipped bugreports instead.\n");
fprintf(stderr, "WARNING: On the host use: adb bugreport filename.zip\n");
fprintf(stderr, "WARNING: On the device use: bugreportz\n");
fprintf(stderr, "WARNING: bugreportz will output the filename to use with adb pull.\n");
fprintf(stderr,
"=============================================================================\n\n\n");
return 0;
}
Hier ist zu erkennen, dass Bugreport eigentlich eine leere Shell ist. Bugreportz ist wirklich am Werk.
Schauen Sie sich die zugehörigen Befehle von Bugreportz an:
Frameworks/native/cmds/bugreportz/main.cpp
int main(int argc, char* argv[]) {
//省略
// TODO: code below was copy-and-pasted from bugreport.cpp (except by the
// timeout value);
// should be reused instead.
// Start the dumpstatez service.
//启动相关的 dumpstate服务
if (stream_data) {
property_set("ctl.start", "dumpstate");
} else {
property_set("ctl.start", "dumpstatez");
}
// Socket will not be available until service starts.
int s = -1;
for (int i = 0; i < 20; i++) {
//与dumpstate进行本地socket跨进程通讯
s = socket_local_client("dumpstate", ANDROID_SOCKET_NAMESPACE_RESERVED, SOCK_STREAM);
if (s >= 0) break;
// Try again in 1 second.
sleep(1);
}
int ret;
//socket接受相关的数据进行处理
if (stream_data) {
ret = bugreportz_stream(s);
} else {
ret = bugreportz(s, show_progress);
}
return ret;
}
Die Zusammenfassung ist in der folgenden Abbildung dargestellt:
Möglichkeiten zur Identifizierung:
Beim Ausführen des Bugreport-Befehls:
test@test:~/aosp/frameworks/native/cmds$ adb bugreport
[ 5%] generating bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-13-02-19.zip
Öffnen Sie eine weitere ADB-Shell im Terminal, um die Berechtigungen des Dumpstate-Dienstes zu überprüfen:
crosshatch:/ $ ps -A | grep dump
root 16137 1 10878140 5172 0 0 S dumpstate
Es ist offensichtlich, dass es sich um einen Prozess mit Root-Rechten handelt.
4. Ursachen und Lösungen finden
Das Prinzip des Bugreports wurde oben analysiert. Tatsächlich wird dumpstate verwendet, um Root mit hohen Berechtigungen zu erhalten. Die Frage ist also: Warum gibt es wmtrace-bezogene Ordner? Diese Frage hängt vom jeweiligen Quellcode von dumpstate ab:
Frameworks/native/cmds/dumpstate/dumpstate.cpp
sah den folgenden Code:
#define PSTORE_LAST_KMSG "/sys/fs/pstore/console-ramoops"
#define ALT_PSTORE_LAST_KMSG "/sys/fs/pstore/console-ramoops-0"
#define BLK_DEV_SYS_DIR "/sys/block"
#define RECOVERY_DIR "/cache/recovery"
#define RECOVERY_DATA_DIR "/data/misc/recovery"
#define UPDATE_ENGINE_LOG_DIR "/data/misc/update_engine_log"
#define LOGPERSIST_DATA_DIR "/data/misc/logd"
#define PREREBOOT_DATA_DIR "/data/misc/prereboot"
#define PROFILE_DATA_DIR_CUR "/data/misc/profiles/cur"
#define PROFILE_DATA_DIR_REF "/data/misc/profiles/ref"
#define XFRM_STAT_PROC_FILE "/proc/net/xfrm_stat"
#define WLUTIL "/vendor/xbin/wlutil"
#define WMTRACE_DATA_DIR "/data/misc/wmtrace"
#define OTA_METADATA_DIR "/metadata/ota"
#define SNAPSHOTCTL_LOG_DIR "/data/misc/snapshotctl_log"
#define LINKERCONFIG_DIR "/linkerconfig"
#define PACKAGE_DEX_USE_LIST "/data/system/package-dex-usage.list"
#define SYSTEM_TRACE_SNAPSHOT "/data/misc/perfetto-traces/bugreport/systrace.pftrace"
#define CGROUPFS_DIR "/sys/fs/cgroup"
Sie können sehen, dass datenbezogene Verzeichnisse nacheinander aufgelistet sind, einschließlich RECOVERY_DATA_DIR und WMTRACE_DATA_DIR. Hier konzentrieren wir uns darauf, warum WMTRACE_DATA_DIR nicht exportiert wurde, um festzustellen, ob relevante Einschränkungen bestehen:
Wenn Sie den folgenden Code sehen, liegt hier eine Bedingung vor: !PropertiesHelper::IsUserBuild()
bedeutet, dass das Verzeichnis WMTRACE_DATA_DIR nur auf Nichtbenutzer-Mobiltelefonen exportiert werden kann.
/* Add window and surface trace files. */
if (!PropertiesHelper::IsUserBuild()) {
ds.AddDir(WMTRACE_DATA_DIR, false);
}
Erkundung des Änderungsplans:
1. Löschen Sie direkt die Bedingung if (!PropertiesHelper::IsUserBuild()) (gewalttätiger und unsicherer).
//if (!PropertiesHelper::IsUserBuild()) {
ds.AddDir(WMTRACE_DATA_DIR, false);
// }
2. Sie können eine oder-Bedingung hinzufügen und Ihre eigene Geheimtür hinzufügen (dies wird empfohlen). Sie können beispielsweise auch selbst eine Requisite erstellen, die über die ADB-Shell geändert werden kann.
if (!PropertiesHelper::IsUserBuild() || isEnableProp（）) {
ds.AddDir(WMTRACE_DATA_DIR, false);
}