Ru-Board.club
← Вернуться в раздел «Магнитные носители информации»

» Восстановление информации с Flash - накопителей

Автор: Alex_Green
Дата сообщения: 05.11.2015 03:28
ICQman2GO
И всё-таки хотелось бы также увидеть сокращенный список кластеров PICT 0023. Кажется там вообще нет тех кластеров, которые якобы перезаписали файл 0005. Так что верить этим показателям по видимому нельзя. Здесь похоже имеет место неоднократная перезапись.
Автор: Big_Endian
Дата сообщения: 07.11.2015 16:37


Цитата:
ICQman2GO

Cluster 1300
[Omitted: 12 885]
Cluster 14186 (16064)


Одним фрагментом файл был записан, но это вам не помогло.
Из 12885 кластеров уцелели только 1163. Всего менее 10% и в разных местах.
Сомневаюсь, что из этого выжмете что-то полезное. Мои вам соболезнования...
Автор: temp9285
Дата сообщения: 08.11.2015 12:40

Цитата:
Из 12885 кластеров уцелели только 1163.

Это если исходить из "постулата" что 1300-й и далее занят PICT0023
Но листинг кластеров "виновника" показывает что он расположен совсем в другом месте.

Возможно и остальные "перекрытия" из той же серии.
Впрочем, как и "первый" кластер нужного.
Автор: temp9285
Дата сообщения: 09.11.2015 00:12
ICQman2GO
Насколько понимаю, у тебя посекторный образ всего диска, а не только раздела.
Если так, то хотелось бы увидеть дампы секторов (из DMDE):
3840, 8475520, 12669824
И ещё (всё таки) скриншот карты кластеров с курсором наведённым на кластер 1300 - последнее делать применительно к логическому разделу.
Автор: ICQman2GO
Дата сообщения: 09.11.2015 21:24
Alex_Green

Цитата:
И всё-таки хотелось бы также увидеть сокращенный список кластеров PICT 0023.

[more=ShortenListClastersPICT0023]Cluster 153100
[Omitted: 2 226]
Cluster 155327
-----
Cluster 155329
[Omitted: 1 922]
Cluster 157252
-----
Cluster 157254
[Omitted: 1 686]
Cluster 158941
-----
Cluster 158943
[Omitted: 1 602]
Cluster 160546
-----
Cluster 160548
[Omitted: 1 702]
Cluster 162251
-----
Cluster 162253
[Omitted: 2 110]
Cluster 164364
-----
Cluster 164366
[Omitted: 2 206]
Cluster 166573
-----
Cluster 166575
[Omitted: 2 006]
Cluster 168582
-----
Cluster 168584
[Omitted: 1 614]
Cluster 170199
-----
Cluster 170201
[Omitted: 1 650]
Cluster 171852
-----
Cluster 171854
[Omitted: 1 598]
Cluster 173453
-----
Cluster 173455
[Omitted: 280]
Cluster 173736
-----
Cluster 155328
-----
Cluster 157253
-----
Cluster 158942
-----
Cluster 160547
-----
Cluster 162252
-----
Cluster 164365
-----
Cluster 166574
-----
Cluster 168583
-----
Cluster 170200
-----
Cluster 171853
-----
Cluster 173454
-----
Cluster 173737 (6912)
-----

Fragment(s): 24
[/more]
Big_Endian

Цитата:
Одним фрагментом файл был записан, но это вам не помогло.
Из 12885 кластеров уцелели только 1163. Всего менее 10% и в разных местах.
Сомневаюсь, что из этого выжмете что-то полезное. Мои вам соболезнования...

Попытка - не пытка, правда товарищ Берия?

temp9285

Цитата:
Насколько понимаю, у тебя посекторный образ всего диска, а не только раздела.
Если так, то хотелось бы увидеть дампы секторов (из DMDE):
3840, 8475520, 12669824

3840
8475520
12669824

Цитата:
И ещё (всё таки) скриншот карты кластеров с курсором наведённым на кластер 1300 - последнее делать применительно к логическому разделу.

Это в DMDE? Карту кластеров открыл через меню Сервис-Карта кластеров, а как перейти на 1300й хз.
Нашел мышкой 1300й, наверное можно как-то по-другому, удобнее?



Автор: temp9285
Дата сообщения: 09.11.2015 21:37
ICQman2GO
Если не сложно, сбрось дампы в одном архиве на rghost а то что то гуглодрайв не отвечает.
Что касается карты кластеров, то всё нормально - и она подтвердила что 1300 кластер накрыт но не тем, про который утверждалось залётным специализдом.
Ну и раз уже научился пользоваться картой кластеров, то сделай ещё такое же для кластеров 66836, 132372, 197908.
Ну и ещё, раз уж попытка не пытка (хотя один скриншот намекает что бесплезно это, но это же не пытка) - выдели в DMDE нужный файл и покажи скриншот в этот момент. Ну и попробуй восстановить.

PS. Позже напишу зачем всё это.
Автор: AntiMember
Дата сообщения: 09.11.2015 21:53
temp9285
И шо, дядьки-модераторы так и оставили temp ???
Автор: temp9285
Дата сообщения: 09.11.2015 22:02
AntiMember
А что им делать, если с базой ников чой то случилось.
Тут есть и другие пострадавшие - http://forum.ru-board.com/topic.cgi?forum=84&topic=5006&start=80#9
ЗЫ: думал что забанили?
Автор: igor ne me
Дата сообщения: 09.11.2015 22:05
На правах оффтопа:
AntiMember
А я за это время дядьку Akam1 тут вроде и не видал... Ну занят видимо. Я вон тоже слегка "перекрасился" Но в сторону "уменьшения", "похудел", было 5500 где-то, стало 11 А вы однако растёте Сами то заметили?

Цитата:
Всего записей: 5002


Цитата:
Gold Member

ПАЗДРАВЛЯЕМ!
Автор: AntiMember
Дата сообщения: 09.11.2015 22:17
temp9285

Цитата:
ЗЫ: думал что забанили?

Не-е. Не аккуратно как-то.
igor me

Цитата:
А я за это время дядьку Akam1 тут вроде и не видал...

Не знаю. Я ему в личку ссыль на пропавшую ветку по сигам с потерянной шапкой кинул вчерась - появилась.

Цитата:
А вы однако растёте Сами то заметили?

Не-а. Не заметил. Не ради орденов тут, однако...

Добавлено:
И таки СПАСИБО!
Автор: igor ne me
Дата сообщения: 09.11.2015 22:19
Вот вернул своего любимого Соника на аватарку Ощущения, как тогда, пять тысяч постов и 5 лет назад. Как там в звёздных воинах:
Many many posts ago...
In a far far away forum...
Что-то напала на меня ностальгия, ну всё, хорош оффтопить.
AntiMember
Напишите мне на e-mail igor_me@inbox.ru Надо обсудить рабочие моменты...
Автор: Alex_Green
Дата сообщения: 09.11.2015 23:17
ICQman2GO


Да, что собственно и требовалось потвердить. Нужный файл перезаписан совсем не файлом PICT 0023.

temp9285

Не совсем понял если честно, для чего были запрошены дампы секторов 3840, 8475520, 12669824?
Автор: AntiMember
Дата сообщения: 09.11.2015 23:25
igorme
Написал.
Автор: temp9285
Дата сообщения: 09.11.2015 23:35
Alex_Green
Возможные варианты (*) размещения начального сектора разыскиваемого файла - ещё один не запросил, потому что ты сам его (86 912) ранее запрашивал.
Кстати, немного тоже поломал голову насчёт числа секторов в кластере, но их реально 64 - просто в одной программе показывает с учётом смещения раздела, в другой без.
PS. загляни в приват на хоботе.

(*) это в меру моих познаний в области FAT32, которые за последние несколько дней чуть увеличились. Ну и гадость же.

Речь была о секторах 8475520, 12669824
Автор: Akam1
Дата сообщения: 10.11.2015 05:33
igor ne me
AntiMember
http://forum.ru-board.com/topic.cgi?forum=27&topic=22888&start=40#7
Автор: ICQman2GO
Дата сообщения: 10.11.2015 22:10
temp9285

Цитата:
Если не сложно, сбрось дампы в одном архиве на rghost а то что то гуглодрайв не отвечает.

Я думал, это у меня только глюки с ним, раньше не подводил.
3840
8475520
12669824

Цитата:
Ну и раз уже научился пользоваться картой кластеров, то сделай ещё такое же для кластеров 66836, 132372, 197908.





Цитата:
Ну и ещё, раз уж попытка не пытка (хотя один скриншот намекает что бесплезно это, но это же не пытка) - выдели в DMDE нужный файл и покажи скриншот в этот момент.




Цитата:
Ну и попробуй восстановить.

Пробовал-не воспроизводится и пишет к примеру "unknown or unsupported file format". Можно как-то химичить с предустановками в VirtualDub, но пока открыть что-нибудь стоящее из этого файла не получается.

Автор: temp9285
Дата сообщения: 10.11.2015 23:00
[more] [more] ICQman2GO
Ок. Далее написанное лишь мои размышления.
Итак.
1. При удалении файла в его записи каталога переписывается начальный байт и, в зависимости от того что работает с ФС, могут измениться и ещё некоторые. И чтобы это определить надо провести эксперимент в котором лождаться удаления файла в используемом устройстве и сравнить запись о нём на тот момент со значением до удаления.
Могу сказать что согласно известному талмуду, правится лишь первый; в ХР и 7-ке правится ещё и ранее упомянутое старшее слово, которое отвечает за значение начального кластера файла.
В твоей записи, после удаления этот номер значится как 00 00 05 14, что соответствует 1300-ому. И если до удаления выделенный байт был 00, то всё актуально. Но он так же мог быть и 01, 02, 03 и обозначенные ранее кластера как раз соответствуют эти значениям. То есть ранее, в любом из этих кластеров, мог начинаться требуемый тебе файл.

В случае, если бы не было записи поверх, DMDE бы мог восстановить файл, чего не могу сказать про винхекс (хотя может я им не умею пользоваться). По крайней мере, в примере-задачке, которую я приводил раньше, если открыть том со второго дампа, DMDE восстанавливает файлы 01 и 08.jpg - винхекс нет. И в такой ситуации DMDE, при выделении файла, в дисковом редакторе (нижнее правое окно) показывает реальный номер начального кластера.
После перезаписи такого нет.

И в твоём случае видно что он показывает другой кластер (*)- не 1300. Вот только я не могу сказать с чем это связано, это лучше знает автор программы, но предположу что в силу того что этот кластер не перекрыт. Хотя было бы лучше если там реально было начало.
(*) и это было видно в самом начале, но я раньше про всё это не знал.

2. Результат поиска DiskDigger-а в режиме RAW-восстановления.
Не знаю алгоритмы его поиска, и как как он восстанавливает продолжение - просто отрезает сектора дальше по размеру из заголовку или ещё как; но как минимум корректный заголовок то должен быть. И он в секторе (и кластеру в котором он расположен), который фигурирует в именах файлов. Но соответствующих возможным твоим нет (**). Поэтому, можно предположить что или начало файла было не в кластере 66836 (который сейчас не занят), или там уже был другой файл который после тоже удалился.
(**) Несмотря на отсутствие таковых, можно выполнить "пытку" - считать размер из заголовка и сравнить с разыскиваем. Хотя это актуально для удалённых файлов - ведь это могут быть и существующие.

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

PS. Если что не так - сильно не пинать.
[/more] [/more]
Автор: tomset
Дата сообщения: 11.11.2015 03:21
Я бы порекомендовал попробовать GetDataBack for FAT.
Иногда она творит чудеса, если еще есть что восстановить.
Спецы которые на FAT собаку съели, гадают, как ей это удается.
После анализа всеми возможными программами и ручным поиском, которые не дали результата.
Автор: ICQman2GO
Дата сообщения: 11.11.2015 22:12
temp9285
Попробовать восстановить ICT0005 по размеру взятому из заголовка и начиная с секторов 3840, 8475520, 12669824, 86 912? А потом пытаться его поместить в контейнер avi?

Цитата:
Если из каких то данных (FAT?) можно пробить цепочку кластеров, то восстановить их. Если нет, то просто вычитать сектора по размеру файла. А затем уже заниматься имплантацией заголовков, реанимаций файлов.

А карта кластеров ICT0005, которую показывает WinHex не может считаться корректной? Т.е. если восстановить соостветствующие кластеры и собрать из них ICT0005 то это целесообразно (не считая необходимости восстановаления контейнера avi со всеми параметрами потока)?

tomset

Цитата:
Я бы порекомендовал попробовать GetDataBack for FAT.
Иногда она творит чудеса, если еще есть что восстановить.
Спецы которые на FAT собаку съели, гадают, как ей это удается.
После анализа всеми возможными программами и ручным поиском, которые не дали результата.

Попробую отпишусь
Автор: temp9285
Дата сообщения: 11.11.2015 22:45
[more]
Цитата:
Попробовать восстановить ICT0005 по размеру взятому из заголовка и начиная с секторов 3840, 8475520, 12669824, 86 912?

Нет, ты немного смешал в кучу. Я предлагал просто проверить размер в заголовках найденных авишках, и это лишь предполагая что они реально найденные "потеряшки" а не имеющиеся на носителе.
3840 не при чём, речь идёт лишь о секторах (кластерах) 86912 (1300), 4281216 (66836), 8475520 (132372), 12669824 (197908). А исходя из карт кластеров, наиболее перспективен 4281216 (66836), так как в его районе сейчас не занят. Хотя и тут два варианта:
- в этом кластере не начинался нужный файл, поэтому то и нет сигнатуры
- файл там всё таки был, но уже была не одна перезапись.
В последнем варианте есть огромное количество подвариантов - в том числе что мог быть перезаписан лишь начальный кластер, или больше, но такое количество, которое не критично при пришивании "чужой головы".
Повторюсь, но я не в курсе структуры, может есть какие то характерные сигнатуры и в других секторах, по которым можно идентифицировать тип файла (минус то, что файлы однотипные и сигнатуры могут быть идентичные).


Цитата:
А карта кластеров ICT0005, которую показывает WinHex не может считаться корректной?

Опять же, я не настолько познакомился с FAT и винхексом, чтобы давать советы. Могу сказать что в тестовых примерах, при просматривании списка кластеров для удалённого файла 01.jpg винхекс показывает список начиная с неправильного начала сектора (кластера). [/more]

Добавлено:
tomset
Знакомая песня.
Один пользователь РС3000 тоже постоянно рекомендовал эту прогу (даже в случаях когда она была бесполезна).
Возможно что и есть в ней что то эксклюзивное, но как то проводил экспериент - так она вообще не нашла какой то очень распространённый ти файла.
Автор: Alex_Green
Дата сообщения: 12.11.2015 01:52
ICQman2GO
temp9285


Цитата:
может есть какие то характерные сигнатуры и в других секторах, по которым можно идентифицировать тип файла (минус то, что файлы однотипные и сигнатуры могут быть идентичные).


В том то и дело, что в основном только AVI файлы и были записаны на карту, поэтому определить по идентичным сигнатурам, принадлежит ли какой то кусок нужному фйалу или нет, практически невозможно.

temp9285


Цитата:
Я предлагал просто проверить размер в заголовках найденных авишках, и это лишь предполагая что они реально найденные "потеряшки" а не имеющиеся на носителе.


Дык я вроде ещё в самом начале предлогал, смотреть сектора предполагаемых начал первых файлов, согласно их размерам в байтах (секторах). Не знаю конечно, как удаляет файлы регистратор, но винда по крайне мере при удалении файла, ничего не меняет в записях, описывающих размер файла в байтах. Так что даже если и начальный сектор нужного файла показан неправильным, то уж по размерам файлов определить его предполагаемое начало не так сложно. Другое дело, что там похоже имеет место неоднократная перезапись, и от файла по видимому действительно если что то и осталось, то не так много.

P.S В приват на хоботе заглянул, отпишусь чуть позже.
Автор: temp9285
Дата сообщения: 12.11.2015 16:42
Alex_Green
В самом начале я мог не понимать о чём ты пишешь.
А сейчас, насколько понял, ты предлагал смотреть размер файла и нарезать такой фрагмент - то есть предполагая что фрагментации нет (*).

Моё же предложение немного другое - считать размер файла из имеющихся заголовков и сравнить с размером разыскиваемого. Это из разряда невероятного, но может какой то заголовок соответствует.

(*) Она есть, и это видно по тому файлу, фрагмент которого накрыл 1300 кластер (начало файла дальше)
Автор: ICQman2GO
Дата сообщения: 20.11.2015 21:15
temp9285
Alex_Green

Цитата:
Моё же предложение немного другое - считать размер файла из имеющихся заголовков и сравнить с размером разыскиваемого.


Цитата:
Я предлагал просто проверить размер в заголовках найденных авишках, и это лишь предполагая что они реально найденные "потеряшки" а не имеющиеся на носителе.
3840 не при чём, речь идёт лишь о секторах (кластерах) 86912 (1300), 4281216 (66836), 8475520 (132372), 12669824 (197908). А исходя из карт кластеров, наиболее перспективен 4281216 (66836), так как в его районе сейчас не занят. Хотя и тут два варианта:
- в этом кластере не начинался нужный файл, поэтому то и нет сигнатуры
- файл там всё таки был, но уже была не одна перезапись.

Подскажи как это сделать - я начинаю плавать...
Автор: Alex_Green
Дата сообщения: 22.11.2015 16:24
ICQman2GO

Цитата:
Подскажи как это сделать - я начинаю плавать...



Ну дык можно уже было давно попробовать сохранить например диапозон секторов 86912 - 911647 в файл, затем взять заголовок от любого другого файла снятый на этот же аппарат и приклеить его к сохранённому файлу. Затем новый файл ( с приклееным заголовком) скормить какой - нибудь видеочинилке (DivFix, Virtual Dub, Video Repair Tool) и смотреть что получится. Всё-таки наиболее вероятно, что нужный файл не был фрагментирован, поэтому и имеет смысл сохранить вышеупомянутый диапозон секторов в файл, и проделать последующие пляски с бубном. Может что то и осталось от файла. Но на одну треть он как минимум перезаписан.
Автор: ICQman2GO
Дата сообщения: 20.12.2015 14:57
Alex_Green

Цитата:
взять заголовок от любого другого файла снятый на этот же аппарат и приклеить его к сохранённому файлу

Сколько секторов откусывать у файла-образца в качестве заголовка?

Еще один кейс. На 4-канальный авторегистратор велась запись поездки. 1й канал- бортовая камера, 2й - салон. Запись осуществлялась фрагментами по 30Мб в формате avi на флешке 64Гб. В фрагменте, когда произошла авария первый канал пуст (синий экран), а 2й - вплоть до 2:52 - шум, потом появляется видео. Есть ли целесообразность искать потерянную часть видео?
lba_0-100
Автор: Alex_Green
Дата сообщения: 21.12.2015 17:52
ICQman2GO
В файле lba_ 0-100 cплошные нули. Так что если это начало потерянной части видео, то восстанавливать там увы нечего. Что касается заголовка исправного файла образца, то как правило у AVI файла это первые 19- 20 секторов. Можно также закинуть на обменник первые 100 секторов от любого рабочего файла, и тогда уже можно будет точно сказать, сколько секторов брать в качестве заголовка.

Добавлено:
temp9285

Цитата:
Если из каких то данных (FAT?) можно пробить цепочку кластеров, то восстановить их. Если нет, то просто вычитать сектора по размеру файла. А затем уже заниматься имплантацией заголовков, реанимаций файлов.


К сожалению при удалении файла на FAT, цепочка его кластеров в обеих фат таблицах полностью зануляется, поэтому ничего пробить уже не получится. А нужный файл, похоже действительно лежал одним фрагментом, как заметил Big Endian. Если посмотреть на этот скриншот, то видно что разница между последним и первым сектором, соответствует размеру файла в байтах (мегабайтах). Теперь видимо можно только поэкспериментировать с приклеиванием даного участка к заголовку исправного файла, снятого на этот же аппарат.
Автор: ICQman2GO
Дата сообщения: 21.12.2015 20:27
Alex_Green

Цитата:
В файле lba_ 0-100 cплошные нули.

Исправил. Файл (образ флешки) был недоскачен.
lba_0-99 Это начало самой флешки.
Автор: temp9285
Дата сообщения: 21.12.2015 21:11
Alex_Green

Цитата:
Если посмотреть на этот скриншот, то видно что разница между последним и первым сектором, соответствует размеру файла в байтах (мегабайтах).

И это лишнее подтверждение того как могут ошибаться "идолы".
Которые базируются на теории + высасывают данные из пальца.

В этом можно убедиться посмотрев ранее выложенные мною образы.
В be4 присуствует трёхфрагментный файл fff. А в be5 он удалён - если посмотреть в винхексе его листинг кластеров, то он начнётся не в том секторе и будет однофрагментным.

ICQman2GO
После четырёх недель командировки подзабыл про эту тему, тем более что перед ней она как бы затихла.
Попробую освежить память, а пока что напомню про написанное раньше

Цитата:
речь идёт лишь о секторах (кластерах) 86912 (1300), 4281216 (66836), 8475520 (132372), 12669824 (197908). А исходя из карт кластеров, наиболее перспективен 4281216 (66836)

Автор: ICQman2GO
Дата сообщения: 21.12.2015 21:32
temp9285

Цитата:
После четырёх недель командировки подзабыл про эту тему, тем более что перед ней она как бы затихла.
Попробую освежить память, а пока что напомню про написанное раньше

Цитата:
речь идёт лишь о секторах (кластерах) 86912 (1300), 4281216 (66836), 8475520 (132372), 12669824 (197908). А исходя из карт кластеров, наиболее перспективен 4281216 (66836)


Я этот случай отложил пока.

Сейчас более интересен свежий

Цитата:
Еще один кейс. На 4-канальный авторегистратор велась запись поездки. 1й канал- бортовая камера, 2й - салон. Запись осуществлялась фрагментами по 30Мб в формате avi на флешке 64Гб. В фрагменте, когда произошла авария первый канал пуст (синий экран), а 2й - вплоть до 2:52 - шум, потом появляется видео. Есть ли целесообразность искать потерянную часть видео?


lba_0-99 флешки, на которую велась запись.
1_20151215-173212_0002p4.avi (hex)-до аварии (видео).
Файл показывает видео с 17:32:12 по 17:35:08, оба канала.
1_20151215-173628_0102p4.avi (hex)-после аварии (видео).
Файл показывает видео с 17:36:28 по 17:41:00, при этом первого канала нет, а второй появляется только на 17:39:22 (2:52 фрагмента).
Вопрос 1й - где участок (файл) с 17:35:08 по 17:36:28 ?
Вопрос 2й - где видео 1го канала с 17:36:28 и дальше ?
Автор: tomset
Дата сообщения: 21.12.2015 22:02
ICQman2GO
А что лежит в 32768 LBA и далее

Страницы: 12345678

Предыдущая тема: Как склеить обьем двух жестких дисков в один...


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.