App Data Backup/Restore

[muntashirakon]

App Data Backup/Restore

[MuntashirAkon]

This codebase might come in handy:

https://github.com/machiav3lli/oandbackupx

Unfortunately, no. OAB* have completely ignored many security issues like signing info verification, OABX has an encryption method which is not convenient (I don't want to give users illusion of security), uses traditional zip archive which doesn't preserve any permission. The backup process that I intend to utilise will be very different from what OAB* authors have implemented.

[MuntashirAkon]

It should also be considered whether AM should offer to back up .odex files, see machiav3lli/oandbackupx#70

As described in the first comment, I'll backup the entire source directory instead of just the apk file. This way you wouldn't need to worry about your patched odex, split apk or anything.

[MuntashirAkon]

Would you also consider giving the user a choice when deriving asymetric/symetric keys? Like a choice between AES-128/192/256 or RSA-2048/4096 or ECC (preferrably Curve25519, no?)

Probably. But it depends largely on how much effort would it take to do that. I'll be supporting OpenKeychain as well if they care to update their API to support Androidx. I never had to work with real-life encryption before so it'll take some time to understand how the APIs work. But since it's Java, the purest OOP, I expect it to be easy.

[MuntashirAkon]

Android Keystore maybe?

Yeah, I was thinking the same thing.

But there are other security issues as well. For example, the backups have to be written to disk before encrypting them which is insecure because a bad app can exploit it easily enough. If I could somehow redirect the tar streams directly to the crypto utils (without writing to a file), that would be more secure. While this isn't impossible, it requires some modifications in the libsu library.

[Atrate]

This codebase might come in handy:

https://github.com/machiav3lli/oandbackupx

[Atrate]

Would you also consider giving the user a choice when deriving asymetric/symetric keys? Like a choice between AES-128/192/256 or RSA-2048/4096 or ECC (preferrably Curve25519, no?)

[MuntashirAkon]

Milestones

• v2.5.10: Metadata creator/loader
• v2.5.11: Initial support for backup/restore (API 23 or later only)
• v2.5.12: #60, #63, Platform dependency issue (#58)
• v2.5.13: Split apk support (5f190a4), run backup/restore in a separate foreground service
• v2.5.14: App crashing after restore (except #82), #64, #65, #70, #84, #87
• v2.5.15: General investigation on OpenKeychain (db0deb2), #94
• v2.5.16: #88, #109, Full implementation of OpenKeychain

[Atrate]

Suggestion: add the possibility to schedule backups (e.g. 2 times a week, only when charging or only when battery ≥ 80%)

[Atrate]

It should also be considered whether AM should offer to back up .odex files, see NeoApplications/Neo-Backup#70

[MuntashirAkon]

Would you also consider giving the user a choice when deriving asymetric/symetric keys? Like a choice between AES-128/192/256 or RSA-2048/4096 or ECC (preferrably Curve25519, no?)

It seems adding support for encryption (other than OpenPGP) requires some work. Since they only rely on keys, it is necessary to secure the key itself which needs a lot of work and I don't have any good examples other than OpenKeychain itself.

[Atrate]

Since they only rely on keys, it is necessary to secure the key itself

Android Keystore maybe? Or only enable the option if the keystore is hardware-backed.

[MuntashirAkon]

8d92570 marks the end of this issue. From now on, issues on backup will be discussed separately in their respective issue.

[MuntashirAkon]

KeyStore has another problem: If the user has set password in the OpenPGP client, s/he will be prompted to provide the password. But KeyStore doesn't have such option. So, there's no protection when decrypting the backup. Any app with accessibility permission can in theory launch AM automatically and decrypt the backup files. So, AM needs to implement a custom app lock as well.

[nerd190]

Hey, sorry I havent been active in sone time now, been hella busy, but I have been keeping up with the project.
How about OpenSSL? a library like this: https://github.com/leenjewel/openssl_for_ios_and_android/blob/master/README.md

My idea?

Use binaries instead:

• OpenSSL.
• GnuPG.

If you added a tiny shell (right now the smallest embeddable shell would be 'NetHunter' terminal, an up-to-date version of JackPal's 'Terminal Emulator' used by Kali NetHunter Android, its way less than half a megabyte! just needs some 'NetHunter' branding stripped from res folder and its ready to use) this way, 'AM' can fire more shell commands without using root access, like Termux, whilst using actual OpenSSL/GnuPG binaries, and skipping the BS that is 'OpenKeyChain' (whilst its the best so far for Android, it doesnt really say much, theres not much competition for it!) plus it could run bash rather than mksh, though all backups etc would have to be in mksh syntax obviously.

Why?
People have suggested a terminal emulator & no-root options too, whilst they are things I do not particulary need, if a shell with OpenSSL/GnuPG can help us encrypt, then this addresses the problem, whilst also giving those who want terminal/no-root options what they want too. Plus added benefits, like being able to add other binaries, like adding sqlite3 for organising meta, I understand that whilst shells can read json, they wasnt designed to so it can be difficult, so most people use a lib to help out with this (or atleast I do when making terminal pkgs, I use YAML for this reason) sqlite3 has been good when I can use it though, e.g If I know its for Termux where it is available. Although, you probably use Java for querying the json, its just an example that other options open up with a more shell-based backend that can provide utilities that only us rooted users can install to /system.

[MuntashirAkon]

My idea?
Use binaries instead:

Terminal emulator is beyond what App Manager stands for. Termux is currently struggling with compatibility problem even after dropping support for several Android versions (this time the problem is with Android 11). Therefore, no terminal emulator will be added.

'AM' can fire more shell commands without using root access, like Termux

AM is already running shell commands without root access. Running a shell command is like creating a new process. There's nothing special about shell commands. Since toybox is now built-in, AM can run most linux commands without problems.

a library like this: https://github.com/leenjewel/openssl_for_ios_and_android/blob/master/README.md

These libraries only support API 23 or later. AM supports API 21 or later. So, they can't be integrated into AM. If you'd followed recent activities, you'd have known that I've already spent a lot of time integrating the toybox binary and I ended up modifying toybox source code in order for it to work up to Android 11 (I've also considered busybox which is even worse).

if a shell with OpenSSL/GnuPG can help us encrypt, then this addresses the problem

They will create even greater problem. OpenPGP clients such as OpenKeychain is considered (besides the fact that it's an audited software) because it's very difficult to store keys without a substantial knowledge of cryptography (I only have a basic knowledge of this field). Using these binaries require AM to store and manage these keys and provide the users necessary UI to import, export or modify them. In order words, AM has to support cryptographic features similar to OpenKeychain. I'm currently designing something similar in #116 but the features are very limited and supported encryptions are AES, RSA and EC. This is mainly for the people who do not use a OpenPGP client and need an encryption solution that somewhat works.

it could run bash rather than mksh, though all backups etc would have to be in mksh syntax obviously.

This isn't a problem for me. I usually do the necessary processing in Java instead of shell as shell is very slow.

[nerd190]

Just an idea is all! I use openssl & opengpg freely within terminal emulators, they work both in or out of Termux, making encryption easy, since then I have stopped using OpenKeyChain.
When I looked into Android encryption, its difficult, its a mess, unlike on linux and I thought, if I had to do it, a small bash shell with openssl/gnupg (a few MBs) wouldve been the easiest approach to do so, also opening up further opportunity, like mosh, ssh, rsync, rclone etc etc. all of which run with or without Termux. I saw that Kali's is the smallest available that is updated regurlarly. Whilst I dont need another "terminal emulator" an independent "shell" that you can add what you see fit too is different, the user doesnt need a UI as AM will fire the commands not the user at a command prompt, user just sees AM's GUi and clicks button, these buttons are commands that AM completes, no "gpg --list-long ass -command here"
Again, just one solution of many, I thought personally (as I was going to) a tiny shell with proper binaries is easiest, these binaries are used millions of times, every day for years, contributed by thousands, minimal bugs, bugs get fixed quick...
Unlike OpenKeyChain, tink, blahblah... that are MUCH newer, made and fixed by few, have more bugs that take longer to fix, and are simply "a java compatability layer" to bring some of the functionality that the binaries I named do. e.g OpenKeyChain is just a java layer for a limited version of OpenGPG etc etc.
I thought, may as well use the binary.
Yes, Android has done something shitty with 11, but Termux has ideas that should continue full functionality, but again, this is only a worry for unrooted devices, I have OpenGPG, OpenSSL, SSH, Rsync, Rclone etc installed on my device already.

[MuntashirAkon]

Unlike OpenKeyChain, tink, blahblah... that are MUCH newer, made and fixed by few, have more bugs that take longer to fix, and are simply "a java compatability layer" to bring some of the functionality that the binaries I named do. e.g OpenKeyChain is just a java layer for a limited version of OpenGPG etc etc.

OpenKeychain isn't a Java compatibility layer. It uses Bouncy Castle library. Bouncy Castle is a widely used library and is as old as GnuPG itself.

[Cyberavater]

It should also be considered whether AM should offer to back up .odex files, see machiav3lli/oandbackupx#70

As described in the first comment, I'll backup the entire source directory instead of just the apk file. This way you wouldn't need to worry about your patched odex, split apk or anything.

As I mentioned here, NeoApplications/Neo-Backup#70 (comment) ; backing up (patched) odex doesn't work. Maybe consider not backing them up, since it's useless and can save up some space? (i.e only backing up split apk)

[MuntashirAkon]

The apk only flag is enabled by default which means odex/vdex won't be backed up by default. It's obviously possible to use patched odex files. Consider opening a separate issue along with what you've done so that I can further look into it in future.

[Cyberavater]

The apk only flag is enabled by default which means odex/vdex won't be backed up by default. It's obviously possible to use patched odex files. Consider opening a separate issue along with what you've done so that I can further look into it in future.

So, what I'll have to do is, unmark apk only, to backup odex and reuse them? Ok, I'll try it and if no luck, I'll file a new issue.

[MuntashirAkon]

So, what I'll have to do is, unmark apk only, to backup odex and reuse them?

You have to unmark APK Only during both backup and restore.

[Cyberavater]

So, Currently I tried the latest version of SB specifically for this one app/issue #473

I found out that SB encrypts (AM equivalent) Internal and External data, by default and which can't be disabled even the users want to.

Now, something similar was already planned by MA (For which I argued with him, sorry). But the thing I didn't like about encryption is that you need to remember a password (at least that's what I knew back then), but it's implemented in a way that SB used (i.e, the user doesn't need to remember anything), then I guess encrypting sensitive data by default won't be a bad idea.

It's possible that MA already had it planned somewhat similarly, I've just added this example here just in case.

Of course, AM can't be 100% like SB, as SB can get its data from Firebase, but AM would also have its own way of handling its data (#237).

[MuntashirAkon]

If you want encryption or verification, you have to use a password or secure hash. I agree that it's not possible to remember all the passwords you use, but that's why password managers exist. This is also what we want people to get familiar with, especially in a time when data breaches have become so prevalent.