Автор: admin

Відновлення з незвичайного зовнішнього накопичувача

Posted on by admin
    Потрапив до нас на відновлення незвичайний жорсткий диск – зовнішній USB2.0 1.8 “Samsung S1 Mini c проблемою« Не зчитуються файли ». Диски рідкісні, малопоширені, можна сказати екзотика. Ось він в порівнянні зі звичайним 2.5 “диском:
 
  Попередня діагностика показала, що диск має пошкодження, які як мінімум потрапили на структури файлової системи.
  Диски цієї серії мають відмінну рису – інтегрований USB інтерфейс, розташований безпосередньо на платі жорсткого диска. Через USB неможлива повноцінна робота з пошкодженими накопичувачами, тому випадок пообіцяв бути цікавим і непростим.
   Для відновлення даних при таких пошкодженнях абсолютно необхідний прямий доступ до накопичувача за основним інтерфейсом (SATA або PATA), тому приступимо до розтину і оцінці того, що нас чекає далі:
  Усередині пластикового кейсу виявився Samsung HS20YJZ c USB-містком JM20335, а значить диск має фізичний інтерфейс PATA. Що ж, випадок дійсно складний, але немає нічого неможливого. Необхідно розпаювати вручну інтерфейс PATA через додатковий перехідник. Готуємо робоче місце, включаємо відеомікроскоп і починаємо розпаювання:
Для роботи з такими випадками використовуємо дуже тонкі жала паяльника і спеціальний ізольований провід, пайка проводиться під мікроскопом. Подібним чином распаиваются монолітні «флешки», наприклад MicroSD. Технологія у нас відпрацьована, так що подібних випадків не боїмося. Кілька годин копіткої роботи – і можна досліджувати диск далі! П’ємо каву і приступаємо до етапу безпосередньо відновлення даних. Тут вже несподіванок немає: як і передбачалося, диск був вдарений і має пошкоджені області в призначеній для користувача зоні. Запускаємо звичайний в таких випадках процес вичитки зайнятого корисними даними простору диска. Через деякий час отримаємо фінальний результат, можна сказати відмінний: відновлено все необхідне замовнику.
Happy END!

Ручне відновлення даних з тому NTFS

Posted on by admin
     У цій статті покажу, як ми відновлюємо дані з дисків, де є пошкодження файлової системи, на прикладі NTFS.
     В даному випадку маємо том NTFS з втраченими BOOT секторами і затертими першими MFT записами в обох копіях. Розділ не визначається в Windows. Можна, звичайно, скористатися однією з сотні програм автоматичного відновлення видалених / втрачених даних, але це не наш метод. Такий спосіб не дає гарантії того, що знайшлися всі дані, часто різного роду R-Studio “втрачають” деякі папки і файли, як ніби їх і не було, або додають в дерево відновлених файлів багато зайвого «сміття», яке залишилось на диску від попередніх установок ОС, перерозподілу диска, дефрагментації та іншої життєдіяльності.
   Запускаємо Hex редактор, починаємо аналіз з BOOT сектора:
   Замість звичного NTFS boot сектора бачимо тріски після мишей «сміття». У цьому місці трохи пізніше відтворимо правильну boot структуру. Проскануємо диск для пошуку структур NTFS, подивимося скільки і яких знайшлося MFT записів, а знайшлося багато цікавого:
   Відразу кидається в очі великий  безперервний ланцюжок з адреси 6291551- це основне тіло шуканої файлової системи. Однак записи з номерами від 0 до 16 або невалидні, або зовсім порожні. Відсіюємо файлові записи з не цікавими для нас залишками інших файлових систем і приступаємо до аналізу MFT # 0 шуканої:
   Ясно-зрозуміло, диск ще й форматувати, створена нова $ MFT. Розмір – 64 кластера.
Значить, потрібно відтворити оригінальні записи boot і MFT # 0, тоді можна буде зібрати повне дерево каталогів. Також для повноцінного аналізу нам знадобиться оригінальний файл $ Bitmap (карта зайнятого простору тому) – це дозволить оцінити якість відновлення за оцінкою обсягу зайнятого простору. Знаючи характерні місця розташування цього метафайлу і його приблизний очикуваний вміст, знаходимо його за адресою LBA 6231879:
   Для перевірки знайденого файлу обчислюємо його розмір згідно з припущенням, що диск використовувався цілком під NTFS і використовувався стандартний розмір кластера: 1953520000/8 / (512 * 8) = 59616 секторів. перевіримо:
   В яблучко! Тут ми бачемо кінець диска, маркований як зайнятий простір. Далі справа техніки: створюємо нову boot структуру, вручну в редакторі записи MFT вписуємо в MFT # 0 обчислений кластерний ланцюжок (тут він один, але буває й сотня-друга), створюємо для неї новий Bitmap запису. Потім можна перевірити валідність отриманого файлу $ MFT по останніх записах, зазвичай воні порожні, але з заголовком:
Все збігається. Будуємо дерево каталогів за отриманим файлом, зайнято 785 Gb:
  Просто чудово – втрат немає, дерево повністю цілісне. Звіряємося за обсягом c картою зайнятого простору тому:
  Разом, не віднесеного до файлового дерева залишилося всього 506 Мб даних. Перевіримо ці дані за допомогою аналізатора за змістом і переконаємося, що вони є індексними записами, а це означає, що  результат відмінний і без втрат!
  Все, можна зберігати всі файли з відновленої файлової системи, перевіряючи паралельно вміст файлів по відомим заголовкам і повідомляти клієнтові про позитивний результат!

Відновлення відеофайлів з камери Canon LEGRIA HF G30

Posted on by admin
    Звернувся до нас клієнт з банальної, здавалося б, проблемою – видалив з карти пам’яті відзнятий відеокамерою Canon LEGRIA матеріал. Більшість відразу скаже: «так скористайся будь-якою програмою по відновленню видалених файлів, в чому проблема?». А проблема, виявляється, є, і суттєва. Всі сучасні камери, з якими ми стикалися – створюють на носії файли в фрагментованому вигляді. Це стосується всіх камер, які зберігали відео в форматі Apple QuickTime (mov / mp4). Наочні приклади – дзеркальні фотокамери Canon, екшн-камери GoPro та їх безіменні аналоги, автомобільні відеореєстратори.
    Коротка ремарка по вмісту файлів в зазначеному форматі: файл має складну вкладену структуру, кожен елемент даних називається атомом. Більш детальну інформацію можна знайти за посиланням, тут залишу лише пояснювальну картинку:

    Продовжимо. Після банального видалення файлів втрачається найважливіше – інформація про розташування фрагментів (кластерний ланцюжок) файлів. Відразу уточнюю – ситуація, про яку я розповідаю, вірна для файлової системи FAT32. Для NTFS або ExFAT ситуація може бути іншою. У випадку з FAT32 і видаленими фрагментованими файлами існує всього два методи їх відновлення:
  1.     Пошук і аналіз на носії безпосередньо відеопотоку і відтворення для нього необхідних службових метаданих, та
  2.     Аналіз службових метаданих відеофайлів та збирання фрагментів вручну за знайденими зачіпками.
    Ми вже неодноразово працювали з різними відеоформатами, і знаємо, що далеко не кожен потік відео / аудіо даних можна відновити і відтворити без супровідних службових метаданих. Наприклад, простий формат MPEG-2 – є потоковим, і для його відтворення не потрібні ніякі додаткові службові дані – просто сирий потік даних, вирівняний по межі фрейма. Такий потік можна відновити першим методом і не витрачати час на службові дані. Також першим методом можна відновлювати сирий відеопотік без службових даних, навіть якщо він був в Apple QuickTime контейнері (mov / mp4), за умови використання певного відеокодека. Однак дана відеокамера створює файли з відеопотоком, який не залишає шансів на відновлення першим методом:
    В такому форматі немає ніяких «зачіпок», щоб відокремити фрейми з відео і аудіо даними друг від друга. Вони йдуть суцільним потоком, а інформація про те, де знаходяться межі фреймів – збережена в службових атомах trak. Ці метадані записуються камерою у вигляді окремого фрагмента в віддаленому від основного потоку даних місці носія. Причому, як показали наші дослідження, кожна камера записує на носій фрагменти файла неоднаково, скрізь використовується різний алгоритм їх розміщення. Десь цей алгоритм простий, і його можна відтворити, отримавши на виході повністю дефрагментовані та робочі відеофайли (дзеркалки Canon). У випадку з піддослідною відеокамерою – ніякої особливої ​​закономірності немає – камера просто пише метадані в одну частину носія, а відеопотік – в іншу. При цьому метадані можуть додатково фрагментуватися. Загалом, все погано, і завдання на перший погляд виглядає нездійсненним.
    Однак, вивчивши в HEX-редакторі кілька прикладів відеофайлу з піддослідної камери, був придуманий алгоритм збірки «фрагментів» за ​​маркерами з вмісту файлу. Для вирішення завдання необхідно повністю проаналізувати приклад файлу, зрозуміти які атоми використовуються, яку інформацію з них ми можемо використовувати для прив’язки, і як потім, знаходячи вміст цих атомів на носії, з’єднати знайдені фрагменти в єдине ціле. Для розуміння первинної структури використовуємо MP4 Explorer:

   Структура стандартна. Атом mvhd з часом створення файлу виявився для нас дуже важливим – за часом створення можна пов’язати знайдений на диску фрагмент з атомами trak з початком файлу, фрагментом ftyp. Глянемо на початок файлу в HEX вигляді:
   Тут в службовому атомі CNTH-> CNDA знаходиться картинка-передперегляд файлу, в якій дуже вдало для нас є дата створення файлу в текстовому вигляді. Ця інформація стане в нагоді далі. Як виявилося, камера при формуванні метаданих резервує фіксоване місце під цю картинку, а також під коментар користувача камери, який можна помістити в службовий атом udta. Ну а найголовніше, що атом з безпосередньо медіапотоком, mdat – записується камерою найчастіше нефрагментованим. І знову дуже вдало – в цьому атомі є за що зачепитися для пошуку відповідного йому атома mhvd і ftyp.
     Приступаємо до створення інструменту для відновлення – створюємо новий проект в С ++ Builder:
     Перший же прохід новоствореним аналізатором по носію показав, що шанси на успіх непогані, але попереду багато роботи.

   По ходу написання інструменту визначаємо алгоритми валідації цілісності знайдених фрагментів, як виявилося – це реально. Знайшлись заголовки файлів і секції mdat з медіапотоком:

   Після цього обробляємо масив знайдених даних, аналізуємо ті атоми, які можемо, і навіть перевіряємо на нефрагментованість знайдені контейнери.

     Непогано, частина метаданих знайшлася єдиним фрагментом, але є й фрагментовані. З ними будемо розбиратися пізніше. Далі пов’язуємо знайдені фрагменти з метаданими з відповідними їм атомами mdat і зберігаємо отримані відеофайли, попутно перевіряючи їх вміст окремою функцією-валідатором структури атомів:

FILE 043A8B6B.mov check ok!
FILE 01010D52.mov check ok!
FILE 019E9DAD.mov check ok!
FILE 017FC7C4.mov check ok!
FILE 00BFA3DE.mov check ok!
 

   Перевіримо відновлені файли:


   Все програється! Ура, але ще залишилося близько 20% невідновлених файлів, метадані яких виявилися фрагментовані. Пишемо для них окремий складальник, який зв’яже знайдені фрагменти початку і середини метаданих, спираючись на дату створення файлу:

    У підсумку програма зібрала нам ще частину робочих файлів.
    На даному етапі залишилося всього 25 фрагментів з метаданими, які не вдалося зібрати в цілісні файли. Зберігаємо всі фрагменти, що залишились, у вигляді окремих файлів, та з’єднуємо ці фрагменти вручну, спираючись на знання про те, що де має лежати всередині файлу. Як виявилося, метадані цих 25 файлів були сильно фрагментовані – від 3 до 5 фрагментів. Однак через кілька годин копіткої роботи всі до єдиного файли вдалося зібрати.
    Як результат, ми отримали рівно 244 робочих файлів, що є 100% успішним відновленням (трохи вище в тексті можна побачити кількість знайдених заголовків файлів – їх було 244).
    Клієнт залишився дуже задоволений, тому що весілля перезняти вже неможливо …

Як ми з карт пам`яті відновлюемо інформацию

Posted on by admin

«Тут вся моя подорож до островів!»

 

 З такими словами клієнт передав нам MicroSD картку зі смартфону. Картка не визначається нормально картрідерами, ємність 0.5 КБ. Звичайна проблема – пошкодження таблиць трансляції або вбудованих мікропрограм. Єдиний метод відновлення – читання вмісту NAND пам’яті минаючи контролер, після чого збірка отриманих «сирих» даних в те, що нам звично бачити як файли. Зі звичайними флешками проблем немає – Випаюємо чіпи пам’яті, читаємо программатором. Але з цієї карти пам’яті нічого випаювати – вона сама по собі і є єдиний чіп. Єдиний шанс – підпаятись до електричних доріжок під захисним лаком, якщо звичайно вони там є…

 

Знімаємо захисний шар:

 

          Так – завдання очевидно розв’язуване, але непросте. Діаметр перехідних отворів близько 0.2 мм, частіше бувають більшими. Головне – на цю задачу є пінаут, тобто розташування потрібних нам доріжок заздалегідь відомо. Без нього завдання все ще залишиться розв’язуваним, але складність сильно виростає – потрібно обчислювати призначення кожної доріжки, щоб знайти потрібні нам.

          Готуємо робоче місце, мікроскоп, надтонкий провід і спеціальну перехідну плату, де буде «жити» піддослідний накопичувач:

 

 

 Через декілька годин копіткої праці, маємо на результат:

 

   Що ж, тепер саме час прочитати ID пам’яті, і якщо все добре, приступати до читання її вмісту: 

 


   Відмінно! Є результат. Однак цей результат – не файли користувача. Тут ще «пиляти і пиляти»: має бути трохи магії багато годин роботи по корекції вичитаних даних за допомогою кодів корекції помилок ECC, обчислення параметрів збірки й аналіз отриманого образу:

 

Після ще кількох чашок кави і магічних заклинань отримуємо те, заради чого було розпочато цей довгий і складний шлях:

 

Дзвонимо клієнту, кличемо його глянути результат й випити з нами кави 

 

Якщо у вас перестав працювати вінчестер

Posted on by admin

     Звичайному користувачеві і навіть “сисадміну” робити в гермоблоці нічого. Повірте, там немає нічого, що потрібно змащувати, протирати, паяти, рихтувати. Відкривши кришку, Ви свої дані не побачите, вони не висипляться звідти. Навпаки, навіть просто розкривши гермоблок, сильно зменшуєте шанс успішного відновлення даних, не кажу вже про будь-які маніпуляції з БМГ (Блок Магнітних Головок) і пластинами.

    Не варто міняти плату електроніки, якщо Вам здається, що справа в ній, навіть якщо дійсно є згорілі елементи. По-перше, на сучасних дисках їх дуже багато схожих між собою, але не сумісних – ні електрично, ні програмно. Навіть якщо вона точно така, з такою самою моделлю – можуть бути різні версії вбудованого мікрокоду, знову ж таки, не сумісні між собою. Більш того, деякі диски мають своєрідний захист від таких перестановок, що навіть повернувши потім плату електроніки на рідний для неї гермоблок, цей жорсткий диск теж вже працювати не буде, як і Ваш.

    Якщо вінчестер видає якісь страшні звуки: стук, скрегіт, завивання при розкручуванні двигуна, не потрібно довго їх слухати, кращий варіант – вимкнути і привезти його до фахівців, які зможуть поставити правильний діагноз, наприклад, до нас. А якщо накопичувач при цьому ще й визначається і повільно копіює дані, які в поспіху рятуєте, запам’ятайте – Ви це робите на свій страх і ризик. Найчастіше подібне закінчується тим, що вдається (чи ні) зберегти частину інформації своїми силами, але подальше відновлення навіть компетентними в цих питаннях людьми буде ускладнене або неможливе.

   Трапляються ситуації, коли перестає нормально функціонувати одна з (або кілька) головок, при цьому  диск ще визначається, навіть якось читає і пише інформацію. Але проблема полягає в тому, що ті дані, які записуються, надалі не можуть бути прочитані. Грубо кажучи – дані, записані несправною головкою, спотворені настільки, що вінчестер вважає ці сектори дефектними (так звані софт-беди). Тому, якщо Ви помітили, що дискові операції стали більш повільними, а так само деякі файли вже не можуть бути прочитані або записані – вимкніть комп’ютер, краще навіть моментально, з розетки, це “менше зло”, ніж та шкода, якої може завдати напівпрацюючий БМГ.