Ok im sorry, im just asking , if you think im stupid thats alryt..

scary though

Обнаруживает он ее следующим образом:

(1)теория.
Контроллер работает с памятью большими блоками (512, 1024, 2048 и т.д. страниц).

Каждая страница состоит из полезных данных и служебных (512+16, 512+24, 4096+128(K9GAG08U0M) это 512х8+16х8, 4304 = (512+26)*8 или посложнее (512+26)*2/(512+28)*6/4).

В служебных данных каждой страницы содержится всякая служебная информация, включая код ЕСС (код коррекции ошибок). В даташите на конкретный контроллер есть все сведения. качайте, смотрите.

В нем то у вас вся и загвоздка.

ЕСС это что-то вроде контрольной суммы страницы памяти, только с возможностью коррекции битовых ошибок. Емкость такой коррекции (число битовых ошибок которые контроллер может поправить зависит от длинны кода ЕСС и метода коррекции.
http://ru.wikipedia.org/wiki/ECC
http://ru.wikipedia.org/wiki/%D0%9A%...BE%D0%BD%D0%B0

(2) Практика (или где кроется "подводный камень):
- контроллеру подается команда считать блок данных, в котором находится ИЗМЕНЕННАЯ страница;
- контроллер читает весь блок одним махом в буфер;
- далее он уже в буфере проходит по всем страницам считанного блока и смотрит каждую на предмет сходится ли ЕСС страницы. Если все в норме, эта страницы памяти пропускается;
ДАЛЕЕ ВНИМАНИЕ!!
Если ОБНАРУЖИВАЮТСЯ битовые ошибки, то контроллер ПЫТАЕТСЯ исправить эти ошибки. Так как ВНОСИМЫЕ ВАМИ изменения малы, а алгоритмы коррекции в современных накопителях все мощнее и мощнее, контроллер скорее всего СКОРРЕКТИРУЕТ Ваши изменения в соответствии с прилагаемым к странице ЕСС.

Что делать и как быть???
(1) искать способ править дамп через контроллер (стандартный интерфейс накопителя) без обходного маневра с программатором. Уверен ГЕРОЙ уже появился на свет. Хватит ли ему духу остаться ГЕРОЕМ, изменяющим весь мир, а не БАРЫГОЙ, скрывающим тайну даже от своей второй половинки???;

(2) научиться писать в изменяемую страницу NAND помимо нужных данных еще и корректный код ЕСС. Этот путь очень тернист, т.к. алгоритмы в контроллерах постоянно совершенствуются, размер страницы тоже разнится.

(3) искать старые флешки, в которых контроллер наткнувшись на некорректный сектор, не сможет его на основании ЕСС скорректировать (алгоритм слабоват - слишком много изменений на странице памяти), и после нескольких попыток отдаст некорректный блок в свой интерфейс далее.






NAND устроена так, что она ВСЕГДА пишется с ошибками. Это связано с самой технологией частоты производства микросхем (фантомные дефекты плавающего затвора). Их еще называют "битовые ошибки" (что-то вроде временных бэд-блоков, только на уровне одного бита данных). Для компенсации этих процессов изобретены алгоритмы коррекции ЕСС (алгоритмы коррекции битовых ошибок).

Скачайте даташит на любую микросхему (скажем на K9GAG08U0M), рассмотрите его. Вы увидите что в служебке страницы NAND заложено место под код ЕСС (у K9GAG08U0M - Page Size : (4K + 128)Byte, 128байт на страницу в 4096).

Сам алгоритм заложен в контроллере. Для примера, скачайте даташит на контроллер AU6980. Контроллер Мемористик блочно мало отличается от этого.




Причина умирания карт кроется в двух моментах:
(1) карты неработоспособны по причине не правильной пайки NAND микросхемы. Если не считать установку не по ключу первой ноги, то "не пропай". Пайка волной + микроскоп все решают.

(2) карты неработоспособны по причине не осторожной разборки корпуса и выковыривании платы.

(3) вероятно, что у контроллера из-за изменений в памяти сорвет крышу (он не отдаст порченный блок в свой интерфейс) и он перейдет в технологический режим. Его можно вывести из этого режима путем замыкания в момент подачи питания соседних выводов шины данных между собой (D0,D1 или D6,D7). Затем форматнуть как обычно.

Erema36,
в принципе, ничего нового, но ёмко и в одном месте =)
Только вот с пропайкой у нас нет проблем, да и контактов "ГЕРОЯ" не знаем. Подскажешь?))

В моём дампе последовательность 204D5350534E5930 встречается 3 раза
2 раза в первом банке и 1 раз в конце второго
Флешка Toshiba TH58NVG5D4CTG20 4Gb - 2 банка по 2Gb
Возникает вопрос - какой msid менять? Или все три?
Вот скрины

первый банк раз
http://s59.radikal.ru/i165/1109/1e/e8fc76f1cf24t.jpg

первый банк два
http://s43.radikal.ru/i101/1109/a5/50342a6dea14t.jpg

второй банк
http://i049.radikal.ru/1109/ea/d4ce0f9f2922t.jpg

И по поводу SN, родной оставлять или тоже менять?

Спасибо.
Тему прочитал. Задача разжевана и понятна.
На днях раздобуду MS Pro и приступлю к экспериментам.

Вопрос: какие-либо утилиты под MS от производителя у кого-нибудь есть ?
Интернет отдает кучу бестолковых страничек.




Глупо хранить служебные данные накопителя в одном месте. Что будет если блок выйдет из строя и будет подменен транслятором? Пропадут немаловажные данные. Это не логично.
По аналогии с файловыми системами, таких мест должно быть два.

Третье - это, наверняка, как раз брошенный контроллером блок. Ему лень тратить время на затирание.

от самой сони есть проги для востановления "убитых" стиков..тока китайцев они нах посылают..

Тему читать кто будет?

Тогда логичный вопрос:
как утилита различает китаец перед ней или нет?
Уже ли не кода MSID играет свою роль. Интересно будет посмотреть что те что другие.
Время покажет.

Извиняюсь. Это тема уже другой темы форума.

Boryan, а у меня сия утилита работала с китайцами. только не все восстанавливались, ибо совсем мертвые были.

labaz, первый скрин это файл msid.bin или его остатки. короче этот файл создал дампер и там ничего менять не нужно.
второй скрин странный, не могу точно сказать.. на половину похож на то что должно быть.
третий скрин наиболее похож на то что надо менять, на всех картах примерно так оно и выглядело(когда я пробовал делать)

Erema36, такая штука как magic gate видимо. программа может проверять карты на поддержку его. хотя у меня она кушала все карты

Не стал цитировать весь пост. Но фактически всё правильно! Наверное первый человек, начавший писать в данной теме по существу =)))

В факе мы не стали расписывать все эти тонкости, т.к. не собираемся писать диссертацию для нубов, а написали инструкцию для более-менее разбирающихся в пайке, микросхемах и радиосхемах, а значит готовым взяться за это дело. Им должно быть и так известно про такие технические подробности.
Конечно же, разобрав карту и обнаружив можель микросхемы, первым делом необходимо ознакомится со спецификацией данного чипа.

Ну а кто никогда не держал в руках паяльник, не собирал хотя бы простейших схем, никогда не программировал микрухи и не в курсе, что такое даташит и считает, что здесь всё так просто - тот всё-таки сильно ошибается )))
Хотя, начинать никогда не поздно, как раз хороший повод бежать в магазин за паяльной станцией с феном или термопинцетом, потому что без неё "ансолдеринг" и "солдеринг" будет ох как затруднительным ))), ну и заодно стоит подкупить немного флюса, оплётку и мозговой жидкости.

Немного стоит уточнить понятия страниц, секторов и блоков.
На примере Hynix HY27UH08AG5M, упоминающейся в факе.

1. 1 сектор = занимает 512 байт + данные позиционирования сектора и контрольная сумма ECC (16 байт) в конце каждого сектора.
2. 1 страница = это 4 сектора со своими служебными данными, т.е. 2048 байт + 64 служебных байта = 2112 байт. Это как раз минимальное значение, которое умеет считывать и писать данный чип по даташиту.
3. 1 блок = 8 страниц или 32 сектора, конечно же вместе с техническими данными. 16384 +512 = 16896 байт или 16,5 килобайт. Это минимальное значение, с которым должен уметь работать контроллёр (чтение/запись), используемый в данной области применения.
   А так же, достоверно известно, что в один и тот же блок не может быть записано 2 разных файла/кода данных. Если в начало блока попадает конец файла/кода данных (даже 1 или несколько байт) из предыдущего блока, то следующий файл/код данных начинает писаться только со следующего блока, заполнив неполностью использованный блок значениями FFFFFFFF...

Конечно в разных микросхемах спецификации страниц и блоков может разниться, но чаще всего, в области PSP, её нанде и картах памяти, я постоянно встречаю именно такую структуру.
Если что не так, поправьте, могу и ошибаться.

Короче, самая малая проблема состоит в правильном демонтаже и пайке.
Но самая главная проблема - именно в этих коррекционных 16-ти байтах, которые записаны в конце каждого сектора и подтверждают его целостность. А так как мы заменяем ID номер (фактически 4 уникальных байта) в определённом секторе, не пересчитывая заново контрольную сумму изменившихся данных, отсюда и происходит большой процент брака, т.к. контроллёр отбраковывает данный сектор или даже весь блок (?). Вот с этим и надо разобраться.

Если писать через контроллёр (т.е. логическим способом), то конечно он сам подсчитает и скорректирует нужную контрольную сумму. Но для этого нужно знать команду записи MSID и написать программу. Другой вариант - считать логический блок, сменить ID и обратно записать этот блок с помощью программы, но опять же, нужно знать номер блока и команду записи. Это самый верный вариант, но пока затруднительный. Команды вроде даже есть у нас и мы об этом варианте задумывались, вон Yoti чешет репу, читает каждый день мануалы и коды по MSID Dumper-у, чтобы поменять название программы на Writer :pleasantry:

Ну а пока, мы чешем репу, чтобы скорректировать ECC. А получается это пока не совсем корректно, только с помощью поддельных карт памяти, в которых, по нашему мнению, именно эта ECC умышленно не учитывается или просто контроллёр на эти 4 изменившихся байта закрывает глаза.

Немного поправлю, чтобы не сложились ложные представления:
микросхема - HY27UH08AG5M
ссылка на datasheet - http://www.alldatasheet.com/datashee...7UH08AG5M.html
Высчитаем размер блока, как минимальной единицы манипулирования данными:
Block size= 128*1024+4*1024= 135 168 байт
т.е. пишем и читаем полезными кусками данных по 128 Кбайт.

Т.о. именно для этой микросхемы размер блока 64 страницы памяти.



Согласен с Вами. Алгоритм коррекции ЕСС есть самое громадное препятствие.
Возьмите один из них - Код Рида — Соломона (самый распространенный).
Почитать вот тут - http://ru.wikipedia.org/wiki/%D0%9A%...BE%D0%BD%D0%B0

Провел эксперимент комплекс PC-3000 Flash SSD Edition + дамп 4Гб от MS Pro (вроде бы оригинал)
Микросхема K9HBG08U1M, страница 528 байт (512 +16)
Избыточность кода позволяет корректировать 5 байт любых изменений на странице.
Т.е. я беру и хаотично меняю байты на странице. Затем делаю проверку и коррекцию ЕСС. И моих изменений как не бывало.

Поэкспериментировал далее. Только утвердился в своих выводах: будет ли сделана коррекция ЕСС зависит от того что и на что я меняю. Вот он может поправить и 8 изменений, а то и 3 байта уже не исправляет. Интересно что будет если я микросхему так и впаяю обратно в карту (контроллер то тоже не сможет скорректировать эту страницу).


Можно мне, на условиях нераспространения, получить исходник/наработки по MSID Dumper?
На чем он написан?

На условиях чохочешделания.. лежат в шапке https://www.pspx.ru/forum/attachment....6&d=1310272923.
Написано на Си. Только код корявый брр.. вместо табуляции пробелы. Редактировать, как по мне, просто нереал пока не оптимизируешь.

Ага, я вручную его от нефиг делать "причесал". А так, можно было попробовать автоматом на регэкспах почистить.

Да, да, да, спасибо за поправку.
Так и есть, 1 блок содержит 64 страницы (256 секторов). Страница спецификации.

---

Писал по памяти и чё-та попутал, видать с "блочностью"-кластерностью логической записи файлов на карты памяти FAT16 до 2 Гб. Да, именно так, файлы пишутся на карту строго кластерами по 32 сектора (8 страниц (16k)). Если файл заканчивается в начале какого-либо кластера секторов, то следующий файл уже не пишется в данный раздел, а начинается только со следующего кластера. То есть, вот такое нерациональное расходование пространства.

---

Далее по делу...

1. Здесь описана процедура чтения и записи, где видно, что это действительно делается страницами - чтение любой страницы или серийно несколько страниц; запись только циклами по одной странице.
2. Здесь описывается процесс стирания и, как я понял, стирать данные в этой микросхеме можно только блоками, но никак не страницами. Причём новый подготовленный блок, необходимо предварительно загрузить в кэш микросхемы, иначе команда стирания будет игнорироваться, защищая её от случайного стирания в случаях посторонних электрических наводок со стороны.

К чему это я...
Дело в том, что мой программатор "Тритон" умеет считывать микруху страницами. Но когда я произвожу обратную запись исправленной страницы, то он выдаёт запрос на стирание. Если отказаться от стирания, а пытаться писать поверх, то после проверки оказывается, что он ничего не пишет.
Если разрешить стирание предыдущих данных, то он производит цикл стирания-записи и все данные прекрасно переписываются.

Отсюда возникает вопрос: а не стирает ли он полностью блок (64 страницы), прежде чем записать новую одну страницу? :xD:
Вот этот момен я как бы не проверял. Я считывал только данную одну страницу под номером 07FFC4 во 2-ом банке памяти и видел, что все данные на этой странице записаны правильно, MSID поменялся точно на своём месте.
А вот что на следующих или предыдущих страницах не проверял. Короче, карты выходят не рабочими.

С другой стороны, если взять программатор "Flash Reader", то на нём карты получаются рабочими, хотя процент брака достаточно велик. Но вот он, как раз, не умеет читать и писать страницами. Он только снимает полный дамп и так же обратно весь дамп и пишет.

этот Flash Reader вообще писать умеет?

Этот Yokel вообще читать умеет?

Да, вариантов там не густо, можно только банки по отдельности читать\писать.
Их софт вообще под другие нужды заточен)
А вот с браком не понял. У меня пока было только пара китайских стиков и контроллеры в них не подходящие. После смены MSID работать отказывались вообще, но после смены MSID на родной работают как прежде.

labaz, ты вписывал оригинальный дамп при восстановлении? Попробуй сменить 1 байт во второй части MSID и проверить, потом записать, но не оригинальный дамп а предыдущий байт. Может с записью чото косячит... но странно.

Сливаю дамп, меняю id (родной дам конечно храню отдельно)
После смены id карты прекращали работать.
Для восстановления вливал, конечно, родной бэкап.

Вот тут что то не понял.
Прежде чем в уже нерабочую флешку лить родной дам, сливал уже второй раз
там всё верно как и записывал (id заменён)

Он наверное имеет в виду, пробовать заменять по 1 байту и заливать, потом каждый раз проверять.

Я думаю, что это контроллёр обнаруживает критическое количество ошибок - несоответствие хеш-суммы в 16-ти байтах после этого сектора, которые контролируют целостность данных этого же сектора (это как MD5 сектора). На самом деле там не все 16 байт контрольных, а кроме первых 4-ёх, которые во всех секторах одинаковые.

Поэтому, я так думаю, некоторые контроллёры замечают изменение 4-ёх байт MSID и заносят этот сектор, как бэд-блок в свою таблицу. Но вот некоторые контроллёры, почему-то этого не замечают и пропускают подвох, и прекрасно дают работать сервисной карте.

Frostegater, предлагает попробовать заменить только 1 байт и проверить на работоспособность карты. Если всё нормально, то заменить следующий байт и т.д.