background
After Brother Ma explained how to use winscope to analyze various flash black, black screen and other problems, many students who bought the course began to use this tool for actual company projects, but many students began to find another problem, that is It was found that the relevant winscope could not be captured on the user version of the mobile device. Even if it could be captured, it was found that it could not be exported for analysis. Ask Brother Ma for help in the group for this problem, and here are some related solutions today.
For related in-depth use of winscope to solve flash blackouts, etc., please watch my b-site video or paid video. You can directly watch the video and contact me
https://www.bilibili.com/video/BV14M411M7Pu/
1. Failed to obtain winscope from the webpage on the user’s mobile phone
The effect of winscope on the user's mobile phone is as follows:
It can be seen that an error is always displayed, but what is the specific reason for the error?
Take a look at the daily log output from the python program on the server side:
It is obvious that the server only executes the relevant adb shell command, but this command requires high-level permissions such as su root. Naturally, it is not available on the user’s mobile phone.
2. It can be captured on the mobile phone, but there is no permission to obtain the file.
The shortcut button can be released in settings
After the crawling is completed, there are relevant trace files:
You can see that the trace file has been exported to the data/misc/wmtrace folder, then try to take it out
and find the following permission issues.
It can be seen that this wmtrace folder has no permissions at all, so it cannot be taken out.
3. Try to explore solutions
Use bugreoport command:
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)
Take a look at the related files exported by this bugreport command:
I found that there is a data folder under the FS folder, as well as misc, because misc itself does not have permission to view the adb shell. It looks promising. .
But the situation is as follows:
only recovery is related, and no wmtrace related folders are seen.
But it is obviously the /data/misc/wmtrace path, why is it not exported?
If you want to know the reason, you must look at the source code.
First of all, you need to understand that bugreport can only have shell permissions at most, because it is also a process launched by adb shell, but why
can it export the relevant folders under data/misc/
To decrypt this we can take a look at the relevant source code
frameworks/native/cmds/bugreport/bugreport.cpp
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;
}
It can be seen here that bugreport is actually an empty shell. Bugreportz is really at work.
Take a look at the related commands of bugreportz:
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;
}
The summary is shown in the figure below:
Ways of identifying:
When executing the bugreport command:
test@test:~/aosp/frameworks/native/cmds$ adb bugreport
[ 5%] generating bugreport-crosshatch-SP1A.210812.016.C1-2022-06-28-13-02-19.zip
Open another adb shell in the terminal to check the permissions of the dumpstate service:
crosshatch:/ $ ps -A | grep dump
root 16137 1 10878140 5172 0 0 S dumpstate
It is obvious that it is a process with root privileges.
4. Finding causes and solutions
The principle of bugreport has been analyzed above. In fact, dumpstate is used to obtain high-privilege root. So the question is, why are there wmtrace related folders? This question depends on the relevant source code of dumpstate:
frameworks/native/cmds/dumpstate/dumpstate.cpp
saw the following 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"
You can see that there are data-related directories listed one by one, including RECOVERY_DATA_DIR and WMTRACE_DATA_DIR. Here we focus on why WMTRACE_DATA_DIR has not been exported to see if there are any relevant restrictions:
Seeing the following code, one condition here is!PropertiesHelper::IsUserBuild(),
that is, the WMTRACE_DATA_DIR directory can only be exported on non-user mobile phones.
/* Add window and surface trace files. */
if (!PropertiesHelper::IsUserBuild()) {
ds.AddDir(WMTRACE_DATA_DIR, false);
}
Modification plan exploration:
1. Directly delete the if (!PropertiesHelper::IsUserBuild()) condition (more violent and unsafe)
//if (!PropertiesHelper::IsUserBuild()) {
ds.AddDir(WMTRACE_DATA_DIR, false);
// }
2. You can add an or condition and add your own secret door (this is recommended). For example, you can also create a prop yourself, which can be changed through adb shell.
if (!PropertiesHelper::IsUserBuild() || isEnableProp（）) {
ds.AddDir(WMTRACE_DATA_DIR, false);
}