Ссылка умерла, и изначально была странновата. Это, похоже Mail.ru, но уже внутренняя ссылка, актуальная для конкретного IP и времени... Я стараюсь заливать в аттачи. Форум вечен...
Я знаю... См. след. абзац...
Кстати, этоже может приводить к неким заблуждениям относительно того записалась ли NVRAM и проблем совметимости модемов. У мя нет аппарата проверять что либо (и не было никогда).
1. Спасибо за инструкцию! (попробовать не на чем в данный момент)
2. Не пользуйтесь QFIL для работы с NVRAM! Пользуйтесь только QPST -> Software Download! Уже писал в др. темах!
QFIL ПОРЕТ NVRAM ПРИ ЗАПИСИ! Запишет не все, что есть в .QCN!
QFIL ЧИТАЕТ НЕ ПОЛНЫЙ NVRAM ПРИ ЧТЕНИИ! Размер бакапа будет меньше! Уточнить "все тонкости" можно сравнив импорты .QCN в текст (исп. утилиту QCNView из компл. QPST).
Как минимум, QFIL не умеет работать с разделом (SIM1), отвечающим за второй SIM в двухсимочных аппаратах!
Хотя, когда я вижу разницу в 80кб против 600кб, я понимаю, что пропал не только крохотный раздел (SIM1).
Тоже самое относится к старому RF_NV_ITEM_Manager, только порет иначе, "что попало". Аналогичные проблемы могут наблюдаться с иными утилитами, работающими по старым методам QMI (QFIL, как раз новый, но там какие-то серьезные ошибки).
Скорее всего да, но не на 100%. Вы можете снять бакапы NVRAM в .QCN с аппаратов с разными версиями модемов (заведомо рабочих, а лучше "не тронутых"), затем экспортировать бакапы в текст с помощью QCNView и сравнить что отличается (хотя бы банальным консольным fc из Винды).
0. Всегда и все проверять неск раз, контролировать данные визуально! Ошибки будут стоит дорого!
1. Скопировать образы разделов ModemST1 / ModemST2 / FSG / иных? на SD карту командами типа dd if=/dev/block/.....mmcblk0p??? of=.../sdcard/....modemst1.img....
(конечно же треб рут права)
2. Пересобрать бинарно заведомо рабочий TWRP/CWM с помощью утилиты AndImgTool, добавив на рамдиске в файл /etc/recovery.fstab соотв строки касательно указанных разделов (modemst....), затем прошить пересобранный рикавери, зайти в него и спокойно бакапить/восстанавливать EFS на SD карту за секунды нужное кол-во раз. Возможно, в топике на 4пда уже "молча" лежит какой нибудь TWRP с прописанным бакапом разделов EFS.
3. В том же рикавери из п.2 в ....prop, в самом начале поправить строки ro.secure=0 и блаблабла.usb.debuggable=1 (если еще не сделано до нас), дабы получить рут без запросов и включить ADB под ядром рикавери. Прошить рикавери, зайти в него, поставить драйвера ADB (если не стоят) и творить что угодно по ADB в ФС аппарата даже не утруждаясь набором su.
Стереть разделы "под EFS" можно любым способом прямо из файловой системы. Либо (самое простое и трудно ошибиться) зайти в режим FastBoot и стереть разделы командами типа fastboot erase modemst1..... (только после предварительного бакапа). Не помню, есть ли в рикавери стирание подобных бинарных разделов, но можно, видимо, добавить в .fstab...
Если кто в танке, стирание заключается в записи ASCII (0) во все байты раздела. Никаких секретных/шаманских действий при этом не производится...
Залить бакап ИЗ .QCN удастся уже только после перезагрузки в систему (произойдет переинициализация EFS/NVRAM) при условии наличия (активации) Diag порта и отсутствии блокировки записи NVRAM через QMI средствами работающего модема.
Скорее всего, в коде модема (раздел modem) стоит "затычка" (блокировка) работы с QMI (по части записи NVRAM). Такая блокировка отсутствует в коде модема сервисных (debug) версий, судя по контексту дальнейшего обсуждения. Возможно, для разблокировки работы с NVRAM достаточно прошить лишь код модема от Debug прошивки соотв версии (той, где структура данных EFS идентична, проблем с расшифровкой не возникает). Из контекста следует, что структуры EFS различаются для неких рядов прошивок, что приводит к "потере IMEI" с какими-то прошивками и его "воскрешению" с другими без вмешательства в EFS/NVRAM). Странно, что "чужеродный" модем, увидев "запоротую" (по его мнению) EFS или NVRAM, не пытается ее переинициализировать (если бы делал это, при возврате старого модема данные, втч ИМЕИ не вернулись бы). Ранее люди сталкивались с тем, что EFS с донора не расшифровывалась на реципиентах, из чего следовала уникальность и аппаратная привязка ключей шифрования EFS в данной модели (соседней? Уже запутался в однотипных названиях), характерная для части устройств на базе референса Qualcomm и не характерная для для другой части, безотносительно к кастомизациям. Вопрос с совместимостью между разными версиями модема по части шифрования EFS, при этом как-то остался за кадром.
Возможно стирание поможет. БАКАПЫ ОБЯЗАТЕЛЬНЫ!!! После стирания или иного повреждения EFS модем производит переинициализацию EFS и NVRAM. После этого, например, возможна перезапись IMEI закрытого ReadOnly после первой записи в РЕФЕРЕНСНОМ дизайне. Однако, восстановление NVRAM в QPST (и иных современных инструментах типа QFIL) идет с Backup Privelege, что позволяет также перезаписывать ReadOnly Item-ы. Бывают случаи, когда QPST тоже не видит чссть данных EFS. OEM умышленно (путем кастомизации) скрывают таким образом какие-то флажки, локи, иные структуры. Примеров не мало. См. тот же Q415.
В данном случае, мне кажется, более вероятна прямая блокировка записи NVRAM чз QMI в стоковой версии модема (ибо для сервисов есть Debug версия). Как программист, я понимаю, что такой метод реализовать легко и просто. Один безусловный переход (в сток версии), и дело сделано... OEM-ы не ищут сложных путей, разработка низкоуровневого кода стоит больших денег, это мы тут за идею работаем "не зная броду" против всех их не законных издевательств над сообществом и чтобы починить какой-то там одинокий аппарат за 1тр.. Матрице не приходит в голову, что норм. русский чел. небоскреб снесет, если он мешает ему на толчок с сердечком во дворе ходить... И миллионы, вложенные в разработку заshitы не помогут. Кроме того, усложнение конструкции порождает бесчисленные издержки с АСЦ, а избранная стратегия выпуска Debug прошивок легко формализуется и соглауется со снятием защиты от записи NVRAM в Debug прошивках ("по инструкции" "мастер АСЦ" все равно должен шить Debug, соотв вопросы с NVRAM у него отпадут сами собой).
Не путайте! Он работает с NVRAM из под работающей системы. 9091 это Diag порт (бывают и иные PID на нем)
Диаг может быть виден только на работающем аппарате с запущенным модемом (и если diag включен в композиции USB). Диаг невозможно увидеть даже из рикавери, поск хоть ядро ОС запущено, но модем не работает. В случае падения загрузчиков, понятно, старт системы не возможен вовсе.
909E толи 900E действительно был один из режимов вылетающих при порче загрузчиков (как помню).
F006 = Trickle Charge вылетает оч редко, когда питания не достаточно для норм. старта проца, но возможны дажа софтовые проб. См. обсуждение на 4пда.
9006 - режим "eMMC наружу", когда вся eMMC отдается наружу по USB как MassStorage. "Можно все!" "По просьбам трудящихся" режим прибили после MSM8x26/28 (ок. 2014) дабы трудящиеся не получили доступ к своим данным в обход "чудесных защит" (Да нет! Это злобных хакеров, конечно же, ну, не от трудящихся же, и в мыслях такого не было)... Режим реализуется с помощью кода SBL. Возможно и в новых процах можно активировать. На 4пда писали, что на "этих ваших Асусах" активируется, не помню как. Можно найти.
9008 реализуется средствами PBL. PBL есть в маске проца и может быть в Boot разделах eMMC (представления типа ROM? либо mmcblk0boot?). На eMMC если есть, то может быть кастомный, с "блокировками", из-за чего "все" может не шиться (см. Micromax Q415). Тестпоинт (см. пред стр) блокирует чтение eMMC на старте путем просадки линии команд CMD на землю GND, что позволяет работать с референсным масочным загрузчиком "бэз п-ды". Кроме того, этот же трюк предотвращает уход в SBL, где все может виснуть по некой иной "неведомой" причине. PBL умеет только принимать внешний загрузчик по USB и запускать его на исполнение. Внешний загрузчик отсутствует на eMMC исправного аппарата, в юзерских прошивках. Загрузчик обычно подписан подписями Qualcomm и/или OEM. Подписи обычно проверяются PBL перед жамусктм загрузчика (SecureBoot), что зависит от конфига QFuses. Загрузчик может присутсвовать в заводских/сервисных прошивках (всегда есть на заводе) если АСЦ упал-намочен восстанавливать GPT/SBL и иные структуры (подобные для иных SoC) до уровня FastBoot (реализуется SBL/ABoot). Odin, если что, это "подмена" кода FastBoot, поэтому нет смысла искать FastBoot, если есть Odin (только Самцы). Его там просто нет.

У Сони все еще круче и прозаичнее, ибо проц кастомизирован (QFuses?) и банально не принимает загрузчики с подписями иными нежели от Сони (в т.ч. не жрет подписи Qualcomm). Сами загрузчики есть только у Сони и у Сергея Лазеровича, в его SETool/S1Tool (низкий поклон ему), однако, их наличие никак не помогает в случаях порчи "соседней зоны" TA (втч при замене дохлых eMMC), ибо зона подписана аппаратно-экземпляро-зависимыми ключами (при порче подписей sbl всегда виснет), а иной загрузчик (любого типа/уровня), который просто покакал бы на эту, крайне опциональную для жизни на Земле, зону запустить невозможно изза подписей "толькоСони" в проце. У Сони, Хуявея и Самца АСЦ настолько "упали и намочены", что им даже эту банальность, восстановление GPT/SBL, не доверяют (не говоря уж о TA), а "рекомендуют" менять матери по цене двух бэу тел на Авито... Сразу хочется дать "директору" дзэйбатсу Сони, чоболя Самсунг и "подвала" Хуавэй текст GNU и GPL для принудительного анального чтения на толчке...
А потребителям не приобретать продукцию с означенными "надписями", уже купленную - убить ап стену, пока не поздно вытащив данные...
Для Asus, загрузчики, слава Богу, ходят, хотя их трудно найти. Но "директор" Асуса тоже давно и настойчиво напрашивается на чтение в туалете.
Почему некоторые боксовые инструменты хотят 9008, когда SBL работает, аппарат [частично] грузится?
Утомившись от бесчисленных мудреных заshit одних идиотов от других, авторы боксов ищут простоты, легкости и стабильности методов работы... Поэтому, если у них есть нормальный, подписанный внешний заорузчик, с разблокированным чтением eMMC, им куда проще залить его из 9008 в оперативу, получить полный доступ к eMMC, как к носителю с секторами, найти любые нужные структуры данных, считать их, поправить, записать без всяких рутов, бутов, мутов, адб, драйверов, прав и вообще, без участия стороннего индусского кода и без ведома и разрешения тупых б... индусов и их яйцеголовых хозяев, возомнивших себя вершителями судеб, которые все это говно городили на пустом месте... Надеюсь доходчиво...
Вениамин, вы как всегда на коне, хотя в дебри даже и не лезите...

Я так понимаю, это Debug... в котором "Можно все!"

СПАСИБО!
Не всегда слетает, зависит от совместимости данных NVRAM, шифрования EFS между прошивками МОДЕМОВ. При апгиейде производитель заботится о совместимости и предпринимает меры чтобы поддержать старые структуры и/или сконвертировать их в новые. А на даунгрейд ему наплевать. Нормальный производитель не корежит структуры данных, не препятствует даунгрейду и вообще старается угодить потребителям, а не руки им выкручивать и проблемы создавать. Асус в число добросердечных явно не входит, что видно из контекста топика и данного примера. Если кому-то нужны старые прошивки и даунгрейд, придется искать debug прошивку под старые версии модема, корректно снимать QCN под новым модемом, потом шить старый в варианте debug и заливать QCN обратно уже под ним (гарантии тоже нет, возможно придется разбираться что поменяли в NVRAM). Иначе, видимо, никак. Делайте бакапы EFS по разделам ДО апгрейда чтобы не наступать на такие грабли.
Те, кто снимает бакапы QCN (тем более, разделы EFS) и публикует - пожалуйста указывайте версию прошивки аппарата (модема), на которой они сняты.
====================
Справка, позволяющая закрыть нелепые вопросы "непосвященных" и направить их усилия в креативное русло на основе физико-математической модели "явления" нежели "домыслов и слухов"
EFS - Qualcomm Encrypted File System (название исп и для иных ФС, не имеющих отношения к теме). Шифрованная файловая система для хранения уникальных данных модема. Обычно хранится в паре разделов ModemST1 / ModemST2. В разделе FSG хранится эталонный образ, исп для переинициализации EFS в случае краха. На практике часто не используется по назначению. Возможны самые разные кастомизации OEM, в т.ч. доп структуиы на EFS за рамками NVRAM или доп разделы с пропрайетарными структурами OEM.
NVRAM - бинарная структура хранения файлов и базы данных (ITEM-ов), специфичная для Qualcomm, хранящаяся в EFS, наряду с иными возможными структурами. С типовыми физическими мсх NVRAM (EEPROM, Flash) соотносится лишь образно.
NVRAM используется для хранения уникальных для экземпляра настроек модема, хотя, на практике, большинство данных идентичны для всех экземпляров модели. Кастомизируется OEM почти всегда. Работать открыто с бинарной структурой NVRAM, расшифрованной структурой EFS, позволяет, разве что, RevSkills, однако, разработка продукта закрыта в 2012г и он безнадежно устарел, при том, что даже в период активной разработки далеко не покрывал всех "тонкостей". Свободных средств статического [рас]шифрования EFS (не средствами фирмвера модема) не наблюдалось за всю 15-летнюю историю развития модемов Qualcomm.
QMI - Qualcomm Modem Interface - бинарный протокол диагностического порта модемов Qualcomm. Посредством QMI можно обратиться к коду модема с целью, в числе прочего, заставить его читать/писать данные NVRAM и передавать их через QMI в Diag COM port. Протокол может быть кастомизирован или заблокирован, но такое встречается редко. Для общения с модемом со стороны Android существует отдельное стандартное API RIL.
.QCN - бинарный формат данных, на основе бинарного формата хранения документов Microsoft (типа Word/Excel), разработанный для хранения бакапов (архива файлов и данных) NVRAM Qualcomm. Бинарно никакого отношепия к бинарным структурам NVRAM или EFS не имеет. Позволяет сохранить данные, передаваемые модемом через QMI или отослать сохраненные данные обратно модему.
Формат xQCN отличается хранением бинарного образа QCN в виде текстового файла в XML формате. Происходит также от Microsoft. Написание редактора (конвертера) QCN/xQCN в текст представляется не слишком сложным (струкруры MS давно разобраны при реверсе парсеров офисных документов), однако, таких инструментов в открытом доступе не видать. Обертка бинарных структур "в сборе" в XML помочь в чтении или понимании бинарных структур QCN никак не может, а лишь мешает необходимостью кодирования/декодирования между бинарными данными и текстом XML. Для чтения структурированных данных NVRAM в виде текста исп QCNView. Импорт текста в QCNView не возможен, только экспорт в текст.
MBN/IMG/BIN (img и bin - понятно, в соотв контексте) - внешние загрузчики Qualcomm под конкретную платформу (устройство) частично совместимые с устройствами на том же SoC, того же OEM или др OEM или даже соседними SoC. Загрузчик грузится только из EDL/Download mode 9008 (HS-USB QDloader, назв может меняться, втч от драйверов) и только в RAM, на носитель тела не пишется. Обеспечивает передачу данных между компом и устройством, имея доступ к аппаратным ресурсам устройства, в т.ч. к носителю (eMMC) (чтение "наружу" в публичных загрузчиках обычно заблокировано). .HEX являет собой тот же самый .MBN, только завернутый в текстовый формат, каж. Intel Hex, который также принимает PBL. Бинарники конвертируются в HEX и обратно, в нете полно утилит еще с 80х гг. Требование [бинарных] подписей определяется конфигом SoC в QFuses. На китайских телах подписи обычно отключены. Если включены и нет (навозможно найти или создать) норм загрузчика, позволяющего свободно писать (и читать, хотяб опосредованно, напр чз 9006, хотя преферред отсутствие подписей вовсе и своб чтение без каких либо "переводов режимов" итп, поск я желаю читать в тч с битых eMMC ) любые данные - лично я таким телом пользоваться (по назначению) не буду. Обмен данными со стартовавшим внешним загрузчиком штатно осуществляется по протоколам Sahara (старый) или Firehose (новый). Загрузчик может поддерживать оба протокола одновременно.
MSImage - укороченный бинарный посекторный образ носителя eMMC, содержащий GPT (или MBR с прописанными, имеющимися в образе, разделами), загрузчик типа SBL и его модули в отдельных разделах (типа RPM, TZ, SBL2/3, иные). Остальные разделы прошивки отсутствуют и не прописаны в GPT образа. После записи образа в начало eMMC средствами внешнего заррузчика аппарат перезагружается и обычно попадает в режим 9006 (HS-USB Bulk итп), когда носитель целиком отдается по USB как MassStorage (флешка) - протокол Sahara. Иной вариант загрузка бинарных образов разделов и xml скриптов их описания с целью непосредственной записи на конкретные сектора eMMC и правки GPT, иных структур в аппарате - протокол Firehose. В последнем случае MSImage не нужен и не используется.