adb, fastboot and ssh and other system stuff on Google Pixel 6 Pro
About this messy post
As I rooted my Google Pixel 6 Pro, there were a few things to get in place on my Linux Mint 19 machine. These are random notes I took as I went along.
Install ADB and fastboot
# apt install android-tools-adb android-tools-fastboot
So that was easy.
Next, opening the phone for ADB access, the standard Android way: Go to the phone settings, into About Phone. Tap seven times on Build Number. The phone prompts for the PIN number, and then the “You are now a developer” message appears.
Now, under System, there’s the Developer options. Enable USB debugging. And then at shell prompt:
$ adb devices List of devices attached 23011xxxxxxxx no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]
Arghh. This was because of a lacking udev rule for when the phone isn’t in File Transfer / Android Auto mode. So I enabled file transfer (even though the real solution is to fix the udev file, as described below). And that’s when a popup appears asking if the computer should be allowed USB debugging. So yes, and pick “Always allow from this computer”.
Now we’re talking:
$ adb devices 23011xxxxxxxx device
Yey. Even more yey: Using adb shell, I got
$ id uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:shell:s0
The privileges in this mode is much better than as an SSH client (see below). For example, one can list the files in /system/bin and /dev with adb shell and not through ssh (unless the ssh session gets root). Same goes with using “top”: It shows all processes, not just the same users’, as with ssh (once again, if the ssh session gets root, sky’s the limit).
There are nice executables in /vendor/bin too (even ifconfig and nc)
Getting the udev rule right
To resolve the “permission denied” thing with adb without file system access and fastboot, a udev rule needs to be added.
With MTP, file transfer on and off, I checked which udev rules got in action for the device with
$ udevadm test -a add $(udevadm info -q path -n /dev/bus/usb/002/004)
The 002/004 in the end are the bus and device numbers as found in lsusb.
It turns out that the relevant rule was in /lib/udev/rules.d/69-libmtp.rules:
# Google Inc Nexus/Pixel (MTP+ADB)
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Note that it sets the group to “audio” and not “plugdev” The ENV{} assignments prevent the call to mtp-probe in this same udev file.
The truth is that I don’t completely understand why that works at all.
Anyhow, I ended up adding the following as /etc/udev/rules.d/20-google-pixel.rules:
# Google Inc Pixel 6 Pro, support for no-file transfer ADB mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee7", MODE="660", GROUP="plugdev"
# Google Inc Pixel 6 Pro, support for USB tethering + ADB mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4eec", MODE="660", GROUP="plugdev"
# Google Inc Pixel 6 Pro, support for MIDI + ADB mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee9", MODE="660", GROUP="plugdev"
# Google Inc Pixel 6 Pro, support for fastboot mode
ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee0", MODE="660", GROUP="plugdev"
and don’t forget
$ sudo udevadm control --reload
I assigned the group “plugdev” or else fastboot required root (on the host computer) to detect the device. Also, I didn’t add any of the ENV{ID_MTP_DEVICE}=”1″ commands, because doing so prevents running mtp-probe. And oddly enough, if mtp-probe doesn’t run, I get a popup saying “Unable to mount mtp device”.
As a side note, mtp-probe runs on virtually every USB device. This is quite ugly, actually.
Backing up some of the phone’s data
You can’t just use tar to backup the root directory. Not sure why, but nothing happened when I tried. Maybe an SeLinux thing? So it boils down to something like this:
$ time adb shell 'su -c "tar -cz /storage/emulated/0/"' | sudo tar -xvz -C /mnt/tmp/googlepixel/
This backs up the visible user data. For hidden application data, repeat this with data/:
$ time adb shell 'su -c "tar -cz /data/"' | sudo tar -xvz -C /mnt/tmp/googlepixel/
And here’s the crux: There are several duplicate mounts in the filesystem. It seems like a lot under /data/user/0 is a repeated backup. And even more so, /data/media/0 is apparently a duplicate of /storage/emulated/0/ (or the other way around? I’m confused), so maybe there’s no point backing up the latter if /data is backed up.
For a round-up of backing up things that are probably completely useless:
$ time adb shell 'su -c "tar -cz /mnt/vendor /apex /metadata"' | sudo tar -xvz -C /mnt/tmp/googlepixel/
Have I missed something that should be backed up? I don’t know.
Grabbing system info
Be sure to check out this reference and this cheat sheet for adb commands.
There’s a utility, dumpsys, that allows getting system information easily from the phone.
So, to tell which application is responsible for a window that just showed up:
$ adb shell dumpsys window windows > windows.txt
Or get some memory info (which application takes how much memory?):
$ adb shell dumpsys meminfo > mem.txt
What caused apps to terminate? This gives a log of last exits for each package.
$ adb shell dumpsys activity exit-info > exit.txt
Or everything at once (takes about 30 seconds to run, and emits a lot of error messages):
$ adb shell dumpsys > all.txt
Note that the file is output on the host, not on the phone with these commands.
To get the system log, use logcat:
$ adb shell logcat -d > all-log.txt
The -d flag tells logcat to terminate when it reaches the end of the log. Otherwise it continues running in “tail -f” style.
To get a list of all running processes:
$ adb shell ps -A > ps-all.txt
Look at this page for some additional utilities, in particular the Package Manager (pm) and Activity Manager (am). For a more in-depth understanding of the machinery, look for information on Intents and Activities.
Also try
$ adb shell device_config list
Bonus: device_config also allows to set the listed parameters, and these settings survive reboot (generally speaking).
List all installed packages:
$ adb shell cmd package list packages > packages.txt
Remove all user data for a package (at adb prompt, com.tencent.mm is WeChat)
pm clear com.tencent.mm
Where apps keep their data
For example, Whatsapp:
- /data/data/com.whatsapp/
- /mnt/installer/0/emulated/0/Android/data/com.whatsapp
The sensitive stuff is in the former. The latter may be accessible to anyone.
SSH session with simpleSSHD
This is a no-cost app, which is essentially the Dropbear server.
Note: It’s also possible to connect with “adb shell” through a plain USB cable, and there’s “adb push” and “adb pull” to transfer files. So the advantage of SSH is limited.
Having SimpleSSHD running and started on the phone, I connected with the address provided on the screen
$ ssh -p 2222 user@10.11.12.13
the password appears on the phone’s screen. To use automatic login, go
cat > ~/authorized_keys
and copy-paste the content of ~/.ssh/id_rsa.pub there. Note that the file on the phone is not under a .ssh/ directory, which is probably why the ssh-copy-id utility doesn’t cut. Note however that once this file is found, a password login is not attempted if the host’s public key doesn’t match, so now try to log in from a computer that doesn’t have one of the listed keys.
In principle, the available executables are in /system/bin. The path contains more directories, but this is the only effective one.
Who am I?
$ id uid=10225(u0_a225) gid=10225(u0_a225) groups=10225(u0_a225),3003(inet),9997(everybody),20225(u0_a225_cache),50225(all_a225) context=u:r:untrusted_app_29:s0:c225,c256,c512,c768
Backing up directly from phone (command run on receiving host):
$ ssh -p 2222 user@10.11.12.13 tar -cvz /storage/emulated/0/
The execution path…?
$ echo $PATH /sbin:/system/sbin:/system/bin:/system/xbin
Unfortunately, these directories aren’t readable as a regular user, so it’s impossible to do a plain “ls” on them. Just in case I was looking for excuses to root the phone.
“more” also works fine, but there’s no “less”.
“top” works nicely, but shows only the same user’s processes. There’s also “ps”, but it seems to do the same. But hey, I rooted the phone. So
$ su # id uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
And that’s the reason I rooted the phone, actually.