I've submitted a patch to the to take the next step in what was probably, externally, my least popular contribution to while I was at Google. Here's the reason I think it's time to go beyond deprecating `adb backup` and remove it entirely.

@alsutton Mhm, doesn't that mean that any backup solution that lets the user decide where to put the backup reproducing the problem?

Say one would use Seedvault, which let's you put a backup into the filesystem, this would basically cause the same problem? Because the impersonator could setup this backup, connect USB and pull the data?

"Getting rid of data backup freedom" doesn't sound like a solution to a problem to me, it sounds like a problem on its own.

@sheogorath If a backup solution allows for the quick and easy exfiltration of a users data then yes, it shares the same problem.

@alsutton Isn't "quick and easy exfiltration of a user's data" literally the main goal of every backup solutions?

@sheogorath With the addition of “to a trusted place”, yes, but the trusted place guarantee is missing in this context.

@alsutton I do agree, but that leaves the question who decides what place is trusted?

I mean, we have an authorised user in front of the device. This user is allowed to add and remove certificate authorities, so they should also be able to decide what backup location is trusted?

@sheogorath I don’t think that the unauthorised user should be able to choose what destination is trusted, and, on almost all production devices sold, they wouldn’t be able to without adb backup being available.

@alsutton But they aren't unauthorised from a device perspective. According to your scenario, they have authorised themselves to the device. (without adb backup also shouldn't allow a backup, iirc).

They have full access to the system. If they want, they can install an MDM solution on the device, install custom CAs, set up a VPN, …

Why shouldn't they also be trusted to set up a backup location?

Or should we rather remove those other features as well?

@alsutton Or being more constructive: Maybe we should add some kind of "sudo" mode to the device? That requires a second factor to perform "dangerous" operations, such as a backup location authorisation, admin permission usage, …?

@sheogorath Doing all of the things you mention would leave user visible traces on the device. There is no easily accessible sign adb backup has been executed.

Theres a whole load of other adb commands that can snuffle out a lot of the data you mention (photos, list of apps) as well as modify/compromise the device

Even without enabling adb you could install an app & enable it as an accessibility service & have a persistent compromise in a hard to detect way

For the kind of people you are suggesting this would protect, allowing anyone access to your unlocked device with sensitive data for a few minutes is potentially 'game over' @sheogorath


Could run a backup of some kind (depending on threat adb, or either Google Backup or Seedvault backup) & factory reset device before passing customs

Could have a secondary user for sensitive operations/data that you backup, store encrypted somewhere safe (on a server somewhere?) & delete before travel. Then recreate afterwards.

Alternatively claim its someone elses user & you cant unlock

Could factory reset the whole device if you are forced to unlocked primary user

@alsutton Is there anything preventing us from implementing a user visible trace for backups?

@sheogorath The biggest hurdle would probably be getting Google to accept the submission.

@alsutton Although I haven't looked at the details yet, the cloud backup at Google can probably be retrieved with just the Google account credentials and some ID/secret that can be easily retrieved from the device, no?
So if adb backup is removed, Google cloud backup should be removed as well for the very same reasons.

@larma Google cloud backup restoration needs a target device to restore to, and you can’t quickly perform an operation which dumps all the data to a PC or other unprotected area without modifying the OS or kernel of the device.

@alsutton what do you mean with "target device". I also need a computer or similar device to run adb backup on while the attacked phone is connected.

Restoring from cloud in the end, is just about downloading files from a Google server, the same files as produced by adb backup. I can download those from any device that has internet connection and the required secrets. Yes, it probably needs some tooling to do that - just like I'd need to install adb, before I can fetch the adb backup.

@larma The target device for adb backup can be something the user is unaware of.
Can you tell me why you believe adb backup files and the files stored on Googles servers are the same? Where has this information been publicly stated?

@alsutton Maybe I wasn't specific enough here. It's not exactly the same files with respect to the file type, but it's the same data of each and every app. Both adb backup and Google cloud backup use the same functions of AOSP to retrieve backup data. This is why settings like affect both backups the same way. (Ironic: I know several app developers that disabled backups so that their user's data is not uploaded to Google, disabling adb backup was an undesired collateral)

@alsutton What is changed is that adb backup gets less app data by adding an additional filter for when adb backup accesses the AOSP backup functions.

Seedvault and Google cloud backup will still see this data. And adb backup is still allowed for debuggable apps targeting 12, so that developers can test what would happen if data is backed-up/restored to/from Google.

adb backup always was more like a debugging tool for Google cloud backup than serious backup tool.


So unless I'm missing something that change to adb backup for android 12 and sdk31 apps is pretty much doing what you suggested in your blog post, except not for apps targeting earlier SDK @alsutton ?

Another thing I just thought is the new device to device backup functionality, that was kind of mentioned/documented previously, but looks set to land in 12, potentially will give access to the same data under similar situations to that which you've blogged

@larma @alsutton

D2D backup has the added worry of also doing backups of apps where the dev has set them to not backup with Google Backups/Seedvault or adb

Although SDK31+ apps can manage what files will be accessible via backups and what will be accessible via D2D.

@dazinism @larma You still get the launcher databases in Android 12 because launcher isn’t a third party app.

@alsutton Besides google cloud backup are there are some more usefull methods on how to backup and restore the phone at home?

@pvagner I’m not familiar with other offerings because I haven’t looked into them.

@alsutton wouldn't a better solution be to have a switch which can prevent backups of a device being taken, without factory resetting it? Imho editing adb just means people will end up using other tools like cellebrite?

Pretty sure cellebrite uses adb backup and other adb commands to get data.
Much of their capabilities with Android is against unlocked devices, although they doubtlessly have some lock exploits against some devices, particularly older ones not getting security updates with publicly known vulns @alsutton

@alsutton uhm, to show a bit of the positive side of backups:

The mvt project uses Android an iOS backup functionality (yes, adb backup for android), to identify whether the system has been compromised by NSO.

Removing such tools would hurt those forensics.

Sign in to participate in the conversation

The original server operated by the Mastodon gGmbH non-profit