Брикнутая KLMBG4GE2a-A001 - шанс на вычитку фулла

[KonstantinVoskr]

Накопитель определяется только через ТП
---------- eMMC Device Information —--------EMMC CID : 15010030303030303056201206133208
EMMC CSD : 902701320F5903FFF6DBFFEF8A404022
Изготовитель eMMC: ID: 0015 , OEM ID: 0100
EMMC Date: 03/2015 Rev.0x56
EMMC NAME: 000000 , S/N: 538052115
EMMC NAME (HEX): 30303030303000
EMMC ROM1 (Main User Data) Capacity: 32768 MB
EMMC ROM2 (Boot Раздел 1) Емкость: 512 kB
EMMC ROM3 (Boot Раздел 2) Емкость: 512 kB
EMMC RPMB (Replay Protected Memory Block) Capacity: 128 kB
EMMC Permanent Write Protection: No
EMMC Temporary Write Protection: No
EMMC Password Locked: No
Extended CSD rev 1.5 (MMC 4.41)
Boot configuration [PARTITION_CONFIG: 0x00] No boot partition configured.
Boot bus config [177]: 0x00 , width 1bit , Partition config [179]: 0x00.
H/W reset function [RST_N_FUNCTION]: 0x00
High-capacity W protect group size [HC_WP_GRP_SIZE: 0x00000000]
Partitioning Support [PARTITIONING_SUPPORT]: 0x03
Device support partitioning feature
Device can have enhanced tech.
Partitioning Setting [PARTITION_SETTING_COMPLETED]: 0x00
—-------------------------------------------
Backup saved: 000000_ 538052115_20160725_1706.extcsd
Сделано.
Pачитаться не дает:
Напряжение подтяжки линии CMD :2103 mVНапряжение активной линии CMD :2567 mV
Box IO Level:1800 mV
CLK Rate:7000 khz
Reading 0x000800000000 bytes from 0x000000000000 ...ROM1 ( USER ROM)
Output file :E:\EMMC\EMMC_ROM1_000000_538052115_00000000_80000 0000.bin
Retry reading adress 0x00000000 (Attempt #1)



Может кому то удавалось подобное побороть?

[lelik]

Был в ремонте i9300 с такой же задачей. Необходимо было вычитать дынные из памяти KMVTU000LM-B503. Через TestPoint у меня тоже ничего не получилось вычитать. Возможно этот режим предназначен только для сервисных операций ? Т.к. клиент не хотел ждать восстановил память через TestPoint и выдал восстановленный аппарат. Но вопрос достаточно интересный аппараты с такой задачей частенько заходят.

[0xMihalich]

Все верно, тест поинт только для восстановления firmware контроллера (режим восстановления будет rev 0x56). В z3x есть еще кнопочка VTU00M repair 000000. через нее vtu00m восстанавливаются (не всегда) без потери инфы, с другими флешками нужно проверять, но как минимум эта кнопочка уронит ее в режим, отличный от 0x56 и из-под него вполне возможно что получится что-то считать

[serviceman]

со сбойным firmware eMMC наверно только так (http://www.ejtag.ru/viewtopic.php?f=18&t=1415&sid=509de3061175a35e2aea11bc9d754227)

[Kapetz]

После восстановления проши , через ТП, кто-то фулл пробывал вычитывать?
Заливаются ноли ?(

[alexplyus]

После восстановления проши , через ТП, кто-то фулл пробывал вычитывать?
Заливаются ноли ?(

Много не вычитывал, но с самого начала идут одни нули.

[Layder]

Дабы не раводили тут люди догадки.

В z3x есть еще кнопочка VTU00M repair 000000. через нее vtu00m восстанавливаются (не всегда) без потери инфы,
всегда с потерей инфы.

Итак немного теории: EMMC состоит из NAND Flash, и контроллера с прошивкой. Прошивка запускается и отвечает на комманды извне. Для работы прошивка использует небольшой кусок спецпамяти называемой "таблицей размещения секторов", в которой хранится соответствие "логического" адресного пространства "физическому". Это необходимо для равномерного "износа" ячеек Flash при операциях записи. Кроме прочего, прошивка контроллера имеет в себе еще и EEPROM, в котором собирает информацию типа S.M.A.R.T. Существуют также "ремапы" Bad Sector'ов.

Теперь о boot режиме (через ТП). в Boot микросхема падает сама, если не может запустить основное firmware или через ТП - принудительно. firmware boot имеет значение 0x56. В режеме Boot (0x56) нету доступа к NAND накопителю и таблице размещения секторов. Кроме boot есть случаи, когда у микросхемы NAME 000000 - бывает когда прописывается firmware, но не прописывается CID. тогда можно принудительно вписать CID.

Теперь о восстановлении firmware Flash - после восстановления firmware обязательно происходит Wipe - переинициализация таблицы размещения секторов со стиранием Flash

Если сделать спец прошивку, залить firmware без Wipe - мы просто получим сильно или не очень перемешанный мусор. Собирать данные не зная, где находится следующий сектор, т.е. без "таблицы размещения" нереально. т.е. такую прошивку сделать можно, практически же толка от нее нет.
То, что флешка упала в boot или не детектится как раз говорит о том, что firmware из-за своего несовершенства запороло эту таблицу и не может с ней разобраться. Поэтому раз таблица запорота, то тут 2 варианта - или давать флешке команду Wipe - на переинициализацию её или обмануть микросхему, получив доступ к внутреннему накопителю без этой таблицы. Во втором случае будет то, что я писал выше - каша, которую нереально собрать.

[0xMihalich]

Layder,
все написано правильно, за исключением одного маленького но. кнопочка vtu00m repair работает по-другому принципу. Она выводит именно эту флеш из режима 00000 убирая какой-то баг в прошивке инфу при этом не трогает. у меня было несколько раз такое, а именно VTU00M с 000000 при нажатии на данную кнопочку флеш становилась частично рабочей с родным бут-конфигом, родной разметкой и насколько смог судить инфа была на месте. Клиентам был озвучен ценник за извлечение инфы получен отказ и после я благополучно затер эти флешки и восстановил телефоны.

будет еще подобная я сниму процесс восстановления именно этой кнопочкой обязательно

как будет на других еммц я не знаю решение именно для VTU00M

[serviceman]

Во втором случае будет то, что я писал выше - каша, которую нереально собрать.

pc3000 flash справляется с этой задачей успешно в большинстве случаев, вот вычитать содержимое внутреннего нанда пока нечем.

[Dimaster]

родной разметкой и насколько смог судить инфа была на месте.
Штук 5 со сбойным именем (00000) микросхем VTU00M после операции "reset 00000" - разметка на месте, а в userdata пусто. Это на практике. Вариант "ушития" предыдущими ребятами не исключен (до сброса имени в 00000)

[Layder]

Layder, все написано правильно, за исключением одного маленького но. кнопочка vtu00m repair работает по-другому принципу.
она работае по тому же принципу - заливает firmware 0xf1 (или 0xf0, точно не помню) и восстанавливает CID.
возможно если до этого там была такая же прошивка, то сохраняется таблица рамещения файлов и не происходит ее (таблицы) переинициализации.

Все случаи Repair 00000 у меня были с потерей всех данных - я раз 5 пробовал. Потом просто стал делать firmware upgrade, потому что при нем прошивка поновее и безглючней.

pc3000 flash справляется с этой задачей успешно в большинстве случаев, вот вычитать содержимое внутреннего нанда пока нечем.
возможно в случае с NAND, pc3000 получает доступ к этой таблице и с ее помощью "наводит порядок". потому как без этой таблице попросту создать порядок блоков можно сказать невозможно. это равносильно тому что вы возьмете файл допусти 16 мегабайт , поделите его на секторы в допустим 2кБ и перемещаете 10-20 процетов секторов местами. Да у вас будет файл в 16Мб, с перемешанными секторами. Скажите как pc3000 "догадается и восстановит" правильную последовательность секторов? Я допустим не могу это понять, проясните мне.

[Layder]

Чтобы было понятно, я приведу вам аналогию. Допустим у нас есть автоматизированый автомобильный многоэтажный гараж (ячейки памяти). Сделаем аналогию с домом. есть 5 этажей, по 4 парковочных места, 3 подъемника. первый подъемник обслууживает места 1-20, второй с 21 по 40, третий с 41 по 60, по аналогии с подъездами дома. Вы привозите машину на въезд в дом, отдаете швейцару (контроллеру (прошивке)) он вам сообщает, что что ваша машина на 5 месте, и вы ее постоянно ставите на 5 место, оно за вами забронировано. допустим в сутки в гараже стоит всего по 30 машин. Через некоторое время хозяин (швейцар, прошивка) понимает, что первый подъемник изнашивается, а 2 и 3-й простаивает. Что он делает. Он вашу машину начинает ставить на 45 место, а у себя помечает, что места 41-50 физическое соответствуют 1-10. Вам же все равно где ваша машина, а хозяину нужен равномерный износ оборудования. Вот когда хозяин помер, а его каракули никто разобрать не может найти машину сложно.

Вот такая аналогия с флешой. контроллер флеши следит за равномерным износом памяти, а для процессора данные выдает в виде адресного пространства неизменного. а что и где находиться физически не забота процессора, который работает с "логическим" пространством.

[serviceman]

если есть содержимое nand emmc то все возможно, таблица как вы ее называете - это транслятор, он расположен в том же nand, нужно только его найти. Другой вариант сборка по номерам блоков, к нашему счастью у нандов у каждого блока есть служебка в которой есть информация о логическом месте этого блока в дампе.
Но вообще это частные случаи, каждый контроллер а вернее его прошивка по разному работают с накопителем, где-то транслятор, где-то номера блоков, с восстановлением инфы с флэшек есть масса ньюансов.

[Layder]

насколько я в курсе транслятор не находится в общем nand. потому что он изнашивается быстрее MLC ячеек и он сделан обычно по SLC технологии, и скорее всего доступ к нему имеет только firmware, и возможно в разных firmware и разных микросхемах он имеет разный формат. поэтому и проблема получить целостный дамп. Вообщем, если Вам это очень хочется - пишите в личку NoName, может он поделится наработками.

[serviceman]

В любом случае пока не будет дампа внутренней nand emmc, ничего достоверно сказать нельзя, как там что устроено, Точно можно сказать только что выводы ее выведены наружу и китайцы знают pinout :)
Был бы дамп можно было бы натравить на него pc3000 и посмотреть что выйдет :-k

[KonstantinVoskr]

serviceman, PC3000 хорош только в том случае, если есть таблица размещения секторов. Если ее нет - то ничего он не сделает, увы но это факт. Насчет узнать распин накопителя- рентген в помощь, но в моем случае клиент не готов расстаться с внушительной суммой, поэтому пока вопрос снимается ( до появления новых наработок с меньшими затратами ресурсов).