А каким образом, какой командой? И были ли признаки что он выдает межсекторные данные?Сообщение от Titus
А каким образом, какой командой? И были ли признаки что он выдает межсекторные данные?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Код:DeviceIoControl(h, IOCTL_FDCMD_SEEK, &Track, sizeof(Track), NULL, 0, &dwRet, NULL); SetDataRate(h, 1); // 300kbps FD_READ_WRITE_PARAMS rwp = {FD_OPTION_MFM, 1, 0, 0, // Определить rpw: 0, 7, 10, 0, 0}; // Режим чтения - MFM // PHead - 0 (Phisycal Head 0) // Cyl - 0 (not used) // Head - 0 (not used) // Sector - 0 (not used) // Size - 0 (0 - 80 байт?, // 1 - 256 байт, // 2 - 512 байт, // 3 - 1024 байта, // 4 - 2048 байта, // 5 - 4096 байт, // 6 - 8192 байт, // 7 - 16384 байта. // EOT - 5 // Gap - 0 (not used?) // DataLen - 0 (not used) printf("\nRaw Read"); DeviceIoControl(h, IOCTL_FDCMD_READ_TRACK, &rwp, sizeof(rwp), DataBuf, 0x2000, &dwRet, NULL); printf("\nAdr = %X, Len = %X\n", DataBuf, dwRet); // pause WriteFile(rawFile, DataBuf, 0x2000, &dwRet, NULL); // Записываем raw-дорожку в файл
Да, сырая дорожка читалась.
CPLx(14.08.2020)
Точно! У меня тоже прочиталась. Хотя тут надо именно те параметры выставлять. Круто.
Лично мне показалось, что толку от чтения трека целиком маловато, т.к. когда сбивается синхронизация, невозможно восстановить информацию.
Синхронизация срывается в момент окончания записи данных сектора - там возникает шов новой записи (записи сектора) и старой (данных записанных при форматировании). По этой причине, если трек форматирован, но на нём не производилась запись секторов, то синхронизация на нём не срывается (это я только что проверил: прочитал трек, и все пробелы там отображены корректно). Сейчас посмотрел на записанном треке - весь первый сектор прочитан правильно, а срыв синхронизации происходит в момент окончания его записи: по идее должны идти байты 4E, но идут 0x27 (которые представляют собой сдвинутый 4E). Т.е. мы знаем в какой точке происходит срыв синхронизации - это сразу после CRC сектора. Мы также знаем чем заполнены эти пробелы между секторами (байтом 4E), поэтому можем вычислить насколько там произошло смещение, сравнив полученные данные с теми что должны быть. Поэтому в принципе восстановить трек можно и попытаться.
Нельзя восстановить, т.к. сместившись, информация уже не может быть расшифрована из MFM. Вернее, она расшифровывается но не правильно и с потерями. Обратно ее преобразовать в MFM, сместить на бит, и перерасшифровать не получится.
CPLx(14.08.2020)
Мне кажется, что использовать её всё-таки можно. Для того чтобы обнаруживать те же самые защиты - плавающие данные, данные без заголовков секторов. Данные самих секторов читать ей не получится действительно. Но хорошо, что после сбивки, очередной правильный синхрокод A1A1A1 возвращает все на место.
Межсекторные 4E даже сбитые прекрасно восстанавливаются. Но сами сбитые данные это не поможет увидеть (при перезаписи секторов перезаписанные тайминги не совпадают с межсекторными).
Вообще можно попробовать перевести данные в МFM поток и сравнить с тем что должно читается без сбивки (прочитав другими утилитами). Возможно, не все так плохо.
MFM поток представляет собой последовательность длительностей в пропорции 2/3/4, а фальшивый синхрокод C2 смещает байтовое окно. Так вот насколько я понял, при этом смещении происходит дублирование куска байта в MFM представлении. Эти закономерности можно было бы попытаться вычислить и сделать некий компенсатор.
Последний раз редактировалось Dexus; 15.08.2020 в 04:24.
Данные совсем без заголовков секторов она прочитать не сможет, судя по всему. Работает эта команда не так как в ВГ93. Она ждет индексный импульс, после чего ищет первый заголовок сектора, потом начинает читать содержимое трека. Первый выданный ей байт это первый байт данных этого сектора. Когда сектор кончается, она продолжает читать данные дальше, пока не считается весь трек (в моем случае она это делает циклически несколько раз, т.е. несколько оборотов диска, выдавая порядка 28 000 байт). Если на треке нет заголовков секторов, то эта команда ничего не читает и драйвер выдает ошибку 1122. У меня подозрение, то что как Titus её использовал это нестандартный прием, т.к. не соответствует документации.
Вот почему-то не возвращает. Этот синхрокод A1A1A1 пишется перед данными каждого сектора и по идее данные секторов должны быть правильными по этой причине. Но на практике это не так, и синхронизация почему-то не восстанавливается, и данные секторов оказываются искаженными.
Вот картинка полученная при чтении чистого трека, на который не производилось посекторной записи и где синхронизация не слетает в конце секторов.
https://ibb.co/WtpF9Wc
(Значения байт указаны в десятичной системе. 78 это 4E) Первым синим прямоугольником обведен 15-й сектор размером 256 байт (имеет код 1), там же видно что это 61-й цилиндр. Вторым синим прямоугольником - 16-й сектор. Большие области нулей - данные, перед которыми идут байты 161, 161, 161, 251 (A1 A1 A1 FB). А красный квадрат это момент срыва синхронизации, как я полагаю из-за шва который получается при записи трека когда он зацикливается. И дальше все сектора идут искаженные, в том числе их данные. Данные становятся равными 255 - это явно попали синхроимпульсы MFM вместо данных. И синхронизация не восстанавливается почему-то перед областями этих данных, хотя по идее должна. Почему так происходит непонятно.
Последний раз редактировалось CPLx; 15.08.2020 в 06:18.
Область с 12 ноликами идет перед A1A1A1, и действительно странно, поскольку Этот синхрокод в контроллере автоматом должен смещать начало байта. Вне зависимости от режима чтения. Может новые контроллеры позволяют отключать пересинхронизацию после первичной? Старые вроде не позволяют (равно как и отключать синхронизацию по C2).
Грустновато с этой точки зрения. Пространства для маневров мало.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
