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

JeDay

Свой
 Профиль  Обзор контента

  • Постов

    278

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

  • Посещение

 Тип контента 

Сообщения, опубликованные JeDay

  1. Опубликовано · Пожаловаться

    В этом случае ваше ядро можно сдампить с флешки, запустить на QEMU и найти файл с ключем, если догадаются где он и для чего. Но декодедирование пакетов этим ключем можно спрятать в другой утилите. Тоесть придется хакерам еще и ее реверс-инжинирить чтоб алгоритм получить, ну либо научиться правильно вызывать.
    МОжно как вариант в Busybox спрятать эту часть кода, чтобы запутать злоумышленника.

  2. Опубликовано · Пожаловаться

    @Neo_Matrix Выше постом правильно сказали. Я бы в вашем случае захардкодил ключ шифрования в ядре где нибуть в /proc Этот же ключ будет на STM32. Шифруйте себе трафик на шине по которой логин/пароль передаете. Может вас никто и не планирует взламывать а вы заморачиваетесь )) Если цена на проц так важна значит продукт дешевый. На дешевом проце мега-защиту не получить. Надо с этим смириться )

  4. Опубликовано · Пожаловаться

    Повторюсь.. Лучше всего юзать более современный и дорогой процессор с secure-boot. Обычно в них есть внутри защищенная память для хранения ключей и процей приватной инфы.

    Если это обычный проц с линуксом на борту, то я бы хранил ключи и пароли на STM32. Но обмен по шине лучше зашифровать. Хэш для шифрования трафика можно сгенерить на основе уникального серийника в STM32.

    На этапе производства линукс вычитает хеш, зашифрует захардкодженым ключем и бросит на ФС. Константный ключ можно спрятать в статическом модуле ядра и вычитывать его с /proc. Таким образом спрятать концы в воду. Можно поставить готовое решение типа ATECC608A от Atmel. Но имхо тоже самое вы можете на STM32 програмно соорудить если цена критична.

  5. Опубликовано · Пожаловаться

    Вы бы полегче. У Olej вообще-то несколько книг с блестящими инженерными мыслями. Нa сайте IBM его книги тоже есть.

    https://www.ibm.com/developerworks/ru/libra...l_01/index.html

    https://www.ibm.com/developerworks/ru/libra...s_02/index.html

     

    А причем тут книги до написанного поста выше? Судя по книгам человек опытный, молодец. Но в после было полезной инфы - ноль.

     

    А как же стильный, модный, молодежный способ - перенести часть функционала в облако?

    У меня облако тоже есть. Но это не значит что это лечение от всего. ;)

  6. Опубликовано · Пожаловаться

    Мысль такая, что юные дарования валом "задавались вопросом" как защитить их "гениальные творения" :santa2: ещё со времён раннего MS-DOS.

    Вы находитесь в разделе Linux, и в мире Linux, который является, вообще-то говоря open+free, где действуют GPL-лицензии в разных вариантах, которые, кстати, предписывают и что вы со своим "гениальным творением" имеете право делать, а чего нет ... раз уж вы опираетесь на Linux ... да ещё и на другие GNU инструменты.

    У Вас по ходу инженерные мысли отсутствуют, а отметиться в этой ветке заходелось :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. Опубликовано · Пожаловаться

    Про качество либы скорее вас спрашивать надо, у вас ведь боевой код и возможность его оценить незашореными глазами непричастного разработчика. sm.gif А насчет ртос - вполне возможно что изначально проект был без ртос, а потом понадобилось и ртос прикрутили к уже имеющейся кодобазе.

    В том то и прикол, что изначально была связка 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. Опубликовано · Пожаловаться

    Не посмотрите, автонег в AR8033 при работе с "медным" модулем включён или нет?

    Если включён, можно ещё осциллографом точно определить тип, но это уже несколько сложнее.

    В регистре значение 0x1140([12] - Enable auto-negotiation process, остальные биты говорят 1000 Mbps Full-duplex).

     

    PS: После Ваших разъяснений я пришел к выводу, что одно режимность нас вполне устроит :laugh:

  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.

     

    Функциональную схему прилагаю.

    mcu_sfp_240.jpgi.gif

     

  17. Опубликовано · Пожаловаться

    Добрый день.

    Есть 3D модель пластиковой детали, хочу сделать партию 10-20шт. Есть технология литья в силикон, когда изготавливается мастер модель, по ней делают силиконовую фотму, потом в нее льют пластмассу. Есть в москве одна фирма, забыл название, они там голову 1.5 месяца проморочили, а в конце вернули деньги. Интерестно есть ли такие в китае? Например печатные платы делает shenzhen2u, на форуме обсуждалилсь, закидываешь герберы, платишь и ждешь посылку. Есть что-то подобное по литью корпусов?

    Спасибо.

  21. Опубликовано · Пожаловаться

    За последние 3 года в Allwinner ситуация изменилась в очень хорошую сторону. Проц 5$ стоит.

    Линукс поддерживается:

    https://github.com/linux-sunxi

    Покупаем "banana-pi" на А20 либо А31 и вперед за орденами.

    У меня коллега эту платку купил, но плотно с ней не работал еще. У кого есть опыт использования этих процессоров?

  24. Опубликовано · Пожаловаться

    Приветствую.

    Столкнулся с проблемой нехватки места на плате, пытаюсь уменьшить все что получается. Дошел черед до защитных супрессоров и диодов.

    Сейчас на 485м стоят SMAJ12CA. Может есть чтото в корпусе подобном 0805 ?

    Спасибо.

×
×
  • Создать...