Guia CNC Brasil - Tudo sobre CNC, Router, Laser, Torno e 3D Print
ELETRÔNICA / ELÉTRICA => Eletrônica Básica => Microcontroladores => Tópico iniciado por: Blackmore em 19 de Março de 2011, 22:58
-
Amigos foristas, boa noite.
Gostaria de saber dos colegas, suas experiências com a encriptação de firmware (.hex) para gravação de microcontroladores via bootloader.
Vc´s criptografam ou já criptografaram algo?
O que vc´s tem usado para criptografar? na unha ?.. software específico?
E no microcontrolador para decriptografar tem o codigo? adaptou de algum bootloader?
Quais os maiores problemas enfrentados?
Agradeço a toda e qualquer ajuda referente ao assunto do tópico.
abrax!
-
O que voce quer proteger o que exatamente? Um arquivo hex supostamente está pronto para ser carregado num microcontrolador e não estaria critptografado, podendo passar por um desassembly.
Já implementei proteções para evitar que um código fosse alterado, mas não usei criptografia.
-
Grande Mestre !!!
O que voce quer proteger o que exatamente?
Eu quero proteger um firmware para que não seja utilizado por um curioso qualquer.
Um arquivo hex supostamente está pronto para ser carregado num microcontrolador
Exatamente, eu quero proteger o meu .hex para que seja gravado somente com o uso do bootloader.
Necessito atualizar um sistema que está a uma certa distância de mim e não posso a cada atualização ir até o circuito, pedir que o cara envie ou traga o circuito para que eu atualize vai inviabilizar $$, e enviar simplesmente o .hex é a mesma coisa que dizer "pega o arquivo e não me pague".
Quero me precaver de depois de finalizar o projeto não copiarão o meu projeto, que pelo menos seja difícil para os mais curiosos e menos experientes.
-
Se é para carregar com um bootloader, voce poderia customizar o bootloader de maneira a só reconhecer o seu hex.
-
Se é para carregar com um bootloader, voce poderia customizar o bootloader de maneira a só reconhecer o seu hex.
é um caminho, mas meu hex ainda não fica protegido ... com uns testes que eu realizei em minha casa, se eu pegar o meu firmware que fiz e simplesmente gravá-lo no microcontrolador com um gravador (ICD2, JDM e outros) sem o auxílio do bootloader ele funcionará normalmente .. e é isso que eu quero evitar, ou dificultar.
Eu quero um firmware que só grave no microcontrolador que eu coloquei o bootloader e de nenhuma outra forma.
Eu pensei em imbutir o firm em um arquivo e atualizá-lo através do win, igual estes tocadores de mp3 e outros pqnos eletronicos ... mas me ocorreu que se um cara "ouvir" a serial ele poderá copiar o meu firm em um microcontrolador limpo.
-
Quanto a questão do bootloader, depende..., o SEU bootloader poderá remover algumas travas de seu hex já carregado em memória Flash e só permitirá que rode aquilo que voce pré-determinar. Se o hex for carregado com um programador comum (ICD2, ICD3,...) então o programa não vai rodar.
Outro esquema possível, seu programa pode se autoverificar, inicialmente após o reset, e só rodar se não tiver sido alterado.
Mas perceba que nenhum esquema é 100% eficaz, pode ser apenas mais dificil para a maioria.
-
Seu programa também pode ler o número de série do microcontrolador e só rodar se for o sistema que voce pré-definir.
Ou então criptografar o arquivo hex, de modo que o SEU bootloader antes de carregar, descriptografa cada byte antes de carregar em memória Flash. Evidentemente que o arquivo criptografado não vai funcionar se for carregado usando um programador comum. Nesse caso, o seu bootloader possui a CHAVE para a descriptografia.
-
Quanto a questão do bootloader, depende..., o SEU bootloader poderá remover algumas travas de seu hex já carregado em memória Flash e só permitirá que rode aquilo que voce pré-determinar. Se o hex for carregado com um programador comum (ICD2, ICD3,...) então o programa não vai rodar.
tah ae uma opção ... como fazer estas travas? e com um diassembly o cara vê o programa?
Mas perceba que nenhum esquema é 100% eficaz, pode ser apenas mais dificil para a maioria
sim eu sei e para mim já está bom, não quero que curiosos utilizem de má fé com o meu trabalho ... só isso.
Ou então criptografar o arquivo hex, de modo que o SEU bootloader antes de carregar, descriptografa cada byte antes de carregar em memória Flash. Evidentemente que o arquivo criptografado não vai funcionar se for carregado usando um programador comum. Nesse caso, o seu bootloader possui a CHAVE para a descriptografia.
é isso que falo desde o início !! :) criptografar o hex !!
-
Blackmore, não sei como funciona com os programadores ICD2 e ICD3, mais nos que eu uso (GPIC USB software
próprio e RCD com Winpic800 ou ICprog), na aba de configuração tem a opção code protect CP. Se ativado na hora
de gravar, outra pessoa não poderá ver nem modifica o seu código hex. Só gravá-lo.
Caso tente ler só aparecera zeros.
-
Quanto a questão do bootloader, depende..., o SEU bootloader poderá remover algumas travas de seu hex já carregado em memória Flash e só permitirá que rode aquilo que voce pré-determinar. Se o hex for carregado com um programador comum (ICD2, ICD3,...) então o programa não vai rodar.
tah ae uma opção ... como fazer estas travas? e com um diassembly o cara vê o programa?
Com um disassembly o programa sempre pode ser lido e submetido a "disassembly", se não estiver criptografado. Mas analisar um código pode ser bem complexo, se o código for extenso ou gerado por um compilador, por exemplo. A idéia é difcultar, já que impedir não é possível...
Ou então criptografar o arquivo hex, de modo que o SEU bootloader antes de carregar, descriptografa cada byte antes de carregar em memória Flash. Evidentemente que o arquivo criptografado não vai funcionar se for carregado usando um programador comum. Nesse caso, o seu bootloader possui a CHAVE para a descriptografia.
é isso que falo desde o início !! :) criptografar o hex !!
Criptografar o hex é outra opção, mas aí o seu bootloader deve ser bem protegido no seu sistema, pois fornece a chave para abrir o código. Mas, novamente, também é outra maneira de dificultar, não impedir...
Existem várias maneiras de criptografar. Mas, com certeza, a maneira que voce usará não será colocada aqui, em público, não é??
-
Acho que esquemas próprios bem construídos, e sendo desconhecidos, podem ser mais seguros não é?
Além disso, estamos falando de duas maneiras diferentes de carregar o programa, a saber: por um programador ou bootloader.
Usando em conjunto com o bootloader, a criptografia do hex impede que o hex ao ser submetido a disassembly gere um código coerente.
O bootloader possui uma vantagem, pois não requer que o usuário possua ou compre um programador, a menos que este seja fornecido com o sistema.
-
Coiote
a proteção para leitura de código já no microcontrolador é definida no meu firmware, sem problemas quanto a isso, além da proteção de código no microcontrolador eu preciso proteger o arquivo .hex ANTES de gravá-lo pois eu devo enviar o arquivo .hex para que ele faça as atualizações através de qqer software de comunicação serial, lá nos cafundó que ele estiver.
Obrigado pela sua atenção.
minilathe
A idéia é difcultar, já que impedir não é possível...
sim dificultar, um cara que tem conhecimentos de programação normalmente não se dá ao trabalho de tentar quebrar uma criptografia, ele já parte para o seu próprio firmware ...
mas aí o seu bootloader deve ser bem protegido no seu sistema, pois fornece a chave para abrir o código
sim, a memória será protegida ...
Existem várias maneiras de criptografar. Mas, com certeza, a maneira que voce usará não será colocada aqui, em público, não é??
sim existem várias, vc manja muito mais de criptografia que eu e nem preciso lhe dizer nada, quanto a colocar aqui, acho que discutir formas trechos de códigos, e trocar idéias como já foi feito com vários outros assuntos, será algo que muitos podem podem aproveitar, e é isso que eu preciso trocar idéias e através de delas transpor esta barreira.
abrax!
-
Acho que esquemas próprios bem construídos, e sendo desconhecidos, podem ser mais seguros não é?
Não entendi ...
-
Acho que esquemas próprios bem construídos, e sendo desconhecidos, podem ser mais seguros não é?
Não entendi ...
Me referi a não usar soluções "públicas", que todos conhecem como funciona.
-
boas blackmore
oque vc quer fazer só é possivel se o seu programa conseguir escrever na memoria de programa se vc consegue o resto da ideia e facil de implementar
-
minilathe
Me referi a não usar soluções "públicas", que todos conhecem como funciona
sim . verdade ...
luciano g
oque vc quer fazer só é possivel se o seu programa conseguir escrever na memoria de programa se vc consegue o resto da ideia e facil de implementar
justamente... o bootloader eu já implementei (tiny bootloader) agora preciso da criptografia.
-
A criptografia usa uma chave, composta de uma parte embutida em seu programa (.hex) criptografado e outra secreta (embutida em seu bootloader). O tamanho das chaves pode ser variável, de modo a dificultar mais ainda a sua descoberta.
Normalmente, a criptografia consiste na aplicação de algoritmos empregando números primos extensos. Tornando a sua descoberta, senão muito demorada, trabalhosa.
-
fragmento de código para encriptar .. e decriptar ... alguém recomenda?
-
Segue algo compacto e eficaz:
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm (http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm)
-
Qual linguagem está usando? Quanto de memória voce dispõe? Qual o microcontrolador?
O códigos em C são os seguintes (TEA=Tinny Encryption Algorithm):
#include <stdint.h>
void encrypt (uint32_t* v, uint32_t* k) {
uint32_t v0=v[0], v1=v[1], sum=0, i; /* set up */
uint32_t delta=0x9e3779b9; /* a key schedule constant */
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3]; /* cache key */
for (i=0; i < 32; i++) { /* basic cycle start */
sum += delta;
v0 += ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
v1 += ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
} /* end cycle */
v[0]=v0; v[1]=v1;
}
void decrypt (uint32_t* v, uint32_t* k) {
uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i; /* set up */
uint32_t delta=0x9e3779b9; /* a key schedule constant */
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3]; /* cache key */
for (i=0; i<32; i++) { /* basic cycle start */
v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
sum -= delta;
} /* end cycle */
v[0]=v0; v[1]=v1;
}
-
Mais algumas fontes:
http://www.brouhaha.com/~eric/crypto/#des (http://www.brouhaha.com/~eric/crypto/#des)
Dois artigos interessantes, um deles ensina como "hackear" microcontroladores. Vivemos num mundo inseguro!!
-
Qual linguagem está usando? Quanto de memória voce dispõe? Qual o microcontrolador?
serão "os" microcontroladores ... no trabalho final 18F2550 e 4550 e ARM´s 2138 e 2368 entre outros ... mas no momento 16F877A pq é o que eu possuo para teste imediato ...
Compiladores ... CCS ... C18 para os PIC e IAR ou Keil para ARM.
-
Outro código e fontes para PIC:
http://edipermadi.wordpress.com/2008/07/07/fast-blowfish-block-cipher-implementation-on-pic18f4550/ (http://edipermadi.wordpress.com/2008/07/07/fast-blowfish-block-cipher-implementation-on-pic18f4550/)
-
Dois artigos interessantes, um deles ensina como "hackear" microcontroladores. Vivemos num mundo inseguro!!
este sobre hackear eu jah conhecia ... foi assunto de discussão no asm51 ... em resumo é possível hackear mas não é qualquer um que pode fazê-lo.
-
Blackmore,
Testei o blowfish e funcionou bem. Mas como pode ter percebido, esses algoritmos consomem memória e tempo de processamento. Mas como dizem: "não existe almoço de graça"...
Acho que o tempo de processamento não é crítico, pois só ocorrerá apenas no momento de carregar o código na memória e fará "parte do processo". A memória ocupada pelo algoritmo em assembly (5640 bytes) reduz a memória disponível para seu programa. Aconselho usar assembly para aumentar a economia de recursos (memória e tempo de processamento).
O código que postei não é compatível com o PIC16F877 e pode complicar a solução, pois este não possui diversas instruções de transferência de memória de dados e de programa, bem como de acesso a palavras mais longas. Use logo um processador da linha PIC18F (2550, 4550, ...).
Mas pode simplicar o algoritmo e perder na segurança...
-
Boas Blackmore
usar estes codigos as vezes é complicado, uma solução simples é dar um rotate nos bytes do programa e salva-lo na memoria de traz para frente isto já é suficiente para complicar bastante a copia
-
minilathe
...como pode ter percebido, esses algoritmos consomem memória e tempo de processamento...
sim, acredito isso pode comprometer alguns firmwares ... quanto ao tempo do processamento eu não me preocupo afinal como vc mesmo disse isso será feito apenas qdo atualizar o sistema.
tentarei fazer testes com os que consomem menos memoria ... muito obrigado pela ajuda até o momento.
luciano g
usar estes codigos as vezes é complicado, uma solução simples é dar um rotate nos bytes do programa e salva-lo na memoria de traz para frente isto já é suficiente para complicar bastante a copia
pois eh, a simplicidade as vezes é o melhor caminho ... li algo a respeito sobre um fato ocorrido onde a criptografia do "código de césar" em uma gerra nos USA no século passado, mas tenho receio ... de qualquer forma vou estudar a melhor opção para meu problema.
abrax!
-
Blackmore
Em um determinado projeto, precisei de algo parecido com sua necessidade.
Então googleando usei e modifiquei o que esta no link abaixo para minha solução.
http://www.microchip.com/forums/tm.aspx?high=&m=126770&mpage=1#126770 (http://www.microchip.com/forums/tm.aspx?high=&m=126770&mpage=1#126770)
Lamento não poder explicar mais, por motivos óbvios, porem acho que com a ajuda do tradudor do google você lerá e entenderá o conceito.
E assim chegará também na sua solução .
-
ivan
opa ... vou ver ... estou enrolado com umas coisas que me afastaram neste momento desta pesquisa.
vou estudar a documentação enviada por ti e espero em breve relatar meus progressos.
obrigado!