"Сырые" и "сухие" сектора
IEC 908 —– стандарт на аудио-компакт диски, вышедший в 1982 году в книге с красной обложной (и потому вполне официально называемой "Красной кКнигой" —– Red Book) описывал сектор как логический блок с длиной в 2352 байта, не имеющийх никаких дополнительных полей и представляющийх собой сплошной аудио-поток оцифрованной музыки. Что ж, логично! Сектора всех остальных накопителей (дискет, винчестеров) на логическом уровне устроены совершенно аналогично и различаются разве что длиной (в частности длина сектора гибких/жестких дисков равна 512 байтам).
К сожалению, попытка непосредственного использоватьния аудиоа диска для хранения данных оборачивалась неизменной потерпела неудачуей. Слишком высокая плотность записи в купе с техническим несовершенством механизма чтения привели к тому, что при воспроизведении диска постоянно возникали ошибки, количество которых на 10-секундном участке трека могло доходить до двухсот! Для аудио это считалось вполне нормальноым(что русскому хорошо, то немцу – смерть), поскольку сбойные биты легко выправляются интерполяцией и хотя достоверность воспроизведения аудио-потока при этом уже не гарантируется, человеческое ухо (даже хорошо тренированное!) все равно не замечаететит разницы, а потому увеличение плотности записи в угоду емкости диска выглядело вполне оправданно.ым.
Естественно, для исправления ошибок, возникающих при чтении файлов данных, методика интерполяции абсолютно непригодна и с вероятностью близкой к единице считанный файл окажется безнадежно изуродованным. Для решения этой проблемы пришлось увеличить избыточность записываемой на лазерный диск информации и ввести дополнительные корректирующие коды. По соображениям совместимости с уже имеющимся оборудованием (и производственными мощностями в том числе!) существующий формат хранения информации был полностью сохранен, но к нему добавился еще один уровень абстракции.
Стандарт "Желтой книги" (Yellow Book), вышедший в 1983 году, описывает сектор, как сложную структуру состоящую из 12-байтовой синхропоследовательности, 4-байтового заголовка, 2048-байтовой области данных, 4-байтового поля кода коррекции EDC, 8-байтовой дополнительной вспомогалтельной области (Auxiliary) и 276-байтового поля кода коррекции ECDC (см. рис. 1.0х039).
Рис. 1.9. унок 9 0х039 Сектора различных типов
Естественно, аппаратная начинка привода CD- ROM скрывает все эти подробности и выдает содержимое служебных полей только по специальной команде (которую, кстати говоря, поддерживают не все модели). С программисткой точки зрения 2048 байта пользовательской области данных —– это и есть та минимальная порция информации с которой штатный привод долженможет работать. Кстати, просто Замечательно, что в результате урезания "настоящего" сектора, длина логического сектора оказалась кратной размеру секторов остальных устройств! Так какие проблемы и зачем, срывая уровни абстракции, лезть в такуюкуда вкуда-то вглубь? А вот зачем. – Манипулируя со служебными полями, вы можете ктак создавать диски не копируемые штатными средствами, так и взламывать защитные механизмы, препятствующие несанкционированному копированию.
Итак, Если вы еще не особенно утомились сухой теорией, то совершим еще один рывок и рассмотрим формат сектора для режима MODE 1 (рис. 1.10) (на случай вашего воодушевления хочу сказать, что теория скоро закончится и начнется увлекательный процесс исследования диска под "микроскопом").
Рис. 1.10.унок 10 0х041 Формат сектора для режима MODE 1
q Поле синхронизации (Syncronistion) состоит из следующей последовательности: 00h FFh FFh FFh FFh FFh FFh FFh FFh FFh FFh 00h и служит индикатором начала сектора.;
q Поле заголовка (Header) состоит из четырех байт, первые три из которых занимает физический адрес данного сектора (Sector Address), заданный в формате минуты:секунды:фреймы, а последний, четвертый байт, определяет формат оставшейся части сектора (Mode); если Mode == 0, то остаток сектора (а это без малого 2336 байт) трактуется как User Data и считывается без какой-либо дополнительный обработки; если же Mode == 1, то остаток сектора приобретает вид, изображенный на рис. 1.10 0х041 (как раз о нем мы сейчас и говорим!); естественно, существуют и другие режимы, но в силу их невысокой распространенности подробно останавливаться на этом вопросе мы не будем, а любопытствующих отошлем к соответствующим спецификациям.
q 2048 байт Областьи пользовательских данных (User Data) 2048 байт, которые, как и следуют из их названия области, представляют собой непосредственно хранимую полезную информацию.;
q Четырехбайтовое поле EDC содержит в себе контрольную сумму сектора, вычисляемую по следующему полиному: P(x) = (x16 + x15 + x2 + 1) ´ .(x16 + x2 + 1), причем наименьший значимый бит четности (x0) записывается в наивысший значимый бит контрольной суммы, а сам подсчет контрольной суммы осуществляется с наименьшего значимого бита данных.
q Вспомогательное поле Intermediate -поле хранит в себе восемь байт нулей и реально никак не , если честно, я не совсем понимаю как оно используется (по-видимому, оно не используется вообще, во всяком случае, защитными механизмами —– точно!).;
q Поля P-parity и Q-parity с длиной в 172- и 104-байта соответственно, вмещают в себя так называемыеющие корректирующие коды Рида-Соломона (Reed-Solomon), математический принцип действия которых, равно как и сам алгоритм их генерации, здесь излагать было бы слишком утомительно, да и не нужно, поскольку все это уже подробно описано в стандарте ECMA-130. Тем более, что для подавляющего большинства задач умения вычислять корректирующие коды и не требуется, —– чаще всего их просто "забивают" всякой бессмысленной чепухой, имитируя тем самым неисправимую ошибку чтения сектора (то есть, попросту говоря, эмулируя физические дефекты поверхности за счет создания логически не читающихся секторов —– для взлома защит, привязывающихся к физическим дефектам —– это самое то!);
