LINUX.ORG.RU

Два изначально идентичных файла отличаются одним битом

 , ,


3

7

Столкнулся с сабжем, неправильный файл (JPEG-картинка) лежит на одном компьютере, правильный в нескольких экземплярах, скопированных с тогда ещё правильного файла, в архивах на другом. Между операциями копирования файла и сравнения происходило выравнивание разделов на первом компьютере, но, учитывая что файлы отличаются всего одним битом, думаю это лишь косвенная причина. Где-то в интернетах проскакивала мысль что такое могло произойти из-за физических свойств жёсткого диска, когда в одно место всё время пишутся единички, а потом внезапно нолики — при чтении всё равно могут получиться единички из-за того что жестяк не может размагнитить эту область. Возможно ли такое и какие ещё причины могут вызывать такое отличие?

★☆

Последнее исправление: CYB3R (всего исправлений: 1)

Так можно параноиком стать. Срочно проверяй все остальные файлы!

UPD Ого, 5 человек подписаны, похоже это эпидемия.

orm-i-auga ★★★★★
()
Последнее исправление: orm-i-auga (всего исправлений: 1)

Где-то в интернетах проскакивала мысль что такое могло произойти из-за физических свойств жёсткого диска, когда в одно место всё время пишутся единички, а потом внезапно нолики — при чтении всё равно могут получиться единички из-за того что жестяк не может размагнитить эту область. Возможно ли такое и какие ещё причины могут вызывать такое отличие?

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

Гораздо вероятнее такая хрень из-за оперативной памяти. ECC - рулит.

Deleted
()

в процессе выравнивания раздела прилетела частица из космоса и поменяла бит в RAM %)

Harald ★★★★★
()
Ответ на: комментарий от Deleted

Там используются какие-то простенькие проверочные суммы

Там используется ECC по алгоритму Рида-Соломона, который надёжнее кодов Хэмминга, используемых в ECC RAM :) Обусловлено это гораздо меньшей надёжностью носителя и, соответственно, гораздо большим шансом нарваться на ошибку.

redgremlin ★★★★★
()

какие ещё причины могут вызывать такое отличие?

1. Стеганография: это условный сигнал «штирлицу».
2. Однобитовая часть трояна/вируса, остальные биты загрузятся позже :)

quickquest ★★★★★
()
Ответ на: комментарий от redgremlin

Там используется ECC по алгоритму Рида-Соломона, который надёжнее кодов Хэмминга, используемых в ECC RAM :) Обусловлено это гораздо меньшей надёжностью носителя и, соответственно, гораздо большим шансом нарваться на ошибку.

Буду знать, спасибо за поправку.

Deleted
()

А точно проблема не софтовая? Может быть, умный просмотрщик jpeg-ов поставил какой-нибудь флаг в файл?

Sadler ★★★
()

вот оно! найден человек, который обнаружил порчу одного случайного бита в файле. Голосую за ошибку памяти - если рассматривать контроль ошибок, это самое узкое место в потребительских выч.устройствах,

Deleted
()

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

Deleted
()
Ответ на: комментарий от Deleted

При передаче по сети, например, зачастую вообще отсутствует контроль ошибок

Контрольные суммы, не? На уровне Ethernet, IP, TCP как минимум. 100% надёжности они конечно не дают, но вероятность их все проскочить очень маленькая

Harald ★★★★★
()

Может быть виновато что угодно.

Была как-то проблема с raid-контроллером, который иногда, после передачи определённой последовательности данных (минимальный размер последовательности который удалось идентифицировать был где-то в 1 МБ) портил один бит. Засекли на передаче многогигабайтных архивов.

Evgueni ★★★★★
()
Ответ на: комментарий от Sadler

Может быть, умный просмотрщик jpeg-ов поставил какой-нибудь флаг в файл?

Сильно вряд-ли, эти картинки с момента последней архивации не просматривались и изменённый бит находится где-то в середине файла, а не в начале.

h578b1bde ★☆
() автор топика

А в каком по счёту байте находится этот бит и в какой позиции? Можешь сам файлик показать?

Harald ★★★★★
()

тебя ж за/раз-банили. или ты опять?

MyTrooName ★★★★★
()
Ответ на: комментарий от Deleted

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

Точно не оно, т.к. переданный файл — правильный. Кроме того, на том же компьютере где бит изменился, также есть копии, совпадающие с „правильным” файлом на другом компьютере. Также сравнение в том числе этих файлов на двух компьютерах проводилось раньше и тогда они были одинаковыми.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от Harald

Можешь сам файлик показать?

Вечером смогу.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от Harald

windows image viewer.

в старых версиях при повороте картинки сразу сохранял результат в файл.

под онтопик таких не знаю, потому что если встречаю - сразу выкидываю

MyTrooName ★★★★★
()
Ответ на: комментарий от Evgueni

минимальный размер последовательности который удалось идентифицировать был где-то в 1 МБ

Да, эти файлы весят несколько мегабайт, но рейд-контроллера нет.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Зато есть дисковый контроллер, ethernet контроллер и куча других контроллеров, да и просто диск, каждый из которых может сбоить как на постоянной основе, так и на временной.

Evgueni ★★★★★
()

При битой памяти такое может быть.

anto215 ★★
()
Ответ на: комментарий от Harald

Контрольные суммы, не?

Да, но есть слабые места. Например, при NAT пересчитывается контрольная сумма TCP. При том что NAT обычно делается девайсами, не отличающимися особой надежностью. Ethernet FCS вообще действует в кабеле от сетевушки до сетевушки. В любом бридже пакет может храниться в памяти без контрольной суммы.

Реально выручает заворачивание сессии в SSL или SSH.

Deleted
()

Один известный юзерскрипт даёт возможность постить картинки как раз с изменённым битом - для обхода проверки на дубликат вроде как. А картинка всё равно отобразится, jpg же.

Bfgeshka ★★★★★
()
Ответ на: комментарий от Harald

только после этого бита отображаться будет мусор

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

h578b1bde ★☆
() автор топика

нет, не так: два идентичных бита, отличаются файлами...

anonymous
()

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

anonymous
()
Ответ на: комментарий от Harald

Как и обещал:

Правильный файл: https://cdn.anonfiles.com/1410879785382.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879694795.jpg
Позиция в байтах: 0x275431

И ещё одна пара из того же каталога:
Правильный файл: https://cdn.anonfiles.com/1410879941314.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879888590.jpg
Позиция в байтах: 0x1F8431

h578b1bde ★☆
() автор топика

Странно, что никто не сказал «виндопроблемы».

Gotf ★★★
()
Ответ на: комментарий от Harald

в процессе выравнивания раздела прилетела частица из космоса и поменяла бит в RAM %)
частица из космоса

Угадал 8)

h578b1bde ★☆
() автор топика
Ответ на: комментарий от pylin

Товарищ намекает что это мол тестовое задание Касперыча

Я не в курсе чего там у свинсперского, у меня реальная ситуация.

И, кстати, уверен что байт ровно один?

Да. И не байт, а именно бит, ссылки на файлы запостил выше.

h578b1bde ★☆
() автор топика

Санкции, импорт нулевых битов в РФ резко сократили.

fero ★★★★
()

какие ещё причины

1. Хреновый шлейф к венику подцеплен. Или контакты. Или разъёмы. Или контроллер.
2. Глючит ОЗУ. ЕЦЦ нема. Или очень магнитно. Или перегрев. Или разгон.
3. Глючит камень. Адовые электромагниты. Или просто глючный.
4. Глючит ОС или софт, занимающийся копированием. Всякое бывает.
5. Ключит промежуточный носитель. Сетевуха, флешка, дискета, болванка и любое другое может запросто сбойнуть.

Goury ★★★★★
()
Ответ на: комментарий от darkenshvein

атрибут файла, поди?

Атрибуты файлов пишутся в служебные области ФС, а не посреди самих файлов. Или ты о чём-то другом?

h578b1bde ★☆
() автор топика
Ответ на: комментарий от darkenshvein

даже если они в архиве?

Расскажи каким образом наличие атрибутов файла в архиве влияет на его целостность, ага. Пути к файлам внутри архива тоже внутри картинок пишутся?

P.S. Если что — „неправильный” файл не архивировался.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от Deleted

т.е. ты всегда побайтово сравниваешь файлы

В этом каталоге — да.

и тут внезапно обнаружил что matrix has you?

Угу. Сейчас вот иду за белым кроликом пишу рыжей белке.

h578b1bde ★☆
() автор топика

Раскопал у себя на том же разделе ещё пару фильмов (mkv), у которых контрольные суммы известны и раньше совпадали, но теперь не совпадают с моими, разбил их на куски по 50 мегабайт (52428800 байт) и сравнил их, в результате у одного фильма с изначальным размером 5.22 гигабайт (5612823907 байт) три фрагмента:

фрагмент 3, позиция 0x16BC42B, байт 0xBC → 0xAC;
фрагмент 74, позиция 0x0D9642B, байт 0x14 → 0x04;
фрагмент 80, позиция 0x219642B, байт 0x31 → 0x21;

и у другого с изначальным размером 7.77 гигабайт (8352445490 байт) восемь фрагментов:

фрагмент 22, позиция 0x08BC42B, байт 0x75 → 0x65;
фрагмент 48, позиция 0x134E42B, байт 0x34 → 0x24;
фрагмент 77, позиция 0x30EE42B, байт 0xFC → 0xEC;
фрагмент 81, позиция 0x08EE42B, байт 0xF8 → 0xE8;
фрагмент 118, позиция 0x072B42B, байт 0x35 → 0x25;
фрагмент 127, позиция 0x251B42B, байт 0xF8 → 0xE8;
фрагмент 140, позиция 0x1B1B42B, байт 0xD0 → 0xC0;
фрагмент 152, позиция 0x1AFB42B, байт 0x1F → 0x0F;

различаются одним байтом.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Упс

Не посмотрел что это hex.

Как и обещал:

Правильный файл: https://cdn.anonfiles.com/1410879785382.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879694795.jpg
Позиция в байтах: 0x27542B

И ещё одна пара из того же каталога:
Правильный файл: https://cdn.anonfiles.com/1410879941314.jpg
Неправильный файл: https://cdn.anonfiles.com/1410879888590.jpg
Позиция в байтах: 0x1F842B


Пофиксил.

h578b1bde ★☆
() автор топика

Т.е. согласно этой статистике видно что все позиции заканчиваются на 0x42B и первая половина байта в этих позициях имеет склонность уменьшаться на единицу (т.е. в битах вместо, например, 11111111 на выходе имеем 11101111).

cast Harald

h578b1bde ★☆
() автор топика
Ответ на: комментарий от anonymous

картинки в jpeg

Смотри выше про mkv и описанную мной закономерность. Проблема не в формате, проблема на более низком уровне.

h578b1bde ★☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.