Limitar números de gravações de firmware

[Jorge_Francisco]

André,

Só se enviar o .Hex com chave pública e enviar a chave privada depois.

Acho que estamos em outro nível de conversa,hehe.

Jorge

[KrafT]

Se fosse chip da Freescale, tipo um 9s08 da vida, bastava o cliente ter um Cyclone como gravador e via internet voce colocava o firware no mesmo com o numero de gravações desejadas.

Alem de poder atualizar o firware da mesma forma...

Mas sendo PIC tem que se pagar o preço.

[marcelo campos]

Amigos,

Grandes idéias, muito mais (e melhores) do que eu sozinho consegui imaginar quando fiquei dias queimando a pestana antes de postar aqui esta questão;

Pela lógica muitos tem razão e vi que tem mesmo muitas maneiras de se fazer umas mais outras menos complexas ou menos ao alcance de cada um...

e por favor sem stress

Agora um porém pra quem quer uma segurança infalível (que não é o meu caso só quero uma "forte" o bastante):
- Uma uma das maiores e mais lucrativas empresas de software do mundo a Microsoft, tem uma a segurança de seu mais lucrativo produto, o Windows, bem quebrável e nem por isto deixa de ter lucros extraordinários e praticamente monopolizar o mercado.

Apesar de dar um trabalho danado, tomar tempo e gasto altos, necessitar de profissional altamente qualificado e.... o firmware não é tudo. E falo isto também como programador;

[vtrx]

Kraft,é possível fazer isso com qualquer µc,basta programar um software próprio com um hardware dedicado,o problema ,talvez,seja o 'sniff'.

[marcelo campos]

Kraft,é possível fazer isso com qualquer µc,basta programar um software próprio com um hardware dedicado,o problema ,talvez,seja o 'sniff'.

É isso aí, em última instância podemos colocar um analizador, ou circuitinho "chupa cabra", direto nos pinos data e ck do pic ou qualquer outro uC.
E pegar o firmware sendo gravado...

Mas até aí já dificultou bastante, é pra se pensar se quem faria isto já não desenvolveria o firmware sendo gravado;

Marcelo Campos
.

[fabim]

Amigos,

Grandes idéias, muito mais (e melhores) do que eu sozinho consegui imaginar quando fiquei dias queimando a pestana antes de postar aqui esta questão;

Pela lógica muitos tem razão e vi que tem mesmo muitas maneiras de se fazer umas mais outras menos complexas ou menos ao alcance de cada um...

e por favor sem stress

Agora um porém pra quem quer uma segurança infalível (que não é o meu caso só quero uma "forte" o bastante):
- Uma uma das maiores e mais lucrativas empresas de software do mundo a Microsoft, tem uma a segurança de seu mais lucrativo produto, o Windows, bem quebrável e nem por isto deixa de ter lucros extraordinários e praticamente monopolizar o mercado.

Apesar de dar um trabalho danado, tomar tempo e gasto altos, necessitar de profissional altamente qualificado e.... o firmware não é tudo. E falo isto também como programador;

à intão pode ser qualquer porcaria mesmo, isto ja vai dar um certo nivel de dor de cabeça pros xupinhos que tentarem burlar seu sistema.
Só que uma vez burlado, o seu cliente vai gravar quantos pic´s quiser sem te dar nenhum centavo por isto..
Sendo assim faça igual a microsoft, venda pra todo mundo, assim abre mais os seus lucros e não vai ter problemas se alguns burlarem o seu sistema de segurança.

[_blackmore_]

marcelo campos

este tópico está muito interessante, a experiência do pessoal ajuda muito mesmo hein?
Agora uma pergunta boba, mas eu não consigo entender pq vc tem que enviar o .hex para o seu (ou seus) cliente(s)?

abrax!

[KrafT]

Kraft,é possível fazer isso com qualquer µc,basta programar um software próprio com um hardware dedicado,o problema ,talvez,seja o 'sniff'.

Na minha sugestão, o cliente compra o uC virgem de quem quiser, mas o gravador que é atualizado remotamente via internet, vai limitar o numero de gravações.

Tudo isso já é nativo na ferramenta, no caso o Cyclone, mas claro que ferramentas sérias tem seu preço, no caso 1000 reais aproximadadente.

Mas também é outro mcu, o que torna minhas colocações meio off-topic.

[vtrx]

Muito interessante esse tópico,eu projetei a muito tempo atraz,proteção para alguns Software que desenvolví utilizando um pic como Hardlock via serial.
Criei um algorítimo anti-sniff eficaz onde qualquer tentativa de se comunicar com o HardLock com algum byte não implementado,ele grava na eeprom um código deixando-o em loop infinito e um Led piscando infinitamente.
Agora fazer ao contrario,proteger o FirmWare do PIC,é muito engraçado.

[marcelo campos]

marcelo campos

este tópico está muito interessante, a experiência do pessoal ajuda muito mesmo hein?
Agora uma pergunta boba, mas eu não consigo entender pq vc tem que enviar o .hex para o seu (ou seus) cliente(s)?

abrax!

Olá blackmore,

Realmente muito interessante e o pessoal tem mesmo contribuído muito, sinceramente não espera que viriam tantas idéias boas quando postei

Agora sobre o que perguntou, a reposta é simples e que já deve ter imaginado: quero difundir mais e para qualquer um, ou seja: o cliente 1) compra o firmware 2) baixa 3)grava 4)ativa

Abraço,

Marcelo.

[_blackmore_]

Com a necessidade ...

Eu fiz um fw simples (botao led e LCD) e precisava que atualizações pudessem ser realizadas a distância, por pessoas que não tenham conhecimento técnico nem ferramentas para tal (gravadores).
Alguns pontos q estavam obscuros para mim foram esclarecidos ...

1 - PIC com bootloader, funciona e muito bem ... eu gostei e vai me ajudar em um trabalho q estou desenvolvendo, devia ter fuçado isso muito antes;

2 - Proteção contra leitura, funciona se na hora de vc gravar o bootloader vc ativar a proteção contra leitura da memória ela ficará protegida;

3 - Funcionamento do código, caso vc pegue o .hex a ser "atualizado" e gravar diretamente na memoria do PIC o fw vai funcionar normalmente, se não tiver a criptografia e o cabra for curioso, trabalho perdido;

Agora o negócio é aprender criptografia ...

abraço

[marcelo campos]

_blackmore_

sobre seu item 2:
2 - Proteção contra leitura, funciona se na hora de vc gravar o bootloader vc ativar a proteção contra leitura da memória ela ficará protegida;

Qual bootloader está usando ? pois nos que uso ao ativar o code protect "dá pau"

valeu

[Guri]

Analizando as inumeras respostas do colegas para a solução do problema sugerido. Eu imaginei o seguinte:

- Você fazer um circuito com o pic onde esse circuito seria uma espécie de contimetro que iria autenticar a liberação de seu programa que estaria no firmware que você deixou com o cliente uma determinada quantidade de vezes (tipo um pre-pago, quando acabar a carga o cliente tem que lhe enviar o aparelho para vc fazer a recarga).

- A comunicação poderia ser rx tx entre os dois circuitos, porém você iria detectar o checksam do seu firmware antes de autenticar o circuito para que funcione, entendeu.

- Após confirmação do checksam o seu firmware irá aguardar por um determinado tempo (tipo 3 segundos) que seja enviado do contimetro a senha de autenticação (essa senha sempre será pedida no programa todas as vezes que o sistema foi reinicializado e estará guardada na eeprom).

- Você então envia uma sequencia por exemplo de 100 bytes e a cada autenticação do contimetro o baudrate seria alterado ciclicamente.

- Lá no seu firmware você teria um detector de baudrate, bem simples, sugiro vc fazer um byte de identificação do baudrate, tipo: 00 = baudrate 1.200bps, 01 = baudrate 9.200bps e assim por diante, lembre-se que lá no seu firmware será feito uma rotina que receber esse byte de status para calibrar o baudrate afim de sincronizar o contimetro.

Essa alternativa de alterar as taxas a cada autenticação de firmware seria para dificultar alguém escutar seus pacotes de dados que estão sendo transmitidos e o fato da leitura do checksam (poderia ser gravado numa área da memória esse cheksam, entendeu, não precisaria ser necessariamente o checksam do mcu) é uma segurança a mais.

Se bem que eu acho que você poderia fazer os clientes enviarem para você gravar os chips, todavia cada um tem seu estilo de trabalho.

Boa sorte,

[_blackmore_]

marcelo campos

Qual bootloader está usando ? pois nos que uso ao ativar o code protect "dá pau"

O bootloader, Tinybootloader com o firm do site ... eficiente, ocupa 103 words ( 3 no início e 100 no final da memória) ...

( http://www.etc.ugal.ro/cchiculita/softw ... loader.htm )

os próximos testes serão com o bootloader da microchip (AN1310)