Limitar números de gravações de firmware

Software e Hardware para uC PIC

Moderadores: andre_luis, 51, guest2003, Renie

Mensagempor guest2003 » 04 Jan 2010 20:54

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
http://www.sethi.com.br (Institucional)
http://www.sethi3d.com.br (Impressoras 3d)
http://www.sethi.com.br/blog (Blog Impressoras 3d)
Avatar do usuário
guest2003
Word
 
Mensagens: 746
Registrado em: 13 Out 2006 11:48
Localização: Campinas - SP

Mensagempor Jorge_Francisco » 04 Jan 2010 21:06

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.
Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Mensagempor fabim » 05 Jan 2010 06:40

Jorge_Francisco escreveu: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
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor guest2003 » 05 Jan 2010 07:08

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
http://www.sethi.com.br (Institucional)
http://www.sethi3d.com.br (Impressoras 3d)
http://www.sethi.com.br/blog (Blog Impressoras 3d)
Avatar do usuário
guest2003
Word
 
Mensagens: 746
Registrado em: 13 Out 2006 11:48
Localização: Campinas - SP

Mensagempor barboza » 05 Jan 2010 11:23

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.
Os homens mentiriam muito menos se as mulheres fizessem menos perguntas.
Avatar do usuário
barboza
Word
 
Mensagens: 948
Registrado em: 17 Out 2006 13:42
Localização: Longe de onde gostaria de estar

Mensagempor fabim » 05 Jan 2010 12:30

barboza escreveu: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@@@@@@
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor Jorge_Francisco » 05 Jan 2010 12:56

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í?
Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Mensagempor fabim » 05 Jan 2010 13:05

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!!
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor guest2003 » 05 Jan 2010 13:26

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
http://www.sethi.com.br (Institucional)
http://www.sethi3d.com.br (Impressoras 3d)
http://www.sethi.com.br/blog (Blog Impressoras 3d)
Avatar do usuário
guest2003
Word
 
Mensagens: 746
Registrado em: 13 Out 2006 11:48
Localização: Campinas - SP

Mensagempor fabim » 05 Jan 2010 13:54

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..
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor andre_luis » 05 Jan 2010 14:38

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.


+++
"Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."
Avatar do usuário
andre_luis
Dword
 
Mensagens: 5447
Registrado em: 11 Out 2006 18:27
Localização: Brasil - RJ

Mensagempor fabim » 05 Jan 2010 14:42

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
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor guest2003 » 05 Jan 2010 15:57

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 !
http://www.sethi.com.br (Institucional)
http://www.sethi3d.com.br (Impressoras 3d)
http://www.sethi.com.br/blog (Blog Impressoras 3d)
Avatar do usuário
guest2003
Word
 
Mensagens: 746
Registrado em: 13 Out 2006 11:48
Localização: Campinas - SP

Mensagempor Jorge_Francisco » 05 Jan 2010 17:35

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
Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Mensagempor guest2003 » 05 Jan 2010 20:43

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
http://www.sethi.com.br (Institucional)
http://www.sethi3d.com.br (Impressoras 3d)
http://www.sethi.com.br/blog (Blog Impressoras 3d)
Avatar do usuário
guest2003
Word
 
Mensagens: 746
Registrado em: 13 Out 2006 11:48
Localização: Campinas - SP

AnteriorPróximo

Voltar para PIC

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron

x