[1.]
Сеть слетает из-за того, что у Qualcomm даже в референсном дизайне EFS шифруется (может шифроваться) с помощью "аппаратных" ключей. В референсе (и близких к нему китайских телах, равно как и в большинстве "брендовых") IMEI, многие другие ID, уникальные настройки радиотракта ("модема") хранятся в NVRAM. NVRAM хранится в Qualcomm EFS (не путать с Windows EFS, другими "EFS" и даже с "некоторыми Samsung EFS", которые тупо хранят NVRAM в рамках ФС телефона). EFS практически всегда шифруется (видел редчайшие случаи "НЕ шифрования"). Метод шифрования практически всегда кастомизируется ОЕМами, в т.ч. даже "дремучими китами". Другое дело, что на практике, скорее всего, "кастомизация" заключается в переносе места хранения ключей (доказать не могу но подозреваю ). Из практики известно 2 основных варианта поведения телефона в отношении шифрованных данных EFS (но, теоретически, могут быть и иные):
1. Ключи шифрования статичны для всех экземпляров, либо хранятся где-то вместе с EFS, на тех же разделах. Обычно это ModemST1, ModemST2 и FSG (последний изначально был задуман как бакап для инициализации EFS без ID, но, на практике, часто вообще не используется даже если содержит данные, зато могут быть иные, "кастомные", разделы с необходимыми данными, но я не припомню чтобы они являлись частью EFS). В этом случае шифрованные разделы можно легко перенести на другой экземпляр устройства (бывают исключения связанные, например, с различием прошивок модема).
2. Ключи шифрования индивидуальны и хранятся в проце в соответствии с референсным дизайном. Qualcomm продумал ситуацию с переносом EFS/NVRAM "в сборе", соотв вместе с IMEI-ями MAC-ами итп. Для этого и предусмотрел данную меру противодействия. Однако киты и иные "простые" производители зачастую не хотят с этим заморачиваться. Это усложняет конструкцию и обслуживание, иногда требует выдачи какого-то "секретного" софта для работы с кастомным EFS/NVRAM в ОСЦ, откуда оно может утечь. В конце концов, проще обычно = лучше, надежнее, а исключения редки.
В случае, если ключи шифрования EFS хранятся в процессоре, перенос разделов ModemSTx (и FSG) становится невозможным. Разделы просто не будут расшифрованы фирмвером модема по причине отсутствия корректных ключей шифрования, данные модема (NVRAM) не будут считаны, модем не будет инициализирован. Возможна ситуация, что модем посчитает EFS поврежденной и переинициализирует ее с заполнением NVRAM дефолтными значениями. Так или иначе, IMEI-и, иные ID, какие-то еще данные и настройки окажутся не прописанными, связь будет отсутствовать. Выявить такое поведение (переинициализацию) можно сравнив залитые образы EFS со слитыми после первого же старта (На фоне отсутствия IMEI и связи. В случае успешной расшифровки EFS, фирмвер модема будет с ним работать и данные также будут тотально изменены, будут "все байты разные", поскольку шифрование блочное, а фирмвер постоянно пишет в EFS при работе.)

Скорее всего, именно второй вариант реализован в этом Asus A500KL.

Иные варианты ("кастомизации") могут включать такой интересный вариант, как хранение ключей шифрования в "скрытой" области еММС, либо использование в качестве ключа ID самой еММС (или его деривативов - например, CID может использоваться как основа ключа или "соль" или еще как-то). В этом случае, после замены еММС ключи шифрования EFS невозможно будет корректно восстановить, соотв расшифровать EFS, даже если процессор стоит "старый" и данные модема перенесены корректно со старой еММС.

Рассуждения такого плана отнюдь не беспочвенны. Многие аппараты уже давно используют CID eMMC как основу для генерации "всем известного" Android Serial Number (именно он невозбранно уходит "Гугле" и к разным другим "вендорам", позволяя безошибочоно идентифицировать конкретный девайс и отслеживать его, пока "мир ведет борьбу" с идентификацией по IMEI, который постепенно стал менее надежным идентификатором в силу повышенного внимания к нему еще со старых времен (его часто меняют, как умышленно "те кому надо", так не умышленно - при сбоях, при ремонте). Serial Number привлекает мало внимания, поск "и без него работает", а его жесткая привязка к аппаратным ресурсам явно намекает на его значимость в глазах "Гугли" (и ББ, соответственно) в качестве средства идентификации пользователей и слежки за ними. В условиях, когда большая часть трафика, идет через интернет, большая его часть и почти весь, содержащий "персональные данные" шифруются, остается немного смысла в отслеживании по IMEI, зато сильно возростает роль других идентфикаторов, спользуемых пользователями (их оборудованием) для коммуникации с конечными сервисами более высокого уровня (они становятся "узким местом", где легко "рыбу ловить"). Я самолично потерял не один день за реверсингом скриптов инициализации, а оттуда - на анализ загрузчиков, чтобы, внезапно, выяснить, что Serial Number есть ничто иное как eMMC CID (его часть или дериватив), который просто так не перешьешь (нужно править фирмвер еММС), хотя можно поменять скрипты инициализации или даже бинарный код ABoot-а и назначать произвольные номера, даже "рэндомные".

В целом же, исходя из информации, просачивающейся через многочисленные "утечки", такие, как документы Сноудена и др., а также по результатам аналитики, "следящие" используют "многофакторную идентификацию", собирая любые "протекающие" ID и иные "признаки" (в т.ч. ключевые слова итп), над которыми соответствующий софт выполняют вероятностный анализ. Уйти от такой слежки, если она НЕ персональная можно и не оч сложно, если понимать, как она работает. От "персональной" уйти очень сложно, придется почти полностью отказаться от средств коммуникаций или сильно осложнить личные правила их использования (и в пассивном, и в активном режиме).

Исходя из этого, следует заметить, что такое решение, как использование CID в качестве основы ключей шифрования EFS напрашивается и оно оч простое, ибо процедуры работы с еММС и CID в частности доступны уже на самых ранних этапах работы загрузчиков. Я в эту сторону думал пока не прочел пост BiNaRs. Пост BiNaRs полностью исключает такую возможность. Если бы ключи хоть как-то были привязаны к еММС, ни у одного чела не расшифровался бы EFS, соотв IMEI итп не могли бы быть считаны и показаны после прошивки. "Кастомизация фирмвера еММС и хранение ключей там в виде отдельный "секретных" структур также возможны, но значительно осложняет и удорожает разарботку (требуется дописывать и отлаживать значительные объемы низкоуровневого кода в фирмвер еММС и в загрузчики), снижает надежность и ремонтопригодность и удорожает производство конечной продукции.

[2.]
Что касается еММС, ВЫПАЯННЫХ из Samsung. На другом форуме (не помню топик) человек писал по аналогичной теме, что еММС в Samsung имеют кастомизированную разбивку/фирмвер, посему могут НЕ работать в аппаратах других производителей. Зависание еММС (отсутствие ответа от нее в пределах таймаута) "квалифицируется" аппаратом (PBL) как фатальный сбой. В такой ситуации PBL считать с еММС ничего не сможет, соотв вывалится в QDLoader 9008 как единственный доступный режим. Аналогичное поведение наблюдается и при полной гибели еММС, либо при "бэдах" в обастях GPT либо SBL/RPM/TZ. В любом случае, SBL не может быть загружен, соотв PBL вываливается в режим QDLoader 9008.

Если SBL загрузить удается и он корректен (в т.ч. подписи сходятся, там где они применены и проверяются перед запуском) - управление отдается SBL и аппарат в 9008 уже не вывалится, кроме как в случае, если SBL сам вернет его в PBL по каким-то причинам. SBL, если ему удалось загрузиться и стартовать, пытается грузить ABoot, который, далее, грузит систему или Recovery и тп. Если он не может найти что грузить, либо стоит соотв флаг (в памяти, или на флеши, или на порту процессора, напр нажаты соотв кнопки или еще что-то...), SBL вываливается в 9006 HS-USB Downloader, он же DM (Download Mode), он же "eMMC наружу", если таковой режим реализован в SBL (не заблокирован, не вырезан из кода унылыми ОЕМ-кастомизаторами), после чего вся еММС определяется как "флешка" с "непонятными" разделами (Windows не опознает их, "хочет" инициализировать, чего делать никак нельзя, Linux видит разделы ExtFS) и можно сливать заливать любые данные/разделы/еММС целиком средствами работу с стандартными и нестандартными разделами на любых носителях для соответствующей ОС.

Для обеспечения входа в режим 9006 необходимо и достаточно (в общем случае) наличия GPT и корретно прописанных в ней SBL/RPM/TZ (собственно это все, что включено в MSImage для конкретного аппарата, в нете есть инструкции по его "ручной" сборке для конкретного устройства). В "аварийном" режиме (чего-то не хватает для дальнейшей загрузки) SBL сам вывалится в 9006. В остальнызх случаяых требуется приндудительно его загонять (зная как).

Вчера читал на 4PDA, что выход в режим 9006 ("еММС наружу") точно реализован в данном аппарате. Есть ли "вход по кнопкам" не нашел, но где-то на 4PDA (пока не нашел), по свидетельству некоторых участников, лежит запатченный ABoot, который принудительно загоняет A500KL в режим 9006 (если его прошить и перезагрузить аппарат чтобы код ABoot получил управление. Позже, когда вся еММС доступна на чтение/запись, понятно, что особых проблем вернуть оригинальный ABoot и восстановить стандартную загрузку проблем не составляет, (по крайней мере для тех, кто ориентируется в общих методах чтения записи разделов целиком на любых, стандартно разбитых в GPT, носителях).

Процедура вывода из 9008 в 9006 (необходимая, когда нормальная загрузка SBL нарушена) с последующей переразбивкой и проливкой разделов на еММС заключается в "засылании" процессору в 9008 соотв "загрузчиков" (xPRGxxxx).hex/mbn) в память и запуск их там (по протоколу Sahara или Firehose - не знаю какие поддерживает A500KL). Следом загрузчикам засылается короткий образ (MSImage), содержащий "обрезанную" GPT, SBL/RPM/TZ (либо иной набор SBL-related, например, SBL1/SBL2/SBL3/RPM/TZ итп) пригодный для данного аппарата. Первый загрузчик перезаписывает начало еММС засланным MSImage (без заголовка). Оный набор после перезагрузки позволяет загнать аппарат в 9006 ("еММС наружу") и залить всю прошивку, в т.ч. с переразбивкой GPT "под все разделы" (а не только указанные SBL-related). Заливка обычно происходит с помощью XML-таблиц для QPST/QFIL (типа RawProgram0.xml), питон-скриптов, ехе-шников или иных "плюшек" разработанных ОЕМ-ом, но суть сводится к записи нужных образов на нужные сектора "флешки".

Следует понимать, что при заливке MSImage, оригинальная GPT, если она сохранилась при сбое, будет утрачена (заменена "короткой"). При наличии "заводской прошивки это не проблема, поск вся информация для переразбивки есть в наличии (равно как и скрипт ее автоматической проливки). В нашем случае "ничего нет". Оригинальную GPT, обычно, нужно искать "около" конца носителя, в последних секторах, за концом последнего раздела. По стандарту разбиения GPT копия должна храниться там, но она может быть бинарно отличной от той, что нужна в начало. Поэтому следует "выдрать" оттуда всю информацию по разделам и прописать ее неким редактором GPT в первую копию, а не пытаться переливать бинарную копию GPT-Backup целиком в начало. Именно в данной модели A500KL в фулле я обнаружил 3 раздела AsusGPT, AsusGPT1, AsusGPT2, явно содержащих данные о разбивке. Насколько формат соответствует бинарному представлению GPT не уточнял. Отдаленно напоминает. Какова потребность в этих разделах тоже сказать не могу. Могу лишь предположить, что Asus подставляет данные оттуда взамен оригинальной GPT (чтобы что-то скрыть), но это, всего лишь, аналитическое предположение ничем не подеркпленное.

Именно в нашем случае дело сильно облегчается большим количеством фуллов, имеющих хождение по форумам. Пытаться выдрать оригинальную GPT и образы поврежденных разделов можно оттуда.
В большинстве случаев GPT, как и разбивка еММС остается статичной на все время выпуска аппарата и обновлений к нему. Но бывают и исключения, когда крупные обновления (например при переходе на новую мажорную версию Android) требуют переразбивки еММС с иным распределением места. (Про кастомы я уже и не говорю). В этом случае меняется GPT и сдвигается расположение некоторых или даже всех разделов. При работе с аппаратом с "неизвестной прошивкой" следует визуально контролировать корректность данных на разделах после восстановления GPT. В случае расхождений искать годную GPT или вносить коррективы вручную.

Но, причиной "внезапного застревания" в 9008, может быть, и "программная засада". Год назад и позже я рыл аппарат Micromax Q415 (аппарат, кстати, был весьма оригинально "защищен" по вопросу SIM-лока), на 4pda и GsmForum-е много моих статей по теме) и столкнулся с интересной "фичей" (как и многие пользователи после меня и по моим инструкциям). При сливе фулла средствами аппарата (Linux-а) по командам dd if=... of=... все сливается, вроде бы, корректно. При заливе обратно ПО РАЗДЕЛАМ (восстанавливать SBL-related не пробовал, нужды не было а риск проблем, потерь времени - был), тоже все восстанавливалось на ура. Но при попытке залить обратно фулл, т.е. образ всей еММС начиная с GPT (с помощью все тех же команд dd if=... of=...), аппарат без ошибок все заливал, но после ребута вываливался в 9008 без вариантов и даже шиться не хотел имеющейся "заводской" прошивкой (с rawprogram, hex/mbn, MSImage итп в комплекте). Помогала только активация тестпоинта по заводской инструкции, после чего аппарат "впадал" во все тот же 9008, но прошивался уже на ура. Когда у меня упал я списал это на "глюк" или собственную неточность. Поэтому найти затык в свое время не удалось. Какие места не читаются или не пишутся так и осталось загадкой. Потом аппарат отдал и больше к этому не возвращался. Позже пользователи неоднократно жаловались на аналогичные проблемы. Но, надо понимать, что там процесс чтения-записи шел "под контролем" аппарата и запросы на чтение-запись каких то секторов могли перехватываться системой и блокироваться. При чтении-записи еММС в программаторе "устроить подляну" можно только средствами фирмвера еММС, а это сложно-мудрено и мало кто с этим заморачивается, хотя известны случаи "в виде подлян HTC" (фирмвер блокировал запись любых загрузчиков, и даже Recovery/System в еММС, что вызвало фатальные проблемы с рутованием/кастомизацией и сильное бурление г...). Другой пример - кастомизаця фирмвера Samsung-ов.

С программной т.з., подозреваю, что проблема возникала из-за некорректного считывания или записи какой-то области (скорее всего вне разделов, либо в одном из разделов sbl-related). Порча данных в ней приводила либо к "нервной" реакции PBL, либо к вылету SBL обратно в PBL каким-то образом, тогда как тестпоинт, скорее всего активирует "масочный" PBL в проце (или какой-то его режим, или блокирует какой-то "висючий" код). Все это лишь предположения, хотя и не лишенные смысла, но, исходя из наличия "других подлян" подозреваю умышленное вмешательство производителя.

Относительно "повреждаемой структуры" (т.е. что так сильно "не нравится" аппарату в лице PBL/SBL, что он "впадает в 9008) - скорее всего речь о флажке (структуре) "защиты бутлоудера", которую из моего опыта часто прячут в "неразмеченных" областях либо в одном из "мелких разделов в начале еММС. На этом Asus-е, например, "флажок бутлоудера" "спрятан" в "неиспользуемом" конце раздела ABoot (это раздел "с кодом", не "с данными", и "так не принято" (традиционно) в области "прошивкописательства", но вот так "намутил" производитель. Сам ABoot (его код) "крохотный", а раздел аж 5МБ, конец пустует, в середине есть еще какие-то данные). Кому интересно, однобайтовый флажок лежит по смещению 004FFE10. 00=Locked, 01=Unlocked, размер раздела и, соотв, имиджа для контроля 5242880 байт. Эта информация была выложена и проверена владельцами данной модели Асуса на 4PDA, в виде "лоченого" и "не лоченого" ABoot-ов, лежащих "бок о бок", которые я нашел и сравнил банально FC. В инструкции автор указал, что для UnLock/ReLock Bootloader достаточно залить соответствующий образ ABoot и перезагрузить аппарат. Завялено, что, в отличие от разлочки заводской утилитой, данные в Asus не отсылаются и обновления OTA продолжают приходить (в противном случае - нет). Ссылка на данную инструкцию с аттачами есть в шапке топика на 4PDA.

Возвращаясь к проблемам с заменой еММС, может статься, что полная проливка уже переразбитой еММС "основной" прошивкой (для другого тела) приводит к попытке записи на какой-то "мелкий блок", где у Samsung-а лежит раздел с "критичным секретом" (напр вся та же унылая блокировка бутлоудера, с которой все ОЕМы трясутся как с писанной торбой), а "заказной" фирмыер еММС для Samsung может "гадить" (блокировать еММС или затирать GPT, еще что-то, вследствие такой попытки). Кто возился с самими этими Samsung-ами, с которых впоследствии выпаивали эти еММС - вспомните, не числится ли за ними подобное поведение в каких-то ситуациях, связанных с попытками записи "секретных" разделов/блоков/секторов. Ранее (неск лет назад) мне встречалось подобное поведение у старых Samsung-ов, когда они "падали" с "черным экраном" после попыток криво снять лок бутлоудера "народными средствами". Уже не помню подробностей, но тогда кастомизацией фирмвера еММС еще никто не "баловался". Позже, "крутую заЩИТу" могли перенести в фирмвер еММС, "украв" копро-идею у HTC.

ОЕМы могут кастмоить референс как душе угодно, соотв., может проявляться самое разное поведение "конечных устройств". Тут нужны базовые знания, статистика и четкий анализ, методом исключения в т.ч. Кто будет копать данный аппарат - почитайте, подумайте, выполните соотв. эксперименты и опубликуйте свои выводы "не пожалев букОв" (чтобы коллегам было понятно и они подхватили и дополнили).


Резюме (предварительное):
1. Не надо пытаться менять еММС в этом аппарате на снятые с Samsung-ов - с высокой вероятностью будут проблемы, много аналогичных далоб на разных форумах и большинство "пострадавших" перепаивало еММС с Samsung-ов. Не забываем, что у кого "все ОК", чаще всего, просто молчат и переключаются на другие дела, даже не ищут обсуждение подобных проблем и не знаю об их существовании.

2. Не всегда вылет в 9008 свидетельствует о гибели еММС. Если есть сомнения, попробуйте хотяб протестировать родную программатором. У меня этих программаторов нет, посему я не советчик тут.
3. Надо усиленно искать заводскую прошивку и/или оригинальные загрузчики типа MPRG8926.hex/mbn и MSImage для заливки заводской из режима QDLoader 9008 (т.е. чз PBL) с помошью QPST/QFIL, иных инструментов для Qualcomm. Кто имеет доступ "к телу" не пожлобьтесь плиз, выложите заводскую и/или иные "материалы", необходимые для ремонта и разработки. Выпаивание еММС гиморный и рискованный вариант и должно практиковаться лишь в случае гибели еММС. На 4PDA люди пробовали загрузчик MPRG8926 от Highscreen Spider, но результата не добились. что мешает, несовместимость загрузчика либо необходимость "шаманских действий" (Test Point?) я не знаю (как, видимо, и никто пока не знает, кроме производителя/ОСЦ).
4. Необходимо переливать образы оригинальных разделов ModemST1/ModemST2, возможно каких-то еще кастомных (не обязательно модемных, могут глючить иные компоненты, аппарат нифига не раскопан). В противном случае будут утрачены данные NVRAM вместе с IMEI-ями и НЕ будет связи. Заливка донорских разделов проблему НЕ решает! Метода заливки бакапов QCN пока нет.
5. Крайне необходимо научиться активировать Diag порт (Qualcomm HS-USB Diagnostics) и сливать-заливать NVRAM средствами QPST. Это позволит восстанавливаться "из любого положения" (в плане порчи данных модема) с помощью донорских QCN образов. Поправить IMEI в образе на родной обычно "дело техники". Также не извстно не заблокирована/кастомизирована ли работа по диагностическому протоколу Qualcomm (такое практиковал Samsung в некоторых моделях, за что убить мало, так что, не дай бог).

========================================================================

Дополнительная информация:
Как перенести данные модема (EFS/NVRAM/ModemSTx)
Рекомендуется вообще всегда сливать фулл и образы отдельных разделов даже если прошивка повреждена. Редко бывает такое чтобы "повредилось все". Обычно, почти все данные целы, а повреждена незначительная часть, хотя без нее не работает. В случае проблем можно пытаться "дергать" данные из битого фулла и "подкладывать" их в рабочий.
Найти данные модема (EFS/NVRAM = ModemSTx) можно в фулле с помощью DMDE или R-Studio. Довольно легко если уцелела GPT. Если GPT повреждена, то неск сложнее. Либо нужно будет вписать GPT (34 сектора) в начало образа (взяв из чужого фулла, восстановив из бакапа в конце еММС), либо просто поискать нужные структуры по известным смещениям. В частности, ModemST1 лежит в LBA: 231424-234495, ModemST2 - в LBA:234496-237567, FSG - в LBA:262144-265215. Примитивно убедиться, что Вы нашли то что нужно, можно "усмотрев" текстовую сигнатуру IMGEFS1/IMGEFS2/IMGEFS-SIGNED_IMAGE в самом начале соотв. разделов. Кто будет работать с "однофайловым" фуллом, со смещениями в HexEditor-е, не забываем, что "стандартный" сектор содержит 512 = 200h байт, соотв, чтобы найти в образе, например, ModemST1 нужно перейти на смещение 231424*512=118489088 байт = 7100000h байт. Информация легко вытащена из фулла размером 39МБ (распакованный 470МБ) взятого тут: http://www.mobile-files.com/forum/sh...=1#post2552615 Сливал Radiotrance.
Вот полная таблица разделов, вытащенная с помощью DMDE и слегка поправленная (DMDE почему-то не разпознает НАЗВАНИЯ гнекоторых разделов, хотя они прописаны в GPT).
"Опытный глаз" сразу увидит кучу "кастомных разделов" в табличке. Разобраться с их назначением до сих пор толком никто не удосужился. Какие еще "подляны" там скрываются одному Богу известно, наряду с копро-разрабами всех этих теплых-ламповых девайсов.

Выдрал из телефонии кучку кодов дайлера. попробовать не на чем. Кто будет пробовать-играться, заблаговременно сделайте бакап ВСЕГО (в т.ч. фулл).
Список может быть НЕ полный!
Какие-то действия должны давать доступ к Diag порту модема. Нередко необходимый функционал "прячут под коды". Так было, к примеру, и с Q415. Порыв основательно дайлер и телефонию я вытряхнул оттуда все звездно-решетчатое г. В результате код активации полной композиции (с Diag впридачу) был найден, равно как и код "обратного преобразования", равно как и код доступа к меню сброса копро-настроек копро-Гугла (что, однако, выяснилось лишь через неск месяцев, поск на "готовый код" никто даже внимания не обратил, включая меня самого).

Asus, как и многие производители скрывает значимые части прошивки, выложив "для отмазки" исходники ядра на своем сайте. Лицензия на linux и иные компоненты подразумевает открытие всех деривативов без исключения и достаточного количества даже "явной пропрайетарщины", необходимого для дальнейшей разработки. Без загрузчиков, простите, невозможно не только разрабатывать, но и прошить устройство упавшее по причине порчи данных, их исходники явно подлежат открытию, поск linux является явно основной и "львиной" частью ПО аппарата, а отсутствие даже бинарников иначе как издевательстом назвать сложно. Ежу понятно, что при разработке ядра аппарат будет "100 раз" падать, и что, после этого, его даже восстановить будет невозможно, каждый раз покупая новый или отправляя в АСЦ "на ремонт". Абсурд полный. "Бизнес" тупо и нагло обобрал опенсурсников, потретивших 20 лет бесплатного труда на разработку linux и кучи иных компонентов, равно как обобрал и всех иных, ремонтников, потребителей, любых иных лиц, имеющих отношение к теме, страдающих от "выкручивания рук" и невозможности самостоятельно или с чьей-то помощью чинить, "допиливать" и менять софт так, как они хотят и могут. Если Qualcomm с Asus-ом так рьяно держатся за исходники своих загрузчиков и иного теплого-лампового УГ, то они могут отказаться от использования Linux и предлагаить свои загрузчики в рамках иных "готовых продуктов", например на WinPhone, вопрос лишь в том, кто это купит... А коль скоро они "снимают сливки" с бесплатного Linux-а, или даже бесплатного Android-а, то путь будут любезны, как минимум, не создавать проблемы тем на чеьм труде они очень жирно кормятся.


Update: поглядел другой архив с фуллом. Фулл оказался тот же, но в архиве есть еще логи и образы ROM2/ROM3 и, что примечательно, они абсолютно пустые. Если это не результат какого либо сбоя, то вывод один - у данного аппарата нет кастомного PBL и используется только масочный из CPU. Масочный, скорее, должен быть стандартным, но, по словам известного исследователя "всяких Qualcomm-ов", VVE, процессоры для разных устройств часто бывают "сами кастомные". В чем выражаются отличия маэстро не уточнял, упомянув лишь, что код загрузчиков часто не работает "между" соседними моделями на одном и том же проце (которых, на самом деле, может быть много разновидностей, по его словам). VVE - человек, безусловно, авторитетный, но логика выходит весьма странная. Сейчас везде все стараются все унифицировать, чтобы упростить и снизить издержки. Процы от Qualcomm, как известно, имеют немало QFuses, призванных определять внутреннюю конфигурацию SoC. Возможно дело в них. "Масочное" ПЗУ, на деле, тоже, скорее всего, яляется чем-то вроде EEPROM или NOR, просто интерфейс по записи хранить будут как зеницу ока, поскольку утекание грозит огромными убытками, если, например, вирус начнет "уничтожать процы пачками". Но даже в этом случае стандартный PBL более вероятен нежели кастомный, просто потому, что это проще и меньше издержек на разработку, производство и поддержку, м меньше риск убытков из-за непредвиденных ошибок.
P.S. Сорри за очепятки, нет сил более их искать-править.

С лока MMX Q415 тоже можно было "что-то заработать" (оценка до 1мр), но в итоге инфа была опубликована во фри к радости сообщества. В свою очередь я бы ничего не опубликовал и сидел бы с "дохлым 415" по сей день, если бы добрые люди сначала не поделились, а потом не опуболиковали для всех заводскую прошивку с необходимыми для восстановления загрузчиками и описанием процесса, в т.ч. указанием Test Point-а, за что я им весьма признателен. Все взаимосвязано в этом мире. Я вот копейки на этом не заработал, даже в "минус" ушел, подарив свой экземпляр другу для дочки-школьницы, а кто-то потом зарабатывал по 100тр и жаловался на отсутствие автоматизации метода... Но я не в обиде - люди делают свою работу для конкретных клиентов (которые сами "вникать не хотят"), трудятся и довольно долго и упорно, почему бы им не заработать. Все честно.

Я и до того и после не раз указывал, что бояться "потерять работу" не нужно. Лишь единицы процентов потребителей сами способны и чинят свою электронику. Чем более раскопан аппарат, тем более он будет популярен (если не Г откровенное, конечно или не переоценен) и больше будет клиентов на ремонт. Чем более раскопан аппарат, тем быстрее и легче его чинить. Чем более раскопан аппарат, тем легче он "прощает" допущенные ошибки. Когда вся инфа есть - сядет спец, разберется, что он накосячил и за час сделает, поск все ресурсы есть и "белых пятен" не осталось, тогда как в противном случае можно потерять неделю и долго объясняться с клиентом на тему "почему полурабочий аппарат стал совсем не рабочим", а то и убытки возмещать. Платить "оч. много" зя "оч. долгую работу" все равно никто не станет. Пойдут новый купят, уже 100 раз сталкивались...

Исключения крайне редки. Держать в секрете имеет смысл какую-то совсем уж "узкую" информацию по значимым вопросам о СВОИХ разработках (ну или доверенных), которую оч трудно найти или раскопать. Какие нибудь прошивки для "боксов" или софт к ним, информацию о мудреных локах, которые оч трудно снять, и то, только при наличии желания и четкой перспективы на этом заработать. У нас с другом были когда-то "секреты" по своим наработкам (в тч, прошивки для процов на опред. тему), которые можно было опубликовать, может с задержкой, и получить "удовольствие от общения" и "славу", но вот вовремя не опубликовали, заработали "3коп" на этом, а по прошествии неск лет оно никому не нужно, поск "техника шагнула вперед". Может, если бы вовремя опубликовали, интерес к теме был бы выше и заработали бы больше. Все равно разводить плату, паять проц и обвес, прошивать, ни один пользователь не станет! "Конкуренты", наоборот, привлекали бы интерес к теме, особенно, когда "своих ресурсов два человека". В самое приятное во всей это идеологии, что "все по доброму". Не надо никому ничего "впаривать" и доказывать что ты не верблюд. Не нравится что-то - бери информацию и иди сам делай. Тебя никто не ограничивает. Когда у челоека есть выбор, то и отвественность за него он берет на себя. Когда выбора нет, он мучается чувством что его вынудили что-то делать. Другой момент в том, что обладая информацией, попытавшись разобраться, человек может оценить степень сложности и трудоемкости задачи, тогда как "будучи в неведении", обычно полагает, что "все просто" и надо лишь "нопку нажать" и "3 руб заплатить", привыкши покупать сложные приборы в магазине по бросовым ценам массового производства.

Diag-порт-интерфейс там есть, просто в дефолтной композиции он выключен (99.999999%). Иначе производитель (и ОСЦ) сам не смог бы заливать NVRAM. Производители НЕ работают с шифрованными даннми "неким своим софтом". Шифрованием занимается фирмвер модема "на лету". На заводе, точно также как и в любом СЦ, специальный софт загоняет данные NVRAM через Diag порт, причем, скорее всего, в процессе калибровки конкретного экземпляра на RF стенде. Именно поэтому ни в каких "заводских прошивках", даже в "самых открытых", от китайских телефонов, Вы не найдете образов разделов с EFS/NVRAM. Вместо этого для ОСЦ может быть приложен QCN файл с дефолтным NVRAM (в т.ч. без прописанных IMEI). См. в квчестве примера прошивки от того же Q415, аппаратов HighScreen (Innos) итп. Изредка, для некоторых китайских аппаратов производители распространяют пропрайетарные утилиты для прописывания ID (IMEI/MAC/Serial/etc). Но обычно такого не найдешь, наверное потому, что соотв ПО на зводе производителя заточено под работу исключительно с аппаратурой стенда и без него не работает. Порт, тоже, не зря называется Diag. По идее производителя - это диагностический порт, а не "порт для записи NVRAM" или "каких-то там разделов". NVRAM - это всего лишь область для записи уникальных настроек RF части аппарата по результатам дисгностики/тестирования, а не какой-то "секретный раздел", как было задумано изначально. Вспомним, что первые телефоны имели физический EEPROM для хранения NVRAM, а само понятие NVRAM в переводе означает лишь "энергонезависимая память", предназначенная для хранения перманентных настроек и названа так только чтобы отличать соотв адресное пространство процессора от остальной, энергоЗависимой памяти. Позже NVRAM переехал в "основную флеш" исключительно с целью экономии "копеечки" на производстве каждого экземпляра устройства (в карман топам, конечно, и как всегда, поскольку в течение более 10 лет себестоимость мобильников в разы и десятки раз отличалась от их конечной цены).

"Секреты" там появились отноюдь не в силу технической необходимости, а в силу стремления ББ лезть "во все дыры без мыла", навешивая всему населению "номерки для учета", равно как стремления производителей выкручивать руки потребителям, бесконечно заставляя их покупать новые устройство под любым благовидным предлогом (например, "сломался"). Ничего секретного, кроме ID's я там даже усмотреть не могу. Теоретически, вмешательство могло бы привести к увеличению уровней излучения, но на практике там, наверное, сегодня такие "дохлые" усилители ставят... Стандарт GSM позволяет вещать с мощностью до 1Вт (или даже 2Вт) на 900МГц. Нынешние телефоны вещают не более 0.1Вт, ну может 0.2Вт. Думаю там RF часть даже аппаратно разрешенный 1Вт ищзлучить не сможет.

"Украденные телефоны", на которые ссылаются демагоги от Матрицы, тоже никто на практике никогда не искал и не ищет по сей день, за редким исключением (когда есть нужные "знакомые" сразу все находится ), ни у нас ни за рубежом (разве что случайно найдут). В любом случае, разграничение уникальных данных NVRAM от "остальной прошивки" очень четко прослеживается на любых устройствах подобного толка. Это мы пытаемся переливать разделы с доноров в отчаянных попытках реанимировать аппарат. Инженерны производителя, не удивлюсь, если даже, не знают о существовании такой возможности.

Сам NVRAM обычно всегда кастомится, добавляют-убавляют какие-то ITEM-ы. Кастомить протокол уже сложнее - надо разрабатывать полностью свои утилиты под этот протокол и нести все изрержки в т.ч. по глюкам и отладке, избыточному обучению, общению с ОСЦ итп. Кастомить модем тотально никто не станет - слишком сложно и фатально трудозатратно - фактически нужно новую структуру хранения (всех уровней) разрабатывать и большую часть фирмвера модема самостоятельно. Случаев "в природе" нет таких. Samsung, было, переносил бинарные структуры NVRAM в файловую систему тела. В итоге просто ослабил защиту, вместо того чтобы ее "усилить". Пользователи быстро раскопали где храняться, даже не шифрованные, бинарники и делали с ними "что хотели". И вообще, там очень удобно - глюкнул модем - чел, прямо в телефоне, запустил какой-нибудь Root Explorer и скопировал "файл NVRAM" из бакапа поверх запоротого, перезагрузил - и все работает и пресловутый IMEI на месте. Я был "в шоке" когда узнал. Эти аппараты оказались наиболее "простые" для исследования. Впрочем перезалить бакап разделов ModemSTx из бакапа с SD-карты в случае сбоя тоже не сильно сложнее. Есть и готовые утилиты. Но с файлами работать пользователям кажется проще и привычнее.

Чудесно кастомизирован был модем от Casio G'zOne С811 (CA-201L). Там производитель создал НЕ шифрованный раздел с бакапом важнейших настроек NVRAM (вкл. IMEI/Serial/etc). Сам NVRAM хранится практически стандартным образом. Если разделы EFS (ModemSTx) повреждены - NVRAM переинициализируется дефолтными значениями, ID вписываются из данных раздела-бакапа. Все происходит автоматически, даже перезагрузка не требуется. Пользхователь даже ничего не замечает. Если разделы целы, бакап "лежит" и его никто не трогает. можно там менять что угодно (если понимаешь бинарную структуру), но на работу телефона это никак не повлияет (пока не случится сбой EFS либо если умышленно его стереть). Вот так и должно было быть сделано везде. Это называется отказоустойчивость. Другое дело, что все это не снимает с производителя отвественности за НЕ опубликованные исходники, заводскую прошивку и "сваливание с рынка" с закрытием СП Casio-Nec и забиванием на гарантии, поставки запчастей итп (см. срок службы по закону).

Вывод: у человека повреждена GPT и разделы cache/userdata, скорее всего и system просто не прописаны там. Это объясняет почему они не прописываются (о них вообще нет речи на скрине 2) при прошивке с SD карты. Их просто некуда восстанавливать ибо нет таких разделов. Это, конечно, не 100% вывод, но это анализ, и анализ вполне разумный, объясняющий имеющиеся факты. Может быть у него еММС "бэдит", а Recovery не стал прописывать "недостающие" разделы по какой-то иной причине...

Главный вывод, который можно сделать и который полезен для всех:
Какой-то и з загрузчиков этого аппарата, причем, скорее всего PBL, умеет грузиться с внешней SD карты!
Какова логика выбора носителя для загрузки я не знаю, но из поста следует еще один важный вывод, что вариантов поведения может быть 2:
1. Один аппарат грузится с внешней SD карты, размеченной и прописанной идентично с eMMC (Вкратце - нужно залить на SD карту образ ВСЕГО ДИСКА слитый с eMMC, подробности можно найти в топике про восстановление загрузчиков, все ссылки есть в шапке).
2. Другой аппарат НЕ грузится с той же самой внешней SD карты, размеченной идентично с eMMC.
Наиболее вероятный сценарий тут:
1. Если PBL видит [неповрежденный] GPT, возможно еще, может загрузить SBL, он отдает загрузку на eMMC, после чего перестает искать другие носители для загрузки (а с еММС загрузиться по какой либо причине не может).
2. Если PBL не видит GPT (или не может успешно загрузить код SBL-related), он пытается найти GPT и SBL-related код на ДРУГОМ носителе, коим (единственным альтернативным и программно почти идентичным еММС) является внешняя SD-карта. И, если он находит там то, что ищет он пытается грузить систему оттуда. Собственно, подобное поведение расписано в указанной теме. Метод не нов и встречался ранее в других Qualcomm-based устройствах. Другое дело, что не все устройства "желают" грузиться с внешней SD-карты и/или неизвестно как их "заставить".

Прояснить точные границы поведения при поиске носителя для загрузки могут только эксперименты (или реверсинг PBL). Существуют иные способы перенести загрузку на внешнюю SD на более поздних этапах. В частности известные разработчики кастомов для Highscreen Boost 2SE (acdev/S-Trace) выпустили кастомный ABoot, позволяющий выбрать загрузку с eMMC либо SD уже на этапе работы ABoot. Такой метод позволяет грузить систему и работать с устройством даже при частично "убитой" еММС. Для работоспособности метода, очевидно, необходима работоспособность еММС в рамках ее выхода в готовность на чтение (при условии заблаговременной записи кастомного ABoot) и целостности GPT/SBL/RPM/TZ и, собственно, ABoot.

Кто может/желает - проведите необходимые эксперименты. Мало того, если удастся загрузиться с внешней SD тем, у кого аппарат впадает в 9008 после замены еММС на снятую с Samsung-а и проливки прошивки, могут попробовать загрузиться и поглядеть что изменилось после "впадания в ступор" (без вторичного выпаивания еММС). Для этого перед перезагрузкой нужно слить всю еММС любым способом, и, после "впадания в стопор 9008", слить еще раз, после чего сравнить и попробовать понять "где косяк".

P.S. Некоторым может показаться, что я не люблю "заЩИТы" (от слова shit, а не ЩИТ). Кто-то может возразить, что производитель защищает данные "неграмотных" пользователей от доступа третьих лиц, в т.ч. в результате кражи аппарата итп.
Простите, но так данные НЕ защищают. Пользователь сам должен выбрать: (или вообще использвать специальные сторонние средства для защиты).
Если "ему нечего скрывать", он не боится доступа третьих лиц (при наличии физического доступа к телефону, поск удаленный доступ всегда защищается и весьма неплохо, в т.ч. на "рутованных аппаратах") и его беспокоит, прежде всего, работоспособность, отказоустойчивость, надежность и ремонтопригодность устройства, доступность данных, их сохранность - ему не нужна никакая защита, осложняющая эксплуатацию и отнимающая производительность, а "от честных людей" хватит и простенького PIN-а (пароля), вроде как тот замочек, который висит на вашем почтовом ящике и вскрывается любой отверткой, но его никто и никогда не вскрывает за очень редкими исключениями.

Если пользователь всерьез обеспокоен безопаностью, личной или корпоративной, утечки недопустимы, а стоимость аппарата пренебрежимо мала с последствиями утечек - ему просто нужно предложить полное аппаратное шифрование носителей или их частей с полной (его) отвественностью за сохранность ключей и иные реально защищающие технологии (включая понимание и приятие физических ограничений и неудобств при работе с устройством). Такое шифрование не должно препятствовать ремонту устройства (в т.ч. в "домашних условиях"), не должно препятствовать снятию любых в т.ч. шифрованных и поврежденных данных. Вопрос расшифровки должен относиться к компетенции пользователя (в его лице или лице корпоративной СИБ) и никого более, включая Билла Гейтса, Сережу Брина, главу ЦРУ и прочих "деятелей".

Такие методы защиты давно разработаны и давно и широко внедрены. Взять, как пример, хорошо известный TrueCrypt, позволяющий прозрачно шифровать разделы и диски целиком (включая стеганографические методы), равно как, позволяющий свободно перемещать шифрованные контейнеры на любые носители.
Методы несанкционированного доступа к данным после этого остаются, но сводятся к использванию вирусов/троянов (перехватывающих пароли и ключи в момент их ввода) внедрить которые на ранние этапы загрузки крайне сложно. Отвественность за использование только надежных источников кода тоже лежит на пользователе (а не производителе и иных лицах, никак не связанных общей ИБ и отвественностью с пользователем), что, в т.ч.. подразумевается выше, под "неудобствами и ограничениями в работе".

А то, что сейчас называют "заЩИТами" - это дырявое сито позволяющее спереть любые данные, контролировать активность пользователя в самых разных аспектах, в т.ч. не связанных напрямую с самим устройством и препятствующее нормальной работе и ремонту устройства.