czy istnieją procki które umożliwiają zaszyfrowanie kodu który do nich
wgrywamy? chodzi o to, żeby nie można było zdeasemblować... dla wyśmiewaczy
powiem, że firmware RTL8186 jest zaszyfrowane więc pytanie jest jak
najbardziej na miejscu...

do góry

W dniu 2012-01-08 21:07, identifikator: 20110701 pisze:
> czy istnieją procki które umożliwiają zaszyfrowanie kodu który do nich
> wgrywamy? chodzi o to, żeby nie można było zdeasemblować... dla
> wyśmiewaczy powiem, że firmware RTL8186 jest zaszyfrowane więc pytanie
> jest jak najbardziej na miejscu...

W wielu uP można zrobić własny bootloder, który odszyfruje właściwy
firmware.

Paweł

do góry

W dniu 2012-01-08 21:07, identifikator: 20110701 pisze:
> czy istnieją procki które umożliwiają zaszyfrowanie kodu który do nich
> wgrywamy? chodzi o to, żeby nie można było zdeasemblować... dla
> wyśmiewaczy powiem, że firmware RTL8186 jest zaszyfrowane więc pytanie
> jest jak najbardziej na miejscu...

Zaszyfrowany to ty masz zakuty łeb. Firmware jest spakowane ZIPem, nie
jest szyfrowane. Poczytaj troche o systemach embedded.

do góry

> Zaszyfrowany to ty masz zakuty łeb. Firmware jest spakowane ZIPem, nie
> jest szyfrowane. Poczytaj troche o systemach embedded.

proszę: wal się cioto!

do góry

> W wielu uP można zrobić własny bootloder, który odszyfruje właściwy
> firmware.

Tylko, czy potem ktoś nie ściągnie bootloadera, napisze funkcję odwrotną i
zdeszyfruje program?

R.

do góry

identifikator: 20110701 <N...@g...pl> napisał(a):
>> Zaszyfrowany to ty masz zakuty łeb. Firmware jest spakowane ZIPem, nie
>> jest szyfrowane. Poczytaj troche o systemach embedded.
> proszę: wal się cioto!

Co jeden to kulturalniejszy...

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 23 days, 0 hours, 30 minutes and 36 seconds

do góry

W dniu 2012-01-08 22:32, Robbo pisze:
>> W wielu uP można zrobić własny bootloder, który odszyfruje właściwy
>> firmware.
>
> Tylko, czy potem ktoś nie ściągnie bootloadera, napisze funkcję odwrotną
> i zdeszyfruje program?
>
> R.

No to dadatkowo blokujesz możliwość odczytu na poziomie procka, w czym
problem?

--
Pozdrawiam
Konop

do góry

> No to dadatkowo blokujesz możliwość odczytu na poziomie procka, w czym
> problem?


Skoro możliwość blokowania odczytu z procka, to po co jeszcze szyfrować kod,
skoro i tak go nie można odczytać?
Czegoś chyba nie rozumiem i uprzejmie proszę o wyjaśnienie.

Używam procków Atmel AVR. One nie mają możliwości blokady odczytu, a jedynie
a) zapisu bądź b) zapisu i odczytu.
Procek z blokadą tylko odczytu byłby chyba kiepskim pomysłem, gdyż nadal
byłaby możliwość zapisu do niego
jakiegoś programu, który odczytywałby program z pamięci i wysyłał na
przykład poprzez RS232 na zewnątrz.
Z kolei blokad zapisu to zawsze utracenie kosztownego procka, gdyby trzeba
było uaktualnić w nim program.

R.

do góry

W dniu 08.01.2012 23:30, Robbo pisze:
> Używam procków Atmel AVR. One nie mają możliwości blokady odczytu, a
> jedynie a) zapisu bądź b) zapisu i odczytu.
> Procek z blokadą tylko odczytu byłby chyba kiepskim pomysłem, gdyż nadal
> byłaby możliwość zapisu do niego
> jakiegoś programu, który odczytywałby program z pamięci i wysyłał na
> przykład poprzez RS232 na zewnątrz.
Flash działa tak, że żeby zapisać trzeba najpierw wyczyścić. Więc jak
procek ma blokadę odczytu to znaczy, że możesz go wyczyścić i wgrać nowy
firmware a nie możesz go odczytać z poziomu programatora.

> Z kolei blokad zapisu to zawsze utracenie kosztownego procka, gdyby
> trzeba było uaktualnić w nim program.
Nawet AVR ma podział na sekcje. Blokujesz zapis/odczyt do bootloadera (i
w nim umieszczasz klucz) i wyłączasz programowanie z zewnątrz.

Jak wysyłasz zaszyfrowane update do klienta to bootloader czyści chip, a
następnie go programuje zdekodowanym wsadem.

--
Pozdrawiam
Michoo

do góry

> Skoro możliwość blokowania odczytu z procka, to po co jeszcze szyfrować
> kod, skoro i tak go nie można odczytać?
> Czegoś chyba nie rozumiem i uprzejmie proszę o wyjaśnienie.
>
> Używam procków Atmel AVR. One nie mają możliwości blokady odczytu, a
> jedynie a) zapisu bądź b) zapisu i odczytu.
> Procek z blokadą tylko odczytu byłby chyba kiepskim pomysłem, gdyż nadal
> byłaby możliwość zapisu do niego
> jakiegoś programu, który odczytywałby program z pamięci i wysyłał na
> przykład poprzez RS232 na zewnątrz.
> Z kolei blokad zapisu to zawsze utracenie kosztownego procka, gdyby
> trzeba było uaktualnić w nim program.

1. Zaszyfrowany firmware możesz opublikować na publicznej stronie WWW.
Bez znajomości tajnego klucza nie uda się zobaczyć co on zawiera.
2. Własny bootloader zacznie programować uP tylko jeśli poprawnie uda mu
się odszyfrować kod. Czyli do uP można wpisać wyłącznie autoryzowane
oprogramowanie.
3. AVR mają możliwość zabezpieczenie pamięci flash przed odczytem.
Oznacza to, że nie uda się odczytać bootloadrea i poznać klucza jaki on
używa.

Paweł

do góry