В прошлой статье мы рассмотрели образцово-показательную реализацию резервного копирования данных на примере устройств Apple iOS. А как обстоят дела на других платформах? Сегодня мы изучим главного антагониста iOS — платформу Google Android и выясним, как сохранить данные с рутом и без, каким образом восстановить данные из резервной копии и как расковырять чужой локальный или облачный бэкап.
Сразу определимся с терминологией. В этой статье мы будем писать исключительно про ту разновидность Android, которая поставляется с сервисами Google. Сторонние прошивки нам не особо интересны: количество их пользователей минимально, при этом создавать и восстанавливать резервные копии данных при прошивке очередного «кастома» эти пользователи отлично умеют. Нет, сегодня мы поговорим об остальных 99% пользователей, которые хотят открыть коробку, ввести логин и пароль от учетной записи и получить что-то работоспособное.
Статья основана на исследовании, в ходе которого мы использовали порядка десяти устройств от ASUS, Google Nexus, LG, Motorola, Oppo и Sony. Тестировались как восстановление данных на то же устройство после сброса к заводским настройкам, так и миграция данных на другое устройство.
Производители устройств часто выпускают фирменные утилиты для резервного копирования данных. Некоторые (например, Sony) предлагают установить софт на компьютер, другие (ASUS, LG) встраивают соответствующую функциональность в прошивку. Samsung предоставляет возможность создавать резервные копии в собственном облаке. Короче говоря, разброд и шатание.
Объединяет решения от производителей две вещи. Во-первых, создаваемая резервная копия будет достаточно полной, что позволяет полноценно восстановить данные после сброса устройства, обновления прошивки или апгрейда. Во-вторых, восстановить бэкап от телефона Sony на планшет от ASUS (и наоборот) тебе не удастся: восстанавливать нужно тем же софтом на модель того же производителя.
Впрочем, если ты планируешь пользоваться устройством долгое время, почему бы и не создать резервную копию? Да, это не всегда удобно, и да, это никак не автоматизируется, но ведь возможность-то есть. А если с твоим телефоном что-то случится и если ты решишь заменить его на устройство от того же производителя, то тебе, может быть, даже удастся восстановить на него данные. Уверенности, разумеется, никакой: производитель гарантирует успешное восстановление только на устройство той же модели, с которой были скопированы данные.
Устройства под управлением Android — это пестрый зоопарк платформ, архитектур, производителей, аппаратных и программных конфигураций. Сложно сделать так, чтобы резервные копии, созданные с телефона одного производителя, не дестабилизировали работу смартфона на совершенно другой архитектуре. Вероятно, это и служит основной причиной того, с какой скоростью Google разрабатывает механизм резервного копирования.
Если не считать существовавших с первой версии Android механизмов синхронизации контактов, календаря и других приложений Google с облаком, то полноценный механизм резервного копирования приложений и настроек появился только в Android 4.3. Он был доступен лишь в режиме разработки и только через Android Debug Bridge. Иными словами, для «обычных» пользователей его не существовало.
[ad name=»Responbl»]
В какой-то момент Google начала синхронизировать некоторые данные с облаком. При восстановлении устройства предлагалось восстановить и данные (ярлыки, приложения и настройки) с одного из предыдущих устройств. Эта функциональность, строго говоря, не является частью Android, а реализована в проприетарных сервисах Google.
С Android 6.0 облачное резервное копирование настроек официально стало частью операционной системы. Теперь разработчику приложения достаточно включить в manifest приложения флажок, разрешающий резервное копирование данных, и система будет автоматически копировать их в облако. Разумеется, облако это от Google, а данные привязаны к учетной записи Google Account, так что пользователи AOSP-сборок без сервисов Google остаются в стороне. Что ж, давай рассмотрим эти механизмы подробнее. Нарушив хронологию, начнем с наиболее современного и интересного механизма, представленного в Android 6.0.
Начиная с Android 6.0 система автоматически сохраняет настройки системы и приложений в Google Drive пользователя. Решил обновить устройство? Твой новый смартфон автоматически подхватит настройки из облака, сам установит приложения, которыми ты пользовался на старом устройстве, и автоматически настроит их привычным для тебя образом. Почти как у Apple! И так оно все и работало в предварительных сборках Android M до самого релиза.
А в официальной версии Android 6.0 разработчики резко сменили пластинку. Если в предварительных сборках автоматическое резервное копирование работало для всех приложений, авторы которых не заблокировали эту возможность в явном виде (флаг opt-out в manifest), то в официальной версии системы резервные копии создаются только для приложений, авторы которых в явном виде затребовали сервис (opt-in через manifest) и прописали поддержку Android 6.0 (target API level 23).
Как ты думаешь, много ли разработчиков воспользовались этой возможностью? В замечательной статье Android 6.0 has a great auto backup system that no one is using (yet) журналисты Ars Technica подробно рассмотрели, какие приложения используют, а какие не используют встроенный в Android 6.0 механизм резервного копирования.
[ad name=»Responbl»]
Результаты оказались… неожиданными. В первую очередь встроенным механизмом резервного копирования НЕ ПОЛЬЗУЮТСЯ приложения Google. Да-да, разработчик этой великолепной системы решил обойтись без нее. Восстанавливаются базовые настройки системы, будильники, «тихий режим», но данные приложений Google — нет. А вот клиенты социальных сетей, почтовые клиенты, игры и прочие популярные приложения не спешат добавлять поддержку. Разумеется, ситуация будет меняться со временем, но пока вот так. После сброса редакционного Nexus 6 и восстановления из облака произошло следующее:
Иными словами, система установила все ранее установленные приложения, но не восстановила данные подавляющего большинства из них. Впрочем, контакты и email подхватились из облака, доступ к фотографиям — тоже. А настроить заново пару десятков приложений — нам не привыкать. Более подробно о работе Android Backup Service можно прочитать в справке Google.
Если Google может сохранить данные в облако, то мы можем их извлечь, не правда ли? Давай посмотрим, что можно сделать.
Во-первых, точно так же, как и в описанном в предыдущем номере примере скачивания данных из iCloud, нужны логин и пароль пользователя к учетной записи Google. Это не все; если включена двухфакторная аутентификация (а ее активируют все чаще), потребуется и одноразовый код, который будет генерироваться приложением Google Authenticator, Microsoft Authenticator, FreeOTP или любым из множества сторонних (работают они по единому принципу, и различается только криптографический код инициализации, который выдается пользователю в виде цветного QR-кода).
Еще нам потребуется соответствующий софт (можно обойтись и без него — об этом ниже). В качестве софта мы использовали Elcomsoft Cloud eXplorer. Запускаем приложение, авторизуемся в учетной записи Google, выбираем данные для скачивания:
Скачали? Наслаждаемся:
Доступен список устройств, установленные на них приложения и собственно данные приложений:
Конечно, есть доступ к фотографиям (привет, iCloud!):
Откуда и каким образом извлекаются все эти данные? А вот это, пожалуй, самое интересное. «Корпорация добра» придерживается политики максимальной информационной открытости. Ты всегда можешь просмотреть или скачать всю информацию, которую корпорация собрала о тебе. Ты можешь удалить любые данные, и для этого не требуется уничтожать свою учетную запись. Наконец, ты можешь отключить сбор отдельных типов данных (например, настроить свой телефон таким образом, что информация о твоем местоположении не будет отсылаться в Google).
Нас же в этом контексте интересует тот пункт, согласно которому ты вправе скачать всю информацию, собранную о тебе Google. Официальный способ сделать это — через сервис Google Takeout. Здесь можно выбрать, какие типы данных мы хотим скачать:
Подвоха как такового, в общем-то, нет. И данные скачать можно. Небольшая проблема возникает с анализом полученной информации. Для хранения и экспорта данных Google использует массу разнообразных форматов (в основном — открытых). К примеру, данные о своих перемещениях ты получишь в виде файла в формате JSON — делай с ним что хочешь, Google тебе не помощник. Не помощник он и спецслужбам: согласно официальной позиции компании, Google подчиняется закону и передает данные в открытом виде и в стандартном формате… что с ними будут делать дальше — ни малейшим образом не забота компании. А вот сам факт выдачи информации спецслужбам Google запишет, сохранит и опубликует.
Еще один момент. При скачивании через сервис Google Takeout пользователю обязательно придет уведомление: такие-то данные были скачаны с такого-то IP. Если тебе это не нужно, обращайся к сторонним инструментам: их использование не вызывает у Google тревоги. И на закуску — самое интересное. Google Takeout по какой-то причине не дает скачать синхронизированные в Chrome пароли. А Elcomsoft Cloud eXplorer извлекает их без особых проблем:
Начиная с Android 4.3 в системе появился штатный способ создания резервной копии через интерфейс Android Debug Bridge (ADB). Для создания резервной копии нужно использовать примерно такую команду:
adb backup -apk -shared -system -all -f C:backup.ab
Почему «примерно»? Да в силу все того же «зоопарка» устройств. Мы протестировали большое количество устройств от разных производителей, работающих под управлением разных версий Android от 4.4 до 6.0.1 включительно. На каких-то устройствах команда сработала в таком виде, на других указание ключей -system или -shared приводило к созданию пустого файла, а третьи отказывались воспринимать ключ -all. Какой-либо логики в поведении команды adb мы уловить не смогли; точно сказать можно одно: от версии Android ее поведение зависит мало. Скорее зависимость здесь от настроек, заданных конкретным производителем.
Например, на редакционном Nexus 6 под управлением Android 6.0.1 прошла следующая команда:
adb backup -all -f c:nexus6.ab
А вот опция -noapk «сломала» бэкап: был создан пустой файл. А еще adb backup может не работать, если включено шифрование раздела данных. Напомним, что шифрование включается по умолчанию на устройствах линейки Nexus, а также (по требованию Google) на всех устройствах, которые выходят с предустановленным Android 6 и оснащены 64-разрядными процессорами.
Еще один момент. Adb backup спроектирован таким образом, чтобы резервную копию, созданную на одном устройстве, можно было без проблем восстановить на другом. И ключевое слово здесь вовсе не «восстановить», а «без проблем»: восстановленное устройство должно работать и не должно глючить. Соответственно, сохраняются и восстанавливаются только те данные и настройки, которые точно не навредят стабильной работе даже тогда, когда данные переносятся с 32-битного смартфона с чипсетом MediaTek на 64-разрядный планшет с Intel Atom.
[ad name=»Responbl»]
Восстановить данные из резервной копии будет несложно с помощью команды adb restore.
Что же попадает в такие резервные копии? И снова ответ зависит от производителя устройства. К примеру, в смартфонах Sony контакты, журнал звонков и СМС в резервные копии ADB не попадает, а телефоны Samsung эти данные сохраняют. То же самое относится к настройкам устройства (которые зачастую уникальны для конкретного производителя) и данным системных приложений.
В резервную копию точно попадает список установленных приложений. Извлекаются и сохраняются APK-файлы (если во время создания копии была указана соответствующая опция). А вот данные приложений могут сохраняться, а могут и нет: зависит это от разработчиков, которые разрешают или не разрешают резервное копирование в manifest-файле приложения.
С практической точки зрения нам не удалось извлечь большой пользы из таких резервных копий. При восстановлении через adb restore все равно приходится авторизоваться в Gmail, Facebook и прочих клиентах почты и социальных сетей. Не сохранились настройки FBReader и Nova Launcher (у которого, к слову, есть собственный механизм создания резервных копий). А что сохранилось? С трудом припоминается, что на некоторых аппаратах удалось восстановить журнал звонков и архив СМС.
[ad name=»Responbl»]
Встроенным в Android механизмом резервного копирования пользуются и некоторые сторонние приложения. Им несть числа, так что рассматривать все мы не будем. Принцип работы всех подобных программ схож, и различаются они только добавленными возможностями. Самая популярная программа такого типа — Helium AppSync and Backup от известной команды разработчиков ClockworkMod (кастомное рекавери CWM — их разработка).
Резервные копии, создаваемые через ADB, — вещь достаточно простая. На выходе — архив, содержащий данные приложений (в зависимости от настроек — и собственно .apk). Они сохраняются в том виде, в котором их хранит само приложение. Как правило, приложения используют формат SQLite, реже — XML, еще реже — двоичные данные в собственном формате.
Для анализа SQLite придумано столько инструментов, что для самого краткого об-
зора потребовалась бы отдельная статья. Скажу лишь, что с помощью таких инструментов можно вытащить удаленные записи. Пример? Пожалуйста. Если тебе повезло и производитель твоего телефона разрешил копировать журнал звонков и СМС, то ты сможешь восстановить сообщения и звонки, которые были удалены пользователем.
Рассказывая о системе резервного копирования Android, нельзя не упомянуть такое явление, как резервные копии Nandroid. Термин образовался от слов NAND (тип флеш-памяти) и Android, и используется чаще всего в контексте создания копии всего пользовательского (и, зачастую, системного) раздела целиком с использованием кастомного рекавери (чаще всего CWM или TWRP). Переносимость резервных копий Nandroid ограничена. Их рекомендуется восстанавливать на то же устройство, с которого они были сделаны, и желательно на ту же прошивку.
Резервные копии Nandroid — штука достаточно абстрактная. У каждого рекавери этот формат свой. Более того, форматы могут отличаться в зависимости от устройства (напомню: кастомное рекавери — это, по сути, отдельная операционная система со своими особенностями для каждой поддерживаемой модели).
[ad name=»Responbl»]
Что же мы получаем? Чаще всего на выходе — образ файловой системы (вкупе с оригинальной файловой системой, которая была использована на конкретном устройстве). Анализ простой: монтируем образ (потребуется драйвер соответствующей файловой системы) и бродим по файловой системе.
В некоторых случаях нам выдают набор ZIP-архивов с данными приложений. Тут тоже все просто: заходим в архив и смотрим; формат данных такой же, как в случае с adb backup, но сам набор данных гораздо полнее. Иногда создается один-единственный архив с набором файлов внутри. Нам попадались как простые .zip, так и .tar.gz (расширение может не совпадать).
Общая особенность бэкапов Nandroid в том, что ни одно протестированное нами кастомное рекавери (а мы тестировали десятки вариантов) не создает полный образ раздела с данными. Под «полным» образом мы понимаем образ, который содержит как оригинальную файловую систему, так и незанятые блоки — свободное место. Анализ свободных блоков позволил бы провести сканирование на предмет поиска удаленных файлов. К сожалению, не выйдет. Если требуется именно это, тебе придется использовать другие методы. (В скобках замечу, что образ системного раздела большинством рекавери создается целиком, со всеми «потрохами».)
Несколько особняком стоит приложение Titanium Backup — самая популярная программа для создания резервных копий, доступная в Google Play. С ее помощью нам удалось создать резервную копию данных всех установленных приложений (включая .apk), после чего успешно восстановить их на новое устройство. Обрати внимание: Titanium копирует двоичные данные из песочниц приложений, поэтому крайне не рекомендуем с его помощью переносить данные системных приложений Android. При восстановлении их на другое устройство система может работать нестабильно.
Сегодня мы изучили часть механизмов резервного копирования, доступных в устройствах под управлением Android. Фрагментация платформы не позволяет рассмотреть все существующие способы и приложения, призванные облегчить резервное копирование и миграцию данных, но даже те, что были описаны, демонстрируют довольно жесткие ограничения как по совместимости, так и по полноте копируемых данных.
В целом наш вывод таков. Пользуешься «стоковым» Android? Включай облачную синхронизацию контактов и фотографий. Облачное резервное копирование может частично восстановить ранее установленные приложения, а если сильно повезет, то в отдельных приложениях могут частично восстановиться и какие-нибудь данные. Если на устройстве, с которого создавалась и на которое была восстановлена резервная копия, стоит Android 6.0 или выше, то из облака восстановится больше данных в сравнении с более старыми версиями Android.
[ad name=»Responbl»]
Встроенный механизм adb backup может помочь восстановить часть данных пользователям более старых версий Android. Сторонние приложения эффективны только при наличии прав root. Использование кастомного рекавери и создание Nandroid backup решит большую часть проблем, но доступен этот режим мизерному числу пользователей.
В результате система резервного копирования в Android получает от нас оценку «лучше, чем ничего». Превзойти Android по неудобству не смог никто: даже в старенькой Windows Phone 8 резервное копирование работает гораздо удачнее.
А как обстоят дела с резервным копированием у аутсайдеров рынка, телефонов под управлением мобильной версии Windows и BlackBerry 10? Об этом — в следующей статье!
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…
View Comments