Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA3/IMA4 2018/2020 P12

2020-01-06T13:33:05Z

Mduquesn : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V. Une mémoire flash (ou carte SD) est alimentée par du 3.3V. Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utiles
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
34
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
34
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
34
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
34
|}

*Nous utiliserons comme mémoire une mémoire de type flash série car elle nécessite moins de broche. Mais en contrepartie il nous faudra sur notre micro-contrôleur deux SPI, un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur se porte sur l'ATXMEGA16A4U.
Il dispose en effet de deux SPI (un sur le port C et l'autre sur le port D ) et il gère les MOSI (Master Out Slave In) MISO (Master In Slave Out) pour la communication avec la mémoire et l'USB. 
Il a aussi 34 broches I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI, non-volatile, travaillant sous une tension de 3.3V et dont la fréquence de travail est inférieure ou égale à 33MHz.

===Semaine 6===
*Il nous reste à réaliser les plan du PCB, pour cela nous allons nous aider des plans suivants. Il s'agit d'un exemple de PCB dans lequel une carte SD est connecté à un ATmeaga. 
La référence est : [https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php] 
[[Fichier:Atmega-cartesd-pcb.jpg]]

*Les principaux éléments retenus sont donc 
le microcontrôleur ATXMEGA16A4U (32 PORTs I/O , dons 2 SPI USB et MOSI , fréquence 33Mhz) 
et la mémoire MX25R6435FM2IL0 (type flash , taille 8 Mbits , fréquence 33Mhz , communication SPI).

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T17:30:02Z

Mduquesn : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===
*Avec tout cela de réalisé il nous reste plus qu'à réaliser les plan du PCB , pour cela nous allons nous aider des plans suivants :
[[Fichier:Atmega-cartesd-pcb.jpg]]
*exemple de pcb afin de connecter un atmega à une carte SD (tiré du site [https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php])
*Les éléments les plus importants t(s retenue sont donc:
*Micro-contrôleur : ATXMEGA16A4U (32 PORTs I/O , dons 2 SPI USB et MOSI , fréquence 33Mhz)
*Mémoire : MX25R8035FM1IL0 (type flash , taille 8 Mbits , fréquence 33Mhz , communication SPI)

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T17:20:16Z

Mduquesn : /* Semaine 3 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===
*Avec tout cela de réalisé il nous reste plus qu'à réaliser les plan du PCB , pour cela nous allons nous aider des plans suivants :
[[Fichier:Atmega-cartesd-pcb.jpg]]
*exemple de pcb afin de connécter un atmega à une carte SD (tiré du site [https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php])

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T17:15:53Z

Mduquesn : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===
*Avec tout cela de réalisé il nous reste plus qu'à réaliser les plan du PCB , pour cela nous allons nous aider des plans suivants :
[[Fichier:Atmega-cartesd-pcb.jpg]]
*exemple de pcb afin de connécter un atmega à une carte SD (tiré du site [https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php])

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T17:15:11Z

Mduquesn : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===
*Avec tout cela de réalisé il nous reste plus qu'à réaliser les plan du PCB , pour cela nous allons nous aider des plans suivants :
[[Fichier:Atmega-cartesd-pcb.jpg]]
exemple de pcb afin de connécter un atmega à une carte SD (tiré du site [https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php])

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T14:39:54Z

Mduquesn : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===
*Avec tout cela de réalisé il nous reste plus qu'à réaliser les plan du PCB , pour cela nous allons nous aider des plans suivants :
[[Fichier:Atmega-cartesd-pcb.jpg]]

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

Fichier:Atmega-cartesd-pcb.jpg

2020-01-03T14:39:22Z

Mduquesn : image venant du site : https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php qui nous montre les branchement à réaliser pour relier une carte atmega avec une carte sd.

image venant du site :
https://www.abcelectronique.com/annuaire/montages/microcontrolleurs-atmel.php
qui nous montre les branchement à réaliser pour relier une carte atmega avec une carte sd.

IMA3/IMA4 2018/2020 P12

2020-01-03T14:35:46Z

Mduquesn : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===
*Avec tout cela de réalisé il nous reste plus qu'à réaliser les plan du PCB , pour cela nous allons nous aider des plans suivants :

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T14:33:11Z

Mduquesn : /* Semaine 5 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

*Nous utiliseront comme mémoire une mémoire de type flash série car elle nécessite moins de broche.Mais en contre partie il nous faudra sur notre micro-contrôleur 2 SPIs,L'un pour la liaison USB et l'autre pour celle avec la carte mémoire .

*Notre choix de micro-contrôleur c'est donc portée sur ATXMEGA16A4U.
Car il dispose de 2 SPIs (un sur le port C et l'autre sur le port D ) et gère le mosi et l'usb.
Il a aussi 34 PORTs I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V , donc on pourra programmer la micro-contrôleur en alimentant directement en 3.3 v.
*Il nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI , non-volatile , travaillant sous une tension de 3.3V et dons la fréquence de travaille est inférieur ou égal à 33MHz.

===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2020-01-03T14:10:46Z

Mduquesn : /* Semaine 3 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons donc commencé par réflechir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V , et une mémoire flash (ou carte SD) est alimenté par du 3.3V .Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)

[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12

2019-12-31T16:37:15Z

Mduquesn : /* Semaine 4 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===Liste des tâches et planification===

*Harware
**Choix des composants principaux : microprocesseur, mémoire
**alimentation
**routage
**liste des composants
**PCB
**connecter la matrice du clavier

*Software
**modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique
**rédiger le programme d'acquisition des touches du clavier par le microprocesseur
**permettre au PC de lire l'état des touches

*Autre
**état de l'art pour le Keygrabber

===Semaine 1===
*- Expression plus précise de notre feuille de route.
*- Entretien avec les professeurs
*- Etude de l'état de l'art des Keygrabber

[1] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications. 
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté. 
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. La page web suivante donne un aperçu de ce qu'il se fait. 
http://airdrivewifi.com/?page=keyloggers 
Nous observons aussi sur ce même site qu'il existe également un Keylogger sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

===Semaine 2===
* Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB.
* Nous l'avons ouvert et avons étudié sur son fonctionnement global. Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

* Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

* Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

===Semaine 3===
*A partir de cette séance, nous avons travaillé sur le choix des composants.
Nous avons lu les datasheet afin de connaitre les composants secondaires actifs et passifs nécessaires.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de ports (24) alors que notre clavier seul en demande déjà 26.
Le nombre de ports est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4.
Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons en outre commencé le schéma du PCB avec notamment de quoi réduire la tension d'alimentation de la mémoire de 5V à 3.3V.

===Semaine 4===
* Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATmega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin. 
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATmega, les AT90USB, les AT32UC3 et les ATXMEGA. 
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

*Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier.
Nous avons obtenue le mappage suivant : (mappage non finalisé par manque de temps)
[[Fichier:Scan_code.jpg]]

===Semaine 5===
A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

{| class="wikitable centre" style="width:40%;"
|+ Tableau
|-
! scope=col | Série
! scope=col | Modèle
! scope=col | Nombre de pins utilisables
|-
| style="width:6%;" rowspan="4" |
AT32
| style="width:10%;" |
AT32UC3B064
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0128
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0256
| style="width:10%;" |
44
|-
| style="width:10%;" |
AT32UC3B0512
| style="width:10%;" |
44

|-
| style="width:6%;" rowspan="4" |
AT90USB
| style="width:10%;" |
AT90USB646
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB647
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1286
| style="width:10%;" |
46
|-
| style="width:10%;" |
AT90USB1287
| style="width:10%;" |
46

|-
| style="width:6%;" rowspan="4" |
ATXMEGA
| style="width:10%;" |
ATXMEGA16A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA32A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|-
| style="width:10%;" |
ATXMEGA64A4U
| style="width:10%;" |
32
|}

===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

=Bibliographie=

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

Fichier:Scan code.jpg

2019-12-31T16:36:44Z

Mduquesn : scan code non complet du clavier

scan code non complet du clavier

IMA3/IMA4 2018/2020 P12

2019-12-12T17:10:35Z

Mduquesn : /* Semaine 4 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretien avec les professeurs
*-Etude de l'état de l'art autour du keygraber :
http://www.keelog.com/wireless-keylogger/ 
http://www.keelog.com/diy-hardware-keylogger/
On sait maintenant que 2 choix s'offre à nous pour la méthode de récupération des donnée.
La première en 'série' , on envoie les données envoyé par le microcontrôleur usb du clavier vers le keygrabbr puis on en fait une sauvegarde et on et les renvoient.
La seconde dite en parallèle consiste quand à elle récupérer les donnée passante du clavier et la les enregistrer.
Les 2 liens au-dessus nous montre l'intégralité du fonctionnement de keygraber en parallèle.
Notre projet différent encore de des 2 type de keygraber trouvé , car nous allons allons traiter des données brut venant du clavier ,et non pas venant d'un microprocesseur gérant le protocole usb.

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage.Une touche pressé correspond à un code brut nommé scancode , chaque clavier à un scancode qui lui est propre.Ce scancod est donc traité par le microprocesseur qui lui retourne en usb un keycode qui est lui universel pour chaque pays.
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du PCB 2,5 cm * 13 cm.
*Problème retenu :
** problème de mappage des touches (est-ce que ce mappage est universalisé ?)
*Lecture et prémisse des composants principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage , car il dispose de peut de port (24) .Alors que seul notre clavier nous en demande déjà 16.
Nous avons alors pensé à utiliser des multiplexeur , mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons donc commencé le schéma du pcb avec les composants qui seront essentiel (passage de 5v à 3.3v ...).

===Semaine 4===
*Création du scan code de notre clavier à l'aide d'une braidboard et des LED.
**Création d'un liste de microcontrôleur correspond à nos attentes

===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-12-12T17:08:52Z

Mduquesn : /* Semaine 3 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretien avec les professeurs
*-Etude de l'état de l'art autour du keygraber :
http://www.keelog.com/wireless-keylogger/ 
http://www.keelog.com/diy-hardware-keylogger/
On sait maintenant que 2 choix s'offre à nous pour la méthode de récupération des donnée.
La première en 'série' , on envoie les données envoyé par le microcontrôleur usb du clavier vers le keygrabbr puis on en fait une sauvegarde et on et les renvoient.
La seconde dite en parallèle consiste quand à elle récupérer les donnée passante du clavier et la les enregistrer.
Les 2 liens au-dessus nous montre l'intégralité du fonctionnement de keygraber en parallèle.
Notre projet différent encore de des 2 type de keygraber trouvé , car nous allons allons traiter des données brut venant du clavier ,et non pas venant d'un microprocesseur gérant le protocole usb.

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage.Une touche pressé correspond à un code brut nommé scancode , chaque clavier à un scancode qui lui est propre.Ce scancod est donc traité par le microprocesseur qui lui retourne en usb un keycode qui est lui universel pour chaque pays.
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du PCB 2,5 cm * 13 cm.
*Problème retenu :
** problème de mappage des touches (est-ce que ce mappage est universalisé ?)
*Lecture et prémisse des composants principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage , car il dispose de peut de port (24) .Alors que seul notre clavier nous en demande déjà 16.
Nous avons alors pensé à utiliser des multiplexeur , mais cela ajoutera un coût et une complexité supplémentaire au projet.
*Nous avons donc commencé le schéma du pcb avec les composants qui seront essentiel (passage de 5v à 3.3v ...).

===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-12-12T17:02:27Z

Mduquesn : /* Semaine 2 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretien avec les professeurs
*-Etude de l'état de l'art autour du keygraber :
http://www.keelog.com/wireless-keylogger/ 
http://www.keelog.com/diy-hardware-keylogger/
On sait maintenant que 2 choix s'offre à nous pour la méthode de récupération des donnée.
La première en 'série' , on envoie les données envoyé par le microcontrôleur usb du clavier vers le keygrabbr puis on en fait une sauvegarde et on et les renvoient.
La seconde dite en parallèle consiste quand à elle récupérer les donnée passante du clavier et la les enregistrer.
Les 2 liens au-dessus nous montre l'intégralité du fonctionnement de keygraber en parallèle.
Notre projet différent encore de des 2 type de keygraber trouvé , car nous allons allons traiter des données brut venant du clavier ,et non pas venant d'un microprocesseur gérant le protocole usb.

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage.Une touche pressé correspond à un code brut nommé scancode , chaque clavier à un scancode qui lui est propre.Ce scancod est donc traité par le microprocesseur qui lui retourne en usb un keycode qui est lui universel pour chaque pays.
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du PCB 2,5 cm * 13 cm.
*Problème retenu :
** problème de mappage des touches (est-ce que ce mappage est universalisé ?)
*Lecture et prémisse des composants principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Choix:
**micro-processeur : ATMEGA32U4
**carte mémoire : mémoire flash

===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-12-12T16:59:00Z

Mduquesn : /* Semaine 1 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretien avec les professeurs
*-Etude de l'état de l'art autour du keygraber :
http://www.keelog.com/wireless-keylogger/ 
http://www.keelog.com/diy-hardware-keylogger/
On sait maintenant que 2 choix s'offre à nous pour la méthode de récupération des donnée.
La première en 'série' , on envoie les données envoyé par le microcontrôleur usb du clavier vers le keygrabbr puis on en fait une sauvegarde et on et les renvoient.
La seconde dite en parallèle consiste quand à elle récupérer les donnée passante du clavier et la les enregistrer.
Les 2 liens au-dessus nous montre l'intégralité du fonctionnement de keygraber en parallèle.
Notre projet différent encore de des 2 type de keygraber trouvé , car nous allons allons traiter des données brut venant du clavier ,et non pas venant d'un microprocesseur gérant le protocole usb.

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage .
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du PCB 2,5 cm * 13 cm.
*Problème retenu :
** problème de mappage des touches (est-ce que ce mappage est universalisé ?)
*Lecture et prémisse des composants principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Choix:
**micro-processeur : ATMEGA32U4
**carte mémoire : mémoire flash

===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T14:50:06Z

Mduquesn : /* Semaine 1 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs
*-Etude de l'état de l'art autour du keygraber :
http://www.keelog.com/wireless-keylogger/
http://www.keelog.com/diy-hardware-keylogger/

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage .
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du pcb 2,5 cm * 13 cm.
*Problème retenue :
** problème de mappage des touches (est-ce que ce mappage est universalisé)
*Lecture et prémisse des composant principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Choix:
**micro-processeur : ATMEGA32U4
**carte mémoire : mémoire flash

===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T14:32:38Z

Mduquesn : /* Semaine 3 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage .
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du pcb 2,5 cm * 13 cm.
*Problème retenue :
** problème de mappage des touches (est-ce que ce mappage est universalisé)
*Lecture et prémisse des composant principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Choix:
**micro-processeur : ATMEGA32U4
**carte mémoire : mémoire flash

===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T14:07:55Z

Mduquesn : /* Semaine 3 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage .
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du pcb 2,5 cm * 13 cm.
*Problème retenue :
** problème de mappage des touches (est-ce que ce mappage est universalisé)
*Lecture et prémisse des composant principaux à utiliser

===Semaine 3===
*choix plus précis des composants qui vont être utilisés et lecture de leurs datasheet afin de connaitre les composants secondaire actif et passif nécessaire.
*Choix:
**micro-processeur : ATMEGA32U2
**carte mémoire : mémoire flash

===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T14:04:13Z

Mduquesn : /* Semaine 2 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global.Les touches du clavier sont relié à un mappage .
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du pcb 2,5 cm * 13 cm.
*Problème retenue :
** problème de mappage des touches (est-ce que ce mappage est universalisé)
*Lecture et prémisse des composant principaux à utiliser

===Semaine 3===
===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T13:58:22Z

Mduquesn : /* Semaine 2 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs

===Semaine 2===
*Dissection d'un clavier , et étude sur son fonctionnement global .
*Notre clavier se compose d'un mappage de touche composé de 26 pins , taille du pcb 2,5 cm * 13 cm.
*Problème retenue :
** problème de mappage des touches (est-ce que ce mappage est universalisé)

===Semaine 3===
===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T13:52:01Z

Mduquesn : /* Semaine 1 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
*-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs

===Semaine 2===
===Semaine 3===
===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T13:51:44Z

Mduquesn : /* Semaine 1 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
-expression plus précise de notre feuille de route.
*-Entretient avec les professeurs

===Semaine 2===
===Semaine 3===
===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-11-21T13:50:50Z

Mduquesn : /* Semaine 1 */

<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==

Liens concernants les concurrents
*du clavier :

Nom du produit :KeyGrabber USB 
Société : Keelog 
URL : http://www.keelog.com/fr/usb-keylogger/

*de la clé

Nom : USB RUBBER DUCKY 
Société : hak5 
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino : 
https://www.arduino.cc/en/Tutorial/CharacterAnalysis 
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA: 

Introduction à LUFA: 
https://www.engineersgarage.com/article/introduction-lufa

Résumé de la bibliothèque LUFA par M. REDON: 
https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/

Un projet IMA4 : Exemple dans laquelle une carte est reconnue en tant que souris à l'aide de LUFA 
https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB. 

Protocole USB par Bernard ACQUIER
http://www.abcelectronique.com/acquier/usb.html

USB : classe HID (Human Interface Device):
http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
* Objectif S6 : prototypes en Arduino.
* Objectif final : ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
* Côté réalisation des prototype
** Hardware : réaliser un hardware qui permette d'avoir un prototype fonctionnel.
** Software : réaliser du code qui permette de faire fonctionné comme il se doit le prototype.

* Côté documentation
** Maîtriser le protocole USB
** Maîtriser l'utilisation de l'ATMega 16 U2

==3.5 Calendrier prévisionnel==

*Protocole USB : Semestres 6 et 7
*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
*Maquettes Arduino : Semestre 6
*Modélisation des PCB et des coques (clavier et clé) : Semestre 7
*Rédaction du code : Semestre 7 et 8
*Montage des périphériques : Semestres 7 et 8
*Implémentation : Semestre 8

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
*Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
*Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
*Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

===Semaine 5===
*Pour implanter la librairie Keyboard.h, il suffit que l'interface Arduino IDE soit à jour.
*Premiers tests avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
*Premier Accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
*Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

*Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche. 
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A. 
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

===Semaine 7===
*Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

* Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets. 
**Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame. 
**Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée. 
**Les paquets DATA optionnels constituent les données utiles. 
**Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication. 
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

===Semaine 8===
*Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

* Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs. 

[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]

- Le descripteur d'appareil précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB. 

- Les descripteurs de configurations 
Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces. 
Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations. 
Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois. 

- Les descripteurs d'interfaces 
Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte. 

- Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro. 
- Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

===Semaine 9===
*Le problème du backslash est résolu, via alt+92.
*Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
*Il y a bien une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

*Il existe quatre types de transferts pour le protocole USB.
** Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
** Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
** Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
** Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

===Semaine 10===
*Pour l’équipe du clavier:

Afin de prendre en main la bibliothèque LUFA, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse. 
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque : 
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci, 
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb). 
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche. 
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile. 
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO. 
Un aperçu du Makefile est donné ci-dessous.

[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h 
Note : l'origine de ces erreurs sera expliquée plus tard.

*Pour l'équipe clé USB :
**Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

===Semaine 11===
*Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion. 
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
Ce code sera réalisé en deux étapes : 
- tout d'abord, avec l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher; 
- puis avec une Arduino LEONARDO pour stocker la valeur de ces touches et les envoyer via des instructions. 
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

===Semaine 12===
*Réalisation de la deuxième partie du programme.
Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD. 
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

*Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?.
Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse. 
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur. 
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)". 
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287, 
sudo dfu-programmer at90usb1287 erase

on le reprogramme. 
sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.
sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse (commande lsusb -v).

[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]

===Documents Rendus===
Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet. 
Vous y trouverez notamment les codes des maquettes. 
Il est possible de visualiser le rapport ici : [[Media:Rapport IMA3.2021 P12.pdf]]

===Remarques de l'oral===

Les remarques qui nous ont été faites sont dans un premier temps sur la forme. 
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives. 
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique: 

A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental. 
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

==Projet S7==

===Objectifs de cette année===

Clé USB

réalisation d'un PCB avec l'atméga16u2 pour la gestion de l'USB.

* réaliser le PCB pour intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Clavier

Nous avons pensé à :

* récupérer un clavier existant et faire un keygrabber (PCB avec l'atmega en série/parallèle sur le bus reliant le clavier à l'ordinateur).
Pb parallèle : C'est un cas avec un maître et plusieurs esclaves, qui n'est pas possible pour le protocole USB. 
Pb série : il faudra gérer un permutateur commandé par notre microprocesseur, car l'ATMEGA 16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devront être récupérées et retransmises au clavier par l'ATMEGA. Cela induit une certaine latence. Nous devront donc veiller à respecter le délai de réponse imposé par le protocole.

* récupérer un clavier et mettre notre ATMEGA à la place du micro-processeur du clavier.
Pb : existe-t-il un mappage universel ?

* monter un clavier de toutes pièces.
Pb : demande beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

===liste des tâches et planification===

*harware
**PCB
**routage
**alimentation
**composants
**connecter la matrice du clavier

*software
**décrire l'architecture pour utiliser la bibliothèque LUFA
**rédiger le programme

*autres
**état de l'art pour le keygrabber

===Semaine 1===
-expression plus précise de notre feuille de route.
-Entretient avec les professeurs

===Semaine 2===
===Semaine 3===
===Semaine 4===
===Semaine 5===
===Semaine 6===

===Semaine 7===
===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-04-23T10:30:22Z

Mduquesn :

__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|KeyGrabber USB 16Mo]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

==Réponse à la question difficile==
Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==
*clavier

Concurrent :

Nom du produit :KeyGrabber USB

Société : keelog

URL : http://www.keelog.com/fr/usb-keylogger/

*la clé

Concurrent :

Nom : USB RUBBER DUCKY

Société :hak5

URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
*coté documentation
**maitriser le protocole USB
**maitriser l'utilisation de l'ATMega 16 U2

afin d'être en mesure de créer nos composants

===Clavier===
===Clé USB===

==3.5 Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Clavier===
===Clé USB===

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
*nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposerons d'un dispositif de stockage.
* Recherche des commandes de téléchargement et ouverture d'un fichier sous Windows.
* Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
* Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier). Pour effectuer nos premiers essai avec les cartes arduino, elle est donc d'un importance capitale.

===Semaine 5===
*pour implanter la librairie Keyboard.h, il suffit que arduino IDE soit à jour.
*premiers test avec la-dite librairie.
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
premier Accomplissement avec l'Arduino : on a réussit un KeyboardLogOut sur Windows.

Recherches sur le protocole USB

===Semaine 7===
*création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreur notamment sur les '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
**'"' et '-': le document wordpad sur lequel on avait enregistré les commandes à utilisé dans le shell n'avait pas enregistré ces caractères comme des ascii 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
**'@' et '#': une incohérence entre les les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

===Semaine 8===
Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

===Semaine 9===
*le problème du backslash est résolu, via alt+92.
*Un code Arduino a était crée il utilise le Powershell de Windows afin de télécharger et d'ouvrir une musique.Le code à était par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passé le clavier en mode anglais).
Nous n’avons pas trouvé de solution afin de connaitre l'activité du pc , (même la communication série avec le pc ne nous donne pas les informations voulues ).

===Semaine 10===
Pour l’équipe du clavier:
utilisation de l’Arduino UNO , modification du pilote (utilisation du mode DFU) afin que l'OS reconnaisse l’Arduino en tant que Atmega16u2, et par la suite utilisation de la bibliothèque LUFA.
Pour l'équipe clé USB :
Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage. La seul solution que nous avons trouvé tout en continuant à utiliser l’Arduino Leonardo nous devons faire un Switch physique, car l'interface que propose l’Arduino ne correspond pas à nos besoins (nous souhaitons une ouverture "normal" d'un périphérique , et non l’utilisation de code Arduino pour la gestion de stockage) .

===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-04-23T09:50:03Z

Mduquesn : /* Semaine 9 */

__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|KeyGrabber USB 16Mo]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==
===le clavier===
Le principal cas d’utilisation de ce clavier est la surveillance, légale ou non.

* Surveillance de son propre pc, par exemple pour savoir ce que font ses enfants quand ils sont sur l’ordinateur.
* Récupération de données.

===la clé===
Les cas d’utilisation d’un tel périphérique sont très variés mais ont la même racine : automatiser et accélérer des actions réalisables par un humain via le clavier.

* Utilisable par un réparateur d’ordinateur pour nettoyer un pc, récupérer des données effacées….
* Utilisable par un parent pour placer des logiciels espions, prendre le contrôle de l’ordinateur de son enfant à distance (pour parent très avertis) ...

===la souris===
Les cas d'utilisation de cette souris, en plus des cas normaux d'utilisation en tant que pointeur graphique, correspondent à l'utilisation du mode berserk (activable à distance).

* Empêcher la mise en veille de l'ordinateur.
* Tournois e-sport amateurs (ou familiaux).
* Satisfaire un esprit blagueur.

==Réponse à la question difficile==

Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==
*clavier

Concurrent :

Nom du produit :KeyGrabber USB

Société : keelog

URL : http://www.keelog.com/fr/usb-keylogger/

*la clé

Concurrent :

Nom : USB RUBBER DUCKY

Société :hak5

URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
*coté documentation
**maitriser le protocole USB
**maitriser l'utilisation de l'ATMega 16 U2

afin d'être en mesure de créer nos composants

===Clavier===
===Clé USB===

==3.5 Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Clavier===
===Clé USB===

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===

* Recherche des instructions de téléchargement et ouverture d'un fichier sous Windows.
* Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
* Téléchargement de la lib Keyboard et essai d'implantation pour exécuter une combinaison de touches

===Semaine 5===
*Suite de l'implantation de la bibliothèque Keyboard
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
premier Accomplissement avec l'Arduino : on a réussit un KeyboardLogOut sur Windows.

Recherches sur le protocole USB

===Semaine 7===
Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

===Semaine 8===
===Semaine 9===
*le problème du backslash est résolu, via alt+92.
*Un code Arduino a était crée il utilise le Powershell de Windows afin de télécharger et d'ouvrir une musique.Le code à était par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passé le clavier en mode anglais).
Nous n’avons pas trouvé de solution afin de connaitre l'activité du pc , (même la communication série avec le pc ne nous donne pas les informations voulues ).

===Semaine 10===
Pour l’équipe du clavier:
utilisation de l’Arduino UNO , modification du pilote (utilisation du mode DFU) afin que l'OS reconnaisse l’Arduino en tant que Atmega16u2, et par la suite utilisation de la bibliothèque LUFA.
Pour l'équipe clé USB :
Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage. La seul solution que nous avons trouvé tout en continuant à utiliser l’Arduino Leonardo nous devons faire un Switch physique, car l'interface que propose l’Arduino ne correspond pas à nos besoins (nous souhaitons une ouverture "normal" d'un périphérique , et non l’utilisation de code Arduino pour la gestion de stockage) .

===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-04-23T09:40:33Z

Mduquesn : /* Semaine 9 */

__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|KeyGrabber USB 16Mo]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==
===le clavier===
Le principal cas d’utilisation de ce clavier est la surveillance, légale ou non.

* Surveillance de son propre pc, par exemple pour savoir ce que font ses enfants quand ils sont sur l’ordinateur.
* Récupération de données.

===la clé===
Les cas d’utilisation d’un tel périphérique sont très variés mais ont la même racine : automatiser et accélérer des actions réalisables par un humain via le clavier.

* Utilisable par un réparateur d’ordinateur pour nettoyer un pc, récupérer des données effacées….
* Utilisable par un parent pour placer des logiciels espions, prendre le contrôle de l’ordinateur de son enfant à distance (pour parent très avertis) ...

===la souris===
Les cas d'utilisation de cette souris, en plus des cas normaux d'utilisation en tant que pointeur graphique, correspondent à l'utilisation du mode berserk (activable à distance).

* Empêcher la mise en veille de l'ordinateur.
* Tournois e-sport amateurs (ou familiaux).
* Satisfaire un esprit blagueur.

==Réponse à la question difficile==

Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==
*clavier

Concurrent :

Nom du produit :KeyGrabber USB

Société : keelog

URL : http://www.keelog.com/fr/usb-keylogger/

*la clé

Concurrent :

Nom : USB RUBBER DUCKY

Société :hak5

URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
*coté documentation
**maitriser le protocole USB
**maitriser l'utilisation de l'ATMega 16 U2

afin d'être en mesure de créer nos composants

===Clavier===
===Clé USB===

==3.5 Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Clavier===
===Clé USB===

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===

* Recherche des instructions de téléchargement et ouverture d'un fichier sous Windows.
* Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
* Téléchargement de la lib Keyboard et essai d'implantation pour exécuter une combinaison de touches

===Semaine 5===
*Suite de l'implantation de la bibliothèque Keyboard
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
premier Accomplissement avec l'Arduino : on a réussit un KeyboardLogOut sur Windows.

Recherches sur le protocole USB

===Semaine 7===
Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

===Semaine 8===
===Semaine 9===
*le problème du backslash est résolu, via alt+92.
*Un code Arduino a était crée il utilise le Powershell de Windows afin de télécharger et d'ouvrir une musique.Le code à était par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passé le clavier en mode anglais).

===Semaine 10===
Pour l’équipe du clavier:
utilisation de l’Arduino UNO , modification du pilote (utilisation du mode DFU) afin que l'OS reconnaisse l’Arduino en tant que Atmega16u2, et par la suite utilisation de la bibliothèque LUFA.
Pour l'équipe clé USB :
Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage. La seul solution que nous avons trouvé tout en continuant à utiliser l’Arduino Leonardo nous devons faire un Switch physique, car l'interface que propose l’Arduino ne correspond pas à nos besoins (nous souhaitons une ouverture "normal" d'un périphérique , et non l’utilisation de code Arduino pour la gestion de stockage) .

===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-04-23T09:37:00Z

Mduquesn : /* Semaine 10 */

__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|KeyGrabber USB 16Mo]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==
===le clavier===
Le principal cas d’utilisation de ce clavier est la surveillance, légale ou non.

* Surveillance de son propre pc, par exemple pour savoir ce que font ses enfants quand ils sont sur l’ordinateur.
* Récupération de données.

===la clé===
Les cas d’utilisation d’un tel périphérique sont très variés mais ont la même racine : automatiser et accélérer des actions réalisables par un humain via le clavier.

* Utilisable par un réparateur d’ordinateur pour nettoyer un pc, récupérer des données effacées….
* Utilisable par un parent pour placer des logiciels espions, prendre le contrôle de l’ordinateur de son enfant à distance (pour parent très avertis) ...

===la souris===
Les cas d'utilisation de cette souris, en plus des cas normaux d'utilisation en tant que pointeur graphique, correspondent à l'utilisation du mode berserk (activable à distance).

* Empêcher la mise en veille de l'ordinateur.
* Tournois e-sport amateurs (ou familiaux).
* Satisfaire un esprit blagueur.

==Réponse à la question difficile==

Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==
*clavier

Concurrent :

Nom du produit :KeyGrabber USB

Société : keelog

URL : http://www.keelog.com/fr/usb-keylogger/

*la clé

Concurrent :

Nom : USB RUBBER DUCKY

Société :hak5

URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
*coté documentation
**maitriser le protocole USB
**maitriser l'utilisation de l'ATMega 16 U2

afin d'être en mesure de créer nos composants

===Clavier===
===Clé USB===

==3.5 Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Clavier===
===Clé USB===

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===

* Recherche des instructions de téléchargement et ouverture d'un fichier sous Windows.
* Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
* Téléchargement de la lib Keyboard et essai d'implantation pour exécuter une combinaison de touches

===Semaine 5===
*Suite de l'implantation de la bibliothèque Keyboard
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
premier Accomplissement avec l'Arduino : on a réussit un KeyboardLogOut sur Windows.

Recherches sur le protocole USB

===Semaine 7===
Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

===Semaine 8===
===Semaine 9===
*le problème du backslash est résolu, via alt+92.

===Semaine 10===
Pour l’équipe du clavier:
utilisation de l’Arduino UNO , modification du pilote (utilisation du mode DFU) afin que l'OS reconnaisse l’Arduino en tant que Atmega16u2, et par la suite utilisation de la bibliothèque LUFA.
Pour l'équipe clé USB :
Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage. La seul solution que nous avons trouvé tout en continuant à utiliser l’Arduino Leonardo nous devons faire un Switch physique, car l'interface que propose l’Arduino ne correspond pas à nos besoins (nous souhaitons une ouverture "normal" d'un périphérique , et non l’utilisation de code Arduino pour la gestion de stockage) .

===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-04-23T09:34:11Z

Mduquesn : /* Semaine 10 */

__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|KeyGrabber USB 16Mo]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==
===le clavier===
Le principal cas d’utilisation de ce clavier est la surveillance, légale ou non.

* Surveillance de son propre pc, par exemple pour savoir ce que font ses enfants quand ils sont sur l’ordinateur.
* Récupération de données.

===la clé===
Les cas d’utilisation d’un tel périphérique sont très variés mais ont la même racine : automatiser et accélérer des actions réalisables par un humain via le clavier.

* Utilisable par un réparateur d’ordinateur pour nettoyer un pc, récupérer des données effacées….
* Utilisable par un parent pour placer des logiciels espions, prendre le contrôle de l’ordinateur de son enfant à distance (pour parent très avertis) ...

===la souris===
Les cas d'utilisation de cette souris, en plus des cas normaux d'utilisation en tant que pointeur graphique, correspondent à l'utilisation du mode berserk (activable à distance).

* Empêcher la mise en veille de l'ordinateur.
* Tournois e-sport amateurs (ou familiaux).
* Satisfaire un esprit blagueur.

==Réponse à la question difficile==

Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==
*clavier

Concurrent :

Nom du produit :KeyGrabber USB

Société : keelog

URL : http://www.keelog.com/fr/usb-keylogger/

*la clé

Concurrent :

Nom : USB RUBBER DUCKY

Société :hak5

URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==
Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

==3.2 Cahier des charges des équipes==
===Clavier===
Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*de disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activées via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et désactiver le stockage des entrées clavier.

===Clé USB===
Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion)

==3.3 Choix techniques : matériel et logiciel==
ATMega16 + bibliothèque LUFA
===Clavier===
Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
===Clé USB===
Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

==3.4 Liste des tâches à effectuer==
*coté documentation
**maitriser le protocole USB
**maitriser l'utilisation de l'ATMega 16 U2

afin d'être en mesure de créer nos composants

===Clavier===
===Clé USB===

==3.5 Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Clavier===
===Clé USB===

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===

* Recherche des instructions de téléchargement et ouverture d'un fichier sous Windows.
* Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
* Téléchargement de la lib Keyboard et essai d'implantation pour exécuter une combinaison de touches

===Semaine 5===
*Suite de l'implantation de la bibliothèque Keyboard
*Recherches sur l'utilisation de la bibliothèque LUFA

===Semaine 6===
premier Accomplissement avec l'Arduino : on a réussit un KeyboardLogOut sur Windows.

Recherches sur le protocole USB

===Semaine 7===
Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

===Semaine 8===
===Semaine 9===
*le problème du backslash est résolu, via alt+92.

===Semaine 10===
Pour l’équipe du clavier:
utilisation de l’Arduino UNO , modification du pilote (utilisation du mode DFU) afin que l'OS reconnaisse l’Arduino en tant que Atmega16u2, et par la suite utilisation de la bibliothèque LUFA.
Pour l'équipe clé USB :
Après réflexion afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seul solution que nous avons trouvé tout en continuant à utiliser l’Arduino Leonardo nous devons faire un Switch physique (car l'interface que propose l’Arduino ne correspond pas à nos attente).

===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-03-05T10:25:07Z

Mduquesn : /* Equipe 3 */

__TOC__
 

=I. Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

==Objectifs==
Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

=II. Analyse du projet=

==Analyse du premier concurrent==

[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché : 
Nom du produit : KeyGrabber USB 
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go. 
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit. 
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

==Analyse du second concurrent==

[[Image:USB_Rubber_Ducky.jpg|thumb|KeyGrabber USB 16Mo]]

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY 
Société :hak5

Description général: 
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique. 
Son prix est de 44,99$.

==Positionnement par rapport à l'existant==

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC. 
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

==Scénario d'usage du produit ou du concept envisagé==
*le clavier
Le principal cas d’utilisation de ce clavier est la surveillance, légale ou non.

- Surveillance de son propre pc, par exemple pour savoir ce que font ses enfants quand ils sont sur l’ordinateur.

- Récupération de données.

*la clé
Les cas d’utilisation d’un tel périphérique sont très variés mais ont la même racine : automatiser et accélérer des actions réalisables par un humain via le clavier.

- Utilisable par un réparateur d’ordinateur pour nettoyer un pc, récupérer des données effacées….

- Utilisable par un parent pour placer des logiciels espions, prendre le contrôle de l’ordinateur de son enfant à distance (pour parent très avertis) ...

*la souris
Les cas d'utilisation de cette souris, en plus des cas normaux d'utilisation en tant que pointeur graphique, correspondent à l'utilisation du mode berserk (activable à distance).

- Empêcher la mise en veille de l'ordinateur.

- Tournois e-sport amateurs (ou familiaux).

- Satisfaire un esprit blagueur.

==Réponse à la question difficile==

Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : 
combinaison 1 : activation de l’enregistrement des touches 
combinaison 2 : désactivation de l'enregistrement des touches 
combinaison 3 : renvoie l'historique des touches pressées 
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

==Bibliographie et webographie==
*clavier

Concurrent :

Nom du produit :KeyGrabber USB

Société : keelog

URL : http://www.keelog.com/fr/usb-keylogger/

*la clé

Concurrent :

Nom : USB RUBBER DUCKY

Société :hak5

URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

=III. Préparation du projet=

==3.1 Cahier des charges du groupe==

*coté documentation
**maitrisez le protocole USB
**maitrisez l'utilisation de l'ATMega 16 U2

afin d'être en mesure de créer nos composants

*définir les fonctions cachées de chaque composants
*définir comment activer et désactiver chacune des fonctions

==3.2 Cahier des charges des équipes==
===Equipe 1===
création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Ce clavier doit permettre :
*d'utiliser le clavier normalement.
*d'enregistrer les entrées au clavier.
*disposer de différentes fonctions autour de l'enregistrement des entrées clavier, qui seront activer via une combinaison de touches :
**de récupérer les entrées clavier dans un document texte .
**de vider le stockage des entrées clavier.
**activer et inactiver le stockage des entrées clavier.

===Equipe 2===
création du souris physique avec son microcontrôleur, son capteur infrarouge permettant l'activation du mode berserk, et son driver.

Cette souris doit permettre :
*d'utiliser la souris normalement
*disposer d'un mode berserk qui sera activé par signal infrarouge ou inactivité prolongée.

le mode berserk est un mode durant lequel la souris envoie des informations en mode aléatoire, c'est à dire qui envoie des informations qui ne correspondent pas à ce que perçoive les capteurs de cette souris.

===Equipe 3===
création d'un périphérique du stockage USB doté d'un microcontrôleur permettant, en cas d'inactivité prolongée.

cette clé USB doit :
*pouvoir servir de stockage de masse
*en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer (au choix) :
**l'installation d'un logiciel (espion)

==3.3Choix techniques : matériel et logiciel==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==3.4 Liste des tâches à effectuer==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==3.5 Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Equipe 1===
===Equipe 2===
===Equipe 3===

=IV. Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
===Semaine 5===
===Semaine 6===
===Semaine 7===
===Semaine 8===
===Semaine 9===
===Semaine 10===
===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-02-05T11:45:50Z

Mduquesn : /* Positionnement par rapport à l'existant */

IMA3/IMA4 2018/2020 P12

2019-02-05T11:33:49Z

Mduquesn : /* Analyse du second concurrent */

Fichier:USB Rubber Ducky.jpg

2019-02-05T11:33:06Z

Mduquesn : Composition de l'USB Rubber Ducky

Composition de l'USB Rubber Ducky

IMA3/IMA4 2018/2020 P12

2019-02-05T11:20:19Z

Mduquesn : /* Analyse du premier concurrent */

IMA3/IMA4 2018/2020 P12

2019-02-05T11:18:59Z

Mduquesn : /* Analyse du premier concurrent */

Fichier:Keygrabber 16Mo.jpg

2019-02-05T11:00:45Z

Mduquesn : Image du Keygrabber 16Mo par Keylogger

Image du Keygrabber 16Mo par Keylogger

IMA3/IMA4 2018/2020 P12

2019-02-05T10:53:33Z

Mduquesn : /* Objectifs */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:52:31Z

Mduquesn : /* Description */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:50:24Z

Mduquesn : /* Description */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:47:18Z

Mduquesn : /* Analyse du second concurrent */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:46:03Z

Mduquesn : /* Analyse du premier concurrent */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:45:17Z

Mduquesn : /* Analyse du premier concurrent */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:31:49Z

Mduquesn : /* Analyse du second concurrent */

IMA3/IMA4 2018/2020 P12

2019-02-05T10:17:25Z

Mduquesn : /* Description */

__TOC__
 

=Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
* et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED. 
La fonctionnalité supplémentaire en un enregistrement des touches tapées par l'utilisateur espionné. Le contenu de cet historique sera stocké dans une mémoire interne du clavier et pourra être visualisé et supprimé en ouvrant un lecteur de fichier texte et en entrant la bonne combinaison.

La souris contrôlera le déplacement du curseur et possèdera des boutons. 
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD. 
En cas d'inactivité prolongée, elle émulera un clavier sur le bus et pourra entrer des lignes des codes de télécharger un logiciel de surveillance sur le PC connecté.

==Objectifs==
Notre objectif est de réaliser des périphériques USB artisanaux avec des fonctionnalités supplémentaires.

=Analyse du projet=

==Positionnement par rapport à l'existant==
==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==
==Réponse à la question difficile==
==Bibliographie et webographie==

=Préparation du projet=

==Cahier des charges du groupe==
==Cahier des charges des équipes==
===Equipe 1===
création d'un clavier physique et son driver
===Equipe 2===
création du souris physique et son driver
===Equipe 3===

==Choix techniques : matériel et logiciel==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Liste des tâches à effectuer==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Equipe 1===
===Equipe 2===
===Equipe 3===

=Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
===Semaine 5===
===Semaine 6===
===Semaine 7===
===Semaine 8===
===Semaine 9===
===Semaine 10===
===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-01-29T11:02:07Z

Mduquesn : /* Description */

__TOC__
 

=Présentation générale=

==Description==
Trois périphériques sont envisagés :
*un clavier
*une souris
*une clef USB

Le clavier aura pour fonction de gérer les entrées et quelques LED.
La fonctionnalité supplémentaire consiste en un programme lancé par une combinaison de touches enregistré dans une mémoire interne au clavier. Ce programme sera entièrement paramétrable via le clavier.

La souris contrôlera le déplacement du curseur et possèdera des boutons.
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD.
En cas d'inactivité prolongée, elle émulera un clavier sur le bus et pourra entrer des lignes des codes de télécharger un logiciel de surveillance sur le PC connecté.

==Objectifs==
Notre objectif est de réaliser des périphériques USB artisanaux avec des fonctionnalités supplémentaires.

=Analyse du projet=

==Positionnement par rapport à l'existant==
==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==
==Réponse à la question difficile==
==Bibliographie et webographie==

=Préparation du projet=

==Cahier des charges du groupe==
==Cahier des charges des équipes==
===Equipe 1===
création d'un clavier physique et son driver
===Equipe 2===
création du souris physique et son driver
===Equipe 3===

==Choix techniques : matériel et logiciel==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Liste des tâches à effectuer==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Equipe 1===
===Equipe 2===
===Equipe 3===

=Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
===Semaine 5===
===Semaine 6===
===Semaine 7===
===Semaine 8===
===Semaine 9===
===Semaine 10===
===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-01-29T11:01:57Z

Mduquesn : /* Description */

__TOC__
 

=Présentation générale=

==Description==
3 périphériques sont envisagés :
*un clavier
*une souris
*une clef USB

Le clavier aura pour fonction de gérer les entrées et quelques LED.
La fonctionnalité supplémentaire consiste en un programme lancé par une combinaison de touches enregistré dans une mémoire interne au clavier. Ce programme sera entièrement paramétrable via le clavier.

La souris contrôlera le déplacement du curseur et possèdera des boutons.
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD.
En cas d'inactivité prolongée, elle émulera un clavier sur le bus et pourra entrer des lignes des codes de télécharger un logiciel de surveillance sur le PC connecté.

==Objectifs==
Notre objectif est de réaliser des périphériques USB artisanaux avec des fonctionnalités supplémentaires.

=Analyse du projet=

==Positionnement par rapport à l'existant==
==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==
==Réponse à la question difficile==
==Bibliographie et webographie==

=Préparation du projet=

==Cahier des charges du groupe==
==Cahier des charges des équipes==
===Equipe 1===
création d'un clavier physique et son driver
===Equipe 2===
création du souris physique et son driver
===Equipe 3===

==Choix techniques : matériel et logiciel==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Liste des tâches à effectuer==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Equipe 1===
===Equipe 2===
===Equipe 3===

=Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
===Semaine 5===
===Semaine 6===
===Semaine 7===
===Semaine 8===
===Semaine 9===
===Semaine 10===
===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===

IMA3/IMA4 2018/2020 P12

2019-01-29T10:35:29Z

Mduquesn : /* Présentation générale */

__TOC__
 

=Présentation générale=

==Description==
3 périphériques sont envisagés :
*un clavier
*une souris
*une clef USB

==Objectifs==
Notre objectif est de réaliser des périphériques USB artisanaux avec des sous fonctions.

=Analyse du projet=

==Positionnement par rapport à l'existant==
==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==
==Réponse à la question difficile==
==Bibliographie et webographie==

=Préparation du projet=

==Cahier des charges du groupe==
==Cahier des charges des équipes==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Choix techniques : matériel et logiciel==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Liste des tâches à effectuer==
===Equipe 1===
===Equipe 2===
===Equipe 3===

==Calendrier prévisionnel==
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
===Equipe 1===
===Equipe 2===
===Equipe 3===

=Réalisation du Projet=

==Projet S6==

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

===Semaine 4===
===Semaine 5===
===Semaine 6===
===Semaine 7===
===Semaine 8===
===Semaine 9===
===Semaine 10===
===Semaine 11===
===Semaine 12===

===Documents Rendus===

==Projet S7==

===Documents Rendus===

==Projet S8==

===Documents Rendus===