Разработка динамических сайтов
SEO услуги
Управление контекстной рекламой

Вход на хостинг

Имя пользователя:*

Пароль пользователя:*

IT-новости

20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла

Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......

подробнее

30.07.2015 Ищем уникальный контент для сайта

Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......

подробнее

11.05.2015 Распространённые ошибки разработчиков сайтов

Не секрет, что в сети Интернет насчитывается миллионы сайтов, и каждый день появляются тысячси новых......

подробнее

PMin=0                  ; -+

PSec=0                  ; -+

PFrame=0                ; -+

PLBA=-150

 

[TRACK 1]

MODE=0

INDEX 1=45000

Сокращение сессий с двух до одной очень сильно смущает. Куда девалась вторая – неискаженная(!) сессия, вообще непонятно. И, хотя искаженные данные первого трека сохранились, оказались неожиданно измененными поля Application Code и ATIP (и это несмотря на то, что запись производилась на ту же самую CD-RW-болванку, что и раньше, хотя ее «прожиг» осуществлялся различными приводами).

Как следствие: скопированный диск оказывается работоспособен не на всех приводах (ASUS и NEC его прочитают, а вот PHILIPS – нет), к тому же защите ничего не стоит прочитать текущий TOC и сравнить его с эталонным.

Короче говоря, «факир был пьян, и фокус не удался». Что ж, попробуем обратиться за помощью к Alcohol– уж он-то должен наверняка с этим справиться. Действительно, Alcohol видит обе сессии: как искаженную, так и неискаженную, однако по малопонятным причинам сохраняет в образ лишь вторую из них (Clone CD сохранял первую). Ну что это за зоопарк, а? Содержимое TOC скопированного диска можно даже и не сравнивать – там будет далеко не то, что защита собирается ожидать. И напрасно! Содержимое TOC, снятое Alcohol, практически полностью соответствует оригиналу. Единственно, в чем ошибся Alcohol, – определил тип pre-gap обоих треков не как Mode 1, но как Mode 2. Впрочем, в силу отсутствия в образе первой сессии полученная с его помощью копия диска все равно оказывается неработоспособной.

Рисунок 2. Alcohol видит обе сессии защищенного диска, но…

Рисунок 3. Копирует лишь вторую из них, а первую нагло пропускает

А ведь заявлялось, что Clone CD/Alcohol 120% способны копировать любые существующие на сегодняшний момент защищенные диски, и вдруг на поверку оказывается, что даже такую простую защиту, которую может создать на кончике пенька любой программист, они преодолеть ни вместе, ни по раздельности не в состоянии! Причем аппаратура, на которой все эти эксперименты и осуществлялись, возможность корректного копирования искаженного диска гарантированно поддерживает (сам проверял), и потому отмахнуться физическими ограничениями приводов разработчикам обоих копировщиков уже не удастся!

Даже не верится, что такой простой прием «ослепляет» лучших копировщиков защищенных дисков! Неужели и вправду создание некопируемых дисков вполне осуществимо на обыкновенном бытовом оборудовании?! Да! Именно так! Конечно, не стоит путать некопируемость диска автоматическими копировщиками с принципиальной невозможностью получения его идентичной копии. В ручном режиме копирование таких дисков вполне осуществимо (правда, при условии, что ваш пишущий привод поддерживает режим RAW DAO, а читающий – читает сектора из обоих секций), и сейчас мы продемонстрируем как.

Так как же все-таки скопировать такой диск?

Конечно, с помощью «Добермана Пинчера» (или любого другого блочного копировщика файлов), HIEW, двух образов защищенного диска (один – с первой сессией – от Clone CD, другой – со второй сессией – от Alcohol) мы можем воссоздать идентичную копию оригинального диска путем их совокупного объединения, но… это будет как-то не по-хакерски, да и вообще некрасиво.

Чтобы не писать свою собственную программу «прожига» диска, ограничимся использованием Clone CD. При условии, что подсунутый ему образ диска запечатлен правильно, Clone CD обычно справляется с прожигом «на ура». Итак, у нас есть более и менее верный файл image.ccd, содержащий TOC, но недостает файла образа image.img. Попробуем его получить? Будем отталкиваться от того, что LBA-адреса всех секторов диска пронумерованы последовательно, включая области, занятые Lead-In/Lead-Out и прочим служебным барахлом. Разумеется, непосредственное чтение служебных областей диска на секторном уровне невозможно, но… именно на этом мы и собираемся сыграть! Последовательно читая диск с первого по последний сектор, мы обнаружим, что сектора с LBA-адресами с 0 по 2055 сектор включительно читаются без каких-либо проблем, после чего наступает сумеречная зона нечитающихся секторов, протянувшаяся вплоть до сектора 13307. Здесь сектора либо совсем не читаются либо возвращаются в сильно мутированном виде, легко опознаваемые по отсутствию правильной синхропоследовательности в их заголовке. Наконец, с адреса 13308 чтение вновь продолжается без каких-либо проблем.


Предыдущая страницаОглавлениеСледующая страница
 
[001] [002] [003] [004] [005] [006] [007] [008] [009] [010] [011] [012] [013] [014] [015] [016] [017] [018] [019] [020]
[021] [022] [023] [024] [025] [026] [027] [028] [029] [030] [031] [032] [033] [034] [035] [036] [037] [038] [039] [040]
[041] [042] [043] [044] [045] [046] [047] [048] [049] [050] [051] [052] [053] [054] [055] [056] [057] [058] [059] [060]
[061] [062] [063] [064] [065] [066] [067] [068] [069] [070] [071] [072] [073] [074] [075] [076] [077] [078] [079] [080]
[081] [082] [083] [084] [085] [086] [087] [088] [089] [090] [091] [092] [093] [094] [095] [096] [097] [098] [099] [100]
[101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120]
[121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140]
[141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153]

+7 (831) 413-63-27
ООО Дельта-Технология ©2007 - 2023 год
Нижний Новгород, ул. Дальняя, 17А.
Rambler's Top100