Дисклеймер. Предметом статьи является восстановление достаточно старого смартфона — Alcatel POP3 4035D модели 2014 года на процессоре MTK6572 и с Андроидом 4.4.2. Для меня цели проекта были следующими:
Понять принципы работы линукс-подобных систем и устройств хранения информации
Получить телефон, в котором могут работать 2 сим-карты, на которые периодически приходят смс. Цели получить устройство, полноценно работающее в 2026 г, не было, да это и невозможно с таким железом
Закрыть гештальт: сломанный телефон лежал 10 лет, пока я набирался знаний, как его починить. Это одна из тех задач, которые откладываешь на «когда-нибудь потом», и вот это «потом» наступает.
Статья описывает процесс переноса операционной системы и большей части данных со встроенной памяти на MicroSD, при этом уделяется внимание подводным камням, с которыми можно столкнуться, и даются общие сведения об устройстве Андроида.
Предыстория
Итак, данный телефон был куплен в 2014 году, и проработав 2 года, сломался: однажды, находясь на зарядке, выключился. После этого попытки включения приводили лишь к лого и циклической перезагрузке. Можно было, впрочем, зайти в recovery, но это мало что давало: было написано что-то вроде «error mounting /system on mmcblk0p7». Я попытался восстановить его с помощью прошивки через SP Flash tool, но безрезультатно. Поизучав 4PDA, я пришел к выводу, что частично отказала встроенная память — eMMC. Частично, но не полностью: ведь работало как минимум recovery, т.е. это был не совсем кирпич. Тогда же появилась и идея восстановления: либо перенести операционную систему в неповрежденную область памяти, либо на внешнюю память (MicroSD), но знаний не хватало. Далее телефон был отложен до лучших времен, и вот в 2026 г, уже имея ИИ-помощника и статьи на похожие темы (например, вот), я принял решение попробовать еще раз.
Состояние телефона перед началом работ
К моменту, когда я впервые включил этот телефон после 10 лет, там не загорался экран, он не принимал зарядку (лампочка горела, но FNIRSI показывал околонулевой ток), и не работало recovery. Возможно, это результат неудачной последней прошивки. Но что важно: при подключении к ноутбуку в менеджере устройств Windows появлялась запись вида примерно «MediaTek preloader» с восклицательным знаком, и почти сразу исчезала. В некоторых статьях я видел, что это означает, что у нас уже «кирпич». На самом деле, если Windows таким образом определяет смартфон, это очень хорошо.
Тут нужно описать, как происходит загрузка Андроида. В упрощенном виде, так:
Т.е. телефон включается в режиме предзагрузчика (что-то вроде BIOS в IBM PC), и в этот момент появляется в Windows, затем передает управление загрузчику, который зависает или уходит в ребут. Но как минимум preloader работает, это значит, что часть памяти жива. И мы можем работать с телефоном, т.к. программы типа SP Flash Tool именно этот режим и требуют. Далее нужно просто поймать момент, пока preloader виден в диспетчере устройств, открыть его и обновить драйвер (я брал отсюда: MediaTek_Preloader_USB_VCOM_Drivers.zip). После установки драйвера всякое упоминание загрузчика и вообще телефона пропадает из диспетчера устройств — это нормально.
Следующий шаг — посмотреть, что происходит с памятью. Используем для этого SP Flash Tool. Чтобы правильно с ней работать, нужно понимать, как устроена память. Упрощая, скажем, что доступ к данным на eMMC, MicroSD и т.д. может быть организован разными способами, в зависимости от уровня взаимодействия «железа» и пользователя (от самого высокого к самому низкому):
Средствами операционной системы. Вы видите папки и файлы в проводнике или другом файловом менеджере.
По логическим адресам: это то, что делает линукс-команда «dd»: она читает/пишет сектора, но внутри логических разделов файловой системы.
По физическим адресам — это то, что делает SP Flash Tool. Для работы ей нужен так называемый scatter-файл—- это разметка памяти. Файл обычно находится в архиве прошивки (например, этого бекапа из видео). Имея scatter, программа знает, какую часть прошивки писать в какие сектора. А процессор знает, из каких секторов что читать.
Теперь разберемся с тем, как устроена eMMC на этом смартфоне. Как видно из архива прошивки, в ее состав входит несколько файлов. Часть из них процессор читает напрямую по физическим секторам (т.е. тем же методом, каким SP Tool их пишет). Это прежде всего preloader, boot и recovery. Часть (например, system.img, custpack2.img) это образы файловой системы. Грубо говоря, это посекторная копия раздела диска. Соответственно, если их записать на диск, то там появится файловая структура.
Почему для нас это важно? Потому что в самом начале мы видели, что recovery показывает проблему с mmcblk0p7 и другими разделами. Это значит, что нормальной файловой системы на памяти нет — поэтому и не грузится system. Но мы видели, что recovery грузится, а boot пытается грузиться. Это значит, что eMMC может отдавать данные в режиме чтения физических секторов, но не может в режиме ОС. Т.е. она не до конца мертвая.
Практический вывод, который мы можем из этого сделать: пускай то, что грузится по секторам, так и остается на внутренней памяти (а это всего-то по 20 М boot/recovery и 100 K предзагрузчика). А вот остальное мы перенесем на MicroSD - это 1,5 G system, custpack и т.д.
В SP Flash Tool есть режим чтения (Readback). В этом режиме я прочитал system и custpack по адресам из scatter’a. Затем посчитал хеш-коды того, что прочитано, и того, что в архиве прошивки, — они полностью совпали. Это значит, что eMMC может и читать, и писать большие объемы данных без ошибок.
А потом я через ADB посмотрел, какие вообще есть разделы (df -h, fdisk /mmcblk0). Оказалось, что есть в наличии mmcblk0 — блочное устройство (вся eMMC), разбитое на разделы mmcblk0boot0-mmcblk0boot1 и mmcblk0p1-mmcblk0p4. Разделов 5–9 нет, хотя мы видели, что recovery рассчитывает, что они должны быть. Разделы boot (не путать с boot.img) читаются без проблем. Разделы p1-p4 выдают I/O error при попытке в них перейти, а также при чтении с них командой dd.
Вывод: 8 мб (boot0-boot1) на памяти еще полностью живо (и я так понял, что живая часть совпала с обособленным разделом не случайно: эти 8 мб физически находятся в другой области NAND - по крайней мере, так считает Chat GPT), а остальные 3,7 гб - только в режиме чтения с физических адресов.
Вывод по структуре: объем памяти частично разбит на разделы, частично неструктурирован (по крайней мере, в смысле структуры разделов Линукса). В разделах находится, например, system, с которой загрузчик работает как с файлами. В неструктурированной части - сам загрузчик и предзагрузчик. У меня работает неструктурированная часть, но не работает структурированная.
Что осталось для меня непонятно: как это может быть, что по адресам читается, а файловую систему создать нельзя? Может быть, в комментариях напишут те, кто это знает более глубоко.
План восстановления
Итак, последовательность действий теперь понятна:
Создаем на флешке структуру разделов такую, как телефон ожидает увидеть на встроенной памяти
Меняем прошивку таким образом, чтобы загрузчик после запуска искал бы Андроид и все остальное на MicroSD
То, что оставляем на eMMC (boot.img, recovery.img), прошиваем как обычно через SP Flash Tool
То, что переносится на флешку, пишем на флешку вручную.
Что потребуется для работы
Основной компьютер у меня с Windows 10, так что в основном все описанное релевантно для него. Также необходим компьютер с линуксом и кардридер для MicroSD. В упоминавшейся выше статье в этом качестве используют рутованный телефон, но я так не пробовал. Что важно: теоретически можно использовать самого же пациента в режиме adb. Но я так пытался делать, и у меня не получилось (записанные образы не читались)
Шаг 1. Подготавливаем флешку
Сама операционная система состоит из 2 основных частей (system и custpack) и нескольких маленьких файлов и в сумме весит около 1,5 Г. Через adb и анализируя scatter можно понять, какая была структура на eMMC.
Как прошивать через SP Flash tool
Как было сказано выше, SP Flash tool работает с телефоном в режиме предзагрузчика, который необходимо "поймать". Во многих местах пишут, что для этого нужно "передергивать" аккумулятор или шить вообще без него. У меня это не понадобилось. Чтобы вывести телефон из циклического ребута (циклический ребут не затрагивает предзагрузчик, т.к. начинается с лого, которое идет после предзагрузчика. Таким образом, во время циклического ребута его поймать невозможно - нужно полностью выключать и начинать загрузку с нулевой отметки - с предзагрузчика), нужно 10-15 с держать кнопку включения. Первое время у меня это не срабатывало, но скорее всего были проблемы с батареей. Тогда да, ее нужно снимать и ставить обратно, пока телефон не начнет вести себя адекватно с точки зрения питания (принимать зарядку, выключаться кнопкой и т.д.). Не знаю, помогло ли, но я немного позаряжал батарею напрямую от 18650. К моменту начала работы на ней было 3,75В - этого достаточно Итак, схема работы 0. Ни в коем случае не прошиваем preloader!!! Сразу снимаем с него галочку (см. ниже) и всегда следим, чтобы она не стояла. Preloader у нас работает, а его изменение может превратить телефон в настоящий кирпич. 1. Загружаем в SP Flash tool scatter-файл 2. Ставим галочки только на тех частях прошивки, которые нам нужны. В данной статье это будет BOOTIMG и RECOVERY. Выбираем соответствующие img-файлы 3. Нажимаем Download. Программа начинает ждать телефон и делает это достаточно долго, т.е. спешка не требуется 4. Если в этот момент телефон не был подключен к ноутбуку - подключаем. Если был и SP Flash Tool после нескольких секунд не начал прошивку - зажимаем включение и ждем до тех пор, пока на телефоне не произойдут какие-нибудь изменения (мигнет лампочка питания, экран перестанет светиться черным и погаснет и т.д.) 5. Если все это не помогло, тогда крайняя мера: вытаскиваем батарею, ждем 10-15 с, вставляем и подключаем телефон к ноутбуку 6. После прошивки появится надпись "Download Ok", после этого отключаем телефон от ноутбука и включаем кнопкой;
Как заставить телефон работать с adb
Т.к. в начале у меня не работало даже recovery, то я начал с того, что прошил сразу более продвинутое. CWM у меня почему-то не заработало, а вот CTR - вполне. Скачал я его отсюда CTR recovery включает в себя поддержку adb Adb является частью пакета platform tools, я скачал его отсюда В Windows нужно открыть cmd в папке с файлом adb.exe и ввести adb shell - откроется некое подобие командной строки линукса, где "компьютер с линуксом" - это смартфон.
В adb shell введем cat /proc/dumchar_info Это выведет системную таблицу с перечнем частей прошивки, их адресами и размерами, а также разделами - теми, которые должны быть на eMMC. Эту таблицу мы отредактировать (поменяв разделы на флешку) не сможем - она генерируется ядром ОС. Но нам и не нужно: Андроид при нормальной работе берет эту информацию в других местах. Нас же сейчас интересуют размеры частей ОС и имена разделов: проще всего будет создать похожую структуру на флешке. Итак, мы видим следующее:
В некоторых строках указан не раздел, а все блочное устройство - mmcblk0. Это как раз те части прошивки, которые размещены в неразмеченной области памяти. Это у нас работает, так что оставляем. Нас интересуют разделы mmcblk0px и их размеры. Например, protect_f: a00000. Переводим в килобайты в шестнадцатиричном виде, путем деления на шестнадцатиричное число 400 (можно сделать в инженерном калькуляторе Windows), получаем Hex 2800, и калькулятор сразу отображает 10240 в десятичном виде. Это совпадает с размером файла protect_f из архива прошивки. Также видим, что с завода protect_f был на втором разделе. Делаем то же самое с остальными строками (учитываем, что строка “android” соответствует файлу прошивки system.img). ebr1 я пропустил: это таблица разделов, и для нашей схемы с флешкой это нерелевантно, хотя раздел на флешке под нее на всякий случай создал.
В принципе, можно было бы брать размеры из архива прошивки, но так будет дополнительная проверка. Плюс важный момент со строками usrdata и cache: таких файлов в прошивке нет, но нам нужно создать под них разделы на флешке. Это данные, которые создаются в процессе работы, а не часть прошивки. Здесь я немного поменял исходную модель, т.к. флешка у меня больше, чем встроенная память, а кэш быстро убивает флешку.
Из таблицы видно, что под usrdata отведено около 2 гб в p9, а под кэш 200 мб в p8. На флешке я раздел под кэш создавать не стал, а весь остаток места после p7 (на флешке он называется p8, но об этом ниже) отвел под data. Cache затем был смонтирован в папке в оперативной памяти. Как пишут в приведенной выше статье, линукс любит очень много писать на диск. Для флешки это губительно. Одно из мест, где идет много операций записи, - это кэш. Но его нет смысла сохранять между перезагрузками. Поэтому я отвел под него максимум 32 М в ОЗУ, но по факту еще ни разу не видел, чтобы он был больше 600 Кб. Дополнительный плюс: выиграли 200 М, которые в заводской архитектуре просто пропадали. В итоге получилась такая таблица:
(про алиасы будет чуть ниже).
Копируем архив (разархивированный из zip) на ноутбук с линуксом.
Через кардридер вставляем флешку в ноутбук с линуксом. В терминале запускаем
sudo lcblk- чтобы понять, как называется устройство флешки. Затемsudo fdisk /dev/sdc(у меня так определилось, но зависит от конкретного ноутбука/линукса). В fdisk командой d удаляем имеющиеся разделы, затем командой n создаем новые. Тут важный момент. Fdisk создает разделы в разметке MBR, и может создать максимум 3 primary и 1 extended (с томами внутри) - ну или 4 primary. Нам это не совсем подходит, т.к. тогда p1-p3 будут primary, а к томам extended можно будет обращаться как p5-p9 (т.к. p4 - это название extended раздела, с ним нельзя работать напрямую). Но у нас на eMMC нумерация была сквозная, и p4 это sec_ro. Теоретически, можно было бы сделать в разметке GPT (через parted), там число primary разделов неограниченное. Я так сначала и сделал, но телефон отказался их признавать. Противоречие (а почему тогда на eMMC были явно 9 primary, т.е. GPT) поиск в интернете объяснил переходной моделью в KitKat: на встроенной памяти поддерживатся GPT, на флешке нет. Это создает неудобства, но в принципе, работать с этим можно: в таблице выше видно, что нумерация разделов после p3 на флешке смещена на 1 против встроенной памяти.
Некоторые реализации fdisk оперируют размерами в цилиндрах, некоторые в секторах, некоторые в байтах/килобайтах. Поэтому не буду здесь писать конкретные цифры начала и конца каждого размера. Главное правило: раздел должен быть не меньше, чем размер части прошивки, которую мы в него поместим. В конце нажимаем w для сохранения. Можно еще раз запустить fdisk и выбрать p, чтобы посмотреть, что получилось. Иногда fdisk пишет, что устройство занято, в таких случаях придется перезагружаться.
Далее нужно отформатировать раздел p9, где будет usrdata (на компьютере он может называться sdc9, или как-то еще, но с цифрой 9 - это не страшно, телефон все равно назовет его mmcblk1p9). Для форматирования используем
make_ext4fs /dev/block/mmcblk1p1илиmke2fs -t ext4 /dev/block/mmcblk1p9Остальные разделы форматировать не надо — там файловая структура создастся после залития образов. Заливаем образы командами
dd if=/sdcard2/protect_f of=/dev/block/mmcblk1p2 bs=4M
dd if=/sdcard2/protect_s of=/dev/block/mmcblk1p3 bs=4M
dd if=/sdcard2/system.img of=/dev/block/mmcblk1p8 bs=4M
dd if=/sdcard2/secro.img of=/dev/block/mmcblk1p5 bs=4M
dd if=/sdcard2/mobile_info.img of=/dev/block/mmcblk1p7 bs=4M
dd if=/sdcard2/custpack2.img of=/dev/block/mmcblk1p6 bs=4M
(здесь вместо /sdcard2 будет путь к файлу на ноутбуке с линуксом, где выполняется работа, а /dev/block/mmcblk1px — название разделов флешки на нем же).
После этого можно смонтировать эти разделы и убедиться, что в них файлы и папки обычного андроида.
Шаг 2. Модифицируем прошивку
Как работать с образами прошивки
Как мы выяснили выше, файлы прошивки бывают 2 типов: с файловой системой внутри и неструктурированные. Нам сейчас нужно отредактировать как раз вторые: boot.img и recovery.img. Причем начать имеет смысл именно с recovery, но не с того, который в архиве прошивки (мы им пользоваться вообще не будем), а с CTR. Дело в том, что когда телефон в recovery (кастомном), то adb запускается с root-правами, что дает гораздо больше простора для отладки, если что-то пойдет не так. Итак, для редактирования нам нужно сначала распаковать эти образы. Для этого используем Carliv Image Kitchen, например отсюда) Интерфейс достаточно понятен. Распаковываем, редактируем, запаковываем. Выбираем опцию сохранить исходный размер. Имеет смысл создать где-нибудь рабочую копию распакованного образа, вносить правки там и потом уже запаковывать. Мне, впрочем, пришлось делать чуть сложнее: распаковывать, копировать из рабочей копии измененные файлы, потом опять запаковывать. Т.к. запаковывать несколько раз рабочую копию после каждой правки он не хотел.
Основные файлы, которые нам нужно поменять, называются (возможны вариации) %fstab% и %init%.rc. Первый (их может быть несколько, и менять нужно все) сообщает загрузчику, какие имеются разделы и что в них, второй (на самом деле, их несколько, и менять нужно тоже все) - это список команд при загрузке, среди них монтирование - его и нужно поменять. Тут отметим особенность моей прошивки - те самые алиасы. Указывать разделы можно по-разному. Есть абсолютный путь, например mmcblk1p1. В статьях про другие телефоны так и было. Но у меня окказалось иначе: в файлах конфигурации использовались обозначения типа emmc@system, emmc@custpack и т.д. Это алиасы. Т.е. где-то либо в предзагрузчике, либо в ядре загрузчика, либо вообще в прошивке процессора жестко зафиксирован меппинг, например, emmc@system = mmcblk0p7. Этот меппинг мы поменять не можем, поэтому первое действие - это пройтись по всем файлам конфигурации (они или сразу в каталоге ramdisk, или в ramdisk/etc) и меняем все эти алиасы на прямые пути. Файлы с уже поменянными значениями я выложил на гитхаб (там же оставил команды создания отладочных логов при загрузке; нужно отметить, что в файлах init предусмотрены варианты для разных файловых систем, в зависимости от модели телефона, т.к. в прошивках используется унифицированный блоки код для разных моделей. Так вот, я менял команды монтирования только для блока с ext4 - если на телефоне файловая система ubifs или yaffs, это будет необходимо поменять отдельно в соответствующих разделах). Следующее изменение: комментируем проверку и исправление ошибок в разделах - строки вида exec /sbin/e2fsck -p /emmc@cache exec /sbin/tune2fs
Я изначально комментировал на время отладки, но пока не было времени тестировать, как заработает после полного переноса ОС на флешку.
Соответствие алиасов и разделов можно установить по названиям: скажем, тот же emmc@system соответствует system.img (это понятно по имени алиаса), а system соответствует android из dumchar_info. Android там на mmcblk0p7, а на флешке у нас mmcblk1p8. Отсюда получаем новый меппинг: emmc@system = mmcblk1p8.
С cache ситуация немного отличается: мы решили его держать в ОЗУ и ограничить 32M, поэтому команда монтирования поменяется на mount tmpfs tmpfs /cache size=32m,mode=0050,uid=0,gid=1028
Помимо этого, имеет смысл сделать небольшой тюнинг других настроек: В default.prop делаем ro.debuggable=1
ro.adb.secure=0 и persist.sys.usb.config=mtp,adb sys.usb.config=mtp,adb
Первое должно помочь запускать adb с повышенными правами после нормальной загрузки (мне, впрочем, не помогло; видимо, надо поменять еще что-то). Второе — разрешить режим MTP при подключении к компьютеру. Есть одно маленькое упрощение, которое я сделал: в исходной системе на eMMC был еще FAT раздел, который и был доступен как хранилище. Он же отображался в проводнике Windows при выборе режима подключения телефона «Накопитель». Мы этот раздел объединили с usrdata — но это ext4, который Windows не понимает. Поэтому Windows сможет работать с телефоном как с накопителем только при выбранном режиме подключения MTP (передача файлов), а не накопитель (mass storage).
Что означает алиас emmc@custom, я не нашел, поэтому просто вообще закомментировал монтирование — на работоспособность это не повлияло.
Шаг 3. Прошиваем модифицированный firmware
Тут все просто: шьем 2 файла: boot.img и CTRv3_3_AlcatelPop_D3.img (после сборки измененных образов) через SP Flash Tool. Отключаем телефон от ноутбука и запускаем сначала в режиме recovery.
Recovery будет ругаться на невозможность записать в кэш лог, но это нормально. Recovery нам нужен, чтобы сделать последнее дополнение: создать папку для загрузок. Для этого либо в recovery выбираем Mount data, либо делаем это через adb. Затем mkdir /data/media/Download chmod 0775 /data/media/Download chown media_rw:media_rw /data/media/Download
Это создает папку “Загрузки” для файлового менеджера и Chrome. Кстати, максимальная версия Chrome, которую можно установить, это 81. Файловый менеджер у меня заработал версии 1.75
Затем загружаемся в обычном режиме. Если все ок, первый запуск займет минут 5-10.
Шаг 4. Что получили в итоге
Телефон загрузился. Несмотря на опасения, что он будет тормозить (MicroSD по определению гораздо медленнее, чем eMMC), я особых лагов не наблюдаю. Телефон теперь считает, что то, что у него на плате (неисправная eMMC), — это убитая флешка, которую в него вставили, и предлагает ее отформатировать (я пока не пробовал, т.к. не совсем понимаю, что он собирается форматировать: там даже разделы толком не созданы. Как бы он не отформатировал участок с предзагрузчиком). Файловый менеджер считает, что то, что физически вставлено как флешка, — это внутренняя память. Сим-карты прекрасно заработали, смс приходят — это мне и было нужно. К Wifi подключается. В целом, все функции телефона работают. Единственно, пока так и не смог заставить его авторизоваться в Google, хотя на сайте они декларируют поддержку Android 4.x.
Ни одно из старых приложений 2015 г, которое требует интернета, не заработало, даже Википедия.
По сравнению с заводской архитектурой, присутствует ряд улучшений:
Выиграл 200 Мб за счет переноса кэша в ОЗУ и ограничения его размера
Флешка 7,4 Гб, из них для приложений/данных доступно 6. На eMMC было 2, но суть не в этом: при работе с eMMC можно было при ее исчерпании вставить флешку, это да. Но большинство приложений на флешку не устанавливались. А сейчас флешка — это как бы внутренняя память, и все устанавливается без проблем.
Я в любой момент могу вынуть флешку, вставить в ноутбук и отредактировать систему как хочу: мне не надо его рутовать для этого. Например, в пару кликов могу удалить предустановленные игры. И вместо них закинуть нужные мне приложения. Причем это не займет места в доступных мне 6 пользовательских Гб, т.к. будет считаться частью прошивки.
