Limitar números de gravações de firmware

[guest2003]

Jorge,

Esse é o problema, depois que o gravador descriptografou é so o mal intencionado escutar o clk e data que entra no PIC... ferrou...

Teria infelizmente que usar bootloader criptografado mesmo...

Qualquer outra coisa, na qual a pessoal tenha o Hex para gravar no PIC ja era... pois a pessoa pode editar o ASM e tirar a protecao...

[]'s

[Jorge_Francisco]

Dá para fazer um bootloader dentro do PIC que grave o firmware? Nunca vi isso, mas se sim, poderia usar criptografia e gravar o .hex criptografado.

Mas pensei nessa hipótese de escutar o data e clk mesmo, aí nem rola.

[fabim]

Dá para fazer um bootloader dentro do PIC que grave o firmware? Nunca vi isso, mas se sim, poderia usar criptografia e gravar o .hex criptografado.

Mas pensei nessa hipótese de escutar o data e clk mesmo, aí nem rola.

sim jorge, da sim.
Todos os 18XXXXX,24XXXX, tem acesso a leitura e gravação da flash, tendo como gravar a flash é so fazer um boot e pronto.
Ja os 16F, apenas algums gravam a flash, porexemplo de cabeça 16f876 877, e alguns outros que não me lembro agora.
Tem boot usb, serial, tempinho atras eu vi um boot I2C e SPI, muito legal os caras.....
esse do SPI tinha 5 pinos no soquete, e o I2C tinha 4 pininhos...
esses dois era bem simples.
Ao inicializar o pic, ele lia a memoria externa no endereço X Y Z T, e montava uma long, se este numero serial igual do anterior que foi gravado na flash na posição......x.x.x. intão não atualizar fw, se diferente atualiza fw.....

blw

[guest2003]

Esquece, pensando bem... é impossivel fazer isso

Mesmo no caso do bootloader, se o cliente tiver acesso ao HEX (nao digo o hex criptografado e sim o que vai no PIC virgem) ja era...

Ou seja, se o cliente comprar o PIC virgem e ELE mesmo for gravar qquer coisa que seja no PIC ja era, nao tem como proteger, o que quer que vá fazer ele pode retirar apenas abrindo o HEX e depois compilando novamente o ASM.

[]'s

[barboza]

Não sei se já levantaram esta hipótese, mas o que é muito usado são os hardlock.

Pense em algo como uma PAL, ou mesmo FPGA na sua placa com uma lógica que só você conhece e vende a mesma com o seu projeto.

Quando o seu MCU der o boot, ele lê e valida o hardlock da placa, neste caso pode enviar o .hex para quem quiser, mas só irá rodar na placa que tem sua lógica montada na sua placa.

Assim você garante que o .hex só será usado em placas que você vendeu ou forneceu o hardlock.

[fabim]

Não sei se já levantaram esta hipótese, mas o que é muito usado são os hardlock.

Pense em algo como uma PAL, ou mesmo FPGA na sua placa com uma lógica que só você conhece e vende a mesma com o seu projeto.

Quando o seu MCU der o boot, ele lê e valida o hardlock da placa, neste caso pode enviar o .hex para quem quiser, mas só irá rodar na placa que tem sua lógica montada na sua placa.

Assim você garante que o .hex só será usado em placas que você vendeu ou forneceu o hardlock.

putz, ai complicou mesmo..

barboza, veja bem.

filizbrino não quer pagar N pelo projeto, quer pagar A por chip gravado.
Filizbrino tem duas opções;
1° compra chip, manda pro designer gravar e paga por chip gravado.!! pois o designer vai poder gravar e testar o funcionamento de um por um isto garante que não vai ser passado pra traz, com mentiras do cliente sacana.
2° compra chip, ja gravado e testado direto do designer.
Se precisar de 10, compra 10, se precisar de 20 compra 20.

Fora isto, não é possivel existir outra maneira, pois o marcelo mesmo falou, coloca um sniffer no data e clock do SPI do bixo e xupa cabra, ou descobre qual porta pela internet o bixim pega os dados de boot online e xupa cabra, ou se usar um bootloader" pelo amor de Deus", vai ter que ser gravado de qualquer forma, ai fode o meio de campo de qualquer forma.
á intão coloca um hard lock, **** m****, aí frudinhou tudo mesmo.

ja tinha avisado, tudo essa dor de cabeça, pois o cliente não quer que o designer grave os uC ? porque ? ele tem medo do designer desassemblar e vender o source pra concorrencia ?kkkkk

vamo la, novamente

mereço
1,
2,
3,
kkkkkkkkkkkkkkkkkkk

Eu avisei@@@@@@

[Jorge_Francisco]

Fabim,

Tem como criar um bootloader HID e o mesmo ter a leitura protegida?No caso, a leitura do cliente, assim como gravamos nosso código e colocamos proteção, imagino que com o booteloader seja a mesma coisa não?

Se a resposta for sim, poderia enviar o .hex para o cliente, mas o .hex seria criptografado e que iria ler o .hex puro seria o PIC, ou seja, internamente teria um descriptografia. Mesmo que alguém escute o clk e o data veria um .hex criptografado entre o PIC e a USB.

E aí?

[fabim]

Intão tche.
os fuses, do pic. só podem ser gravados externamente.
digamos assim, a CPU não alcança o endereço do registrador dos fuses.
aí como abilitar a proteção contra leitura?
ai como isso ou como aquilo.!!!

resumindo, esqueçam.

A unica e melhor solução simples e possivel, é a mais obvia de todas...

Abraços jorgim!!

[guest2003]

Pessoal,

Uma coisa ja ficou clara para mim, espero que com este post consiga deixar claro para os outros tambem...

Se o cliente for gravar o PIC virgem com algum HEX que sera enviado para ele, já ferrou ! Esqueçe.

Criptografia de 500 bits, Hard lock, QUALQUER COISA NAO ADIANTA

Pois ele vai ter o Hexa que sera gravado no PIC virgem... ai ele pode olhar no assembler deste hexa e eliminar o hardlock, eliminar a criptografia... etc etc etc...

TUDO ISSO SO FUNCIONA SE JA EXISTIR ALGO GRAVADO NO PIC ANTERIORMENTE, ai sim, um bootloader serve, hardlock serve, etc etc etc serve... MAS ! se for pra gravar antes, ja grava o firmware e pronto heheeh

Entendam, qquer tipo de seguranca é inutil se o cara tiver o hexa que vai no PIC...

[]'s

[fabim]

SÓ PARA PODEREM TER IDÉIA.
outro dia eu estava lendo um forum americanu, e os caras tavam falando como conseguiram clonar o ulink, com base em um blog chines.

tem o KEIL instalado certo ?
quando espeta o Ulink, que o fw é anterior ao keil no meu caso por exemplo 4.01, o keil avisa que precisa atualizar o fw do ulink, se eu aceito que ele atualize.

SABE LÁ DEUS COMO, os caras escutaram a porta que o keil usa pegara o dito cujo hex, e sei lá como conseguiram gravar num LPC2138 e fizeram um ulink clone..
Sei que existe outros, com outros processadores, mais pqp, até nisso os caras metem a cara e conseguem..

[andre_luis]

Srs,

Não convém a nós julgarmos o cliente ou a relação do Marcelo com o cliente, que como ele mesmo comentou, é um caso particular. Nem todos aqui são tão pouco profissionais a ponto de não saber avaliar isso; Por isso ainda acho que não cabe fazer deboche algum, nem do cliente.

Outra coisa : Quanto mais o nível de complexidade da restrição, menos provável será a chance do sujeito conseguir fazer uma engenharia reversa bem-sucedida, a menos que seja por um produto que compensa o sacrifício.

Já tentaram copiar um projeto que fiz para um cliente, e no final decidiram compr-á-lo e ponto final.

Por isso, acredito que qualquer solução proposta aqui que dificulte uma clonagem é bem vinda, e não é correto ridicularizar e nem diminuir a importancia dessa tentativa.


+++

[fabim]

Andre, queridinho.
NÃO ESTOU RIDICULARIZANDO NADA.
MUITO MENOS DEBOCHANDO.

O cara perguntou como e de que forma, A RESTRINGIR O NUMERO DE GRAVAÇÕES ETC.
E o consenço é que, de forma perfeita e ant fraud!! é impossivel, não tem como e ponto final.

Agora se ele não esta preocupado com hex, não ta nem aí de ser passado pra traz por este cliente ou funcionario deste cliente.
Dane-se, faça de uma das formas que foi postado e pronto..
Acabou a discução..

Abraços

[guest2003]

Pessoal, sem estresse por favor...

A discussão foi legal, varias ideias surgiram, e como o André disse algumas podem até ser usadas, porém nenhuma garante a segurança... umas são burlaveis mais facilmente, outras nem tanto e por ai vai...

Pequeno comentario:

Somo de diversas partes do Brasil, com formação / modo de pensar / nivel de brincadeira e tolerancia a elas variados.

Então devemos equalizar um pouco as coisas, o pessoal mais formal deve procurar entender os que só querem falar sempre na informalidade e vice-versa.

Compreendo que as vezes é complicado, mas não final não vale a pena... as informações que sempre acabam surgindo são muito mais valiosas.

abraço a todos e Feliz 0x7DA !

[Jorge_Francisco]

Guest,

Criptografia funciona pra isso né! Se o cara pega o .hex criptografado não consegue ver nem alterar nada. É essa a ideia! Sim, existiria um bootloader para tirar a criptografia. Eu imagino que dê certo. Ok, num PIC talvez não, mas se fosse um ARM eu faria um DES e pronto. A minha dúvida era sobre a proteção de leitura do bootloader, mas o fabim já disse que não dá.

Jorge

[guest2003]

Entao Jorge,

Isso que voce nao entendeu... vou tentar explicar melhor... vão existir 2 firmwares...

Firmware A - do bootloader, que vai ser gravado no MCU qquer virgem... (percebe que se vc der este firmware pro cliente ja ferrou com tudo)

Firmware B - firmware da aplicação com criptografia 3DES que vai ser aberto internamente no MCU previamente gravado com o Firmware A...

Entende o problema ? se voce der o Firmware A pro cara... acabou... no B vc pode fazer o que quiser que nao adianta... a resposta pra abrir o B sempre vai estar desprotegida no A

Entende ?

Por isso eu disse... se for pra mandar o xip com o A gravado, ja manda com a aplicação e pronto.

[]'s