Rom sur USB

Fri Jan 06, 2012 9:56 pm   

Bonjour,

Je voudrais fabriquer un circuit qui permettrait à un PC de lire
quelques dizaines d'octets sur un de ses ports USB. Donc, par exemple,
une ROM ou les octets de ram Flash ou Rom interne d'un PIC, c'est à
voir. Ces octets peuvent être définitifs, ils n'ont pas a être changés
ultérieurement.

Quelqu'un connaitrait-il un montage qui fait cela ?

Michel.

Fri Jan 06, 2012 10:43 pm   

michel :


Un exemple de montage à uC basé sur un 18F2455,
il suffit de connecter ta mémoire sur les I/O libres.
Ensuite il faut (bien sûr) écrire le firmware uC
et un soft PC pour la com USB ...

http://cjoint.com/data/0AgvQ74zWE2_USB232.GIF

Fri Jan 06, 2012 10:47 pm   

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

Fri Jan 06, 2012 11:06 pm   

On 6 jan, 21:43, Jean-Christophe <5...@free.fr> wrote:

Merci. J'ai vu le PIC18F14K50, à 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émoire à mettre à
l'extérieur si je ne me trompe pas.

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

Help ...

Michel

Fri Jan 06, 2012 11:28 pm   

On 6 jan, 22:06, michel

| http://cjoint.com/data/0AgvQ74zWE2_USB232.GIF


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


Une fois que tu as choisi un modèle de PIC,
ratisse le site de Microchip qui fournit souvent
du code (driver USB asm ou C) pour interfacer le hard.
Exemple (entre autres)
http://tinyurl.com/7flmdvb


Je compatis ... ;o)


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

Sat Jan 07, 2012 2:29 am   

On 06/01/2012 20:56, michel.legeria_at_free.fr wrote:

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 :
http://www.obdev.at/products/vusb/index.html

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

v.

Sat Jan 07, 2012 9:49 am   

michel.legeria_at_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

Sat Jan 07, 2012 11:18 am   

michel.legeria_at_free.fr a écrit :

Je te conseille de jeter un oeil (juste un oeil) sur la spé de l'USB
(www.usb.org, 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

Sat Jan 07, 2012 11:24 am   

Merci à tous pour vos réponses. Il s'agit de faire un dongle, un
logiciel ne doit pouvoir fonctionner que si ce dongle est branché sur
un port USB d'un PC. Le dongle contient, dans mon idée, du code que
l'application protégé utilise pour fonctionner : elle ne fonctionne
pas sans ces données. Les octets en question ne sont lisibles qu'en
appliquant un protocole connu par l'application et différent du
protocole habituel des clé USB : l'exploreur de fichier ou tout autre
éditeur de fichier lambda ne peut pas lire ces données. L'ensemble est
simple: Il ne faut que quelques centaines d'octets, la vitesse de
lecture n'a aucune importance, il suffit (à priori) d'un processeur ou
d'une mémoire morte accessible en série par le port USB (mais là
j'avoue mon incompétence, 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'étudie vos réponses, et merci encore pour le temps que vous avez
pris pour les faire.

Michel.





On 7 jan, 09:49, Pierre Maurette <maurette.pie...@free.fr> wrote:

Sat Jan 07, 2012 12:14 pm   

On 7 jan, 10:24, michel


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

Le port USB d'un PC est soumis à certains formats
et protocoles, tu ne peux pas les contourner comme
tu le ferais avec un port série RS232 ou parallèle.
Il est donc possible, par soft ou avec une carte électronique,
d'enregistrer les messages USB qui transitent entre
ton soft et le uC, puis ensuite les « rejouer »
pour que ton soft croie que le dongle est branché.
( ou pour étudier et casser le protocole )

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

( sans parler d'une attaque directe sur l'exécutable
de ton logiciel PC, en shuntant la partie de ton code
qui récupére les données provenant de ta carte à uC )

Sat Jan 07, 2012 12:16 pm   

On 7 jan, 02:29, vic


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

Sat Jan 07, 2012 9:34 pm   

On 7 jan, 11:14, Jean-Christophe <5...@free.fr> wrote:


Oui tout à fait, de toutes façons, d'une manière ou d'une autre une
protection est cassable. Ce qui est déterminant, à mon sens, est le
ratio Quantité de travail à fournir pour casser la protection /
intérêt du logiciel. Dans mon cas, cette protection par dongle
donnerait un
rapport que je juge adapté.


Ca je pensais l'éviter en mettant dans ces octets des données
indispensable au fonctionnement du logiciel. Autrement dit, shunter
cela reviendrait, pour le shunteur, à devoir comprendre le logiciel
et à en réécrire la partie manquante. Mais cette idée n'est peut-être
pas bonne.

Sun Jan 08, 2012 12:47 am   

On 7 jan, 20:34, michel

| (...)

Un autre point est le temps minimal nécéssaire
pour casser la protection. Si ca prend 3 minutes
pour enregistrer les échanges USB et cloner le dongle,
c'est pas le top ... il reste la possibilité de crypter
la com avec des clés différentes à chaque transaction.

| (...)

Des données, ou du code ?


Au contraire, je trouve l'idée intéréssante ...
(à condition de blinder la protection anti-clonage)
Et tu peux loger ca dans 256 octets ?
C'est quel genre de soft que tu écris ?

Sun Jan 08, 2012 4:34 am   

On 07/01/2012 11:16, Jean-Christophe wrote:

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

Sun Jan 08, 2012 12:49 pm   

On 8 jan, 04:34, vic


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


C'est le but )


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

Mais c'est dit sans privilégier aucune marque puisque
tous mettent à disposition des développeurs du code
pour les couches basses, et des exemples et démos
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é
d'implémentation des couches basses (que ce soit USB,
Ethernet, etc) n'est plus vraiment un critère décisif
puisqu'aujourd'hui tous les boîtes sérieuses fournissent
ce code pour accélérer l'implémentation de l'appli client.
Aprés tout c'est bien leur intérêt qu'un client
puisse rapidement mettre au point son prototype.