Перейти к содержанию
    

JeDay

Свой
  • Постов

    278
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о JeDay

  • Звание
    Местный
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

3 004 просмотра профиля
  1. В этом случае ваше ядро можно сдампить с флешки, запустить на QEMU и найти файл с ключем, если догадаются где он и для чего. Но декодедирование пакетов этим ключем можно спрятать в другой утилите. Тоесть придется хакерам еще и ее реверс-инжинирить чтоб алгоритм получить, ну либо научиться правильно вызывать. МОжно как вариант в Busybox спрятать эту часть кода, чтобы запутать злоумышленника.
  2. @Neo_Matrix Выше постом правильно сказали. Я бы в вашем случае захардкодил ключ шифрования в ядре где нибуть в /proc Этот же ключ будет на STM32. Шифруйте себе трафик на шине по которой логин/пароль передаете. Может вас никто и не планирует взламывать а вы заморачиваетесь )) Если цена на проц так важна значит продукт дешевый. На дешевом проце мега-защиту не получить. Надо с этим смириться )
  3. iMX6ULL посмотрите. В него есть секюрити, но надо подписывать NDA чтоб доки получить.
  4. Повторюсь.. Лучше всего юзать более современный и дорогой процессор с secure-boot. Обычно в них есть внутри защищенная память для хранения ключей и процей приватной инфы. Если это обычный проц с линуксом на борту, то я бы хранил ключи и пароли на STM32. Но обмен по шине лучше зашифровать. Хэш для шифрования трафика можно сгенерить на основе уникального серийника в STM32. На этапе производства линукс вычитает хеш, зашифрует захардкодженым ключем и бросит на ФС. Константный ключ можно спрятать в статическом модуле ядра и вычитывать его с /proc. Таким образом спрятать концы в воду. Можно поставить готовое решение типа ATECC608A от Atmel. Но имхо тоже самое вы можете на STM32 програмно соорудить если цена критична.
  5. А причем тут книги до написанного поста выше? Судя по книгам человек опытный, молодец. Но в после было полезной инфы - ноль. У меня облако тоже есть. Но это не значит что это лечение от всего. ;)
  6. У Вас по ходу инженерные мысли отсутствуют, а отметиться в этой ветке заходелось :biggrin: Отвечу сам себе может кому-то пригодится. Если в проца нет секюрного загрузчика то на 100% защититься от перепрошивки кастомными прошивками не получится. Есть чипы ATECC608A, ATSHA204.. отличное решение если конечно secure boot обеспечивает запуск u-boot к примеру в котором реализован драйвер этих чипов. Тогда вы можете проверить цифровую подпись линукса открытыми ключами которые будут хратиться в чипах упомянутых выше. Но без secure boot злоумышленник может просто заменить ваш u-boot своим и наплевав на цифровую подпись загрузить линукс напрямую. Чтобы хоть как-то усложнить взлом, Ambarella и Atmel тоже рекомендуют загрузчик прописывать в OTP сектор в NAND либо лочить его от перезаписи. http://ww1.microchip.com/downloads/en/AppNotes/doc8753.pdf Но такую защиту можно обойти: снять дамп с оригинальной флеши, перепаять на новую заменив при этом u-boot.
  7. В предыдущей зелезке мы имели неосторожность и алгоритмы антиклонинга вынесли в отдельный модуль ядра. lsmod его хорошо видел. Символов там было минимальное колличество. Вот там можно было сделать патч) Потом уже пришла мысль что надо было модуль статически в ядро линукса запихнуть. Хотя я если честно не проверял, покажет ли lsmod его как отдельный модуль? Это мы все обсуждаем как не дать склонировать девайс. Есть еще одна проблемка, для кого-то это вовсе не проблема - кастомные прошивки. Против этого в том же внешнем МК у нас был хард-ресет заведен на процессор. И если долго небыло запроса с линукса о проверке подлинности, МК ребутал проц. Но такую штуку легко хардварно пофиксить :(
  8. Добрый день. Задался вопросом, как защитить свое устройство на базе линукса на не секюрном процессоре с внешней SPI флешкой. Единственное, что приходит в голову это поставить рядом МК и зашить туда закрытый ключ. Написать драйвер и вкомпилить статически в ядро в котором будет периодически считываться зашифрованный пакет с МК и открытым ключем валидировать. Если пакет неправильный - перегружаться либо начать глючить. МК будет делать тоже самое зеркально. Если долго нет контрольного запроса, то делать хардварный ресет процессора. Это менее надежно чем процессор со встроенной верификацией бинаря по цифровой подписи, но лучше чем ничего. У кого какие мысли?
  9. В том то и прикол, что изначально была связка FreeRTOS+QP. Причем порт FreeRTOS кривоват, очереди для сигналов он использует свои а не xQueue. Что-то мне подсказывает что люди просто применили то что под руку попалось )
  10. Да я знаю. Ему нужна переключалка контекста. Причем QP содержит cooperative и pre-emptive планировщика. Можно использовать любой. В мной упомянутом проекте юзается FreeRTOS+QP/C. Переключения контекста QActive происходит в конце отработки QState. Ну и в итоге мы получили на pre-emptive планировщике cooperative переключение контекста. Интересует мнение людей которые на деле попробовали QP. Лично я фишку не уловил. Мне лучше нативная многозадачность с приоритетным вытеснением. А стейт-машины где потребуется я на switch-case реализую.
  11. Всех приветствую. Где-то лет 10 назад я первый раз услышал про QP. Почитав интернет и не найдя ни весомых аргументов для использования ни обсуждений на форумах забил... Ссылка на QP: https://www.state-machine.com Недавно довелось занырнуть в проэкт написанный на QP. Данный фреймворк работает поверх известной RTOS. Используется около 15ти состояний в которых есть свои под-состояния. Больше 30ти ивентов и 8ми актив-обьектов(QActive) их обрабатывающих. Каждый QActive работает в отдельном потоке. Пока состояние не закончит работу, другое не стартует(даже в другом потоке). В QP переключатель контекста свой. Приоритетное вытеснение, как я понял, самой RTOS полезной нагрузки не несет ибо не знает о QP работающего поверх нее. В общем парадигма программирования совсем другая. Мне интерестно, кто нибуть вообще эту штуку применял? Интересует впечатления, удобство написания прошивок под Cortex-M. Лично я не вижу смысла, имея ОС с приоритетным вытеснением, накатывать непонятный фреймворк и делить код на пару десятков состояний которых априори не планировалось бред. Из плюсов в QP есть возможность подписываться на событие нескольким QActive. Но тоже самое в uc/OS существует в виде "Event Flag Group" да и многими другими объектами синхронизации можно обойтись. :smile3009: Думаю данный подход может понравиться тем кто еще не освоил RTOS и многопоточное программирование, продолжает по накатанной пилить прошивки на базе while-loop со стейтами. Вот еще пара ссылок: http://we.easyelectronics.ru/kovz/ispolzov...vstuplenie.html https://habr.com/post/114239/
  12. В регистре значение 0x1140([12] - Enable auto-negotiation process, остальные биты говорят 1000 Mbps Full-duplex). PS: После Ваших разъяснений я пришел к выводу, что одно режимность нас вполне устроит :laugh:
  13. Cпасибо за развернутый ответ! :)
  14. Спасибо за ответ. А можно попродробней для безграмотных :) Как из схемы видно что режим работы 8033 менять не может? У меня недопонимание чем отличается SGMII от SerDes на протокольном утровне. И там и там вроде 8b/10b. Для SGMII вроде как клоки, передаваемые по дифф паре, не обязательны. Одно уяснил что у них физика разная: SGMII->LVDS, SerDes->PECL.
  15. Всех приветствую. Пост упила задача поддержать максимальное к-во SFP модулей. Coper в идеале еще и на разных скоростях 10/100/1000. AR8033 хардварно включен в режиме 1011 = "Copper/fiber auto-detection, RGMII". Модули SFP использую Finisar FCLF8522P2BTL(coper), Avago ABCU-5740ARZ-CG1(coper), JDSU PLRXPL-VI-S24-22(optic). Оба coper модуля на гигабите запускаются без проблем, оптика тоже. Когда модуля нет, регистр PHY(0x1F) возвращает 0x81BB, когда же модуль подключен значение меняется на 0x812B. Режим 2 это 1000BASE-X. Для оптики норм, но для копера я ожидал другое значение режима. Попробовал воткнуть копер модуль в 100мбит свитч. Линк не горит и модуль не подхватывается, в регистре значение 0x81BB. После переконфигурации(конфиг взят с Finisar доки AN-2036_FAQ_1000BASE-T_SFPs.pdf) линк подымается, но режим опять тот же 0x812B(1000BASE-X) как для оптики. Ну и следовательно пинг не ходит. Конфиг: i2cset -y "QUP I2C adapter" 0x56 0x1b 0x8490 w i2cset -y "QUP I2C adapter" 0x56 0x09 0x000F w i2cset -y "QUP I2C adapter" 0x56 0x00 0x4081 w i2cset -y "QUP I2C adapter" 0x56 0x04 0xE10D w i2cset -y "QUP I2C adapter" 0x56 0x00 0x4091 w Отсюда я сделал вывод что AR8033 всегда работает через шину SerDes в режиме 1000BASE-X. Вопрос: как мне заставить AR8033 работать с SFP-coper по шине SGMII? чтобы я мог данные ганять на скоростях отличных от 1000. В даташите вроде как заявлена возможность работы с SFP по SGMII. Функциональную схему прилагаю.
×
×
  • Создать...