One of the less known novel features introduced inwards ICS is the powerfulness to backup a device to a file on your reckoner via USB. All you lot cause got to do is enable USB debugging, connect your telephone to a reckoner as well as type the
This doesn't require rooting your telephone as well as lets you lot backup application data, both user installed as well as organisation applications (APK's), every bit good every bit shared storage (SD card) contents. There are some limitations though: it won't backup apps that cause got explicitly forbidden backups inwards their manifest, it won't backup protected (with DRM) apps as well as it won't backup some organisation settings such every bit APN's as well as WiFi access points. The transfer speed is express past times ADB channel speed (less than 1MB/s), so total backups tin cause got quite some time. There is also a rather annoying bug inwards 4.0.4 where it volition backup shared storage fifty-fifty if you lot don't asking it. With all that said, it's a real useful tool, as well as volition hopefully encounter some improvements inwards the side past times side Android version.
The backup ascendence is fairly flexible as well as lets you lot specify what apps to backup, whether to include organisation apps when doing a total backup, as well as whether to include shared storage (SD card) files. Here's a summary of the available options every bit displayed past times
The restore ascendence is yet quite express -- at that spot are no options, you lot tin alone specify the path to the backup file. One of the features most noticeably lacking is conditional restore: restores are all or nothing, you lot cannot restore alone a subset of the apps (packages), or restore alone the contents of the shared storage. Supporting this volition require modifying the firmware, but you lot tin extract alone the needed information from the backup as well as re-create it manually. Copying apps as well as app information to your device requires root access, but extracting as well as copying external storage files such every bit pictures as well as music tin live done on whatsoever stock ICS device. And if you lot create a backup file containing alone the files you lot call for to restore, you lot wouldn't call for root access at all. This postal service volition nowadays the format of Android's backup files as well as innovate a small-scale tool that allows you lot to extract as well as repackage them every bit needed.
SDK API's for using Android's backup architecture were announced every bit far dorsum every bit Froyo (2.2), but it has likely been available internally fifty-fifty earlier that. As introduced inwards Froyo, it uses a proprietary Google carry to backup application settings to the "cloud". ICS adds a local carry that lets you lot salve backups to a file on your reckoner every bit well. The actual backup is performed on the device, as well as is streamed to your reckoner using the same protocol that
After all this is done, you lot should cause got a backup file on your computer. Let's peek within it. If you lot opened upwards it alongside your favourite editor, you lot volition encounter that it starts alongside a few lines of text, followed past times binary data. The text lines specify the backup format as well as encryption parameters, if you lot specified a password when creating it. For an unencrypted backup it looks similar this:
The showtime trouble is the file 'magic', the instant the format version (currently 1), the tertiary is a compression flag, as well as the lastly 1 the encryption algorithm ('none' or 'AES-256').
The actual backup information is a compressed as well as optionally encrypted tar file that includes a backup manifest file, followed past times the application APK, if any, as well as app information (files, databases as well as shared preferences). The information is compressed using the deflate algorithm, so, inwards theory, you lot should live able to decompress an unencrypted archive alongside measure archive utilities, but I haven't been able to fine 1 compatible alongside Java's
App information is stored nether the
If you lot specified an encryption password, things larn a niggling to a greater extent than interesting. It volition live used to generate an AES-256 primal using 10000 rounds of PBKDF2 alongside a randomly generated 512 chip salt. This primal volition live as well as so used to encrypt a randomly generated AES-256 chip main key, that is inwards plough used to encrypt the actual archive information inwards CBC fashion ("AES/CBC/PKCS5Padding" inwards JCE speak). H5N1 main primal checksum is also calculated as well as saved inwards the backup file header. All this is fairly measure practice, but the way the checksum is calculated -- non so much. The generated raw main primal is converted to a Java graphic symbol array past times casting each
The main primal blob contains the archive information encryption IV, the actual main primal as well as its checksum, all encrypted alongside the primal derived from the user-supplied password. The detailed format is below:
Based on all this info, it should live fairly tardily to write a elementary utility that decrypts as well as decompresses Android backups, right? Porting relevant code from
This seems to do the trick, as well as nosotros tin at in 1 trial successfully decrypt as well as decompress Android backups. Extracting the files is merely a affair of using tar. Looking at the archive contents allows you lot to extract sure files that are non unremarkably user accessible, including app databases as well as APK's without rooting your phone. While this is sure as shooting interesting, a to a greater extent than useful scenario would live to restore alone a constituent of the archive past times selecting alone the apps you lot need. You tin do this past times deleting the ones you lot don't need, repacking the archive as well as and so using
Full code for the backup pack/unpack utility is on github. Keep inwards heed that piece this code works, it has real minimal mistake checking as well as mightiness non comprehend all possible backup formats. If it fails for some reason, await a raw stack line rather than a friendly message. Most of this code comes take away from Android's
adb backup ascendence inwards a shell. That volition exhibit a confirmation dialog on the telephone prompting you lot to authorize the backup as well as optionally specify a backup encryption password. It looks something similar this:
This doesn't require rooting your telephone as well as lets you lot backup application data, both user installed as well as organisation applications (APK's), every bit good every bit shared storage (SD card) contents. There are some limitations though: it won't backup apps that cause got explicitly forbidden backups inwards their manifest, it won't backup protected (with DRM) apps as well as it won't backup some organisation settings such every bit APN's as well as WiFi access points. The transfer speed is express past times ADB channel speed (less than 1MB/s), so total backups tin cause got quite some time. There is also a rather annoying bug inwards 4.0.4 where it volition backup shared storage fifty-fifty if you lot don't asking it. With all that said, it's a real useful tool, as well as volition hopefully encounter some improvements inwards the side past times side Android version.
The backup ascendence is fairly flexible as well as lets you lot specify what apps to backup, whether to include organisation apps when doing a total backup, as well as whether to include shared storage (SD card) files. Here's a summary of the available options every bit displayed past times
adb's usage:adb backup [-f] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>] - write an archive of the device's information to <file>. If no -f selection is supplied as well as so the information is written to "backup.ab" inwards the electrical current directory. (-apk|-noapk enable/disable backup of the .apks themselves inwards the archive; the default is noapk.) (-shared|-noshared enable/disable backup of the device's shared storage / SD carte du jour contents; the default is noshared.) (-all way to dorsum upwards all installed applications) (-system|-nosystem toggles whether -all automatically includes organisation applications; the default is to include organisation apps) (<packages...> is the listing of applications to live backed up. If the -all or -shared flags are passed, as well as so the bundle listing is optional. Applications explicitly given on the ascendence trouble volition live included fifty-fifty if -nosystem would ordinarily travail them to live omitted.)
The restore ascendence is yet quite express -- at that spot are no options, you lot tin alone specify the path to the backup file. One of the features most noticeably lacking is conditional restore: restores are all or nothing, you lot cannot restore alone a subset of the apps (packages), or restore alone the contents of the shared storage. Supporting this volition require modifying the firmware, but you lot tin extract alone the needed information from the backup as well as re-create it manually. Copying apps as well as app information to your device requires root access, but extracting as well as copying external storage files such every bit pictures as well as music tin live done on whatsoever stock ICS device. And if you lot create a backup file containing alone the files you lot call for to restore, you lot wouldn't call for root access at all. This postal service volition nowadays the format of Android's backup files as well as innovate a small-scale tool that allows you lot to extract as well as repackage them every bit needed.
SDK API's for using Android's backup architecture were announced every bit far dorsum every bit Froyo (2.2), but it has likely been available internally fifty-fifty earlier that. As introduced inwards Froyo, it uses a proprietary Google carry to backup application settings to the "cloud". ICS adds a local carry that lets you lot salve backups to a file on your reckoner every bit well. The actual backup is performed on the device, as well as is streamed to your reckoner using the same protocol that
adb pull uses to permit you lot salve a device file locally. When you lot execute the adb backup ascendence a novel Java procedure (not an action or service) volition live started on your device as well as it volition bind to the system's BackupManagerService as well as requests a backup alongside the parameters you lot specified. BackupManagerService volition inwards plough start the confirmation action shown above, as well as execute the actual backup if you lot confirm (some to a greater extent than details including code references here). You cause got the selection of specifying an encryption password, as well as if your device is already encrypted you lot are required to come inwards the device encryption password to proceed. It volition live used to encrypt the archive every bit good (you can't specify a split upwards backup encryption password).After all this is done, you lot should cause got a backup file on your computer. Let's peek within it. If you lot opened upwards it alongside your favourite editor, you lot volition encounter that it starts alongside a few lines of text, followed past times binary data. The text lines specify the backup format as well as encryption parameters, if you lot specified a password when creating it. For an unencrypted backup it looks similar this:
ANDROID BACKUP 1 1 none
The showtime trouble is the file 'magic', the instant the format version (currently 1), the tertiary is a compression flag, as well as the lastly 1 the encryption algorithm ('none' or 'AES-256').
The actual backup information is a compressed as well as optionally encrypted tar file that includes a backup manifest file, followed past times the application APK, if any, as well as app information (files, databases as well as shared preferences). The information is compressed using the deflate algorithm, so, inwards theory, you lot should live able to decompress an unencrypted archive alongside measure archive utilities, but I haven't been able to fine 1 compatible alongside Java's
Deflater (Update: here's how to convert to tar using OpenSSL's zlib command: dd if=mybackup.ab bs=24 skip=1|openssl zlib -d > mybackup.tar). After the backup is uncompresed you lot tin extract it past times merely using tar xvf mybackup.tar. That volition attain output similar to the following:$ tar tvf mybackup.tar -rw------- 1000/1000 1019 2012-06-04 16:44 apps/org.myapp/_manifest -rw-r--r-- 1000/1000 1412208 2012-06-02 23:53 apps/org.myapp/a/org.myapp-1.apk -rw-rw---- 10091/10091 231 2012-06-02 23:41 apps/org.myapp/f/share_history.xml -rw-rw---- 10091/10091 0 2012-06-02 23:41 apps/org.myapp/db/myapp.db-journal -rw-rw---- 10091/10091 5120 2012-06-02 23:41 apps/org.myapp/db/myapp.db -rw-rw---- 10091/10091 1110 2012-06-03 01:29 apps/org.myapp/sp/org.myapp_preferences.xml
App information is stored nether the
app/ directory, starting alongside a _manifest file, the APK (if requested) inwards a/, app files inwards f/, databases inwards db/ as well as shared preferences inwards sp/. The manifest contains the app's version code, the platform's version code, a flag indicating whether the archive contains the app APK as well as finally the app's signing certificate (called 'signature' inwards Android API's). The BackupManagerService uses this information when restoring an app, to a greater extent than oftentimes than non to cheque whether it has been signed alongside the same certificate every bit the currently installed one. If the certificates don't gibe it volition skip installing the APK, except for organisation packages which mightiness live signed alongside a dissimilar (manufacturer owned) certificate on dissimilar devices. Additionally, it expects the files to live inwards the lodge shown to a higher house as well as restore volition neglect if they are out for order. For example, if the manifests states that the backup includes an APK, it volition travail to read as well as install the APK first, earlier restoring the app's files. This makes perfect feel -- you lot cannot restore files for an app you lot don't cause got installed. However BackupManagerService volition non search for the APK inwards the archive, as well as if it is non right after the manifest, all other files volition live skipped. Unfortunately at that spot is no indication virtually this inwards the device GUI, it is alone shown every bit logcat warnings. If you lot requested external storage backup (using the -shared option), at that spot volition also live a shared/ directory inwards the archive every bit well, containing external storage files for each shared book (usually alone shared/0/ for the first/default shared volume). If you lot specified an encryption password, things larn a niggling to a greater extent than interesting. It volition live used to generate an AES-256 primal using 10000 rounds of PBKDF2 alongside a randomly generated 512 chip salt. This primal volition live as well as so used to encrypt a randomly generated AES-256 chip main key, that is inwards plough used to encrypt the actual archive information inwards CBC fashion ("AES/CBC/PKCS5Padding" inwards JCE speak). H5N1 main primal checksum is also calculated as well as saved inwards the backup file header. All this is fairly measure practice, but the way the checksum is calculated -- non so much. The generated raw main primal is converted to a Java graphic symbol array past times casting each
byte to char, the final result is treated every bit a password string, as well as run through the PBKDF2 business office to effectively generate some other AES key, which is used every bit the checksum. Needless to say, an AES primal would most likely comprise quite a few bytes non mappable to printable characters, as well as since PKCS#5 does non specify the actual encoding of a password string, this produces implementation subject results (more on this later). The checksum is used to verify whether the user-specified decryption password is right earlier truly going ahead as well as decrypting the backup data: after the main primal is decrypted, its checksum is calculated using the method described as well as compared to the checksum inwards the archive header. If they don't match, the specified password is considered wrong as well as the restore procedure is aborted. Here's the header format for an encrypted archive: ANDROID BACKUP 1 1 AES-256 B9CE04167F... [user password tabular array salt inwards hex] 9C44216888... [master primal checksum tabular array salt inwards hex] 10000 [number of PBKDF2 rounds] 990CB8BC5A... [user primal IV inwards hex] 2E20FCD0BB... [master primal blob inwards hex]
The main primal blob contains the archive information encryption IV, the actual main primal as well as its checksum, all encrypted alongside the primal derived from the user-supplied password. The detailed format is below:
[byte] IV length = Niv [array of Niv bytes] IV itself [byte] main primal length = Nmk [array of Nmk bytes] main primal itself [byte] MK checksum hash length = Nck [array of Nck bytes] main primal checksum hash
Based on all this info, it should live fairly tardily to write a elementary utility that decrypts as well as decompresses Android backups, right? Porting relevant code from
BackupManagerService is indeed fairly straightforward. One thing to complaint is that it uses SYNC_FLUSH fashion for the Defalter which is alone available on Java 7. Another requirement is to cause got the JCE unlimited forcefulness jurisdiction policy files installed, otherwise you lot won't live able to role 256 chip AES keys. Running the ported code against an unencrypted archive plant every bit expected, yet trying do decrypt an archive consistently fails when checking the main primal checksum. Looking into this farther reveals that Android's PBKDF2 implementation, based on Bouncy Castle code, treats passwords every bit ASCII when converting them to a byte array. The PKCS#5 standard states that 'a password is considered to live an octet string of arbitrary length whose interpretation every bit a text string is unspecified', so this is non technically incorrect. However since the 'password' used when calculating the main primal checksum is a randomly generated value (the AES key), it volition apparently comprise bytes non mappable to ASCII characters. Java SE (Oracle/Sun) seems to process those differently (most likely every bit UTF-8), as well as therefore produces a dissimilar checksum. There are 2 ways roughly this: either role a Bouncy Castle library alongside the Android patches applied, or implement an Android-compatible PBKDF2 business office inwards our decryption code. Since the Android Bouncy Castle acre is quite big (more than 10,000 lines inwards ICS), the instant selection is clearly preferable. Here's how to implement it using the Bouncy Castle lower degree API's: SecretKey androidPBKDF2(char[] pwArray, byte[] salt, int rounds) { PBEParametersGenerator generator = novel PKCS5S2ParametersGenerator(); generator.init(PBEParametersGenerator.PKCS5PasswordToBytes(pwArray), salt, rounds); KeyParameter params = (KeyParameter) generator.generateDerivedParameters(PBKDF2_KEY_SIZE); render novel SecretKeySpec(params.getKey(), "AES"); } This seems to do the trick, as well as nosotros tin at in 1 trial successfully decrypt as well as decompress Android backups. Extracting the files is merely a affair of using tar. Looking at the archive contents allows you lot to extract sure files that are non unremarkably user accessible, including app databases as well as APK's without rooting your phone. While this is sure as shooting interesting, a to a greater extent than useful scenario would live to restore alone a constituent of the archive past times selecting alone the apps you lot need. You tin do this past times deleting the ones you lot don't need, repacking the archive as well as and so using
adb restore alongside the resulting file. There are 2 things to scout out for when repacking though: Android expects a exceptional ordering of the files, as well as it doesn't similar directory entries inwards the archive. If the restore procedure finds a directory entry, it volition silently fail, as well as if files are out of order, some files mightiness live skipped fifty-fifty though the restore action reports success. In short, merely tarring the unpacked backup directory won't work, so brand sure you lot specify the files to include inwards the proper lodge past times creating a backup file listing as well as passing to tar alongside the -T option. The easiest way to create 1 is to run tar tvf against the decompresed as well as decrypted original backup. Once you lot create a proper tar file, you lot tin pack it alongside the provided utility as well as feed it to adb restore. Another thing you lot should live aware of is that if your device is encrypted, you lot call for to specify the same encryption password when packing the archive. Otherwise the restore volition silently neglect (again, mistake messages are alone output to logcat). Here's how to pack the archive using the provided rhythm out script: $ ./abe.sh pack repacked.tar repacked.ab password
Full code for the backup pack/unpack utility is on github. Keep inwards heed that piece this code works, it has real minimal mistake checking as well as mightiness non comprehend all possible backup formats. If it fails for some reason, await a raw stack line rather than a friendly message. Most of this code comes take away from Android's
BackupManagerService.java alongside (intentionally) tike modifications. If you lot detect an error, experience costless to fork it as well as shipping me a draw asking alongside the fix.
0 Komentar untuk "Droidcedas : Unpacking Android Backups"