logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[AVR] Jak zabezpieczyć urządzenie przed kopiowaniem bez lock bitów?

morswin89 17 Cze 2012 22:03 3637 15
  • #1 11012078
    morswin89
    Poziom 23  
    Witam

    Mam takie pytanie/problem jak zabezpieczyć urządzenie przed nieautoryzowanym skopiowaniem tzn. żeby skompilowany program działał tylko na jednym określonym urządzeniu. Stosuje układy DS2401 wpisuje ich numer do program i z nim kompiluje ale co sprytniejsza osoba może to ominąć stosując emulator DS. Pomijam stosowanie lock bitów gdyż użytkownik ma mieć możliwość np własnoręcznej aktualizacji.
  • #2 11012156
    tymon_x
    Poziom 30  
    morswin89 napisał:
    Witam

    Mam takie pytanie/problem jak zabezpieczyć urządzenie przed nieautoryzowanym skopiowaniem tzn. żeby skompilowany program działał tylko na jednym określonym urządzeniu.

    W ATXmega jest zaszyty w krzemie unikalny numer ID, który idealnie się do tego nada. W tych zwykłych AVR czegoś takiego chyba nie ma, zaszycie takiego ID do EEPROM czy FLASH odpada. Zostają lock bity.
  • #4 11012172
    gaskoin
    Poziom 38  
    Do aktualizacji powinno się raczej zastosować bootloader.

    Co z tego, że zablokujesz kod przed odczytem z procesora, skoro dajesz komuś hexa do wgrania ("żeby sobie zaktualizował"), którego można zdeasemblować i sobie podejrzeć program ? :)

    Niektóre kontrolery mają jakieś klucze, jednorazowo wypalane na amen w chipie i można z nich skorzystać (tu raczej nie ma czegoś takiego) i inne szyfrowane pierdoły. Możesz na podobieństwo coś takiego zrobić w eepromie, albo gdzieś jeszcze indziej.
  • #5 11012199
    mariuz
    Poziom 31  
    Jeżeli użytkownik ma dostęp do wsadu to chyba nic nie da się zrobić...
    AVRy mają taką strukturę, ze nawet nie możesz mieć pamięci programu w innej kości niestety... A to otwierałoby drogę do zakodowania części programu w pamięci wewnętrznej na stałe, a części w zewnętrznej pamięci udostępnianej dla aktualizacji przez użytkownika.

    Dodano po 2 [minuty]:

    LordBlick napisał:
    Kluczyk w EEPROM...

    A co to da? Skoro autor obawia się emulatora DS, to użytkownik tym bardziej będzie w stanie odczytać EEPROM.
    Z resztą czy nie jest przypadkiem tak, że wgranie pamięci programu czyści wewnętrzny EEPROM?
  • #6 11012216
    LordBlick
    VIP Zasłużony dla elektroda
    mariuz napisał:
    LordBlick napisał:
    Kluczyk w EEPROM...

    A co to da? Skoro autor obawia się emulatora DS, to użytkownik tym bardziej będzie w stanie odczytać EEPROM.
    Z bootloaderem, odpowiednio ustawionymi lockbitami i szyfrowanym właśnie tym indywidualnym kluczykiem wsadem nie ma większych szans.
    mariuz napisał:
    Z resztą czy nie jest przypadkiem tak, że wgranie pamięci programu czyści wewnętrzny EEPROM?
    Niekoniecznie, jest fusebit EESAVE, ale nie o to mi chodzi, aby był ustawiony, jest to wręcz niewskazane... ;) Niech sobie czyści, wykasowanie µC będzie podpadało pod obsługę pozagwarancyjną.
  • #7 11012272
    pixel7
    Poziom 23  
    Jest gotowy bootloader AES dla AVR : Link. Stosuje go z powodzeniem, posiada 256 bitowy klucz. Wsad nie do rozszyfrowania. Atmel daje gotowe narzędzia do upgrade przez port rs.
    Wystarczy zablokować lockbity do odczytu i masz po sprawie.
  • #8 11012784
    ostag
    Poziom 18  
    Ciężki temat. Wysyłasz zabezpieczonego proca do Chińczyka i za 200$ masz zawartość każdego AVRa razem z fusami i eepromem. Niestety sprawdzone. Pozdrawiam
  • #9 11012962
    Krauser
    Poziom 26  
    ostag napisał:
    za 200$ masz zawartość każdego AVRa razem z fusami i eepromem
    Jeśli procesor jest lepiej zbudowany tzn. warstwa flash jest na wierzchu a lockbity są głęboko zakopane to trudno będzie je brutalnie skasować nie uszkadzając pamięci programu. Tak jest ponoć w STM32 (zapytaj inżynierów aplikacyjnych)
    Nie ma zabezpieczeń nie do złamania. Rzecz w tym by bardziej opłacało się wynająć programistę niż bawić się w hackowanie.
  • #10 11013003
    leonow32
    Poziom 30  
    Krauser napisał:
    ostag napisał:
    za 200$ masz zawartość każdego AVRa razem z fusami i eepromem
    Jeśli procesor jest lepiej zbudowany tzn. warstwa flash jest na wierzchu a lockbity są głęboko zakopane to trudno będzie je brutalnie skasować nie uszkadzając pamięci programu. Tak jest ponoć w STM32 (zapytaj inżynierów aplikacyjnych)
    Nie ma zabezpieczeń nie do złamania. Rzecz w tym by bardziej opłacało się wynająć programistę niż bawić się w hackowanie.

    Znam firmę, która potrafi otworzyć scalak bez uszkadzania go i ściągnąć pamięć ;) pytanie tylko czy "klient-haker" rzeczywiście jest w stanie szarpnąć się na taką operację i czy to będzie mu się opłacało. Ile kosztuje urządzenie kolego morswin89 i ile sztuk zamierzasz wyprodukować? W większości przypadków takie cudowanie z wymyślnymi zabezpieczeniami nie ma sensu, a wystarczą jedynie podstawowe lockbity, bootloader i proste sztuczki, jak klucz zapisany w EEPROMie. W książce Francuza jest napisane trochę więcej na ten temat.
  • #11 11013034
    dondu
    Moderator na urlopie...
    leonow32 napisał:
    W książce Francuza jest napisane trochę więcej na ten temat.

    Jest opisany AES, o którym wspomniał kol. pixel7 oraz cały proces zabezpieczania i wgrywania uaktualnienia (patrz: Spis treści - rozdział 27).
    Nie stosowałem, ale cały proces można zautomatyzować, co ułatwia cykl produkcyjny.

    Wprawdzie temat dotyczy AVR, ale dla informacji (może autor kiedyś się skusi) PIC'e mają często możliwość zabezpieczania części FLASHa, pozostawiając część dostępną dla zmian.
  • #12 11018394
    morswin89
    Poziom 23  
    Dziękuje za zainteresowanie tematem. Koszt urządzenia to powiedzmy jakieś 350zł co do ilości sztuk ciężko powiedzieć. Rozwiązanie z botloaderem i szyfrowaniem wydaje mi się wystarczające aby uniemożliwić większości a ktoś kto byłby na tyle zdolny to sądzę, że sam szybciej by stworzył od podstaw takie urządzenie.
  • #13 11019395
    tplewa
    Poziom 39  
    Tylko po co rozbierac uC :) 90% popularnych uC - a i sporo specjalizowanych (z dziedziny zabezpieczen) leci bez tego. AVR-y jak i temu podobne maja zabezpieczenia ktore wystarcza jednak w wiekszosci wypadkow, jak ktos siadzie do procka to i tak go ruszy. Tutaj nalezy tylko rozsadnie kalkulowac czy koszt zabezpieczen nie przekracza czasem wartosci calej pracy, to samo przy wyciaganiu czegos z procesora...

    IMHO do prostych projektow LockBits + bootloader z szyfrowaniem (najlepiej wlasny i nie jestem tutaj za AES-em ;) ). Rijndael tak na prawde nie zapewnia najlepszego szyfrowania, wystarczy zerknac co decydowalo przy wyborze algorytmu na Advanced Encryption Standard... Do tego cos niestandardowego tez potrafi utrudnic zadanie (byle nie jakies XOR-y bo to sie w parenascie minut rozwala).
  • #14 11020477
    ostag
    Poziom 18  
    To co pisałem dotyczy nie tylko avr-ów. Mało czego chinol nie robi. I robi bezinwazyjnie - nie dostaje się do struktury procka, bo:
    1. robi to w 12h od otrzymania procka
    2. może odesłać oryginalny procesor, tylko koszt wysyłki jest większy niż proc kosztuje.
    Korzystałem ich z usług - działa bez problemu.
    Także co by w procu nie było to powstanie klon. Jak coś kombinować to na zewnątrz - ponoć pal/gal jest bardzo zniechęcający dla kopiarzy, ale oczywiście i to da się obejść.
    Pozdrawiam
  • #15 11021123
    tplewa
    Poziom 39  
    Tak na prawde nie potrzeba tutaj Chinol-a bo AVR-y nigdy nie mialy super zabezpieczenia, choc i tak Atmel troche je poprawil w stosunku do pierwszych wersji.

    Jednak jak mowie nie ma co popadac w paranoje, kolega produkuje pewien uklad (popularny i czesto uzywany w swiecie tuningu samochodowego). Uklad rozwalilem w parenascie minut - lacznie z napisaniem deszyfratora (firmware bylo ladowane przez bootloader - oczywsicie szyfrowane). W sumie przez to po malej awanturze sie poznalismy ;) Jak do tej pory nikt ukladu nie kopiuje, a mozna by na tym troche zarobic - natomiast napisanie takiego firmware nie jest proste ;)

    Problemem w przypadku firmware jest to ze na jego poczatku mamy wektory przerwan i wiemy co ma byc w kodzie po deszyfracji - to jest okropna wada i wiele ulatwia przy lamaniu wszelkich metod szyfrowania.

    Mozna stosowac jakies uklady CPLD - ale wtedy musi on wykonywac cos potrzebnego w ukladzie (np. fragment obliczen itd.) - z tym ze to podnosi znowu koszty gotowego ukladu. Tutaj pytanie czy warto, bo i tak jak ktos sie uprze to zrobi kopie.

    Jednak w przypadku wiekszosci prostych rozwiazan nie ma to tez sensu, bo jak juz wspomnial kolega za zwyczaj lepiej i taniej stworzyc funkcjonalny odpowiednik urzadzenia niz kopiowac czyjes rozwiazanie.
  • #16 11021737
    mirekk36
    Poziom 42  
    tplewa napisał:

    Jednak w przypadku wiekszosci prostych rozwiazan nie ma to tez sensu, bo jak juz wspomnial kolega za zwyczaj lepiej i taniej stworzyc funkcjonalny odpowiednik urzadzenia niz kopiowac czyjes rozwiazanie.


    Mnie się wydaje że w 99,99% takich dyskusji tu na forum to zawsze właśnie o to chodzi. I rozprawianie o chinolach co to łamią zabezpieczenia za ileś tam $ czy też o nie wiadomo jakich ciężkich szyfrowaniach nie mają najmniejszego sensu. To mogłoby nabierać sensu, gdyby taki wynalazek/urządzenie zaczynało nabierać popularności co najmniej międzynarodowej i byłoby produkowane w setkach tys egzemplarzy i nawet nie ważne ile by kosztowało. Ale wtedy to nikt by nie dyskutował tutaj o tym bo już dawno miałby kasę na pewne i sprawdzone sposoby zabezpieczeń swoich urządzeń.

    Więc na tym etapie to Lockibty + Bootloader + nawet jakieś własne byle zakodowanie i nawet gdyby było to zwykłe XOR'owanie - to Panowie ? kto? gdzie? kiedy ? jak? i dlaczego miałby to kopiować. Klient który kupi to pewnie nie zna się na tym więc nawet nie będzie zainteresowany hackowaniem a co najwyżej dalszym rozwojem projektu i jeśli dzięki temu zarobi to pewnie chętnie wyda kolejne pieniądze na upgrade...... I takich klientów koledze autorowi życzę. Takich jest najwięcej jak się zrobi coś dobrego .... takich uczciwych ... nie ma co popadać w paranoję ... a zwykle minimum zabezpieczeń i tak odstrasza domorosłych majsterkowiczów. Bo nawet jeśli zhakuje to co ? to nie program na PC - trzeba jeszcze produkować elektronikę , testować itp ... komu to się opłaci przepraszam przy takich super mega mikro nakładach produkcyjnych ?
REKLAMA