Rom sur USB

michel :

Un exemple de montage =E0 uC bas=E9 sur un 18F2455, il suffit de connecter ta m=E9moire sur les I/O libres. Ensuite il faut (bien s=FBr) =E9crire le firmware uC et un soft PC pour la com USB ...

Merci. J'ai vu le PIC18F14K50, =E0 priori il pourrait aussi faire l'affaire (non ? et il est un peu moins couteux) et il a aussi 256 bytes de ROM interne, cela me suffit, donc pas de m=E9moire =E0 mettre =E0 l'ext=E9rieur si je ne me trompe pas.

Par contre maintenant il faudrait mettre du code dans le PIC et savoir comment =E9crire le soft qui lira les octets, je programme en Delphi je ne sais pas si c'est possible.

Help ...

Michel

On 6 jan, 22:06, michel

|

=E0

Ok, je pensais que ta m=E9moire =E9tait externe. Effectivement ca simplifie (un peu) C'est pour faire quoi ? Un dongle ?

Une fois que tu as choisi un mod=E8le de PIC, ratisse le site de Microchip qui fournit souvent du code (driver USB asm ou C) pour interfacer le hard. Exemple (entre autres)

Je compatis ... ;o)

Embarcadero fournit s=FBrement des librairies, non ? Il en existe bien pour interfacer du RS232 ... (bien qu'on le fasse aussi avec des fonctions natives)

Le 06/01/2012 22:28, Jean-Christophe a écrit :

Lazarus, c'est bien aussi....

en fait, tu as 2 possibilités simples:

1) dialoguer par un "pseudo" rs232 avec le pic, facile à programmer en pascal, c'est du bête port série. 2) dialoguer directement en USB HID et tu peux faire qq chose de plus custom, mais c'est plus dur à programmer...

JJ

La solution la plus simple, et qui de plus permet d'éviter de devoir programmer un driver coté PC, est d'utiliser le mode HID (human interface device).

Il existe une librairie tout faite très simple à utiliser pour AVR (Atmel) qui fonctionne avec presque toute la gamme de µC en mode low-speed :

Il y a pas mal d'exemples sur le site.

v.

snipped-for-privacy@free.fr :

[...]

Je ne parviens pas à comprendre ce qui disqualifie l'utilisation de simples clés USB (flash RAM), sans doute parce que la problématique globale m'échappe. Bien sûr, vous ne pouvez pas mapper le contenu de la clé dans l'espace mémoire du PC, mais cette limitation est la même avec un microcontroleur puisque venant de l'interface USB. Ça fait plusieurs années que je n'ai plus touché à Delphi, mais les solutions me semblent simples, sachant qu'il faudra lire sur la clé un /array of bytes/. Google semble bien réactif sur le sujet. Puisque 256 octets vous suffisent, vous pouvez formatter vos clés en FAT et lire un secteur, comme s'il s'agissait d'un lecteur de disquettes. Vous pouvez placer sur votre clé une DLL (de resource ?) compilée par Delphi ou une autre toolchain, contenant vos données sous la forme de données initialisées, d'une string, d'une image. Vous pouvez regarder les solutions de sérialisation d'objets habituelles en Delphi. Vous pouvez écrire en quelque lignes votre propre sérialisation, vers un fichier texte par exemple, en allant de l'explicatif à l'obfusqué selon vos besoins. Ce sera dans tous les cas très simple, et il n'y a aucune contrainte à utiliser le même outil à l'écriture et à la lecture. Mais je le répète, sans doute un truc m'échappe dans le cahier des charges...

--
Pierre Maurette

Merci =E0 tous pour vos r=E9ponses. Il s'agit de faire un dongle, un logiciel ne doit pouvoir fonctionner que si ce dongle est branch=E9 sur un port USB d'un PC. Le dongle contient, dans mon id=E9e, du code que l'application prot=E9g=E9 utilise pour fonctionner : elle ne fonctionne pas sans ces donn=E9es. Les octets en question ne sont lisibles qu'en appliquant un protocole connu par l'application et diff=E9rent du protocole habituel des cl=E9 USB : l'exploreur de fichier ou tout autre =E9diteur de fichier lambda ne peut pas lire ces donn=E9es. L'ensemble est simple: Il ne faut que quelques centaines d'octets, la vitesse de lecture n'a aucune importance, il suffit (=E0 priori) d'un processeur ou d'une m=E9moire morte accessible en s=E9rie par le port USB (mais l=E0 j'avoue mon incomp=E9tence, j'ai appris qu'il existe des processeurs qui sont accessibles directement par l'USB, pic ou atmel, mais je me demande si de simple ROM ne le seraient pas aussi).

J'=E9tudie vos r=E9ponses, et merci encore pour le temps que vous avez pris pour les faire.

Michel.

=E0

e

es

On 7 jan, 10:24, michel

Je m'en doutais ! Lire une m=E9moire si petite ne pouvait pas vraiment avoir d'autres applications.

Le port USB d'un PC est soumis =E0 certains formats et protocoles, tu ne peux pas les contourner comme tu le ferais avec un port s=E9rie RS232 ou parall=E8le. Il est donc possible, par soft ou avec une carte =E9lectronique, d'enregistrer les messages USB qui transitent entre ton soft et le uC, puis ensuite les =AB rejouer =BB pour que ton soft croie que le dongle est branch=E9. ( ou pour =E9tudier et casser le protocole )

A mon sens l'USB ne permet pas une protection solide.

( sans parler d'une attaque directe sur l'ex=E9cutable de ton logiciel PC, en shuntant la partie de ton code qui r=E9cup=E9re les donn=E9es provenant de ta carte =E0 uC )

On 7 jan, 02:29, vic

Idem chez Microchip, et sans doute aussi chez Freescale, etc ...

snipped-for-privacy@free.fr a écrit :

Je te conseille de jeter un oeil (juste un oeil) sur la spé de l'USB

de tete) Tu vas y voir que le dialogue host (PC) function (le dongle) est bien plus compliqué qu'une simple liaison série : il y a échange de transactions pour négocier la puissance d'alim demandée par le dongle, pour identifier le dongle (classe = mémoire/disque/interface etc...)

En fait il y a trois couches de protocole : la couche liaison (en gros la liaison série) la couche USB (le protocole USB) la couche application (ici la récupération des octets)

Tout ça passe tres tres largement au dessus d'une simple ROM !!! il faut obligatoirement un µP avec certes l'interface physique (liaison) mais aussi tout ce qu'il faut comme niveau 2 et 3 en firmware et en bibliothèque de programme pour le µP. Noter que la couche application *dans le host* (PC) est faite par un driver spécifique à l'application. Certes, il y en a des "standard" (implantés par défaut dans Windows) mais si tu veux une appli non standard (qui ne soit pas vue de Windows comme une simple mémoire) tu vas devoir écrire ton propre *driver* pour XP/Vista/Seven (on ne parle plus des autres vieux machins), sans parler des drivers pour Mac et pour Linux.

Il te faut impérativement (pour éviter du développement monstrueux) "récupérer" des applis standard auxquelles tu rajoutes simplement une couche "cryptographique" : le dongle ne renvoyant jamais son contenu tel quel, identique d'une fois sur l'autre, car sinon il serait trop facilement copiable.

Mais tout dépend du coût du logiciel que tu veux ainsi protéger !!! (le coût de développement de la partie "protection dongle" n'étant pas négligeable !)

Cordialement.

--
Philippe C., mail : chephip, with domain  free.fr

Oui tout =E0 fait, de toutes fa=E7ons, d'une mani=E8re ou d'une autre une protection est cassable. Ce qui est d=E9terminant, =E0 mon sens, est le ratio Quantit=E9 de travail =E0 fournir pour casser la protection / int=E9r=EAt du logiciel. Dans mon cas, cette protection par dongle donnerait un rapport que je juge adapt=E9.

Ca je pensais l'=E9viter en mettant dans ces octets des donn=E9es indispensable au fonctionnement du logiciel. Autrement dit, shunter cela reviendrait, pour le shunteur, =E0 devoir comprendre le logiciel et =E0 en r=E9=E9crire la partie manquante. Mais cette id=E9e n'est peut-= =EAtre pas bonne.

On 7 jan, 20:34, michel

| (...)

Un autre point est le temps minimal n=E9c=E9ssaire pour casser la protection. Si ca prend 3 minutes pour enregistrer les =E9changes USB et cloner le dongle, c'est pas le top ... il reste la possibilit=E9 de crypter la com avec des cl=E9s diff=E9rentes =E0 chaque transaction.

| (...)

Des donn=E9es, ou du code ?

Au contraire, je trouve l'id=E9e int=E9r=E9ssante ... (=E0 condition de blinder la protection anti-clonage) Et tu peux loger ca dans 256 octets ? C'est quel genre de soft que tu =E9cris ?

Tu peux développer ? Quel est l'équivalent pour PIC ?

On 8 jan, 04:34, vic

| Idem chez Microchip, et sans doute aussi chez Freescale, etc ...

C'est le but :o)

Le 6 j'ai post=E9 une URL Microchip pour downloader des sources de frameworks USB pour 18F/24F/32.

Mais c'est dit sans privil=E9gier aucune marque puisque tous mettent =E0 disposition des d=E9veloppeurs du code pour les couches basses, et des exemples et d=E9mos pour l'exploitation de ces couches basses. ( qu'il s'agisse d'USB sous plusieurs classes (HID, etc) mais aussi d'Ethernet (IP/UDP/TCP etc) et autres )

Ce que je voulais souligner est que si une personne pose une question relative au choix d'un uC, la facilit=E9 d'impl=E9mentation des couches basses (que ce soit USB, Ethernet, etc) n'est plus vraiment un crit=E8re d=E9cisif puisqu'aujourd'hui tous les bo=EEtes s=E9rieuses fournissent ce code pour acc=E9l=E9rer l'impl=E9mentation de l'appli client. Apr=E9s tout c'est bien leur int=E9r=EAt qu'un client puisse rapidement mettre au point son prototype.

ne

Les octets codent des appels de proc=E9dures/fonctions, quelques donn=E9es et des pointeurs sur des variables du programme. La suite d'octet code donc une suite d'appels de proc=E9dures/functions avec certaines donn=E9es et certaines variables , le tout fabriquant une portion du programme n=E9cessaire =E0 son fonctionnement. Sans ces donn=E9es le programmes est incomplet, il ne fonctionne plus. Il faut le comprendre et r=E9=E9crire la partie manquante pour qu'il fonctionne =E0 nouveau. Ce code stock=E9 sur la cl=E9 est en fait une sorte de bytecode.

Merci pour ces id=E9es et ces liens. J'ai un boulot monstrueux et je ne me sens pas la force de me plonger dans tout cela. Si quelqu'un connait un exemple de dongle USB, approchant, utilisant ces processeurs, et qui me permettrait de commencer, merci de me l'indiquer.

On 8 jan, 13:56, michel :

s s t a

C'est int=E9r=E9ssant et original comme approche.

Lors de son lancement, le programme PC pouvant =EAtre charg=E9 n'importe o=F9 dans la RAM du PC, les adresses de ses fonctions ne sont pas fixes : ton dongle se comportant comme une ROM, je vois mal comment on peut y coder =AB en dur =BB des pointeurs sur du code relogeable ?

( =E0 moins qu'il ne s'agisse pas de pointeurs, mais d'index dans une table d'appels de fonctions )

On 8 jan, 13:59, michel :

Est-ce pour une appli perso ou professionnelle ?

C'est un peu contradictoire parce-que la diffusion du code et du sch=E9ma d'un dongle le rend moins s=E9curis=E9, il faudra forc=E9ment y apporter un travail cons=E9quent. En cherchant un peu sur le net tu y trouveras des impl=E9mentations que tu pourras customiser =E0 souhait.

Exemple d'impl=E9mentation PIC/USB avec code et sch=E9ma :

La doc Microchip du firmware USB :

Le firmware USB de Microchip :

On 8 jan, 16:00, Jean-Christophe

Pour le code PC sous Delphi :

682.aspx

Chez Intel :

eDoc/MCHPFSUSB.ZIP