bootloader AVR nieco inaczej.

Po co sie meczyc, z atmegi mozna wydlubac bez problemu zawartosc znam 2 osoby w polsce ktore to potrafia :))

sprytne ...

Bootloader znajduje sie na koncu flasha poczytaj w dokumentacji bo wielkosc zajmowanej pamieci bootloadera jest zalezna od fusebitow.

zobacz tu

czy to cos posiada karte sieciowa? jezeli tak to jest jakis loader oparty na tcp/ip, txn mozna ladowac firmware z sieci.

:( Ale przynajmniej amatorów jakoś zablokuje. Swoją drogą robią to jakimiś metodami typu rozpuszczanie plastiku czy kombinacja z zasilaniem ? A może jakoś inaczej ;) ?

No ba ;)

Wiem, ale dokumentacja jest słaba w tym miejscu, i nie jestem na 100% pewny, czy mam dostęp do całego flasza włacznie z wektorami przerwań itd. W ogóle mam wrażenie, że ta technika bootloadera jest jakaś taka niedorobiona do końca :/

Źle się wyraziłem - chodzi o algorytm z asymetrycznym kluczem - deszyfrować można wyłącznie na konkretnym uC. To lekkie utrudnienie, nawet gdyby ktoś wyrwał mi program z atmegi, to będzie miał poważny kłopot w przygotowaniu plikow do zaladowania - z racji innego klucza. Oczywiście dla chcącego nic trudnego i można zmodyfikować binarkę, ale tu już bym postarał się lekko utrudnić życie.

Nie - żadnej łaczności - z róznych względów. Jesli miałbym sieć to w ogóle nie było by o czym mówić na pewno bym to wybrał i pozbył się MMC.

Moim zdaniem jest wszystko z nim OK. Sam bootloader znajduje sie na koncu gdzie wielkosc zalezna od fusebitow. Z poziomu bootloadera masz dostep do calego flasha.

Jak umiesz zdeasembloac i przeanalizowac to mam przykladowego bina z takim rozwiazaniem :) Poszukaj dobrze w sieci kiedys przemknal mi przed oczami takie rozwiazanie.

W artykule news:cksd4j$evj$ snipped-for-privacy@atlantis.news.tpi.pl, niejaki(a): Pawe³ K z adresu snipped-for-privacy@qs.pl napisa³(a):

Na stronie Atmela jest nota aplikacyjna AVR230 - DES Bootloader ¯eby uzyskaæ namiastkê asymetrycznego szyfrowania trzeba by klucz do DES-a trzymaæ na karcie zaszyfrowany "niesymetrycznie". Wtedy najpierw trzeba by odszyfrowaæ klucz a potem wykorzystaæ go do odszyfrowania samego programu. Obawiam siê tylko ¿e tak skomplikowane operacje nie zmieszcz± sie w obszar przeznaczony dla bootloadera.

U¿ytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisa³:

Tak, robi³em co¶ takiego, przeciez niewielka ró¿nica czy kod bootloadera odczyta program z portu szeregowego, z karty, przez USB czy z internetu.

Darek ¯o³na

U¿ytkownik "Fish" snipped-for-privacy@onet.pl napisa³:

Dok³adnie tak. Nawet z samym odczytem kodu z MMC mog± byæ problemy.

Darek ¯o³na

w miarę uniwersalne funkcje odczytu karty MMC przy użyciu sprzętowego portu SPI zajmują mi 324 bajty. po optymalizacji na pewno da się zejść poniżej 300. reszta to już tylko kwestia tego, ile chcemy przeznaczyć na aplikację.

w.

U¿ytkownik "Wojtek Kaniewski" snipped-for-privacy@SPAM.SPAM.SPAM> napisa³:

Dodaj do tego kod obs³ugi FAT i samego programowania flash'a i ju¿ nie bêdzie tak ró¿owo.

Darek ¯o³na

ale w czym problem? masz do dyspozycji maksymalnie 2kB na bootloader. programowa obsługa SPI, MMC, FAT, paru klawiszy i zewnętrznego dekodera MP3 zajęła mi 1,7kB. poza tym, jeśli sam wrzucasz firmware na kartę, równie dobrze możesz umieścić go w określonych blokach pamięci i obsługa FAT nie będzie konieczna. programowanie to góra kilkaset bajtów. na oko wychodzi, że zmieściłyby się co najmniej 2 bootloadery.

w.

U¿ytkownik "Wojtek Kaniewski" snipped-for-privacy@SPAM.SPAM.SPAM> napisa³:

To akurat zale¿y od procka.

Darek ¯o³na

w.