Unable to unpack backup on S5 with Android 4.4.2 about android-backup-extractor HOT 14 CLOSED

Are you using the latest version (from Github)? If you are, the cause is probably some change/customization Samsung made, so not much I can do.

from android-backup-extractor.

Yes, I am using the latest version from Github.

from android-backup-extractor.

Same issue with Samsung S3 with Android 4.4.2

I am using the latest build from Github and getting the following exception:

Exception in thread "main" java.lang.RuntimeException: javax.crypto.BadPaddingException: Given final block not properly padded
    at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:199)
    at org.nick.abe.Main.main(Main.java:35)
Caused by: javax.crypto.BadPaddingException: Given final block not properly padded
    at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
    at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
    at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:313)
    at javax.crypto.Cipher.doFinal(Cipher.java:2087)
    at org.nick.abe.AndroidBackup.extractAsTar(AndroidBackup.java:117)
    ... 1 more

from android-backup-extractor.

This usually means the derived key is wrong, but could be caused by something else. I don't know what Samsung changed. How does the header look like? Does unpacking unencrypted backups work at all?

from android-backup-extractor.

The derived key is not wrong from what I could tell.

This is what the top of the file looks like:

ANDROID BACKUP
1
1
AES-256
BF43EA6D1ED7863E6D80936CB352B2D54659204CCAD187DA42A1A34D252C0A94D08CAD0F38D377AF8DB7AFA3976CE96D85342A6E4404FC24D38CDD03BF73A511
C49E1BB669BD0C3FB737D293E89B49416FB7CCD60C3FC93AC6BCC6A969F278E4523206743E0C3787A379EC876AA7F93028B5068C133FD2F2AE4473E9808ABF3C
10000
E3A7E2C2BFD83B887E9D723F0F8F1320
05CA61CF1A73CF60DF7C8615711265FC98FA8B0FC383F6E225839919E55D96858EFD901918CA66247FCAB3C948152508BDD3EB7F770EEF30F481A597613E63FE77C2E3F3C8DBDE10774541A759618C2A74D0E9F9D9FBC1CE65DB42E06F4F382B
...

When I try to generate a backup on my device without a password, the generated .ab file is 0 bytes. When I generate it with a password, it's 549. Very strange.

from android-backup-extractor.

Thanks. The header looks the same so the format probably is too, but key derivation might be different.
The backup service is not very user friendly, you are probably getting an error when trying to do a no-password backup, check the logcat for errors. Generally, if your device is encrypted, it forces you to use the same password for backups.

from android-backup-extractor.

Very interesting. My device is encrypted.

Here is the pastebin of my logcat: http://pastebin.com/V3enDbm9

This seems to be the most interesting piece:

I/BackupManagerService( 1653): Device encrypted; verifying against device data pw
I/MountService( 1653): validating encryption password...
D/VoldCmdListener(  148): cryptfs verifypw {}
I/Cryptfs (  148): this function isn't supported due to the security concern.
I/MountService( 1653): cryptfs verifypw => 0

from android-backup-extractor.

It looks like it can't verify that the disk encryption password is the same as the backup encryption password and that is why backup fails, or creates a partial backup. The header you posted is about 520 bytes, so you are definitely not getting a full backup in 549 bytes.

from android-backup-extractor.

Makes sense to me. I'd be curious to find out why it can't verify the
password.

I will decrypt my device and attempt again. Thanks for the info and I'll
let you know how it goes!

On Tue, Jul 1, 2014 at 11:51 AM, Nikolay Elenkov [email protected]
wrote:

It looks like it can't verify that the disk encryption password is the
same as the backup encryption password and that is why backup fails, or
creates a partial backup. The header you posted is about 520 bytes, so you
are definitely not getting a full backup in 549 bytes.

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

from android-backup-extractor.

Not an expert on Knox, but sounds like it is preventing the backup service from talking to vold, which is required to verify the FDE password.

from android-backup-extractor.

I decrypted the drive and now I am able to do backups and extract them.

from android-backup-extractor.

Same problem here on Note 8 LTE (GT-N5120) running (stock) KitKat 4.4.2.
I verified 'adb restore' does work after 'adb backup' on the 'encrypted device' (with 'encrypted backup' file). If Samsung mod'd the backup service, at least they did it consistently.
Maybe worth noting: 'adb backup' prompts for the 'encrypted device' (only) password, while 'adb restore' prompts for both the 'encrypted device' and 'encrypted backup' passwords (which are identical if the backup was performed on the same device).
Maybe also of interest: I successfully restored non-encrypted backups (performed using Android 4.1.2 SDK emulator) on my 'encrypted device' (I just left the '(non-encrypted) backup' password empty).
I would personally suspect the issue lies with the way the backup encryption key is derived when the device is encrypted. It would be interesting to know if a backup performed on an encrypted device can be restored on another encrypted device (with different 'encrypted device' passwords). If not, it would mean the 'encrypted backup' password is somehow mixed with the 'encrypted device' password (the two being identical, of course) during the key derivation process.

from android-backup-extractor.

Hi again,
After going through the code of the (latest) BackupManagerService, it appears no extra "mangling" is achieved on the backup password on encrypted device (the 'encrypted backup' password is forced to match the 'encrypted device' password, no matter what, even if a "Default backup password" is specified in the "Developer options").
On the other hand I'm wondering whether this could related to the "PBKDF2WithHmacSHA1" (PBKDF_CURRENT) versus "PBKDF2WithHmacSHA1And8bit" (PBKDF_FALLBACK) discrepancy? BackupManagerService makes sure to try both "algos" when validating the password, while ABE code seems to rely on default. This would mean that unmatching Java versions (between device and computer running ABE) would trigger the issue.
EDITED: Ha! ABE does handle the 8bit vs (new) utf8 passwords. Anyway, it shouldn't have made a difference since my password in ASCII only (according to http://android-developers.blogspot.ch/2013/12/changes-to-secretkeyfactory-api-in.html)

from android-backup-extractor.

Right, the whole 'disk encryption password required' thing is done in the UI, the backup/restore service doesn't care what the password is. There is no mixing, etc. of keys and passwords, the encryption key is derived from the password alone.

Also the Java version doesn't really matter, key derivation is done using Bouncy Castle.

In any case, this whole thing is by design, so not much can be done. Things have changed in the L release, because disk encryption is handled differently.

from android-backup-extractor.