Version du 31 janvier 2020 à 08:25 (voir la source) Rguillom (discussion | contributions) (→‎3.4 Liste des tâches à effectuer) ← Modification précédente		Version du 31 janvier 2020 à 08:26 (voir la source) Rguillom (discussion | contributions) (→‎3.5 Calendrier prévisionnel) Modification suivante →
Ligne 158 :		Ligne 158 :
	Nous devrons également nous documenter sur le protocole USB et l'utilisation de l'ATMega16U2.		Nous devrons également nous documenter sur le protocole USB et l'utilisation de l'ATMega16U2.
−	==3.5 Calendrier prévisionnel==	+	==3.5 Calendrier prévisionnel par semestre==
−	*Protocole USB : Semestres 6 et 7	+	Protocole USB : Semestres 6 et 7 <br>
−	*Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7	+	Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7 <br>
−	*Maquettes Arduino : Semestre 6	+	Maquettes Arduino : Semestre 6 <br>
−	*Modélisation des PCB et des coques (clavier et clé) : Semestre 7	+	Modélisation des PCB et des coques (clavier et clé) : Semestre 7 <br>
−	*Rédaction du code : Semestre 7 et 8	+	Rédaction du code : Semestre 7 et 8 <br>
−	*Montage des périphériques : Semestres 7 et 8	+	Montage des périphériques : Semestres 7 et 8 <br>
−	*Implémentation : Semestre 8	+	Implémentation : Semestre 8
	=IV. Réalisation du Projet=		=IV. Réalisation du Projet=

---

Version du 31 janvier 2020 à 08:26

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

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

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/

... et 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 dans lequel 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.

Tout en permettant une utilisation classique, ce clavier devra assurer un enregistrement des entrées. Les fonctions inhérentes, activées via une combinaisons de touches, sont
- de récupérer les entrées clavier dans un document texte,
- de vider le stockage des entrées clavier,
- et d'activer et de 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 et, 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

Objectifs

L'objectif du semestre 6 est de réaliser des prototypes de nos périphériques avec Arduino.
L'objectif final est de faire fonctionner le tout avec nos propres PCB avec un ATMega16U et la 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

Du côté de la réalisation des prototypes nous devrons réaliser un hardware qui permette d'avoir un prototype fonctionnel et les codes relatifs au fonctionnement des prototypes.

Nous devrons également nous documenter sur le protocole USB et l'utilisation de l'ATMega16U2.

3.5 Calendrier prévisionnel par semestre

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

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

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

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

Documents Rendus

Voici un lien vers le 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 devrons 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 tuteurs
• - 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éfléchir 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 broches (24) alors que notre clavier seul en demande déjà 26.

Le nombre de broches 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)

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.

Tableau

Série	Modèle	Nombre de pins utiles
AT32	AT32UC3B064	44
	AT32UC3B0128	44
	AT32UC3B0256	44
	AT32UC3B0512	44
AT90USB	AT90USB646	46
	AT90USB647	46
	AT90USB1286	46
	AT90USB1287	46
ATXMEGA	ATXMEGA16A4U	34
	ATXMEGA32A4U	34
	ATXMEGA64A4U	34
	ATXMEGA64A4U	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 le microcontrôleur en l'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 peut être inférieure ou égale à 16MHz.

Semaines 6 et 7

• 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ée à un ATmega.
  

La référence est : [1]

• Nous devons également choisir un convertisseur de tension de 5V vers 3,3V pour l'alimentation du microcontrôleur et de la mémoire flash.

Pour cela, nous avons estimé grossièrement un courant de consommation maximal de notre PCB à 250mA.
Nous trouvons sur les catalogues le LM3670MF-3.3/NOPB (tension d'entrée entre 2,5V et 5,5V, courant de sortie jusqu'à 350mA).

• Les principaux éléments retenus, communs au clavier et à la clé USB sont donc
  

le microcontrôleur ATXMEGA16A4U (34 broches I/O, protocole USB et interface SPI (Serial Peripherical Interface), fréquence 32Mhz)
la mémoire MX25R6435FM2IL0 (type flash , taille 64 Mbits , fréquence maximale de 33Mhz , communication SPI) et le convertisseur de tension LM3670MF-3.3/NOPB.

Soutenance de fin de S7

Voici une liste des principales remarques et questions évoquées lors de notre soutenance. Il y a un manque de recherche et de connaissance de l'existant au sujet du clavier. Pourquoi n'avons nous pas cherché des claviers faits maison ? Il nous a été demandé de d'étudier l'utilisation de l'atmega32U4 du projet d'un site web [2] et d'expliquer pourquoi ce cas-là ne convient pas à notre projet.

Pourquoi voulons nous utiliser une architecture AVR ? Nous aurions dû regarder les possibilités de faire autrement. M. VANTROYS citait l'utilisation d'un STM32.

Nous avons trop peu communiqué sur la clé USB et la taille de mémoire pour la clé est insuffisante (64Mbit).

Réponses aux questions de la soutenance

Discrimination de l'ATMEGA32U4

Les différents tutoriels que l'on peut trouver sur Google utilisent un ATMEGA32U4. Dans notre cas, l'utilisation de ce micro-contrôleur ne convient pas pour le clavier.
Pour commencer, nous avions le choix entre trois claviers (deux de marque Dell, et un de marque Kraken). Le choix s'est porté sur le Kraken car les trois claviers ont 26 broches d'entrées et sorties et le clavier kraken est celui qui dispose du plus d'espace pour la incorporer notre PCB.

De plus, nous avons donc besoin de 26 broches entrées/sorties, uniquement pour le mappage du clavier. L'ATMEGA32U4 ne dispose que de 26 broches dont 20 sont utilisées pour le clavier dans les exemples que l'on peut trouver. Parmi elles, trois broches sont consacrées à l'interface SPI. Un si faible nombre de broches par rapport à notre clavier s'explique par le type de clavier utilisé pour leur projet, qui ne contient ni pavé numérique, ni flèches de navigation.

Une piste est de limiter le nombre de broches utilisées en ne rendant fonctionnel que la partie alphanumérique principale du clavier (pas de pavé numérique ni de flèches de navigation). Cependant le mappage du clavier Kraken n'est pas conçu par région et cette partie alphanumérique est mappée sur l'ensemble des 26 broches entrée/sortie (voir le scan code de notre clavier).

Dans le cas où toutefois nous souhaitons utiliser l'ATMEGA32U4 pour le clavier, il nous faut réduire d'au moins trois le nombre de pins du microprocesseur nécessaires. Pour ce faire, nous pouvons utiliser des démultiplexeurs/décodeurs. Nous voulons que ces démultiplexeurs sortent un état haut sur la broche sélectionnée et un état bas sur les autres broches. Malheureusement les multiplexeurs trouvés font l'inverse. Il faut donc rajouter des portes non en sortie des démultiplexeurs. Le clavier étant mappé en 8 broches par 18, deux choix s'offrent à nous : utiliser comme entrées le groupe de 8 broches (permet de gagner 5 pins), ou celui de 18 broches (permet de gagner 13 pins). Si nous choisissons le groupe de 8, nous aurons besoin d'un décodeur/démultiplexeur "3 vers 8" et deux unités de portes "non" 14 broches. Si nous choisissons le groupe de 18, nous aurons besoin de trois décodeurs/démultiplexeurs "3 vers 8" et six unités de portes "non" 14 broches. Mais cette dernière solution implique un routage plus complexe.
Voilà pour la partie électronique, maintenant intéressons-nous aux prix. Les solutions utilisant l'ATMEGA32U4 coûtent 3.45€/unité de microprocesseur (chez Farnell), auxquels il faut additionner 1.5€/25 unités de décodeurs (chez RS, 1 unité nécessaire pour 8 entrées clavier), et 1.25€/25 unités de portes "non" (chez RS, 2 unités nécessaires par démultiplexeur), soit un total de 6.20€. La solution utilisant l'ATXMEGA16A4U n'a pas besoin de décodeurs ou démultiplexeurs. Elle coûte donc 2.64€/unité (chez Farnell) de microprocesseur.

Il nous revient donc également moins cher d'utiliser l'ATXmega16A4U pour la clé USB en comparant le prix des deux microcontroleurs seuls.

Pourquoi voulons nous utiliser un microprocesseur avec une architecture AVR ?

Ce choix est conditionné par l'utilisation de LUFA. Il nous a été suggéré d'utiliser cette bibliothèque afin de limiter le travail de programmation dû au protocole USB. De plus, l'an dernier nous avions déjà fait des recherches sur cette bibliothèque, et nous l'avons utilisée en tutorat de systèmes.

Taille de la mémoire pour la clé USB

Elle n'est pas pertinente et est trop limitée par l'utilisation d'une interface SPI. Nous devons mieux explorer les différents types de mémoires et en trouver une mieux adaptée à notre projet.

Documents Rendus

Projet S8

Semaine 8

Semaine 9

Semaine 10

Semaine 11

Semaine 12

Semaine 13

Semaine 14

Semaine 15

Semaine 16

Semaine 17

Semaine 18

Semaine 19

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