Захист мікропрограмного забезпечення на контролерах AVR та PIC


23

Чи може хтось витягти файл HEX, який я записую в мікроконтролер, я їх надаю?

Якщо це можливо, як хтось може забезпечити захист свого коду у вбудованих системах? Що стосується мікроконтролерів PIC та AVR, як можна захистити їх прошивку від відтворення?



1
У випадку, якщо вам здається, що ви пропонуєте вам надати hex-файл своїм клієнтам, у такому випадку вони можуть просто записати його на кілька пристроїв-клонів, реально не потрібно декомпілювати код, хоча це можливо. Що стосується заблокованого пристрою (№2), зазвичай питання про те, наскільки вони визначаються, щоб отримати код (іншими словами, скільки вони готові витратити), але зазвичай це можливо.
alexan_e

1
Раніше це було два роки, але захист у наші дні, як правило, перемагає за день-два в середньому для популярних пристроїв. в основному, коли хтось вирішив, що це варто зробити. Якщо ви дійсно хочете забезпечити вам безпеку, щоб увійти в чіп-бізнес, ви не отримаєте жодного з комерційних деталей на полиці.
old_timer

Відповіді:


33

Більшість мікроконтролерів у цей час мають певні або конкретні для виробника способи захисту вбудованого коду програмного забезпечення. Зазвичай це робиться шляхом блокування ланцюгів, які зазвичай дозволяють зчитувати пам'ять коду. (Вам потрібно буде шукати детальну інформацію про деталі на сторінці даних або на веб-сайті виробників у відповідних примітках до додатків).

Після блокування неможливо зчитувати пам'ять коду за допомогою звичайних методик. Це забезпечує достатній рівень захисту, щоб унеможливити більшість хакерів від перегляду машинного коду вбудованої програми.

У багатьох MCU-пристроях сьогодні є вбудована FLASH-пам'ять для зберігання програмного коду. Раніше збережена та захищена програма, що зберігається у FLASH, зазвичай може бути замінена новим кодом, але для розблокування механізму захисту потрібна повна операція стирання FLASH. Після стирання деталь буде працювати так, як це було раніше, ніж оригінальний замок захисту. Якщо ви завантажуєте нову програму, то, як правило, можна повторно заблокувати деталь для захисту щойно завантаженого машинного коду.

Будь-яке обговорення захисту коду в мікроконтролерах не було б повним, не зазначаючи, що зазвичай немає гарантії того, що будь-яка схема захисту, запропонована виробником деталей, є неправдивою. Виробники навіть заявлять, що захисні системи не є 100% нерозумними. Однією з причин цього є те, що відбувається ціла галузь чорного ринку, де за певну плату старанні хакери зачитують код із захищеної частини для всіх, хто хоче платити. Вони розробили різні схеми, які дозволяють зчитувати код з ПЗУ або ФЛЕШ на захищених мікроконтролерах. Деякі з цих схем неймовірно розумні, але працюють для кращого успіху для деяких сімей, ніж для інших. Тож знайте про цей факт, тоді ви намагаєтеся захистити свою програму від сторонніх очей.

Після того, як хтось влаштує свої руки на двійкове зображення машинного коду, який зчитується з мікроконтролера, чи це був захищений мікроконтролер чи ні, він може обробити машинний код за допомогою інструменту, який називається розбирачем. Це перетворить бінарні дані назад в код мови збірки, який можна вивчити, щоб спробувати дізнатися, як працюють алгоритми вашої програми. Точне розбирання машинного коду - кропітка робота, яка може зайняти величезну кількість роботи. Врешті-решт процес може призвести до коду асемблера, як я описав. Якщо ваша програма була написана якоюсь мовою високого рівня, наприклад C, C ++ або Basic, код складання буде представляти лише складений і пов'язаний результат вашої програми. Як правило, неможливо повернути викрадений інженером код повністю до рівня мови на високому рівні.

Це означає, що є насправді користь для написання вбудованого програмного забезпечення на мові високого рівня. Це забезпечує ще один шар, який ускладнює повну реверсивну розробку вашої програми. Ще більшу користь можна отримати, використовуючи найвищий рівень техніки в оптимізації компіляторів для складання вбудованого додатку, оскільки оптимізатори найвищої продуктивності можуть буквально перетворити програму у величезну чашу спагетті, наповнену десятками дзвінків на короткі підпрограми, які дуже важкі розшифрувати в розбиральнику.

Більшість досвідчених вбудованих розробників скажуть вам продовжити та використовувати будь-яку схему захисту, що пропонується на MCU у вашій програмі .... але не залежати від неї до кінця дороги вашого продукту. Вони скажуть вам, що найкращий спосіб випереджати конкуренцію - постійно оновлювати свій продукт, щоб застарілі версії застаріли та нецікаві на той час, коли хакери, можливо, клонували ваш код. Змініть код навколо, додайте нові функції, час від часу обертайте дошки ПК, щоб обмінятись усіма введеннями / виводами навколо та будь-якими іншими речами, про які ви можете подумати. Таким чином ви можете виграти гонку кожен раз.


Дуже дякую @Michael Karas. Це була повна відповідь
Rookie91

12

Я думаю, що відповіді Майкла достатньо для цього питання, але я додаю ці обидва посилання: Злом PIC 18F1320 і все, що вони роблять, Ми можемо зламати! Це обидва мені були дуже цікаві.


Старанний ЕЕ повинен вивчити цю останню посилання та дослідити / порівняти / вибрати пристрої, які відсутні у списку. Складність завжди більше стримує - наприклад, додавання DS3641 або ATSHA204 . Хоча жодна додаткова безпека ніколи не буде на 100% непорушною, додаткова складність може зробити це не варто.
rdtsc
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.