Автоматическое копирование и обсуждение его результатов
В какой бы привод защищенный диск ни был вставлен, CloneCD выдает неизменно постоянный результат, не имеющие ничего общего с реальной действительностью. По его скромному мнению, диск содержит всего одну сессию с общей протяженностью в 4,6 мегабайт, но зато размер единственного трека последней составляет ни много ни мало – 3,9 терабайт!
ИНФОРМАЦИЯ О CD В ДИСКОВОДЕ:
Число сессий: 1
Занято на диске: 4726 Кбайт
Секторов: 2058
Время: 00:27:33 (мин:сек:кадр)
ИНФОРМАЦИЯ О СЕССИИ 1:
Размер сессии: 4726 Кбайт
Число треков: 1
Pregap: Данные Mode 1, размер: 103359 Кбайт
Track 1: Data, размер: 4294868664 Кбайт
Глоссарий
Lead-In Area – (вводная область диска). Служебная область диска по сути своей представляющая нулевой трек, всегда предшествующий первому треку PA. Каждая сессия многосессионного диска имеет собственную вводную область. Размер вводной области по стандарту составляет 9 мегабайт (60 секунд или 4500 секторов). Q-канал подкода вводной сессии содержит TOC, среди прочей полезной информации указывающей либо на адрес выводной области (закрытый диск), либо на адрес вводной области следующей сессии (открытый диск). Содержимое вводной области недоступно для чтения на программном уровне. Визуально вводная область выглядит равномерно освещенным блестящим кольцом.
Lead-Out Area – (выводная область диска). Служебная область диска, условно обозначаемая треком номер AAh и замыкающая собой всякую закрытую сессию. Выводная область служит своеобразным индикатором конца сессии и/или диска и помогает оптической головке не вылететь за пределы диска. Пишущие приводы должны корректно обрабатывать диски с незакрытыми сессиями, однако, обыкновенные приводы CD-ROM и аудио проигрыватели это делать не обязаны. Внимание! Отсутствие выводной сессии (равно как и некорректное задание ее адреса) может повредить некоторые модели приводов (один из них PHILIPS).
Емкость выводной области одно-сессионного диска по стандарту составляет 13.5 MB (6750 секторов или 1.5 минуты). Емкость выводных областей для второй и последующих сессий многосессионных дисков уменьшена до 4 МБ (0.5 минуты или 2250 секторов). Содержимое выводной области недоступно на программном уровне. Визуально выводная область выглядит равномерно освещенным блестящим кольцом.
TOC – Table Of Content (Таблица Содержимого или попросту оглавление диска). Служебная область диска, записанная в Q-канале подкода вводной области диска, так же называемой Lead-In областью (такое блестящее кольцо у внутреннего края диска). Многосессионный диск имеет несколько независимых TOC – по одному TOC'у на каждую закрытую сессию.
TOC содержит информацию о стартовых адресах вводной/выводной областей диска и атрибуты всех его треков (как-то тип трека: аудио или данные, а если данные то в каком режиме – Mode 1, Mode 2 и т. д., абсолютном стартовом адресе трека и номере соответствующей ему сессии). Так же TOC содержит часть ATIP и указатели на местоположения ее продолжения.
Непосредственно (т. е. на секторном уровне) для чтения TOC недоступен, но для извлечения его содержимого в "сыром" виде можно воспользоваться следующей SCSI/ATAPI командной READ TOC/PMA/ATIP
(операционный код: 43h) с format field == 2h.
Однако не стоит путать TOC с файловой системой – между ними нет ничего общего! Файловые системы лазерных дисках хранятся непосредственно в PM и свободно доступы для чтения на секторном уровне.
Program Area – (программная область). Область диска, расположенная между Lead-In и Lead-Out областями и содержащая информационные треки с музыкой или данными. Это – основная область диска, целиком доступная на секторном уровне с паузами между аудио треками включительно.
[1]
правда, это умение даровано не всем программам, вот Roxio Easy CD Creator'у оно даровано, а, например, Stomp Record Now! – нет
[2]
уменьшение свободного пространства объясняется тем, что каждая открываемая сессия требует для своего размещения определенного места, однако, если удалению одних файлов сопутствует запись других, то открывать новую сессию по любому приходится и в этом случае, накладные расходы на удаление отсутствуют.
[3]
посмотрите внимательно на лицевую панель своего CD-ROM'а, видите, – внизу лотка расположено крохотное отверстие порядка 1 мм в диаметре? воспользовавшись любым длинным, тонким и достаточно прочным предметом, например, металлической канцелярской скрепкой, слегка приоткройте лоток, введя "отмычку" в указанную дырку до упора и еще чуть-чуть надавив. Все! – дальше лоток можно выдвинуть уже руками. Внимание! Во-первых проделывайте эту операцию только при выключенном компьютере, а, во-вторых, держите "отмычку" строго горизонтально, иначе вы можете промазать и угодить в какой ни будь нежный узел, основательно его повредив.
оригинальный стартовый
Изменим поля PMin:PSec:PFrame, принадлежащие point'у 0xa2 так, чтобы они указывали на самый конец диска (0xa2 – это как раз Lead-Out и есть). Измененный Lead-Out может выглядеть, например, так: 74:30:00. Адрес Lead-Out следует выбирать с тем расчетом, чтобы между ним и внешней кромкой диска оставался по меньшей мере 30-секундный зазор. Еще лучше, если ширина Lead-Out составит полторы минуты или около того. Однако в этом случае будут неизбежно теряться последние треки восстанавливаемого диска (если, конечно, вам действительно требуется их восстановить).
К содержимому полей PMin:PSec:PFrame, принадлежащих point'у 0x01 (стартовый адрес первого трека) необходимо добавить ту же самую величину, которую вы добавили к соответствующим полям Lead-Out'a. Отредактированный вариант может выглядеть, например, так: 74:01:42. (74:30:00 /* новый адрес Lead-out */ – 00:29:33 /* старый Lead-Out */ + 00:01:00 /* старый стартовый адрес первого трека */ == 74:01:42 /* новый стартовый адрес */. Короче говоря, новая версия ccd-файла должна выглядеть так:
[Entry 2] [Entry 3]
Session=1 Session=1
… …
PMin=74 PMin=74
PSec=30 PSec=01
PFrame=00 PFrame=42
содержимое неискаженного
Давайте теперь немного поиздевается над TOC'ом и увеличим стартовый адрес первого трека так, чтобы он вышел далеко за пределы первой сессии и попал… ну, собственно, куда ни будь он все равно попадет. Чтобы быстро отыскать соответствующую ему запись, воспользуется контекстным поиском. Жмем <F7>
и вводим "point=0x1":
[Entry
3] ; данные элемента TOC'a №3
Session=1 ; элемент сессии 1
Point=0x01 ; данные трека 1 сессии 1
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=0 ; \
PSec=2 ; + - абсолютный адрес начала трека 1 сессии 1
PFrame=0 ; /
PLBA=0 ; LBA-адрес начала трека 1 сессии 1
Как мы видим, здесь присутствует
Как мы видим, здесь присутствует как абсолютный, измеряемый в минутах:секундах: фреймах, так и LBA-адрес трека, представляющий собой ничто иное, как порядковый номер сектора, считая от нуля. На самом деле, LBA-адрес – это "отсебятина", добавляемая в файл самим Clone CD и в TOC'е LBA-адрес не храниться. Судя по всему, Clone CD вычисляет LBA-адрес исходя из соображений удобства (работать с LBA-адресацией, действительно намного комфортнее). Однако, при внесении каких-либо изменений в CCD-файл, за согласованием обоих типов адресов нам придется следить самостоятельно. Для перевода абсолютных адресов в LBA можно воспользоваться следующей формулой: Logical Sector Address = (((Minute * 60) + Seconds) * 75 +Frame) – 150.
Ниже представлен вид атрибутов трека 1 до и после искажения:
[Entry 3] [Entry 3]
Session=1 Session=1
Point=0x01 Point=0x01
ADR=0x01 ADR=0x01
Control=0x04 Control=0x04
TrackNo=0 TrackNo=0
AMin=0 AMin=0
ASec=0 ASec=0
AFrame=0 AFrame=0
ALBA=-150 ALBA=-150
Zero=0 Zero=0
PMin=0 à PMin=10
PSec=2 à PSec=2
PFrame=0 à PFrame=0
PLBA=0 à PLBA=-1
атрибуты трека 1 до искажений (слева) и после искажения (справа)
На самом деле коварный автор схитрил и вместо вычислений LBA-адреса залощился на тот факт, что его версия Clone CD всегда использует абсолютные адреса, а LBA – игнорирует. Выбор абсолютного адреса первого трека – произвольный, но осуществленный с таким расчетом, чтобы искаженный адрес гарантированно вылетал за границы первой сессии, Lead-out область которой находится по адресу 00:29:33 (см. элемент TOC'а №2).
сводная информация по
Во-вторых, обнаружив, что запись искаженного TOC'a на данном приводе невозможна, Clone CD корректирует TOC так, чтобы его облик принял человеческий вид. В результате, процесс "прожига" протекает без каких либо ошибок и мы получаем как будто бы
работоспособный диск. Стартовый адрес первого трека начинается там, где кончается Lead-in область первой сессии (точнее, pre-gap первого трека начинается там, где кончается post-gap Lead-in области первой сессии, но это уже детали). Такой диск нормально читается в любом приводе CD-ROM, но! Если защитный механизм прочитает содержимое TOC'а, он легко обнаружит, что имеет дело с копией, но не оригиналом. Спрашивается: и на кой черт нам такое копирование нужно?! Хоть бы предупреждение было какое… Ладно, профессионалы запросто определят в чем подвох, но в каком положении окажутся новички и/или просто квалифицированные пользователи, использующие Clone CD для своих нужд? В общем мрак одним словом…
Правда, в режиме RAW DAO нарезка искаженного образа протекает отлично и Clone CD не вносит в TOC никакой отсебятины, благодаря чему, у нас образуется действительно защищенных CD, который мы сейчас и будем ломать.
таким видит защищенный
Еще до завершения процесса копирования нас начинают одолевать стойкие сомнения или, я бы даже сказал, непоколебимая уверенность, в том, что диск будет скопирован неправильно. И действительно, чего мы опасались, то мы и получили! Давайте создадим образ скопированного диска в плане сравнения копии TOC'а с оригиналом.
[CloneCD] ; данные о копировщике
Version=3 ; версия Clone CD
[Disc] ; данные о диске
TocEntries=7 ; кол-во элементов TOC'a == 7 (в оригинале было 12)
Sessions=1 ; кол-во сессий == 1 (в оригинале было 2)
DataTracksScrambled=0 ; поле DVD
CDTextLength=0 ; CD-Text'a
в полях подкода Lead-in области нету
[Session
1] ; данные сессии 1
PreGapMode=1 ; тип трека == Mode 1
PreGapSubC=0 ; данных подканала – нет
[Entry
0] ; данные элемента TOC'a №0
Session=1 ; элемент сессии 1
Point=0xa0 ; номер первого трека сессии 1 в PMin/тип диска в PSec
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=1 ; номер первого трека сессии 1
PSec=0 ; тип диска CD-DA и CD-ROM
диск в Mode
1
PFrame=0 ; не несет никакой полезной информации
PLBA=4350 ; номер трека представленный CloneCD
как LBA-адрес, т.е. чушь
[Entry
1] ; данные элемента TOC'a №1
Session=1 ; элемент сессии 1
Point=0xa1 ; номер последнего трека сессии 1 в PMin
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=1 ; номер последнего трека сессии 1 (в сессии только один трек)
PSec=0 ; не несет никакой полезной информации
PFrame=0 ; не несет никакой полезной информации
PLBA=4350 ; номер трека представленный CloneCD
как LBA-адрес, т.е. чушь
[Entry
2] ; данные элемента TOC'a №2
Session=1 ; элемент сессии 1
Point=0xa2 ; положение Lead-out
области в PMin:PSec:PFrame
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=0 ; \
PSec=29 ; + - абсолютный адрес Lead-out области сессии 1
PFrame=33 ; /
PLBA=2058 ; LBA-адрес Lead-out области сессии 1
[Entry
3] ; данные элемента TOC'a №3
Session=1 ; элемент сессии 1
Point=0x01 ; данные трека 1 сессии 1
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=10 ; \
PSec=2 ; + - абсолютный адрес начала трека 1 сессии 1
PFrame=0 ; /
PLBA=45000 ; LBA-адрес начала трека 1 сессии 1
[Entry
4] ; данные элемента TOC'a №4
Session=1 ; элемент сессии 1
Point=0xb0 ; позиция следующий записываемой области в AMin:ASec:AFrame
ADR=0x05 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=2 ; \
ASec=59 ; + - абсолютный адрес следующей записываемой области
AFrame=33 ; /
ALBA=13308 ; LBA-адрес следующей записываемой области
Zero=3 ; кол-во pointer'ов в Mode 5
PMin=22 ; \
PSec=14 ; + - абсолютный адрес максимальной записываемой области
PFrame=34 ; /
PLBA=99934 ; LBA-адрес максимальной записываемой области
[Entry
5] ; данные элемента TOC'a №5
Session=1 ; элемент сессии 1
Point=0xc0 ; стартовый адрес Lead-in области Hybrid диска (если он есть)
ADR=0x05 ; Mode 5 (Оранжевая книга)
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=162 ; рекомендуемая мощность лазера для
ASec=200 ; Application code (в оригинале здесь было 128)
AFrame=224 ; в оригинале здесь было 140
ALBA=294074 ; LBA-"адрес" трех предыдущих полей
Zero=0 ; зарезервировано
PMin=97 ; \
PSec=27 ; + - абсолютный адрес Lead-in области Hybrid диска
PFrame=21 ; / ( адрес лежит за пределами диска, т.е. Hybrid-диска нет)
PLBA=-11604 ; LBA-адрес Lead-in области Hybrid'a(вычислен с переполнением)
[Entry
6] ; данные элемента TOC'a №6
Session=1 ; элемент сессии 1
Point=0xc1 ; копия ATIP-информации
ADR=0x05 ; -+
Control=0x04 ; -+
TrackNo=0 ; -+
AMin=4 ; -+
ASec=192 ; -+
AFrame=150 ; -+- ATIP (изменена!)
ALBA=32400 ; -+
Zero=0 ; -+
PMin=0 ; -+
PSec=0 ; -+
PFrame=0 ; -+
PLBA=-150
[TRACK 1]
MODE=0
INDEX
1=45000
образ защищенного диска
Сокращение сессий с двух до одной очень сильно смущает. Куда девалась вторая – неискаженная(!) – сессия вообще непонятно. И, хотя искаженные данные первого трека сохранились, оказались неожиданно измененными поля Application Code и ATIP (и это несмотря на то, что запись производилась на туже самую CD-RW болванку, что и раньше, хотя в ее "прожиг" осуществлялся различными приводами).
Как следствие: скопированный диск оказывается работоспособен не на всех приводах (ASUS и NEC его прочитают, а вот PHILIPS – нет), к тому же защите ничего не стоит прочитать текущий TOC и сравнить его с эталонным.
Короче говоря, "факир был пьян и фокус не удался". Что ж, попробуем обратиться за помощью к Алкоголю – уж он-то должен наверняка с этим справиться. Действительно, Алкоголь видит обе сессии: как искаженную, так и неискаженную, однако по малопонятным причинам сохраняет в образ лишь вторую из них (Clone CD сохранял первую). Ну что это за зоопарк, а? Содержимое TOC'а скопированного диска можно даже и не сравнивать – там будет далеко не то, что защита собирается ожидать. И напрасно! Содержимое TOC'а, снятое Алкоголем практически полностью соответствует оригиналу. Единственно, в чем ошибся Алкоголь – определил тип pre-gap обоих треков не как Mode 1, но как Mode 2. Впрочем, в силу отсутствия в образе первой сессии, полученная с его помощью копия диска все равно оказывается неработоспособной.
вывод содержимого диска
Ага, совокупный объем девяти файлов, доступных для операционной системы, составляет всего 72 мегабайта (76.082.156 байт), а совокупный объем всех сессий диска – 47,66 + 6,50 + 8,21 + 8,04 + 6,91 + 10,62 + 9,04 + 9,10 + 9,22 + 9,46 == 124,76 МБ, что на 52 МБ длиннее! (примечание: поле "Write Sector", содержащее длину записанной области диска и равное в данном случае 255 Мб, для наших целей абсолютно бесполезно, поскольку в записанную область диска входят не только полезные данные, но и служебные области каждой сессии, в результате чего полная емкость диска всегда меньше его эффективной емкости даже если на нем нет никаких удаленных файлов).
В какой именно сессии содержаться удаленные файлы сказать невозможно, – они могут присутствовать в любой из них (или даже в нескольких сессиях сразу). Поэтому, в общем случае все имеющиеся сессии должны просматриваться последовательно. Однако, иногда удается найти более короткие пути. Применительно к рассматриваемому нами примеру: давайте попробуем оттолкнуться от того факта, что количество имеющихся на диске сессий на единицу больше числа выведенных командой dir файлов, причем, размеры девяти последних секций практически совпадают с размерами соответствующих им файлов. Первая же сессия диска, имеющая размер 48 МБ, не соответствует ни одному из видимых файлов. Что же она тогда содержит? А вот сейчас смонтируем эту сессию на отдельный дисковый том и посмотрим! К сожалению, штатные средства Windows не позволяют осуществлять такое монтирование непосредственно и потому приходится идти обходным путем, записывая выбранную сессию в ISO-образ с последующим копированием последнего на чистый CD-R/CD-RW диск. Естественно, CD-RW диски более практичны для таких экспериментов, поскольку их можно использовать многократно. Еще удобнее Alcohol 120%, динамически монтирующий ISO-образы на виртуальный CD-ROM, и тем самым экономящий кучу времени (но, к сожалению, он не предоставляет возможности выбора сохраняемых сессий и всегда помещает в создаваемый им образ содержимое всего диска целиком, поэтому одного лишь Алкоголика для наших экспериментов будет более чем недостаточно).
Возвращаясь к нашим баранам (простите, к Roxio Easy CD Creator), дважды щелкнем мышем по строке "Session 1" или, предварительно выделив ее курсором, нажмем на кнопку "Read Track". На экране немедленно появится диалоговое окно следующего вида:
ключевой фрагмент "реаниматора" 75-минутных CD-RW дисков
Вообще-то, для приличия следовало бы скорректировать и поля PLBA (LBA адрес связан с абсолютным адресом следующим соотношением: LBA == ((Min*60) + Sec)*75 + Frame, однако, текущие версии работают исключительно с абсолютными адресами и LBA-адреса игнорируют. Теперь, все, что находится между концом Lead-in области и началом первого сектора и будет называться pre-gap. При "прожиге" диска область pre-gap остается нетронутой и позже может быть прочитана на секторном уровне (а это как раз то, что нам нужно!) Сказать по чести, чрезмерное увеличение pre-gap первого трека – не самая лучшая идея, т. к. не все приводы способны читать такой "жирный" pre-gap. С точки зрения совместимости было бы лучше увеличивать pre-gap второго трека, однако при этом первый трек придется располагать в самом начале диска и его тело неизбежно затрет восстанавливаемые сектора. И хотя это не такая уж большая проблема (в первых секторах диска все равно ничего ценного нет), к такой мере без особой необходимости все же лучше не прибегать. На крайний случай действуйте так: запишите на диск две сессии и вместо стартового адреса point'a номер 0x01 меняйте стартовый адрес point'a номер 0x02 (он будет находится в разделе session=2).
Теперь наскоро очистим наш подопытный диск и до отвала забьем его какими ни будь файлами (предпочтительнее всего использовать текстовики – т.к. в этом случае будет сразу видно: извлекается ли с восстановленного диска мусор или полезная информация). Записав файлы на диск тут же выполним его быструю очистку.
Убедившись, что диск действительно очищен и его содержимое уже недоступно, запустим Clone CD и запишем только что созданным нами "лечебный" образ. Запись должна проводиться в режиме DAO, иначе ничего хорошего у вас не получится (поэтому, прежде чем восстанавливать сколь ни будь ценный диск на еще не известном вам приводе, попробуйте потренироваться на "кошках", – диске, не содержащем ничего интересного).
Вот наконец мы держим в руках свежевосстановленный диск. Но действительно ли он восстановлен? А вот сейчас и убедимся! Вставляем "воскресшего из пепла" в привод NEC и с замираем сердца пробуем прочитать один из наугад взятых секторов из середины диска (начальные сектора обычно содержат нули, потом – файловую систему и их очень легко принять за бессмысленный мусор). О чудо!!! Оригинальное содержимое очищенного диска читается как ни в чем не бывало!!! Правда, при попытке прочесть оглавление диска средствами операционной системы, привод может впасть в глухую задумчивость, граничащую с полным зависанием (ведь стартовый адрес первого трека расположен не в начале диска, а совсем в другом месте), но это все ерунда! Главное, что на секторном уроне диск все-таки доступен, пускай и не на всех приводах. Так, в частности, ASUS вообще отказывается читать такой диск, возвращая ошибку, а PHILIPS читает один мусор (к счастью, этот мусор можно восстановить, – достаточно просто на битовом уровне выполнить EFM-перекодировку с более "правильной" позиции. Поскольку возможных позиций всего 14, перебор обещает не затягиваться на длительное время. Тем не менее, лучше не извращаться, а просто приобрести более качественный привод).
Остается лишь привести диск в состояние, пригодное для переваривания операционной системой (что толку в работе с диском на низком уровне?). Последовательно читая все сектора диска один за один мы будем собирать их в один img-файл, для определенности именуемый recover.img Сектора, которые не удалось прочитать даже с нескольких попыток, мы будем просто пропускать. Теперь скопируем "лечебный" ccd-файл в recover.ccd и вернем стартовый адрес первого трека на прежнее место. Запишем сформированный образ диска на новую болванку и… (если все сделано правильно) любой привод должен читать ее правильно. Сеанс демонстрационного восстановления окончен и мы, малость освоившись с этой технологией, можем приниматься за вещи куда как более серьезные. Например, откроем собственную компании по восстановлению очищенных дисков. Шутка! Хотя… почему бы и нет?
Хорошо, а как быть если очищенный диск был многосессионным? Ведь описанные выше приемы рассчитаны на работу лишь с одной сессией! На самом деле, можно восстановить и многосессионный диск. Это лишь чуть-чуть труднее. Но, чтобы это сделать, мы должны предварительно познакомиться с остальными полями TOC'а. А это уже тема следующей статьи!
Постой, а если после очистки диска на него что-то писалось, – возможно ли тогда его восстановление или нет? Разумеется, непосредственно затертые места утеряны безвозвратно, но остальную часть информации по-прежнему можно спасти. Если диск до очистки был многосессионным, то нам даже не придется корпеть над восстановлением файловой системы, т. к. файловая система каждой последующей сессии обычно дублирует предыдущую ("обычно" это в смысле "за исключением удаленных файлов") и последняя сессия диска оказывается достаточно далеко от его начала, а потому и риск ее затирания – минимален (если, конечно, схватиться вовремя, а не тогда, когда весь диск перезаписан до отказа). Восстановление одно-сессионных дисков с затертой файловой системой – намного более трудная, но все-таки разрешимая задача. Во-первых, этих файловых систем на типовом диске целых две: ISO-9660 и Joliet, правда в силу их близкого географического положения при затирании диска они обычно гибнут обе. Во-вторых, указанные файловые системы не поддерживают фрагментации и всякий файл, записанный на лазерный диск, представляет собой единый информационный блок. Все, что нужно для его восстановления – определить точку входа и длину. Точка входа в файл всегда совпадает с началом сектора, а подавляющее большинство типов файлов позволяют однозначно идентифицировать свой заголовок по уникальной сигнатуре (в частности, для zip-файлов характерна следующая последовательность: 50 4B 03 04). Конец файла, правда, определяется уже не так однозначно и единственная зацепка – структура самого восстанавливаемого файла. Впрочем, большинство приложений довольно лояльно относится к "мусору" в хвосте файла и потому точностью определения его длины с погрешностью в один сектор на практике оказывается вполне достаточной. Поскольку, файлы располагаются на диске вплотную, без "зазоров", конечный сектор всякого файла надежно вычисляется путем вычитания единицы из стартового сектора следующего за ним файла.
Вообще же говоря, техника восстановления лазерных дисков намного проще и незатейливее искусства врачевания их прямых коллег – дискет и жестких дисков. Правда, поговорку "семь раз отмерь – один раз отрежь" еще никто не отменял и одна из пренеприятнейших особенностей работы с CD-RW как раз и состоит в том, что вы не можете гарантированно управлять процессом происходящей записи. Дискеты и жесткие диски в этом смысле полностью прозрачны, – что вы пишите, то вы и получаете. Перезаписываемые же носители, напротив, представляют собой "черный ящик" и вы никогда не можете быть уверенными в том, что данный конкретный привод будет правильно интерпретировать отдаваемые ему команды (увы, восстановление CD-RW дисков никак не вписывается в рамки Стандарта, а все нестандартные махинации могут интерпретироваться приводом неоднозначно). Единственно, что остается посоветовать – не пускайте все на самотек, а бесконечно экспериментируйте, экспериментируйте и еще раз экспериментируйте, накапливая бесценный опыт, который вам когда-то очень пригодиться.
сводная информация по
Вот это номер! Если верить Алкоголю, то длина первой трека составляет целых 8 терабайт. Этот чудовищный объем не то, что на CD-, на DVD-диск не залезет! На самом деле, длина треков в TOC'е нигде явным образом не хранится, но вычисляется как разница стартовых адресов двух смежных треков (если же сессия содержит всего один трек, в ход идет адрес Lead?out области, примыкающий к треку). Искажение стартового адреса первого трека привело к тому, что разница стартовых адресов Lead-out области и этого самого трека стала отрицательной. Действительно, 00:29:33 – 10:02:00 = 2058 – 45000 == – 42942, а, если вспомнить, что LBA-адреса по стандарту выражаются 32-разрядными неотрицательными числами, становится понятно, как Алкоголик получил такой неестественно огромный объем (отрицательные числа – это такие числа, чей старший бит взведен, отсюда – маленькое отрицательное число – это очччень большое положительное). Расчеты показывают, что заявленное Алкоголиком значение в 8-терабайт достигается лишь при использовании 43-битных переменных. Вот это да! Алкоголик спроектирован с закладом на будущее (а в будущем нас, как известно, ждут диски с объемами от 30 и более гигабайт, для адресации которых 32-бит оказывается уже недостаточно, плюс еще необходимо учесть резерв, предназначенный для "отлова" отрицательных длин, образовавшихся в результате жестоких извращений с TOC'ом, ведь Алкоголь – это защищенный копировщик!)
И вот наступает волнующий момент – момент заливки искаженного образа на CD-R/CD-RW диск (внимание! используя CD-RW диск вы должны отдавать себе отчет в том, что можете его безвозвратно потерять! Если ваш единственный пишущий привод откажется опознавать такой диск, очистка последнего окажется невозможной!). Благополучно проглотив искаженный образ, Алкоголь, безо всяких препирательств со своей стороны, зажигает огонек индикации записи (если, конечно, на вашем приводе он есть) и приступает к делу. Проходит минута, другая… а индикатор прогресса по прежнему остается на нуле. К исходу шестой минуты, когда пишущая головка достигает кромки диска, процесс записи аварийно прерывается приводом и Алкоголь, издав грустное "бэмс", сигнализирует об аппаратной ошибке.
Просмотр "недорезанного" диска на приводах ASUS и NEC обнаруживает лишь первую сессию, а от второй не видно и следа. С приводом PHILIPS дела обстоят еще хуже – он вообще отказывается признавать засунутую в него шутку лазерным диском и, после непродолжительного скрежета своих механических внутренностей, сопровождаемых натужными завываниями перебирающего различные скорости мотора, индикатор "DISC IN" прощально гаснет. "Прощально" в том смысле, что с испорченной болванкой вам придется расстаться. Конечно, если это всего лишь дешевый CD-R, то туда ему и дорога, но потерять CD?RW – жалко. К счастью, на NEC'е очистка диска протекает успешно и воодушевленные этим обстоятельством, мы продолжаем свои издевательства вновь.
Копировщик Clone CD ведет себя в этом отношении иначе. Во-первых, он оценивает длину искаженного трека в 4.294.868.664 байт (см. листинг, приведенный ниже), что указывает на использование 32-разрядных переменных и вытекающую отсюда невозможность отличать положительные длины от отрицательных.
ИНФОРМАЦИЯ О ФАЙЛЕ-ОБРАЗЕ:
Число сессий: 2
Занято на диске: 34850 Кбайт
Секторов: 15173
Время: 03:22:23 (мин:сек:кадр)
ИНФОРМАЦИЯ О СЕССИИ 1:
Размер сессии: 4726 Кбайт
Число треков: 1
Pregap: Данные Mode 1, размер: 103359 Кбайт
Track 1: Данные Mode 1, размер: 4294868664 Кбайт
ИНФОРМАЦИЯ О СЕССИИ 2:
Размер сессии: 3939 Кбайт
Число треков: 1
Track 2: Данные Mode 1, размер: 3939 Кбайт
демонстрационный пример
Предлагаемая защита не копируется Clone CD (т. к. он создает всего одну сессию вместо ожидаемых двух), но легко обходится Алкоголем, которой хоть и помещает на место первой секции непотребный мусор, зато вполне корректно воссоздает оригинальный TOC.
Для усиления защиты мы можем попытаться не только проверять обе сессии на существование, но и контролировать целостность их содержимого. Разумеется, не обязательно перелопачивать каждую их секций целиком. Достаточно выбрать несколько ключевых секторов, желательно имеющих по возможности уникальное содержимое. Постойте! – воскликнет внимательный читатель. Разве автор не предостерегал нас о последствиях такой проверки?! Ведь никто не может гарантировать, что на оборудовании пользователя эти сектора вообще прочтутся! Что ж, – отвечу я. Закладываться на читабельность
секторов, действительно категорически не рекомендуется, но вот контролировать успешно просчитавшиеся сектора можно и нужно! То есть: если ключевые сектора не читаются, то все ОК и нет никаких поводов считать диск нелицензионным – это просто у конечного пользователя оборудование такое (в смысле что кривое). Другое дело, если чтение секторов прошло без ошибок, но вместо ключевых данных в них оказалось нечто совсем иное. Вот тогда, действительно, проблема не в оборудовании, а в диске.
Усиленный вариант защиты уже не копируется Алкоголем (т.к. вместо оригинального содержимого первой сессии Алкоголь помещает на диск какой-то дикий мусор), но может быть скопирован вручную по методике, описанной выше. К тому же, привязка к искаженному TOC'у элементарно отламывается в отладчике/дизассемблере. Так что дальнейшее совершенствование защиты практически полностью бессмысленно. От "простых смертных" пользователей мы уже защитились, а от хакеров мы не сумеем защититься все равно (во всяком случае не этим способом). В любом случае, более продвинутые защиты – тема отдельного разговора.
Пример реализации защиты на программном уровне
Покажем теперь как такая защита может быть реализована на программном уровне. Самое простое, что можно сделать – отправить приводу команду "сырого" чтения TOC (opcode: 43h, format: 2h) и сравнить возращенный ею результат с эталоном. Какие именно поля TOC'a защита будет проверять – это ее личное дело. По минимуму достаточно проверить количество сессий и стартовый адрес искаженного трека. По максимуму можно контролировать весь TOC целиком. Естественно, от побайтового сравнения контролируемого TOC'a с оригиналом настоятельно рекомендуется воздержаться, – т. к. это неявно закладывает защиту на особенности микропрограммной прошивки читающего привода. Стандарт ничего не говорит том, в каком порядке должно возвращается содержимое TOC'а и потому его бинарное представление может варьироваться от привода к приводу. Грамотно спроектированная защита должна анализировать только те поля, к содержимому которых она привязывается явно.
Демонстрационный пример, приведенный ниже, как раз и иллюстрирует технику корректной привязки к TOC'у. Разумеется, явная проверка целости TOC'а может быть элементарно обнаружена хакером и выкинута из программы как ненужная, поэтому не стоит копировать этот демонстрационный пример один к одному в свои программы. Лучше используйте значения полей TOC'а как рабочие константы жизненно необходимые для нормальной работоспособности программы, – в этом случае сличение паспортов с лицами будет не столь наглядным. Естественно, явная проверка оригинальности диска все равно обязана быть, но ее основная цель отнюдь не защитить программу от взлома, а довести до сведения пользователя, что проверяемый диск с точки зрения защиты не является лицензионным.
/*----------------------------------------------------------------------------
*
* crack me 9822C095h
* ==================
*
* демонстрация техники привязки к искаженному TOC'у;для работе программе
* требуется лазерный диск, прожженный соответствующим образом
Анализ содержимого диска на предмет выявления удаленных файлов
Как мы и видим, перед нами представлен перечень всех сессий, имеющихся на диске с указанием номеров, стартовых адресов (в секторах) и длин (в мегабайтах). Давайте попробуем определить, имеются ли на диске скрытые файлы или нет. Используя команду "dir", выведем директорию диска и запомним суммарный размер всех файлов, которые только "видит" операционная система:
KPNC$G:\>dir
Том в устройстве G имеет метку 030710_1433
Серийный номер тома: 4DD0-BB09
Содержимое папки G:\
28.05.2003 05:57 6 283 745 phck31.drf.zip
03.06.2003 05:39 8 085 410 phck31.Вт 03.06.2003.zip
04.06.2003 16:45 7 898 149 phck31.Ср 04.06.2003.zip
05.06.2003 06:06 6 718 926 phck31.Чт 05.06.2003.zip
03.07.2003 15:51 10 612 230 phck31.Чт 03.07.2003.zip
05.07.2003 06:37 8 946 860 phck31.Сб 05.07.2003.zip
08.07.2003 12:51 9 009 642 phck31.Вт 08.07.2003.zip
09.07.2003 06:21 9 138 651 phck31.Ср 09.07.2003.zip
10.07.2003 14:32 9 388 543 phck31.Чт 10.07.2003.zip
9 файлов 76 082 156 байт
1 папок 0 байт свободно
отрицательная длина первого трека сводит штатный копировщик с ума
Постойте, но как же тогда осуществляется доступ к содержимому первого трека? А кто вам вообще сказал, что лазерный диск адресуется по трекам?! Основной адресацией лазерного диска с данными является сектор. Абсолютный же адрес всякого сектора однозначно определяется принадлежащим ему Q-каналом подкода (с учетом несовпадения границ секций и секторов максимально возможное расхождение допускаемое стандартом составляет 1 сек, т. е. 75 секторов, поэтому этот способ используется лишь для грубого позиционирования оптической головки). Точная наводка на цель выполняется непосредственно по самому секторному заголовку, в явном виде содержащему его абсолютный адрес. Номера треков в процессе обработки сектора вообще не участвуют, вернее могут и не участвовать… Но могут ведь и участвовать! Все зависит от электронной начинки привода и его микропрограммной прошивки. Как именно они в этом участвуют, – сие есть великая тайна разработчиков привода и простым смертным ее понять не дано. Но, так или иначе, встретив некорректный TOC некоторые приводы запутываются и в стройных битовых рядах возникает настоящая сумятица.
Результаты тестирования трех моих приводов следующие: NEC, как уже говорилось выше, показывает содержимое обоих секций, корректно обрабатывая их содержимое. ASUS показывает только первую – искаженную – сессию и в упор не видит вторую, делая ее недоступной даже на секторном уровне. Зато файлы первой сессии обрабатываются вполне корректно. PHILPS, напротив, видит обе сессии, но корректно обрабатывает файлы лишь последней из них (т.е. той, что не искажена). Искаженная сессия доступна на секторном уровне, но нестабильно. Иногда без всяких видимых причин, Филька едет крышей и возвращает лишенный всякого смысла мусор.
Мораль: защитные механизмы, базирующиеся на искаженном TOC'e не могут закладываться ни на одну из сессий. Поэтому, обе сессии должны дублировать содержимое друг друга – авось хоть одну из них привод пользователя да прочтет. Какой же тогда в этой защите смысл? А вот какой – пускай защита не может без риска для жизни привязаться к сессиям, она может привязаться к сырому содержимому TOC"a. О том как осуществить такую привязку на практике мы поговорим чуточку позднее, а пока попробуем скопировать защищенный диск нашими фаворитами – Clone CD и Alcohol 120%.
x058 диалоговое окно извлечения сессии с настройками по умолчанию
Поле "Имя файла", как и следует из его названия, задает имя образа (по умолчанию "Track"), а "Тип файла" – формат. Каким либо образом "колдовать" над ним бесполезно, поскольку других форматов бесплатная версия программы все равно не поддерживает и возможность их выбора (точнее видимость возможности выбора) предоставляется пользователю исключительно из соображений этикета и/или вежливости.
А вот настройки, обведенные рамкой "Read Data Track Settings", намного более интересны. Окно редактирования "Start Block" содержит LBA-адрес первого сектора выбранной сессии, а "Length in Block" – длину сессии в секторах и по умолчанию сюда подставляется информация, подчеркнутая из TOC'а. При условии, что TOC не был умышленно искажен с целью защиты диска от копирования, этим данным можно верить. Однако, как мы увидим в дальнейшем искажение TOC'а не редкость и с ним довольно часто приходится сталкиваться на практике (впрочем, возможности Easy CD Creator'a по восстановлению треков с искаженными адресами даже более чем ограничены, т. к. он слишком щепетильно проверяет "правильность" начального и конечного адресов и, если TOC говорит, что начальный адрес больше конечного, то Easy CD Creator будет свято верить TOC'у, причем настолько свято, что все попытки убедить его в обратном заранее обречены на провал, так что для работы с защитами лучше подыскать другую программу – поумнее).
Поле "Block Size" содержит размер пользовательской части сектора в байтах. Свобода выбора здесь представлена чисто символически, – все равно изменить это значение вы не сможете (да и нужно ли его изменять? ведь "сырых" секторов Easy CD Creator все равно не поддерживает, а размер пользовательской части сектора однозначно определяется типом самого сектора и его изменение – бессмысленно).
Короче говоря, оставив все установки в состоянии, предлагаемом по умолчанию, нажимаем кнопочку "сохранить" и некоторое время ждем, пока выбранная нами сессия копируется в ISO-файл. Когда же процесс "трансплантации" будет закончен, сформированный образ можно "закатать" на новую болванку тем же Easy CD Creator'ом (для в меню "File" необходимо выбрать пункт "Record CD from CD image", указав в типе файлов "ISO Image File"), либо запустить "Алкоголика" и смонтировать образ на виртуальный диск.
Так или иначе, доступ к удаленным файлам будет получен и вы сможете делать с ними все, что хотите (внимание! при просмотре содержимого "сграбленной" сессии всегда учитывайте что: во-первых, файлы, физически принадлежащие другим сессиях, из данной сессии окажутся недоступными, в то время как ссылки на них здесь могут изобиловать. При обращении к реально несуществующему файлу будет выдаваться либо мусор, либо сообщение об ошибке. Как альтернативный вариант – операционная система может просто зависнуть. Если это произошло, просто нажмите кнопку выброса диска. Windows тут же выйдет из ступора и радостно завопит "устройство не готово". Во-вторых, в силу сквозной адресации секторов, каждая "сграбленная" сессия должна записывается на тоже самое место диска, на котором она была ранее, в противном случае все ссылки на стартовые адреса файлов внутри этой сессии окажутся недействительными. Требуемый результат обычно достигается изменением стартового адреса первого трека. О том, как это сделать, рассказывается в следующей части статьи, посвященной восстановлению информации с очищенных CD-RW дисков).
копирует лишь вторую из них, а первую нагло пропускает
А ведь заявлялось, что Clone CD/Alcohol 120% способны копировать любые существующие на сегодняшний момент защищенные диски и вдруг на проверку оказывается, что даже такую простую защиту, которую может создать на кончике пенька любой программист они преодолеть ни вместе, ни по раздельности не в состоянии! Причем, аппаратура, на которой все эти эксперименты и осуществлялись, возможность корректного копирования искаженного диска гарантированно поддерживает (сам проверял) и потому отмахнуться физическими ограничениями приводов разработчикам обоих копировщиков уже не удастся!
Даже не вериться, что такой простой прием "ослепляет" лучшие копировщики защищенных дисков! Неужели и вправду, создания некопируемых дисков вполне осуществимо на обыкновенном бытовом оборудовании?! Да! Именно так! Конечно, не стоит путать некопируемость диска автоматическими копировщиками с принципиальной невозможностью получения его идентичной копии. В ручном режиме копирование таких дисков вполне осуществимо (правда, при условии, что ваш пишущий привод поддерживает режим RAW DAO, а читающий – читает сектора из обоих секций) и сейчас мы продемонстрируем как.
четвертый
Теперь смонтируем искаженный образ диска на виртуальный привод, создаваемый программой Alcohol120% и посмотрим, что из этого получилось. Конечно, нет никакой уверенности в том, что виртуальный привод поведет себя как настоящий, но ведь и настоящие приводы на искаженных дисках ведут себя по разному! Поэтому, использовать Алкоголя в качестве рабочего "макетника" вполне допустимо, тем более что это экономит уйму времени и болванок, ведь монтирование виртуального диска в отличии от "прожига" болванки осуществляется мгновенно, если, конечно оно вообще осуществляется… Вплоть до версии 1.4.3 включительно – самой свежей версии на момент написания этих строк – Алкоголик органически не переваривал искаженные образы дисков и отказывался их монтировать, апеллируя к недоступности образа файла: "Unable to mount image. File not accessible". Судя по всему, Алкоголик понимает искаженный TOC слишком буквально, пытаясь отыскать файле-образе то, что там заведомо нет (трека, начинающегося с адреса 10:02:00 и заканчивающегося адресом 00:29:33 там нет точно!).
Какая жалость! Возможность монтирования дисковых образов с искаженным TOC'ом позволила бы нам преодолевать защиту от копирования на любых пишущих приводах, а не только тех, что поддерживают режим RAW DAO, – просто сбрасываем образ защищенного диска на болванку в виде обыкновенного файла и динамически монтируем его Алкоголем по мере необходимости. Выходит, что на проверку Алкоголик оказывается гораздо менее крут, чем это кажется!
первый
Достаем из упаковки CD-R болванку (еще девочку) или– что даже лучше – засовываем в привод потертый жизнью CD-RW диск (нет, это не проститутка, это просто CD-RW) и записываем на него пару сессий в штатном режиме. Будет лучше (вернее нагляднее) если вторая сессия будет включать в себя файлы первой сессии – той самой сессии, чей TOC мы и собираемся искажать. Интересно, сможет ли привод прочесть ее содержимое или нет?
пятый
В порядке эксперимента попробуем "прожечь" искаженный образ в режиме RAW SAO, в котором, как уже было сказано выше, корректная запись сессий с искаженным TOC'ом невозможна. Для гарантированного исключения возможных побочных эффектов желательно использовать привод не поддерживающий RAW DAO чисто физически (ну мало ли, вдруг копировщик в плане проявления чудес искусственного интеллекта автоматически перейдет на более подходящий режим записи, игнорируя наши установки).
Мастер записи образов копировщика Alcohol 120% выдает следующую информацию о записываемом образе:
Тип: Файл-образ CloneCD
Путь: L:\
Имя: Image.ccd
Image.img
Image.sub
Размер: 8.81 MB
Сессий: 2
Треков: 2
Сессия 01:
Трек 01: Mode
1, Длина: -42942(8191.92 GB), Адрес: 045000
Сессия 02:
Трек 02: Mode 1, Длина: 001715(3.3 MB), Адрес: 013458
шестой
Просмотр защищенного диска под приводом NEC показывает все файлы, даже те, что принадлежат первому треку– тому самому треку, чей стартовый адрес жестоко искажен. Двойной щелчок мышью доказывает, что файлы не только присутствуют в каталоге, но и успешно открываются ассоциированным с ними приложениям и, судя по всему, выглядят вполне нормальными. Нашу душу начинают грызть смутные сомнения: действительно ли пишущий привод записал стартовый адрес первого трека таким, который мы просили или молчаливо исправил его налету?
Для ответа на этот вопрос мы должны исследовать геометрию диска, т. е. попросту говоря, прочитать TOC. Запускам уже полюбившийся нам Roxio Easy CD Creator и в меню "CD" находим пункт "CD Information". Щелкаем по нему мышкой и на экран тут же выпрыгивает диалоговое окно с раскладкой диска (внимание! не все программы способы "переваривать" искаженный TOC! Easy CD Creator это умеет, а вот, например, Record NOW! – нет. В отсутствии подходящей утилиты вы можете воспользоваться программой raw.TOC.exe, поставляемой вместе с этой книгой).
Как и следовало ожидать, стартовый адрес первого трека лежит далеко за пределами своей "родной" сессии и его длина, будучи выраженная положительным числом, значительно превышает доступную емкость диска (см. рис. ниже). Так что все наши волнения абсолютно безосновательны!
третий
Если все сделано правильно и программно/аппаратное обеспечение во всей своей совокупности работает нормально, на жестком диске должны образоваться три файла: IMAGE.CCD,– несущий в себе содержимое Q-канала подкода Lead-In области или, попросту говоря, TOC; IMAGE.IMG – "сырой" образ диска со всеми секторами от 00:00:02 до "сколько-на-диске-есть-там" и IMAGE.SUB – содержимое полей подкода "программной" части диска. Последний файл в принципе может и отсутствовать (он создается только если взведена галочка "Чтение субканалов из треков с данными"), но это некритично, т. к. сейчас нас в первую очередь интересуют не каналы подкода, а сам TOC! Откроем файл IMAGE.CCD в любом текстовом редакторе и попытаемся перевести расклад геометрии диска на человеческий язык.
[CloneCD] ; данные о Clone CD
Version=3 ; версия Clone CD. Идет лесом
[Disc] ; данные диска
TocEntries=12 ; кол-во элементов TOC'a
Sessions=2 ; кол-во сессий = 2
DataTracksScrambled=0 ; поле DVD
(см. inf-8090), для CD эта информация лишена смысла
CDTextLength=0 ; CD-Text'a
в полях подкода Lead-in области нету
[Session
1] ; данные сессии 1
PreGapMode=1 ; тип трека Mode
1(трек с данными, 2048 байт данных)
PreGapSubC=0 ; данных подканала – нет
[Session
2] ; данные сессии 2
PreGapMode=1 ; тип трека Mode
1(трек с данными, 2048 байт данных)
PreGapSubC=0 ; данных подканала – нет
[Entry
0] ; данные элемента TOC'a №0
Session=1 ; элемент сессии 1
Point=0xa0 ; номер первого трека сессии 1 в PMin/тип диска в PSec
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=1 ; номер первого трека сессии 1
PSec=0 ; тип диска CD-DA и CD-ROM
диск в Mode
1
PFrame=0 ; не несет никакой полезной информации
PLBA=4350 ; номер трека представленный CloneCD
как LBA-адрес, т.е. чушь
[Entry
1] ; данные элемента TOC'a №1
Session=1 ; элемент сессии 1
Point=0xa1 ; номер последнего трека сессии 1 в PMin
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=1 ; номер последнего трека сессии 1 (в сессии только один трек)
PSec=0 ; не несет никакой полезной информации
PFrame=0 ; не несет никакой полезной информации
PLBA=4350 ; номер трека представленный CloneCD
как LBA-адрес, т.е. чушь
[Entry
2] ; данные элемента TOC'a №2
Session=1 ; элемент сессии 1
Point=0xa2 ; положение Lead-out
области в PMin:PSec:PFrame
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=0 ; \
PSec=29 ; + - абсолютный адрес Lead-out области сессии 1
PFrame=33 ; /
PLBA=2058 ; LBA-адрес Lead-out области сессии 1
[Entry
3] ; данные элемента TOC'a №3
Session=1 ; элемент сессии 1
Point=0x01 ; данные трека 1 сессии 1
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=0 ; \
PSec=2 ; + - абсолютный адрес начала трека 1 сессии 1
PFrame=0 ; /
PLBA=0 ; LBA-адрес начала трека 1 сессии 1
[Entry
4] ; данные элемента TOC'a №4
Session=1 ; элемент сессии 1
Point=0xb0 ; позиция следующий записываемой области в AMin:ASec:AFrame
ADR=0x05 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=2 ; \
ASec=59 ; + - абсолютный адрес следующей записываемой области
AFrame=33 ; /
ALBA=13308 ; LBA-адрес следующей записываемой области
Zero=3 ; кол-во pointer'ов в Mode 5
PMin=22 ; \
PSec=14 ; + - абсолютный адрес максимальной записываемой области
PFrame=34 ; /
PLBA=99934 ; LBA-адрес максимальной записываемой области
[Entry
5] ; данные элемента TOC'a №5
Session=1 ; элемент сессии 1
Point=0xc0 ; стартовый адрес Lead-in области Hybrid диска (если он есть)
ADR=0x05 ; Mode 5 (Оранжевая книга)
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=162 ; рекомендуемая мощность лазера для записи
ASec=128 ; Application code
AFrame=140 ; зарезервировано
ALBA=288590 ; LBA-"адрес" трех предыдущих полей
Zero=0 ; зарезервировано
PMin=97 ; \
PSec=27 ; + - абсолютный адрес Lead-in области Hybrid диска
PFrame=21 ; / ( адрес лежит за пределами диска, т.е. Hybrid-диска нет)
PLBA=-11604 ; LBA-адрес Lead-in области Hybrid'a(вычислен с переполнением)
[Entry
6] ; данные элемента TOC'a №6
Session=1 ; элемент сессии 1
Point=0xc1 ; копия ATIP-информации
ADR=0x05 ; -+
Control=0x04 ; -+
TrackNo=0 ; -+
AMin=4 ; -+
ASec=120 ; -+
AFrame=96 ; -+
ALBA=26946 ; -+ - ATIP информация
Zero=0 ; -+
PMin=0 ; -+
PSec=0 ; -+
PFrame=0 ; -+
PLBA=-150 ; -+
[Entry 7] ; данные элемента TOC'a №7
Session=2 ; элемент сессии 2 (вот мы и добрались до сессии 2!)
Point=0xa0 ; номер первого трека сессии 2 в PMin/тип диска в PSec
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=2 ; номер первого трека сессии 2 (нумерация треков сквозная!)
PSec=0 ; тип диска CD-DA и CD-ROM
диск в Mode
1
PFrame=0 ; не несет никакой полезной информации
PLBA=8850 ; номер трека представленный CloneCD
как LBA-адрес, т.е. чушь
[Entry 8] ; данные элемента TOC'a №8
Session=2 ; элемент сессии 2
Point=0xa1 ; номер последнего трека сессии 2 в PMin
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=2 ; номер последнего трека сессии 2 (в сессии только один трек)
PSec=0 ; не несет никакой полезной информации
PFrame=0 ; не несет никакой полезной информации
PLBA=8850 ; номер трека представленный CloneCD
как LBA-адрес, т.е. чушь
[Entry 9] ; данные элемента TOC'a №9
Session=2 ; элемент сессии 2
Point=0xa2 ; положение Lead-out
области в PMin:PSec:PFrame
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=3 ; \
PSec=24 ; + - абсолютный адрес Lead-out области сессии 2
PFrame=23 ; /
PLBA=15173 ; LBA-адрес Lead-out области сессии 2
[Entry
10] ; данные элемента TOC'a №10
Session=2 ; элемент сессии 2
Point=0x02 ; данные трека 2 сессии 2
ADR=0x01 ; q-Mode == 1
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=0 ; \
ASec=0 ; + - абсолютный адрес текущего трека
AFrame=0 ; /
ALBA=-150 ; LBA-адрес текущего трека
Zero=0 ; это поле должно быть равно нулю, как оно и есть
PMin=3 ; \
PSec=1 ; + - абсолютный адрес начала трека 2 сессии 2
PFrame=33 ; /
PLBA=13458 ; LBA-адрес начала трека 2 сессии 2
[Entry
11] ; данные элемента TOC'a №11
Session=2 ; элемент сессии 2
Point=0xb0 ; адрес следующей записываемой области в AMin:ASec:AFrame
ADR=0x05 ; Mode 5
Control=0x04 ; диск с данными, запрещенный ;-) для копирования
TrackNo=0 ; трек, который мы сейчас читаем – это Lead-in трек (т.е. TOC)
AMin=4 ; \
ASec=54 ; + - абсолютный адрес следующей записываемой области
AFrame=23 ; /
ALBA=21923 ; LBA-адрес следующей записываемой области
Zero=1 ; кол-во pointer'ов
Mode 5
PMin=22 ; \
PSec=14 ; + - абсолютный адрес последней возможной Lead-out области
PFrame=34 ; / (на самом диске написано 23мин, это ж как надо округлять 22:14:34)
PLBA=99934 ; LBA-адрес последней возможной Lead-out области
[TRACK
1] ; данные трека 1
MODE=1 ; режим Mode 1
INDEX 1=0 ; post-gap?
[TRACK
2] ; данные трека 2
MODE=1 ; режим Mode 1
INDEX 1=0 ; post-gap?
второй
Запускаем Clone CD и просим его создать образ оригинального диска (выбираемый профиль настроек на данном этапе некритичен, поскольку диск еще не защищен, то с равным успехом можно использовать как "CD с данными", так и "Protected PC Game"; галочку "создавать Cue-Sheet" взводить необязательно – все равно она действительна лишь на одно-сессионных CD).
Создание защищенного диска с искаженным TOC'ом
Для создания защищенного диска с искаженным TOC'ом нам понадобиться: любая программа записи на диск, умеющая создавать многосессионные диски (например, Roxio Easy CD Creator), копировщик защищенных дисков, сохраняющий содержимое TOC'a в текстовом файле, доступном для редактирования (мы выбираем Clone CD) и, естественно, сам пишущий привод, поддерживающий режим сырой записи в режиме DAO. Для облегчения восприятия материала все действия будут расписаны по шагам, хотя это выглядит и не слишком литературно.
Статья №1 восстановления данных с лазерных дисков
…такой объем информации можно уничтожить в один миг разве что динамитом, потому что существуют дублирующие системы и у скорости обработки есть предел
Джон Варли "Нажмите ENTER"
Записываемые и перезаписываемые лазерные диски представляют собой идеальное средство для резервирования информации умеренных объемов (а всякий администратор обязательно должен заботиться о периодическом резервировании вверенной ему информации!). К сожалению, никакая работа без ошибок не обходится (что поделаешь– человеку свойственно ошибаться – ERRARE HUMANUM EST как говорили древние) и ошибочное удаление файлов CD-R/CD-RW дисков, равно как и непредумышленная очистка последних – хотя бы однажды да случается (на самом деле, как показывает практика, с этим явлением приходится сталкиваться с этим далеко не однажды, особенно если пользователи самостоятельно резервируют ту или иную информацию на CD-R/CD-RW).
Насколько известно автору, утилит, предназначенных для восстановления информации с лазерных дисков, до сих пор не разработано (во всяком случае, они не были широко представлены на рынке), поэтому, восстановлением запоротых дисков в подавляющем большинстве случаев приходится заниматься самостоятельно. О том, как именно это сделать и рассказывает настоящая статья.
Крис Касперски
Статья №2 искажение TOC'а как средство борьбы с несанкционированным копированием диска
Уже давно
Утихло поле боя,
Но сорок тысяч
Воинов Китая
Погибли здесь,
Пожертвовав собою...
Ду Фо
"Оплакиваю поражение при Чэньтао"
Искажение TOC'а – жестокий, уродливый но на удивление широко распространенный прием, использующийся в доброй половине защитных механизмов. Штатные копировщики на таких дисках в буквальном смысле слова сходят с ума и едут крышей. Копировщики защищенных дисков (Clone CD, Alcohol 120%) к искаженному TOC'у относятся гораздо лояльнее, но требуют для своей работы определенного сочетания пишущего и читающего приводов, да и в этом случае копируют такой диск не всегда.
Пишущий привод обязательно должен поддерживать режим RAW DAO (Disc At Once), – в котором весь диск записывается за один проход лазера. Режим RAW SAO (Session At Once) для этих целей совершенно непригоден, поскольку предписывает приводу писать сначала содержимое сессии, а потом – TOC. Как следствие – приводу приходится самостоятельно анализировать TOC, чтобы определить стартовый адрес сессии и ее длину. Попытка записать искаженный TOC в режиме SAO в общем случае приводит к непредсказуемому поведению привода и работоспособной копии защищенного диска нечего и думать! Первая, встретившаяся приводу, сессия с искаженным TOC'ом, обычно оказывается и последней, т. к. остальные сессии писать уже некуда
(искажение TOC'а обычно преследует цель увеличения размера сессии до нескольких гигабайт).
Читающий привод помимо режима "сырого" чтения (который поддерживают практически все приводы) должен уметь распознавать искаженный TOC, автоматически переходя в этом случае на использование "резервного" средства адресации – Q-канала подкода. В противном случае, сессия, содержащая искаженный TOC, окажется недоступной для чтения даже на сектором уровне.
Таким образом, копирование дисков с искаженным TOC'ом осуществимо не на всяком оборудовании и порядка 1/3 моделей "писцов" для этих целей непригодны. Узнать: поддерживает ли выбранная вами модель привода режим RAW DAO или нет можно в частности из раздела "Tech support" справки Clone CD, где перечислены характеристики достаточно большого количества всевозможных приводов (впрочем, моих приводов там увы нет). Другой путь – "скормить" приводу SCSI/ATAPI команду 46h (GET CONFIGURATION) и посмотреть что он ответит. Из двух моих "писцов" режим RAW DAO поддерживает один лишь NEC. С определением возможности чтения искаженных сессий дела обстоят на порядок сложнее, ибо данная особенность поведения является исключительно внутренней характеристикой привода и не афишируется ни самим приводом, ни его производителями. Приходится выяснять эту информацию экспериментально. Возьмите диск с чудовищно искаженным TOC'ом (о том как его создать – рассказано ниже), воткните его в привод и попробуйте прочесть несколько секторов из искаженной сессии. Реакция приводов может быть самой разнообразной. Тот же PHILIPS в зависимости от "настроения" своих электронных цепей, то рапортует об ошибке чтения, то возвращает совершенно бессмысленный мусор, в котором не угадывается даже синхро-последовательность, возглавляющая заголовок сырого сектора.
Основной недостаток защитных механизмов с искаженным TOC'ом состоит в том, что некоторые приводы такие диски просто не "видят" и потому не могут их воспроизвести. Легальный пользователь, испытавший несовместимость защиты со своей аппаратурой, в лучшем случае обложит ее разработчика матом и поспешит вернуть диск продавцу…. если конечно, сможет вытащить эту "бяку" из недр CD-ROM'а, что вовсе не факт, поскольку микропроцессорная начинка некоторых приводов при попытке анализа искаженного TOC'а просто "зависает" и привод полностью абстрагируется от всех раздражителей внешнего мира, не реагируя в том числе и на настойчивые попытки пользователя сделать диску "EJECT". Дырку для аварийного выброса диска, правда, еще никто не отменял[3], но по слухам не везде она есть (хотя лично мне приводов без дырки еще не встречалось), а там где есть – зачастую оказывается скрытой за декоративной панелью или – что более вероятно – пользователь может вообще не знать, что это за отверстие такое, для чего оно предназначено и как им, собственно, следует пользоваться. На "Макинтошах" таких дырок нет – это точно (или же "Маковские" пользователи все сплошь идиоты). Во всяком случае, количество судебных исков, поданных последними, в буквальном смысле слова не поддается ни разуму, ни исчислению. Самое интересное, что подавляющее большинство этих исков были удовлетворены и разработчикам пришлось оплатить и "ремонт" аппаратуры, и моральный ущерб, и, собственно сами, судебные издержки. (Между нами говоря, снятие защиты с дисков, записанных с грубыми нарушениями Стандарта, коими в частности и являются диски с искаженным TOC, не считается взлом, и не преследуется по закону, поэтому: ломайте, ломайте и еще раз ломайте).
Так как же все-таки скопировать такой диск?
Конечно, с помощью "Добермана Пинчера" (или любого другого блочного копировщика файлов), HIEW'а, двух образов защищенного диска (один– с первой сессией – от Clone CD, другой – со второй сессией – от Алкоголя) и еще чьей-то матери мы можем воссоздать идентичную копию оригинального диска, путем их совокупного (не путать с совокупленным) объединения, но… это будет как-то не по-хакерски, да и вообще не красиво.
Чтобы не писать свою собственную программу "прожига" диска ограничимся использованием Clone CD. При условии, что подсунутый ему образ диска запечатлен правильно, Clone CD обычно справляется с прожигом на ура. Итак, у нас есть более и менее верный файл image.ccd, содержащий TOC, но недостает файла образа image.img. Попробуем его получить? Будем отталкиваться от того, что LBA-адреса всех секторов диска пронумерованы последовательно, включая области, занятые Lead-In/Lead-Out и прочим служебным барахлом. Разумеется, непосредственное чтение служебных областей диска на сектором уровне невозможно, но… именно на этом мы и собираемся сыграть! Последовательно читая диск с первого по последний сектор, мы обнаружим, что сектора с LBA-адресами с 0- по 2055 сектор включительно читаются без каких-либо проблем, после чего наступает сумеречная зона не читающихся секторов, протянувшаяся вплоть до сектора 13307. Здесь сектора либо совсем не читаются, либо возвращаются в сильно мутированном виде, легко опознаваемым по отсутствию правильной синхро-последовательности в их заголовке. Наконец, с адреса 13308 чтение вновь продолжается без каких-либо проблем.
Судя по всему мы имеет дело в двух-сессионным диском и сумеречная зона между сессиями есть ни что иное как Lead-Out/Lead-In. Накинув два сектора на post-gap (при условии, что он записан с соблюдением Стандарта), получаем, что LBA-адрес последнего значимого сектора первой сессии составляет: 2057 или, в пересчете на абсолютные единицы – 00 минут, 29 секунд и еще 32 фрейма. Соответственно, LBA-адрес первого сектора второй сессии равен: 13308 + 150 (pre-gap) == 13458 или 3 минуты, 1 секунда, 33 фрейма. Конечно, если исследуемый диск содержит большое количество ошибок, то его анализ значительно усложняется, т. к. физические дефекты на сектором уровне могут выглядеть точно так же, как Lead-In/Lead-Out области, конечно, при том условии, что дефективные области имеют соответствующую протяженность – а это вряд ли.
Отбросив сектора, расположенные в зонах pre- и post-gap (т.е. 150 секторов от конца первой читаемой области и ровно столько же от начала следующей), мы должны объединить их в один файл, используя для этой цели любой файловый копировщик (например, штатную команду MS-DOS copy file_1 /b + file_2 image.img). Остается прочитать сырой TOC SCSI/ATAPI командой READ TOC (opcode: 43h, format: 2h) и записать его в image.ccd файл в соответствии с синтаксисом Clone CD. Как альтернативный вариант – можно воспользоваться ccd-файлом, сформированным программой Alcohol, предварительно скорректировав pre-gap Mode (как уже сказано выше, Алкоголик определил его неправильно, перепутав Mode 1 с Mode 2). Согласно стандарту, режим сектора задается пятнадцатым, считая от нуля, байтом его заголовка. Если этот байт равен одному (что, собственно, и наблюдается в нашем случае), то и Mode сектора будет 1, но не 2.
При условии, что все сделано правильно, после записи собственноручно сформированного образа диска, мы получаем практически идентичный оригинал. Просто? Да проще простого! И написать автоматический копировщик, автоматизирующий наш труд, можно буквально за несколько часов! Если чтение "сырых" секторов с диска представляет для вас проблему, воспользуйтесь исходными текстами утилит ASPI32.raw/SPTI.raw как раз такое чтение и осуществляющих.
Так что искажение TOC'a – не очень-то надежный прием защиты от копирования, как ни крути. Правда, от обычных пользователей, вооруженных Clone CD/Alcohol'ем он все-таки спасает, а больше от защиты зачастую и не требуется.
Условные обозначения
Под приводом NEC понимается _NECCD-RW NR-9100A; firmware version 1.4;
Под приводом ASUS понимается ASUS CD-S500/A; firmware version 1.4K;
Под приводом PHILIPS понимается PHILIPS CDRW2412A firmware version P1.55;
Alcohol 120% – отличный копировщик защищенных дисков, условно-бесплатную версию которого можно утянуть с сайта http://www.alcohol-soft.com/. Автоматически ломает более половины всех существующих типов защит от копирования и позволяет динамически монтировать образы защищенных дисков на виртуальный привод CD-ROM, что очень удобно для экспериментов. К сожалению, монтированию подлежат лишь "правильные" образы, коими большинство образом защищенных дисков отнюдь не являются.
Clone CD – хороший копировщик защищенных дисков, условно-бесплатную версию которого можно утянуть по следующему адресу: http://www.elby.ch/. С копированием защищенных дисков в полностью автоматическом режиме Clone CD справляется скорее плохо, чем хорошо, однако, после ручного шаманства с настройками и непосредственно самим образом защищенного диска он может скопировать добрую половину существующих типов защит. Утверждение о том, что Clone CD "берет" практически все существующие защиты от копирования – ложное и невероятно далеко от действительности.
Восстановление очищенных CD-RW
Существует две принципиально различных методики очистки CD-RW: быстрая
(quick) и полная (full). При быстрой очистке диска с него удаляется лишь область TOC, в результате чего диск выглядит "пустым", хотя его основное содержимое остается совершенно нетронутым. Напротив, при полной очистке луч лазера "выжигает" всю поверхность диска целиком– от первого пита до последнего. Естественно, на это требуется время и полная очистка диска может растянуться на добрый десяток минут, в то время как быстрая спокойно укладывается в одну-две минуты.
Восстановление полностью очищенных дисков возможно только на специальном оборудовании, способном улавливать даже незначительные изменения отражательной способности рефлекторного слоя. Такое оборудование подавляющему большинству пользователей, разумеется, недоступно. Однако диски, подвергнувшиеся быстрой очистке, могут быть восстановлены и на штатом рекордере (правда, не на всех моделях).
Мы не будем касаться этической стороны проблемы и для простоты предположим, что вы хотите реанимировать свой собственный непредумышленно очищенный CD-RW диск, или условимся считать всех читателей сотрудниками КГБ, которым поручили восстановить информацию с диска, добытого бесстрашными советскими разведчиками у американских шпионов. Отметим лишь то, что восстановление конфиденциальной информации с чужих CD?RW может быть классифицировано как получение несанкционированного доступа к последней со всеми вытекающими отсюда последствиями (на долгие годы – друзья в клетку и небо – в полоску).
Для опытов по восстановлению информации с очищенных CD-RW дисков нам потребуется следующее:
· пишущий привод
не слишком дотошно следящий за корректностью содержимого TOC'a, поддерживающий режим RAW DAO и умеющий читать содержимое pre-gap первого трека. Не все модели писцов подходят для этой цели, поэтому, будьте готовы к тому, что вам придется перепробовать большое количество различного оборудования (из двух моих рекордеров для восстановления очищенных дисков подходит лишь NEC, а PHILIPS на это, увы, не способен);
· продвинутый записывающий soft, позволяющий манипулировать служебными областями диска по своему усмотрению. Вы можете использовать Clone CD, CDRWin, Alcohol 120% или любую другую аналогичную утилиту по своему выбору. Однако, весь последующий материал рассчитан исключительно на Clone CD и при переходе на остальные программы вы можете столкнуться с теми или иными проблемами. Если вы не уверены, что сможете справиться с ними самостоятельно – используйте Clone CD, ну а затем, по мере приобретения профессиональных навыков и должного опыта, вы без труда восстановите диск любой такой программой;
· средство для работы с диском на сектором уровне, – утилита, позволяющая прочесть любой заданный сектор (конечно, при условии, что он вообще читается приводом) и не пытающаяся пропустить те сектора, в которых по ее самоуверенному мнению ничего интересного все равно нет. Копировщики защищенных дисков, перечисленные выше, для этой цели не подходят, т. к. отказываются читать "бесполезные" с их точки зрения сектора. Может быть, другие копировщики ведут себя и иначе – не знаю, не проверял. Вместо этого необходимую для работы утилиту я написал самостоятельно (ее можно скачать с сайта журнала по адресу: http://xxxx).
Прежде, чем начинать экспериментировать, дайте разберемся, почему после очистки диск перестает читаться. Вопрос не так глуп, каким он кажется, – ведь информация, необходимая для позиционирования головки и поиска конкретных секторов при быстрой очистке диска остается нетронутой! Управляющие данные "размазаны" вдоль всей спиральной дорожки и для чтения диска на сектором уровне TOC в, общем-то, и не нужен. Да, отсутствие TOC'a значительно усложняет анализ геометрии диска и для определения количества треков/сессий диска, в общем случае, привод должен прочитать весь этот диск целиком. Но при восстановлении информации фактор времени играет второстепенную роль и им можно полностью пренебречь.
Тем не менее, при попытке чтения любого из секторов очищенного диска, привод с неизменным упорством возвращает ошибку. Почему? Очень просто, – это "защита" от чтения заведомо некорректной информации. Еще ни один из всех знакомых мне приводов не мог читать сектора за пределами Lead-Out области (собственно, на программном уровне содержимое Lead-in/Lead-out областей недоступно тоже). Тем не менее, эта невозможность отнюдь не концептуального уровня и удаление из микропрограммы привода "лишних" проверок позволят прочитать такой диск на ура. Нет, не подумайте! Призывать вас к дизассемблированию прошивок я не собираюсь. Дело это сложное, трудоемкое, да к тому же небезопасное. Неверно хакнутая прошивка может ко всем чертям угробить привод без малейшей надежды на его восстановление. Нет, уж лучше мы пойдем другим путем!
Идея восстановления информации, предлагаемая автором, в общих чертах сводиться к записи на диск фиктивного TOC, адреса Lead-in и Lead-out областей которого указывают на первый и последней сектор диска соответственно, а стартовый адрес первого трека аккурат совпадает с концом pre-gap области, которая по стандарту должна занимать не менее 150 секторов (или 2 секунд в пересчете на абсолютные адреса). После этой нехитрой операции привод будет читать оригинальное содержимое очищенного диска как миленький, конечно, при том условии, что мы ухитримся настроить пишущий софт так, чтобы он записав фиктивный TOC, никоим образом не пытался интерпретировать подсунутые ему указатели на Lead?in/Lead?Out области как указание "выжечь" всю поверхность диска целиком.
Проверка показывает, что Clone CD вообще не записывает такой TOC на диск, ругаясь на несоответствие размеров диска и образа файла. Alcohol 120% выполняет нашу просьбу без лишних препирательств, но совсем не так как мы хотели! Забив весь восстанавливаемый диск непонятно откуда взятым мусором, он авторитетно сообщает, что в процессе записи произошли ошибки и, возможно, вам следует убедиться в исправности оборудования.
Хорошо, зайдем с другой стороны. Запишем на диск один реальный трек, занимающий минимально возможное количество секторов (по стандарту – 300, но некоторые проводы вполне удовлетворяются и меньшими значениями), но расширим его pre-gap с двух секунд на… весь диск! В результате, мы потеряем лишь 300 последних секторов, но получим доступ ко всему остальному содержимому. Учитывая, что на диске этих секторов начитывается немногим более 300 тысяч, нетрудно подсчитать, что процент успешно восстановленной информации составляет по меньшей мере 99,999% емкости всего диска, да и то, лишь при том условии, что исходный диск был забит целиком, что в живой природе практически никогда не наблюдается. Если же это вас не удовлетворяет – разрабатывайте своей собственный софт, корректно записывающий фиктивный TOC, но ничего не делающий сверх этого (Lead-in область по любому записывает сам привод, ну а без Lead-out при аккуратном обращении с диском, в принципе, можно и обойтись, главное – пытаться прочитать сектора, находящиеся за пределами диска, иначе поведение привода станет трудно предсказуемым). Мне же по любому это делать лень, – с восстановлением полностью забитых дисков я еще сталкивался. Во всяком случае пока…
Процедура восстановления состоит из трех частей: подготовки исходного образа трека с нормальным pre-gap; увеличения pre-gap до размеров целого диска и записи исправленного образа на восстанавливаемый диск. Первые два этапа достаточно выполнить всего один раз, т. к. полученный образ (далее мы будем называть его "лечебным") может использоваться для всех дисков (читай: для всех дисков той же самой емкости, по понятным соображениям вы не сможете корректно восстановить 23-минутрый диск с помощью образа, предназначенного для 80-минутного диска и, соответственно, наоборот).
Для начала возьмем чистый CD-RW диск ("чистый" не в смысле "ни разу не записанный", а очищенный быстрой или полной очисткой, так же для этих целей подойдет и CD-R). Используя любую утилиту для штатного "прожига" запишем на него один крошечный файл, "весящий" не более 500 килобайт (более тяжелый файл просто не уместится в запланированные 300 секторов). Выполнять финализацию диска не нужно.
Запустим Clone CD (Alcohol 120%) и снимем образ диска. Спустя минуту-другую на винчестере образуются два файла: file name.img и file name.ccd (если вы попросили Clone CD сохранять так же и субканальную информацию, образуется третий файл – file name.sub, однако, субканальная информация в данном случае будет только мешать, потому опцию "чтение субканалов из треков с данными" лучше всего отключить или же просто удалить file name.sub с диска; так же нам не нужен "Cue-Sheet", который Clone CD предлагает создавать для совместимости с другими программами, конкретно – с CDRWin).
Открыв file name.ccd-файл любым текстовым редактором (например, "Блокнотом") найдем в нем следующие строки (ключевые слова для поиска "Point=0xa2" и "Point=0x01"):
[Entry 2] [Entry 3]
Session=1 Session=1
Point=0xa2 Point=0x01
ADR=0x01 ADR=0x01
Control=0x04 Control=0x04
TrackNo=0 TrackNo=0
AMin=0 AMin=0
ASec=0 ASec=0
AFrame=0 AFrame=0
ALBA=-150 ALBA=-150
Zero=0 Zero=0
PMin=0 PMin=0
PSec=29 PSec=1
PFrame=33 PFrame=0
PLBA=2058 PLBA=0
Восстановление удаленных файлов с CD-R/CD-RW
Заявляя о своей поддержке многосессионных дисков, операционные системы Windows 9x и Windows NT (вплоть до W2K включительно) тактично умалчивают о том, что поддерживают их лишь частично. Каждая сессия – это вполне самостоятельный том (в терминологии Windows – "логический диск"), имеющий свою собственную файловую систему и свои собственные файлы. Благодаря сквозной нумерации секторов лазерного диска, файловая система одной сессии может ссылаться на файлы, физически расположенные в любой другой сессии. Для того, чтобы с многосессионным диском было можно работать как с единым томом, файловая система последней сессии должна включать в себя содержимое файловых систем всех предыдущих сессий. Если этого не сделать, то при просмотре диска штатными средствами Windows, оглавления остальных сессий окажутся потерянными, поскольку Windows монтирует лишь последнюю сессию диска, а все прочие – игнорирует. Программы "прожига" CD?R/RW по умолчанию добавляют содержимое файловой системы предыдущей сессии к последующей, однако это еще не означает, что последняя сессия диска всегда
содержит в себе все то, что имеют предыдущие.
Рассмотрим например, как осуществляется удаление файлов с CD-R/RW. Нет, это не опечатка! Содержимое дисков CD-R, несмотря на физическую невозможность их перезаписи, в принципе все же уничтожаемо. Для имитации удаления файла, программы записи на CD просто не включают ссылку на уничтожаемый файл в файловую систему последней сессии[1]. И хотя "удаленный" файл все еще присутствует на диске, "отъедая" часть дискового пространства, при просмотре содержимого диска из-под Windows он уже не отображается в каталоге. Какой же тогда смысл несет в себе удаление файлов с CD-R, если свободная емкость диска при этом не увеличивается, а даже уменьшается[2]?! – удивленно спросит иной читатель. На самом же деле, смысл этой операции (если, его вообще можно назвать "смыслом") заключен исключительно в сокрытии "удаляемых" файлов от простых пользователей. Раз удаленные файлы не видны при просмотре содержимого диска штатными средствами, то неквалифицированному пользователю они формально недоступны. Подчеркиваю: для штатных средств операционной системы Windows – недоступны, но те же "Маки" позволяют монтировать любую сессию диска на отдельный том, благодаря чему при просмотре многосессионных дисков под "Маками" все удаленные файлы сразу же "всплывают".
Аналогичным образом обстоят дела и при удалении информации с CD- RW дисков. Несмотря на теоретическую возможность физического уничтожения их содержимого, подавляющее большинство записывающего софта поддерживают лишь функцию очистки всего диска целиком, но не в состоянии выборочно удалять отдельные файлы. Так что все, сказанное выше о CD-R дисках, в равной мере применимо и к CD-RW.Поэтому, записывая на диск информацию, предназначенную для передачи постороннему лицу, ни в коем случае не используйте для этой цели, болванки, содержащие конфиденциальные данные. "Удаление" ранее записанных на болванку данных на самом деле не уничтожает их!
Просматривая содержимое лазерного диска, полученного от приятеля (купленного на радио-рынке, вытащенного из мусорной корзины) имеет смысл попытаться заглянуть внутрь предыдущих сессий на предмет поиска скрытой информации. Как показывает практика, очень часто там обнаруживается много интересного. Так же, вам может потребоваться восстановить ошибочного удаленный файл со своего собственного диска, а то и воскресить всю пришибленную сессию целиком (некоторые программы записи на CD позволяют пользователю выбирать: следует ли при создании новой сессии добавлять в нее файловую систему предыдущей или же в новую сессию следует включать только новые файлы. Неверный выбор настроек приводит к утрате содержимого всех предыдущих сессий, но к счастью, эта утрата обратима).
Для восстановления удаленных файлов можно воспользоваться любой программой, умеющий извлекать содержимое выбранной сессии диска и записывать его в ISO-образ. Пусть для определенности это будет Roxio Easy CD Creator. Позволив приводу "заглотить" восстанавливаемый диск, в меню "CD" выбираем пункт "CD Information" и после непродолжительного ерзанья головки привода на экране отображается диалоговое окно следующего вида:
