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 /storage/emulated/0 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.
System startup
Services that are started during boot are listed in /etc/init/. There’s update_engine.rc and update_verifier.rc services there by the way.
Linux kernel
To download the Linux kernel, go
git clone https://android.googlesource.com/kernel/gs
This is a Generic Kernel Image kernel, meaning that it includes the parts that are common to all devices. Device-specific drivers are applied as kernel modules instead.
The Linux kernel that runs on my machine is commit 740f7fbe5f3917e0a5fa0582b98543af4a15a7ba (with no special tag), which identifies itself as v5.10.43. I deduced the commit based upon the “g740f7fbe5f39″ part in the kernel version that appears in the phone’s about part (5.10.43-android12-9-00005-g740f7fbe5f39).
Note however that some drivers don’t come from this kernel tree, but are rather loaded as modules from other sources. google_charge.c, for example.
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.
Recording phone calls
Google has cracked down on phone call recording apps, probably because it’s illegal in some places in the world. Where I live it’s legal to record a phone call you’re participating in, so no problem. The only problem is to find an app that does the job.
So BCR (Basic Call Recorder) is a godsend. It works only on a rooted phone, and mine is, and it’s an open-source no-nonsense, plain and simple app that does one thing: It records phone calls. All of them.
I Installed BCR-1.76 as a Magisk module. After setting up the destination directory and trying to make a call, I got a notification saying “Failed to record call” also saying “This device might not support recording calls associated with the ‘com.android.phone’ app. Following this, I changed the output format to WAV/PCM 48000 Hz, and the recording was successful.
It was OGG/Opus @ 16000 Hz before, and that obviously didn’t work. But I don’t want to generate huge files, so I went for M4A/AAC, 64 kbps and 16000 Hz. And that worked as well. Both sides of the conversation are heard loud and clear, and it works well on and off speaker as well as in the car with bluetooth. Something I wouldn’t mention unless I saw how these things don’t work with the apps available at Google Play. But as BCR gets its voice stream from the natural place in the software environment (which is why root is required), and not with some quirky workarounds, it just works. Plus this app won’t start nagging about upgrades and whatnot. Bliss.
As for installing an app downloaded from the web with root privileges: The project has been running for a few years with its source published on Github, and there’s clearly a community and a userbase of relatively savvy people. So if something was wrong with it, I suppose it wouldn’t have gone unnoticed. I can only speculate on why this is released like this: Possibly this project is part of a spyware suite, so letting legit people use the call recorder helps ensuring that it works on all platforms, as complaints arrive if that isn’t the case.