Rom sur USB

On 7 jan, 20:34, michel

| (...)

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é.

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.

| (...)

Ca je pensais l'éviter en mettant dans ces octets des
données indispensable au fonctionnement du logiciel.

Des données, ou du code ?

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.

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 ?

On 7 jan, 02:29, vic

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.

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

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

Merci pour ces idées 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.

Exemple d'implémentation PIC/USB avec code et schéma :http://www.jacquet80.eu/blog/post/2006/04/29/26-carte-de-test-pic18f-usb

La doc Microchip du firmware USB :http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_FW_UG_51679...

Le firmware USB de Microchip :http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB.ZIP

On 8 jan, 13:56, michel :

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

C'est intéréssant et original comme approche.

Lors de son lancement, le programme PC pouvant être
chargé n'importe où 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 « en dur »  des pointeurs sur du code relogeable ?

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

Voilà. Tout est en relatif. L'octet numéro 120, situé sur la clé,
index le pointeur numéro 120 situé dans une table initialisée
dans la procédure d'initialisation du programme. Table qui
contient des pointeurs sur des procédures ou des variables.

On 8 jan, 17:10, michel :

| à moins qu'il ne s'agisse pas de pointeurs,
| mais d'index dans une table d'appels de fonctions

Voilà. Tout est en relatif. L'octet numéro 120, situé sur la clé,
index le pointeur numéro 120 situé dans une table initialisée
dans la procédure d'initialisation du programme. Table qui
contient des pointeurs sur des procédures ou des variables.

Ok.

Sinon, j'ai l'impression que tu cherches un truc
tout fait, pourtant avec les liens donnés tu as déja
un schéma PIC et toutes les couches USB bas niveau
disponibles : il te reste juste à implémenter ton appli.

Côté uC pas grand-chose puisque c'est de la lecture seule,
et côté PC les exemples d'implémentation USB sous Delphi.
----

Implémentation USB pour uC PIC avec code et schéma :http://www.jacquet80.eu/blog/post/2006/04/29/26-carte-de-test-pic18f-usb

La doc Microchip du firmware USB :http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_FW_UG_51679...

Le firmware USB de Microchip :http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB.ZIP

Pour le code PC sous Delphi :http://www.delphifr.com/codes/USB-ENTREES-16-SORTIES-AVEC-PIC18F4550-...

Chez Intel :http://www.intel.com/intelpress/usb/examples/zipfiles/delphi_hid.htm

On 7 jan, 11:16, Jean-Christophe<5...@free.fr> wrote:
On 7 jan, 02:29, vic

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.

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

Merci pour ces idées 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.