zombi

Как заставить винду считать что на диске файловая система RAW независимо от того какая реально FS на диске находится?

Рано радовался. При выполнении функции DeviceIoControl с кодом IOCTL_DISK_DELETE_DRIVE_LAYOUT винда сразу затирает 70 байт в конце нулевого сектора диска нулями (таблицу разделов диска и сигнатуры обнуляет). И при следующем чтении сектор уже испорчен!

1. Дабы дать возможность клиентам использующим некое устройство в составе которого присутствует неформатированная карта самостоятельно менять функциональность изделия путём переписывания оной с минимальным привлечением для этого разработчика того самого лисапета. 2. Удобно запускать запись образа на карту прямо из консоли. 3. Можно менять содержимое части карты без полного переписывания оной. 4. Просто было интересно как шуршит вся эта "кухня" с прямым доступом к диску.

Интересно, а какие стоят Step-Down Voltage RegulatorЫ в этом изделии? На фото не видно и в схеме не указаны.

методика - гуглопоиск Windows IOCTL Reference

Нашел 0x7С100 Теперь делай с дисками ШТО ХОШ не взирая на лица содержимое! И помощь имагеврайтерописателей не понадобилась.

Таки да, писать разрешает, но только если приложение открывает диск без разрешения совместного доступа на запись. Для FAT16/32 это помогает, для NTFS нет. Копаю дальше. Вот такая функция еще имеется DeviceIoControl и вроде как с кодом IOCTL_DISK_DELETE_DRIVE_LAYOUT должна заставить винду забыть о всех настройках диска в системе (если я правильно понял описание). Но Delphi не знает такой константы. Где взять конкретное её значение?

печальный вывод. И тем не менее M$ ведёт себя по разному ... и не считает что на них нет никакой FS

Да есть. Уже лет 100 как её пользую. Только мне нужно свою подобную прогу накалякать. Со своим функционалом.

А я, по Вашему, из под чего пытаюсь получить доступ к диску?

Какие-нибудь imagewriterЫ и winhexЫ прекрасно читают и пишут такие диски. Под вопросом "как побороть" я имел ввиду - как это побороть в программе написанной мной на Delphi с использованием Windows API? Что такого особенного эти imagewriterЫ и winhexЫ делают что у них такой проблемы на возникает? to SSerge к чему Ваши ссылки? Попутный вопрос : можно ли как-то из под винды прочитать содержимое идентификационного сектора CF карты? Того сектора который карта по CF-ATA команде "Identify Device" (0xEC) выдаёт ? PS. Как выяснилось : если на CF карте вообще нет никакой файловой системы, то винда разрешает её и читать и писать. если на карте любая FS от винды, то её можно только читать, а запись запрещена. если от FS от линукса, то ни прочитать ни записать карту невозможно. Мне нужно написать программу которая могла бы читать/писать образы дисков с/на CFMC карты независимо от содержимого на оных. Подскажите куда копать?

Сэр, Вы пьяны? Где бы он не использовался в дальнейшем, а прочитать/записать я его хочу в винде и сейчас! Именно такая возможность у этой функции и есть. Вы не знали? Да, его родимого. Первый сектор диска размером 512 байт.

Windows 7 (32-bit). Функцией CreateFile открываю физический диск (Compact Flash Card в кардридере USB). Функцией ReadFile пытаюсь прочитать первый сектор. Всё отлично работает если : карта не отформатирована вообще, отформатирована в Windows (FAT любой), на карте какой либо бред записан. И только если карта отформатирована в Linux, то при попытке чтения возникает ошибка 87. Почему это происходит? Как побороть?

Спасибо. Успокоили.

Я так полагаю что всё специально максимально запутанно и неоднозначно дабы на корню отбить охоту у юзеров использовать какую либо защиту прошивки и уж тем более ШЫФрование! Ну его нафиг это отключение JTAGа. Скажите достаточно ли для приемлемой защиты вот этого: 1. В проекте в квартусе в "Device options" поставил галку "Verify protect" 2. В конвертере создал EKP и шифрованный POF (Security Options - все OFF) Может ли злоумышленник "вытащить" прошивку в таком случае?

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

Нее, это уже перебор. Вдруг апгрэйд потребуется. Документик конечно изучал. Но наверно не внимательно. Да и ни слова по русски там нет тяжело понять всю эту "кухню". И не вижу в документе где про Tamper Protection пишут...

Нет. Ничего дополнительного прикручивать мне не надо! Я всего лишь хочу добиться невозможности считывания прошивки из MAX10. А если и прочитают, то зашифрованную - на здоровье. Дабы запретить, ну или максимально усложнить, копирование изделия.

Запутали Вы меня окончательно.

С созданием и заливкой в мс шифрованного битстрима проблем нет. Шифрую, заливаю всё как производитель рекомендует (.pof+.ekp > плис). Но как проверить что все правильно, и в плис всё именно в зашифрованном виде находится? Пока проверяю так : Пытаюсь залить .sof (именно в CRAM залить) без предварительного полного стирания чипа. Если программатор выдаёт ошибку, то считаю что все ОК. Насколько правильный такой контроль? Или подскажите как протестировать? И меня по прежнему интересует подробное описание каждой опции 'Security Options' и каждого возможного её состояния. Сейчас опции не меняю, все в состоянии "OFF (unless by the OTP fuse option)". Достаточно ли этого для надёжной защиты прошивки от чтения?

Может кто посоветовать доку по особенностям применения шифрованного битстрима? Для MAX10 или для другого похожего семейства Intel, а если б еще и на русском...

Всё, разобрался. Качнул Quartus Prime Standard Edition Quartus Prime 18.1 Programmer and Tools (32-bit) (вроде как последняя 32-битная версия). Теперь весь "колхоз" за 50 сек стирает и шьёт

Даже если что-то не так прожглось то изделие не будет работать в принципе. Что вылезет при обязательном полном тестировании целиком всего изделия в лаборатории. Но проблема кажется не в сравнении а в чём-то другом. Продолжил копать дальше. Теперь запускаю quartus_pgm c параметрами и опциями. Оказалось что если программировать по одному корпусу U169, то общее время стирания и прожига каждой мс примерно 17 сек. Даже если все три корпуса U169 скопом в одной командной строке писать - примерно 30 сек. занимает. И только если один корпус U324 (или вместе с U169-ми) программировать - время 3 мин 30 сек! Т.е. если программируется U324 - время 3:30, независимо от того один этот чип или вся цепочка пишется! Что за беда такая? В чем может быть проблема? Может quartus_pgm обновить? Какая версия последняя 32-х битная есть?

В JTAG цепочке 4-ре плис MAX10. Все 10М02, первая в корпусе U324, остальные U169. Файл прошивки для U324 - A.pof, для U169 один для всех - B.pof Программирую путём запуска BAT файла из командной строки в котором стартует quartus_pgmm.exe с параметром *.cdf Сам BAT файл: E.cdf P.cdf Результат работы (копия экрана): Время программирования 3 минуты 29 сек! Причём 2 мин. 45 сек - это между строками : "Info (209021): Performing verification on device(s)" и "Info (209023): Programming device(s)" Как я понимаю это verify? Как запретить процесс сравнения? Или как ускорить всю эту "кухню"? Рад любым советам, ибо три с половиной минуты ну ни в какие ворота!!!

А по другому никак. Площадь ограничена. Горизонтально sdram не поставить.