Programator AVR: ISP + HVSP

[df]

Witam,
Zmotywowany chińskimi blokowanymi Atmelami, a ostatnio bardzo złośliwi są ci Chińczycy postawiłem sobie za cel pokonać ich zabezpieczenia przy pomocy czegoś, co nie kosztuje majątku.
Po dokładnym rozpoznaniu tematu i zarzuceniu własnego projektu budowanego od zera, zbudowałem uproszczoną wersję programatora HVSP pewnego japończyka Elm-Chan`a ( http://elm-chan.org/ ) dokonując tam kilku niewielkich zmian.

Co ważne rozwiązanie to udało się uruchomić, choć sprawiło mi ono nad wyraz sporo problemów.

Po 3 miesiącach pracy na "pająku" znalazłem wreszcie chwilkę czasu, by dokończyć dzieła i korzystając z dobrodziejstw istniejących rozwiązań (w tym rozwiązania HVSP ChaN`a) zbudować sobie poręczny programatorek 2-w-1 implementujący jednocześnie ISP w standardzie STK-200 oraz programowanie wysokonapięciowe HVSP.

Tak więc obecnie RSTDISBL, SPIEN oraz CKSEL`e nie są mi straszne a przy okazji zrobiłem sobie narzędzie, które można wykorzystać do innych układów, np. do pamięci szeregowych.

Na razie szybciutko tylko kilka zbiorczych fotek...



Opis dodam niebawem (jak tylko skończę coś dla Maćka).

[Pyra]

No to czekamy

[Manekinen]

Witam. Nie wierzę że oni tylko wyłączają reset w procku tym samym uniemożliwiając dostęp do niego przez SPI. Czemu nie ustawiają bitów blokujących których obejść się po prostu nie da? Bo chyba pisząc "pokonywanie zabezpieczeń" mamy na myśli możliwość zgrania programu z procka? Jestem zainteresowany, czekam na więcej info

[df]

Witam. Nie wierzę że oni tylko wyłączają reset w procku tym samym uniemożliwiając dostęp do niego przez SPI.

Niestety tak robią - zarówno ustawiają RSTDISBL jak i wyłączają SPIEN
Co więcej miałem wersje w których pin5 zwarty był ścieżką do masy (MOSI).

Czemu nie ustawiają bitów blokujących których obejść się po prostu nie da?

Oprócz innych zabiegów stosowanych nie wiadomo po co, są także ustawione oba poziomy lock-bitów.

Bo chyba pisząc "pokonywanie zabezpieczeń" mamy na myśli możliwość zgrania programu z procka? Jestem zainteresowany, czekam na więcej info

Jeśli chodzi o zgrywanie firmware`u z zabezpieczonych procków, to jak najbardziej się da.
Czytałem ostatnio baaaardzo ciekawy materiał jednego z naukowców jak takie rzeczy się robi.
I przyznam się szczerze, że z jednej strony jestem pełen podziwu dla pomysłowości i determinacji, a z drugiej prostoty niektórych zastosowanych tam rozwiązań.

Sergei Skorobogatov, bo to jego dokonania naukowe mam na myśli, pracuje obecnie w University of Cambridge w UK i jednocześnie sporo udziela się na wszelakich konferencjach.
Ale co najważniejsze swoją wiedzę publikuje również w internecie na swojej stronie:

http://www.cl.cam.ac.uk/~sps32/

Gorąco polecam - szczególnie bogate w opisy i zdjęcia prezentacje "Tamper resistance and hardware security" prezentowane m.innymi na konferencjach dot. bezpieczeństwa informacji, która oprócz elektroniki także jest moim "konikiem".

[Manekinen]

Dzięki za link jutro będę miał troszkę czasu to sobie poczytam Zapewne wcześniejsze procki dało się odczytać, poprzez zabawę z temperaturą i napięciem, lub zwyczajne otwarcie układu, wytrawienie tego co niepotrzebne i albo ręczne przestawienie lockbitów albo podpięcie się do pamięci - też coś czytałem o tym. Kosztuje to grubą kasę nigdy nie wartą badziewnego programu z latarki wklepanego przez chińczyka w jeden wieczór

Po za tym... jeśli każdy w domu mógłby sobie obejść lockbity to raczej wszystkie avrki zniknęły by ze sklepów lub kosztowałyby grosze

[df]

Po za tym... jeśli każdy w domu mógłby sobie obejść lockbity to raczej wszystkie avrki zniknęły by ze sklepów lub kosztowałyby grosze

Złamać da się wszystko - tylko kwestia czasu oraz kosztu.
Są na świecie firmy, które świadczą takie usługi - ceny zaczynają się od miliona $.

Łamane są karty chipowe (bankomatowe), łamane są sprzętowe klucze do dekoderów (np. TV), jest wywiad, jest konkurencja, producenci też się z pewnością "podglądają", a niektóre zapisane w środku informacje mogą być bardzo wartościowe - zwłaszcza algorytmy i klucze kryptograficzne.

Oczywiście nikt nie będzie wyciągał w ten sposób softu z chińskich driverów, bo ani technologia, ani innowacyjność nie ta.
A poza tym to nawet jak już ktoś sobie wyciągnie binarny kod z procka i będzie go dekompilował, by poznać jak działa, to znaczy, że ma wystarczająco dużą wiedzę, by taki kod napisać samemu od zera i zrobić to jeszcze 10x lepiej.