Juste pour le plaisir des yeux, le keyset KAT Milkshake de biipmk sur le clavier mécanique Vortex Tab90M, et dessous, le même clavier avec les touches d'origine (spécifiques à la version ISO-FR).
Multi-head virtualized workstation: the end.
Four years ago I've started a journey in workstation virtualization. My goal at the time was to try and escape Apple's ecosystem as it was moving steadily toward closedness (and iOS-ness). I also though back then that it would allow me to pause planned obsolescence by isolating the hardware from the software.
I've been very wrong.
My ESXi workstation was built with power, scalability and silence in mind. And it had all this for a long time. But about 1.5 year ago I've started to notice the hum of one of its graphics card. Recently this hum turned into an unpleasant high pitched sound under load. The fans were aging and I needed a solution. Problem is, one just can't choose any graphics card off the shelf and put it into an ESXi server. It requires a compatibility study: card vs motherboard, vs PSU, vs ESXi, vs VM Operating system. If you happened to need an ESXi upgrade (from 5.x to 6.x for example) in order to use a new graphics card then you need to study the compatibility of this new ESXi with your other graphics cards, your other VM OSes, etc.
And this is where I was stuck. My main workstation was a macOS VM using an old Mac Pro Radeon that would not work on ESXi 6.x. All things considered, every single upgrade path was doomed to failure unless I could find a current graphics card, silent, that would work on ESXi 5.x and get accepted by the Windows 10 guest via PCI passthrough. I've found one: the Sapphire Radeon RX 590 Nitro+. Worked great at first. Very nice benchmark and remarquable silence. But after less than an hour I noticed that HDDs inside the ESXi were missing, gone. In fact, under GPU load the motherboard would lose its HDDs. I don't know for sure but it could have been a power problem, even though the high quality PSU was rated for 1000W. Anyway, guess what: ESXi does not like losing its boot HDD or a datastore. So I've sent the graphics card back and got a refund.
Second problem: I was stuck with a decent but old macOS release (10.11, aka El Capitan). No more updates, no more security patches. Upgrading the OS was also a complex operation with compatibility problems with the old ESXi release and with the older Mac Pro Radeon. I've tried a few things but it always ended with a no-go.
Later this year, I've given a try to another Radeon GPU, less power-hungry but it yielded to other passthrough and VM malfunctions. This time I choose to keep the new GPU as an incentive to deal with the whole ESXi mess.
So basically, the situation was: very nice multi-head setup, powerful, scalable (room for more storage, more RAM, more PCI) but stuck in the past with a 5 years old macOS using a 10 years old Mac Pro graphics card in passthrough on top of a 5 years old ESXi release, the Windows 10 GPU becoming noisy, and nowhere to go from there.
I went through the 5 stages of grief and accepted that this path was a dead-end. No more workstation virtualization, no more complex PCI passthrough, I've had enough. Few weeks ago I've started to plan my escape: I need a silent Mac with decent power and storage (photo editing), I need a silent and relatively powerful Windows 10 gaming PC, I need an always on, tiny virtualization box for everything else (splunk server, linux and FreeBSD experiments, etc.). It was supposed to be a slow migration process, maintaining both infrastructures in parallel for some weeks and allowing perfect testing and switching.
Full disclosure: it was not.
I've created the Mac first, mostly because the PC case ordered was not delivered yet. Using a NUC10i7 I've followed online instructions and installed my very first Hackintosh. It worked almost immediately. Quite happy about the result, I've launched the migration assistant on my macOS VM and on my Hackintosh and injected about 430 Go of digital life into the little black box. Good enough for a test, I was quite sure I would wipe everything and rebuild a clean system later.
Few days later I started to build the PC. I was supposed to reclaim a not-so-useful SSD from the ESXi workstation to use as the main bare metal PC storage. I've made sure nothing was on the SSD, I've shutdown ESXi and removed the SSD and it's SATA cable. I've also removed another SSD+cable that was not used (failed migration attempt to ESXi 6.x and test for Proxmox). I've restarted ESXi just to find out a third SSD has disappeared: a very useful datastore is missing, 7 or 8 VM are impacted, partially or totally. The macOS VM is dead, main VMDK is missing (everything else is present, even its Time Machine VMDK), the Splunk VM is gone with +60 Go of logs, Ubuntu server is gone, some FreeBSD are gone too, etc.
Few reboots later, I extract the faulty SSD and start testing: different cable, different port, different PC. Nothing works and the SSD is not even detected by the BIOS (on both PCs).
This is a good incentive for a fast migration to bare metal PCs.
Fortunately:
- a spare macOS 10.11 VM, blank but fully functional, is waiting for me on an NFS datastore (backed by FreeBSD and ZFS).
- the Time machine VMDK of my macOS VM workstation is OK
- my Hackintosh is ready even though its data is about a week old
- the Windows 10 VM workstation is fully functional
So I've plugged the Time machine disk into the spare macOS VM, booted it, and launched Disk Utility to create a compressed image of the Time machine disk. Then I've copied this 350 Go dmg file on the Hackintosh SSD, after what I've mounted this image and copied the week worth of out-of-sync data to my new macOS bare metal workstation (mostly Lightroom related files and pictures).
I've plugged the reclaimed SSD into the new PC and installed Windows 10, configured everything I need, started Steam and downloaded my usual games.
Last but not least, I've shutdown the ESXi workstation, for good this time, unplugged everything (a real mess), cleaned up a bit, installed the new, way smaller, gaming PC, plugged everything.
Unfortunately, the Hackintosh uses macOS Catalina. This version won't run many of paid and free software I'm using. Say good bye to my Adobe CS 5 suite, bought years ago, good bye to BBEdit (I'll buy the latest release ASAP), etc. My Dock is a graveyard of incompatible applications. Only sparkle of luck here: LightRoom 3 that seems to be pretty happy on macOS 10.15.6.
In less than one day and a half I've moved from a broken multi-head virtualized workstation to bare metal PCs running up-to-date OSes on top of up-to-date hardware. Still MIA, the virtualization hardware to re-create my lab.
What saved me:
- backups
- preparedness and contingency plan
- backups again
Things to do:
- put the Hackintosh into a fanless case
- add an SSD for Time machine
- add second drive in Windows 10 PC for backups
- buy another NUC for virtualization lab
- buy missing software or find alternatives
Vortex Tab90M, premiers retours
ViBE et Tab90M
Je vous passe les considérations de type "unboxing", le clavier est livré dans une boite en carton ce qui n'est pas une grosse surprise en soi, avec câble USB-A vers USB-C et un jeu de touches colorées. Ce qui impressionne au premier abord c'est le poids. Le Tab90M ISO-FR pèse 1404 grammes. Un kilo quatre cent grammes.
En comparaison, mon clavier mécanique Vortex ViBE ISO-FR avec ses pieds de sur-élévation pèse 808 grammes, et des claviers d'entrée de gamme grand public pèsent entre 400 et 500 grammes. Le Tab90M est aussi 5 bons centimètres plus court qu'un clavier grand public. Le châssis du Tab90M est sensiblement plus épais que celui du ViBE. Sans autre outil de mesure que mes yeux, je dirais qu'il est entre 1,5 et 2 fois plus épais, ce qui contribue à n'en pas douter au poids du clavier ainsi qu'à sa grande rigidité.
Le Tab90M est livré sans pied de sur-élévation, ce qui n'a pas manqué de me causer une certaine déception avant que je remarque que le châssis aluminium est usiné de façon à donner une légère inclinaison au clavier, exactement comme le font les petits pieds vissables sur le ViBE. L'absence de pieds pour sur-élever le Tab90M a un effet secondaire inattendu : posé sur un tapis de bureau le clavier repose alors sur toute sa surface ce qui lui donne une friction très importante avec le tapis. Ainsi il en devient très dur à faire glisser, en comparaison d'un clavier avec pieds, ou d'un clavier plus léger. C'est vraiment surprenant.
L'esthétique de la version ISO-FR peut aussi être une déception quand on a attendu ce modèle plus d'un an en regardant les photos de la version originale ANSI ou même des dérivés ISO-DE ou ISO-NOR. En effet les touches ne sont pas du tout similaires. Celles que l'on retrouve sur la version ISO-FR sont dans un profil DSA et dye sub en thème gris identique au Race 3, au lieu d'un profil VSA et d'un thème kaki double shot. Heureusement je savais à quoi m'attendre.
Pris cote à cote, le Tab90M a beaucoup moins de style ou de classe que le ViBE à mes yeux : il présente une rangée et une colonne de touches supplémentaires et l'écart entre chaque touche est plus étroit ce qui lui donne un aspect moins engageant (106 touches contre 80 pour le ViBE). Par contre le fait de disposer d'un pavé numérique qui n'assure pas en plus les fonctions de navigation (flèches, haut de page, bas de page, etc.) est un confort que je retrouve avec un immense plaisir.
L'utilisation du clavier est agréable, au moins autant que celle du ViBE, même si plus qu'à mon tour je cherche les flèches ou la touche Suppr sur le pavé numérique. Ce n'est qu'une question de temps avant que je reprenne mes marques. Chose assez déroutante : sur Mac OS la touche entrée du pavé numérique n'a pas fonctionné immédiatement alors qu'elle est fonctionnelle sur Windows et FreeBSD. J'ai du basculer le clavier en mode "Mac" (combinaison de touche Pn+z) puis rebasculer en mode "Windows" (Pn+a) et la touche entrée du pavé numérique s'est mise à fonctionner. Autant que je puisse dire cette manipulation n'est à faire qu'une fois.
À l'usage on découvre malgré tout un souci de conception assez problématique : l'absence totale de retour visuel lors de l'activation du verrouillage majuscule (caps lock) ou du verrouillage numérique (num lock). Sur 99,99% des claviers, presser ces touches va activer une diode lumineuse quelque part pour indiquer à l'utilisateur que le verrouillage souhaité est engagé. Ici non, enfin si, mais non. Pour le verrouillage numérique, ce n'est tout simplement pas prévu, la LED n'existe pas. Par contre pour le verrouillage majuscule la LED existe, mais elle est placée sous le switch de la touche et ce dernier n'est pas transparent ! Si bien qu'on peut apercevoir pour peu que le regard ait la bonne inclinaison par rapport aux touches, une très discrète émission lumineuse sortant de quelque part sous les entrailles de la touche Verr. Maj. Je vois deux solutions à ce problème, toutes deux hors de ma portée : tout démonter et dessouder le switch pour le remplacer par un modèle compatible retro-éclairage ou reprogrammer le firmware du clavier pour que le verrouillage majuscule utilise la LED juste à côté qui ne sert qu'à valider les étapes de programmation du clavier.
3 semaines avec le Vortex ViBE
Après avoir utilisé mon nouveau clavier mécanique Vortex ViBE pendant un peu plus de 3 semaines il est temps de faire un petit retour sur l'engin. J'utilise depuis plus de 20 ans des claviers Apple français dont la disposition des touches diffère un peu de celle d'un clavier PC.
Le passage de l'un à l'autre n'est donc pas immédiatement naturel, a fortiori quand on abuse comme moi des raccourcis clavier. La touche maîtresse sur Mac est ⌘, qui est "mappée" sur la touche Win dont la position est inversée avec la touche Alt entre les deux types de clavier. Je me retrouve donc assez régulièrement à tenter des raccourcis clavier "alt-truc" en voulant taper ⌘-truc alors qu'il faudrait que je tape Win-truc (qui sur un clavier Mac donnerait "alt-truc"). C'est très frustrant sur macOS où je passe le plus clair de mon temps, mais pas sur d'autres OS où la touche utilisée pour les raccourcis est ctrl.
Autre aspect un peu pénible : sur un clavier Apple, la touche ⌘ est en deux exemplaires, de part et d'autre de la barre espace. Sur les claviers PC la touche Win n'existe qu'à gauche. Et ça s'est compliqué car la réalisation de certains raccourcis juste avec la main droite n'est plus possible tout en étant parfois trop tendue pour la main gauche, ce qui impose de faire Win avec la main gauche et la lettre ad-hoc avec la main droite. Les utilisateurs PC de longue date n'ont pas forcément ce souci, au moins ils en ont l'habitude et leurs doigts ne cherchent pas un raccourci que jamais ils ne trouvèrent. Dans le même ordre d'idée, l'emplacement du signe moins sur un clavier PC est une calamité incroyable, très hors d'atteinte alors qu'il (me) sert littéralement tout le temps. Sur clavier Apple il est à la place du signe égal à gauche de la touche Retour Arrière ce qui le rends très facile d'accès sans traverser tout le clavier.
Je pourrai continuer un certain temps sur les différences entre clavier Apple et clavier PC. C'est totalement pertinent dans mon vécu quotidien avec le ViBE mais cela concerne sans doute assez peu de gens car j'imagine que la majorité des utilisateurs de ViBE utilisaient déjà un clavier PC auparavant.
L'accès aux touches de fonction en surcouche de la rangée numérique du haut du clavier n'est par contre pas un souci. J'utilise très peu les touches fonction et sur Mac je suis déjà habitué à devoir activer la touche Fn pour y accéder. Simplement ici la touche Fn n'est pas au même endroit que sur Mac.
L'accès aux flèches et autres touches de navigation se fait sur le pavé numérique, immédiatement car par défaut le pavé n'est pas en verrouillage numérique. Cela se fait très naturellement et sans regarder tant leur disposition est proche de ce que l'on trouve sur des claviers étendus classiques. C'est très agréable car ça tombe naturellement sous les doigts.
Ce fonctionnement que Vortex nomme "Tenkeyless mode" (en référence aux claviers TKL) neutralise malheureusement les touches moins, plus et entrée du pavé numérique : moins devient pause, plus et entrée ne font rien. C'est à mon avis un mauvais choix, j'aurais largement préféré que ces touches gardent leur fonction native.
Mais mon vrai souci avec le ViBE c'est l'accès aux chiffres du pavé numérique. Il se fait via le verrouillage numérique : sur Mac il faut presser Fn+Numlock alors que sur les autres OS il faut presser Numlock. Déjà c'est un problème si vous passez d'un OS à l'autre fréquemment, mais ce n'est pas tout. La course des touches est sensiblement plus longue que sur mes claviers Apple Alu, si bien qu'il m'arrive assez fréquemment (tapant trop vite) de rater l'activation soit de Fn soit de Numlock, quand je tape la combinaison de touches (sous réserve que j'ai pensé à le faire). Il y a bien une LED sur le clavier pour indiquer que le pavé numérique est activé, malheureusement elle se trouve sous la touche capslock. Cette touche est totalement masquée à ma vue par ma main gauche quand je suis en position de frappe. Si bien que pour valider le mode de fonctionnement du pavé numérique, je dois faire une pause dans ma frappe, décaler ma main gauche et alors seulement je sais si je vais taper des chiffres ou déplacer mon curseur avec l'autre main.
Cette partie de l'expérience utilisateur n'est pas du tout agréable et de dépit je me trouve parfois à taper des chiffres sur la rangée du haut ce qui est bien plus lent que sur le pavé numérique mais à l'avantage de ne pas envoyer mon point d'insertion de balader si je rate l'activation du verrouillage numérique. Par ailleurs mon utilisation des flèches est aussi très importante (rappel de commandes dans le terminal, sélection des messages dans le webmail du boulot, etc.). Donc impossible de laisser le pavé numérique en Numlock en permanence.
Pour moi c'est une régression sérieuse. Sur un clavier normal je vais pouvoir taper d'une seule traite des chiffres, lettres, positionner mon curseur ou rappeler une commande avec les flèches, etc. Sur le ViBE c'est un vrai saut d'obstacles. Il serait bien plus agréable avoir la LED sous la touche Numlock et que cette dernière soit utilisable directement sur Mac sans recours à la touche Fn. C'est pour moi un vrai problème de conception.
Bref, j'aime bien le ViBE mais j'ai sérieusement hâte d'avoir un Vortex Tab90M sur mon bureau.
Premiers pas sur un clavier mécanique moderne
Compte tenu que mes débuts avec l'informatique, ou tout au moins avec le matériel informatique, remontent à 1985, je ne peux pas réellement parler de premiers pas avec un clavier mécanique. Ici il s'agit par contre réellement de ma première expérience avec un équipement moderne : un clavier VortexGear ViBE en ISO-FR, doté de switches MX silent red. Une bestiole assez rare finalement puisqu'elle a été importée de Taïwan spécialement pour moi, en un seul exemplaire.
Tout d'abord il faut savoir que le monde des claviers mécaniques de bonne facture est riche et varié, plein de formes, de couleurs et de sons qui ont en général pour effet de créer l'addiction chez les gens qui s'y intéressent d'un peu trop prêt. Avant même d'en avoir touché un j'en voulais déjà deux. Mettre un pied dans cet univers c'est aussi découvrir l'attente et la frustration. Certaines pièces rares produites à la demande à l'issue de longues procédures d'achat groupé peuvent se faire attendre plus d'un an.
Moi j'ai presque de la chance, ayant fixé mon dévolu sur une marque puis sur un modèle, j'ai modestement attendu 5 mois. Les modèles ISO-FR étant particulièrement rares, il faut d'abord avoir la chance que le fabricant le propose, ensuite qu'il constitue des stocks, pour finir qu'il daigne vendre et expédier ces stocks.
Je remercie d'ailleurs énormément l'importateur/revendeur français sans qui je n'aurais sans doute jamais pu acheter mon clavier : Gamers Industry.
Un clavier mécanique de bonne facture, correctement construit, avec des matériaux qui tiennent la route, c'est une expérience unique. Tout ou presque peut se choisir pourvu qu'on y mette les moyens : matière, couleurs, typo des touches, profil, switches (linéaires ou pas, silencieux ou pas, durs ou tendres), nombre et disposition des touches, avec ou sans fil, boîtier en plastic, bois ou métal, programmable ou pas, etc.
Celui que j'ai acheté ne démérite pas. Je l'ai choisi sur la base de son look et de la promesse d'une ergonomie originale mais aussi parce qu'il était disponible dans les options que je souhaitais : disposition des touches ISO-FR, avec fil, boîtier métal, switches silencieux. Ce n'est pas un clavier haut de gamme, mais il coûte déjà autour de 155€.
Je me suis imprégné de culture "méca" pendant plus de 6 mois, j'ai beaucoup lu pour prendre la mesure de la chose, connaître les termes et les techno, savoir ce qui est possible et ce qui ne l'est pas et à quel prix. Et c'est finalement une fois que j'ai l'objet sur le bureau, que je m'en sers, que je me confronte à ses qualités et à ses limites que je vis enfin les choses pour de vrai loin du tumulte des forums d'aficionados et des vidéo d'unboxing.
L'expérience en elle même est dure à raconter. Je suis ravi de mon achat, la bête est compacte, trapue, lourde et sa construction lui donne une belle sonorité. Il était primordial pour moi que le clavier soit silencieux. Il l'est absolument comparé à un méca quelconque, mais il reste plus sonore que mon clavier Apple alu. La frappe est très douce grâce à ses switches silent red mais l'ergonomie me comble un peu moins que l'esthétique. Ce n'est pas étonnant : il faudra quelques semaines ou mois d'utilisation avant d'habituer mes doigts à une disposition sur plusieurs couches. Comme je l'avais mesuré, je fais une utilisation non négligeable des flèches de navigation et du pavé numérique. Ici les deux sont sur les mêmes touches physiques et on passe de l'un à l'autre via l'activation d'une couche logique : la touche numlock transforme le pavé numérique en pavé de navigation avec flèches, page-up etc. Pour compliquer les choses sur MacOS c'est Fn-Numlock au lieu de seulement NumLock.
Si le look général du clavier est extrêmement satisfaisant, dans le détail la réalisation pêche parfois. Au nombre des défauts je mentionnerai particulièrement la touche "entrée" du pavé numérique qui était installée à l'envers et dont un des stabilisateurs est grippé. Si bien que si la touche est convenablement enfoncée sur le switch et ses deux stabilisateurs, alors quand on la presse elle reste coincée en position basse. Il suffit de démonter la touche et de la remonter en douceur pour ne pas enfoncer le stabilisateur récalcitrant et tout fonctionne bien. Il aura besoin d'un coup de lubrifiant probablement. Les légendes de certaines touches aussi sont mal alignées, comme la touche 5 du pavé numérique qui est légèrement décentrée. Le signe € ajouté un peu "à l'arrache" sur la touche E n'est pas du tout plaisant à l'œil non plus.
Autre défaut significatif : le clavier probablement fabriqué assez récemment est pourtant livré avec un firmware très ancien qui ne fonctionne pas bien. Il faut donc le mettre à jour dans sa dernière version datant elle-même de plus d'un an. Une fois mis à jour le clavier fonctionne parfaitement.
Moyennant quelques réglages côté système, je suis parvenu à le faire fonctionner à 100% sur OSX et sur FreeBSD, le fonctionnent complet sur Windows 10 étant lui immédiat. Il me reste encore des tonnes de choses à découvrir puisque le ViBE dispose de 4 couches dont 3 sont programmables. C'est à dire qu'il est possible de créer 3 personnalisations complètes du clavier, chacune étant activable par une combinaison de touches et repérée par une led de couleur différente sous la barre espace.
J'ai déjà hâte d'acheter le prochain, sans doute un Vortex Tab 90M dès qu'il sera disponible en ISO-FR, ou un Planck EZ, ou les deux... :)
Moving to Borgbackup
I used to have a quite complicated backup setup, involving macOS Time Machine, rsync, shell scripts, ZFS snapshots, pefs, local disks, a server on the LAN, and a server 450 km away. It was working great but I've felt like I could use a unified system that I could share across every systems and that would allow me to encrypt data at rest.
Pure ZFS was a no-go: snapshot send/receive is very nice but it lacks encryption for data at rest (transfer is protected by SSH encryption) and macOS doesn't support ZFS. Rsync is portable but does not offer encryption either. Storing data in a pefs vault is complicated and works only on FreeBSD.
After a while, I've decided that I want to be able to store my encrypted data on any LAN/WAN device I own and somewhere on the cloud of a service provider. I've read about BorgBackup, checked its documentation, found a Borg repository hosting provider with a nice offer, and decided to give it a try.
This is how I've started to use Borg with hosting provider BorgBase.
Borg is quite simple, even though it does look complicated when you begin. BorgBase helps a lot, because you are guided all along from ssh key management to creation of your first backup. They will also help automating backups with a almost-ready-to-use borgmatic config file.
Borg is secure: it encrypts data before sending them over the wire. Everything travels inside an SSH tunnel. So it's perfectly safe to use Borg in order to send your backups away in the cloud. The remote end of the SSH tunnel must have Borg installed too.
Borg is (quite) fast: it compresses and dedup data before sending. Only the first backup is a full one, every other backup will send and store only changed files or part of files.
Borg is cross-plateform enough: it works on any recent/supported macOS/BSD/Linux.
Borg is not for the faint heart: it's still command line, it's ssh keys to manage, it's really not the average joe backup tool. As rsync.net puts it: "You're here because you're an expert".
In the end, the only thing I'm going to regret about my former home-made backup system was that I could just browse/access/read/retrieve the content of any file in a backup with just ssh, which was very handy. With Borg this ease of use is gone, I'll have to restore a file if I want to access it.
I won't detail every nuts and bolts of Borg, lots of documentation exists for that. I would like to address a more organizational problem: doing backups is a must, but being able to leverage those backups is often overlooked.
I backup 3 machines with borg: A (workstation), B (home server), C (distant server). I've setup borgmatic jobs to backup A, B and C once a day to BorgBase cloud. Each job uses a dedicated SSH key and user account, a dedicated Repository key, a dedicated passphrase. I've also created similar jobs to backup A on B, A on C, B on C (but not Beyoncé).
Once you are confident that every important piece of data is properly backed up (borg/borgmatic job definition), you must make sure you are capable of retrieving it. It means even if a disaster occurs, you have in a safe place:
- every repository URIs
- every user accounts
- every SSH keys
- every repository keys
- every passphrases
Any good password manager can store this. It's even better if it's hosted (1password, dashlane, lastpass, etc.) so that it doesn't disappear in the same disaster that swallowed your data. Printing can be an option, but I would not recommend it for keys, unless you can encode them as QRCodes for fast conversion to digital format.
You must check from time to time that your backups are OK, for example by restoring a random file in /tmp and compare to current file on disk. You must also attempt a restoration on a different system, to make sure you can properly access the repository and retrieve files on a fresh/blank system. You can for example create a bootable USB drive with BSD/Linux and borg installed to have a handy recovery setup ready to use in case of emergency.
Consider your threat model, YMMV, happy Borg-ing.
Cartographie de l’utilisation d’un clavier
Il y a quelques temps je me suis mis en tête d'investir dans des claviers mécaniques de bonne facture. L'exercice va se solder notamment par l'achat d'un Vortex ViBE sur lequel il manque pas mal de touches par rapport à un clavier étendu grand public.
J'ai donc voulu faire un état des lieux de mon utilisation actuelle du clavier étendu dans mes activités privées et professionnelles, raison pour laquelle j'ai investi dans un enregistreur de frappes clavier.
Après environ 3,5 jours d'utilisation de ce keylogger j'ai obtenu un fichier de ~55000 "touches pressées".
J'ai plusieurs options pour exploiter ce fichier : un compte-rendu statistique en chiffres et graphiques ou une cartographie visuelle (heatmap). J'ai choisi la cartographie dans un premier temps pour sa lisibilité immédiate. C'est par contre une option complexe à mettre en œuvre. Il existe différentes pistes pour réaliser une heatmap de clavier sur la base d'un texte fourni par l'utilisateur, mais toutes celles que j'ai trouvées utilisent un clavier réduit et ne proposent pas la disposition AZERTY.
La seule piste viable était donc de trouver une solution libre et ouverte, dans un langage que je comprenne a minima, de sorte que je puisse modifier le programme pour l'adapter à un clavier étendu en français.
J'ai jeté mon dévolu sur Tapmap, petit programme codé en Python 3. La première étape a été de valider que le programme fonctionne sur mon PC sous FreeBSD, après une installation via pip install --user pour épargner mon système. Le test avec un jeu de données bidons ayant été concluant, le plus gros du travail restait à faire. Avant d'attaquer la modification du code de l'application pour étendre la liste des caractères pris en charge j'ai remplacé le fichier keyboard.png représentant un clavier qwerty court par un clavier azerty étendu. Par chance le clavier initial est de marque Apple, ci-bien qu'il est exactement superposable à une image de mon propre clavier. Cela évite d'avoir à refaire toute la correspondance entre un caractère et ses coordonnées physiques sur l'image du clavier. Attention, l'image du clavier doit être en PNG avec une couche alpha, sinon le logiciel ne pourra pas lui superposer la heatmap.
À partir de là il reste le plus dur : faire correspondre chaque caractère enregistré par le keylogger à une zone de pixel sur l'image du clavier. Le programme tapmap est très simple : pour chaque caractère présent dans le fichier en entrée, il cherche une correspondance dans un tableau de coordonnées. Cela impose que chaque caractère qu'on veut représenter soit décrit de manière unique dans la table de correspondance, et que chaque touche qu'on souhaite représenter soit codée par un caractère unique.
De ce constat découlent deux problèmes : le 1 en haut à gauche du clavier doit être traité différemment du 1 du pavé numérique, les codes multi-caractères enregistrés par le keylogger doivent être convertis en caractères uniques. Par exemple quand le keylogger enregistre [1N] il indique que le 1 du pavé numérique a été tapé, quand il enregistre [Sh]1 il indique que la touche majuscule a été pressée pour taper le chiffre 1 en haut à gauche du clavier. Dans le même esprit [Alt][Sh]° représente le caractère ] obtenu par pression sur les touches alt-maj-) du clavier.
Pour palier ces deux problèmes d'un seul coup j'ai converti l'ensemble des codes spécifiques en caractères spéciaux (des lettres grecques en majorité). Ainsi le 1 du pavé numérique ([1N]) devient ρ, le 0 ([0N]) devient π, etc. Via un script shell (juste une grosse commande sed) je transforme le fichier du keylogger en fichier utilisable par tapmap où chaque caractère représente de manière univoque une touche du clavier.
Par de nombreux tests successifs la table de correspondance entre caractères et emplacements sur l'image est complétée avec les spécificités du clavier Apple français, et les touches supplémentaires du clavier étendu. Au final, j'obtiens ces résultats comme synthèse de mes ~55K touches enregistrées :
En fonction du choix de gradient de couleurs la lisibilité est très variable, le second rendu permet par exemple de distinguer bien plus de nuances que les deux autres puisqu'on y aperçoit même les frappes sur le pavé numérique.
En supprimant du fichier source tous les caractères qui ne représentent pas des chiffres il devient possible de comparer l'utilisation du pavé numérique avec l'utilisation des chiffres du haut du clavier :
Dans mon cas le petit doigt de la main gauche appuie sur "maj" et l'index et le majeur atteignent les chiffres de 1 à 5, alors que la main droite se reporte spontanément sur le pavé numérique, que j'utilise aussi systématiquement pour poser des calculs ou taper des adresses IP.
Short review of the KeyGrabber USB keylogger
Few days ago I've bought a USB keylogger to use on my own computers (explanation in french here). Since then, and as I'm sitting in front of a computer more than 12 hours a day, I've got plenty of time to test it.
The exact model I've tested is the KeyGrabber USB MPC 8GB. I've had to choose the MPC model because both my current keyboards are Apple's Aluminum keyboards. They act as USB hubs, hence requiring some sort of filtering so that the keylogger won't try and log everything passing through the hub (mouse, usb headset, whatever…) and will get only what you type.
My setup is close to factory settings: I've just set LogSpecialKeys to "full" instead of "medium" and added a French layout to the keylogger, so that typing "a" will record "a", and not "q".
First of all, using the device on a Mac with a French Apple keyboard is a little bit frustrating: the French layout is for a PC keyboard, so typing alt-shift-( to get a [ will log [Alt][Sh][Up]. "[Up]"? Seriously? The only Macintosh layout available is for a US keyboard, so it's unusable here.
The KeyGrabber has a nice feature, especially on it's MPC version, that allows the user to transform the device into a USB thumbdrive with a key combination. By default if you press k-b-s the USB key is activated and mounts on your system desktop. The MPC version allows you to continue using your keyboard without having to plug it on another USB port after activation of the thumbdrive mode, which is great. You can then retrieve the log file, edit the config file, etc.
Going back to regular mode requires that you unplug and plug back the KeyGrabber.
Applying the "kbs" key combo needs some patience: press all three keys for about 5 seconds, wait about 15-20 seconds more, and the thumbdrive could show up. If it does not, try again. I've not tested it on Windows, but I'm not very optimistic, see below.
I'm using a quite special physical and logical setup on my home workstation. Basically, it's an ESXi hypervisor hosting a bunch of virtual machines. Two of these VM are extensively using PCI passthrough: dedicated GPU, audio controller, USB host controller. Different USB controllers are plugged to a USB switch, so I can share my mouse, keyboard, yubikey, USB headset, etc. between different VMs. Then, the KeyGrabber being plugged between the keyboard and the USB switch, it's shared between VMs too.
Unfortunately, for an unidentified reason, the Windows 10 VM will completely loose it's USB controller few seconds after I've switched USB devices from OSX to Windows. So for now on, I have to unplug the keylogger when I want to use the Windows VM, and that's a bummer. Being able to use a single device on my many systems was one of the reasons I've opted for a physical keylogger, instead of a piece of software.
Worse: rebooting the VM will not restore access to the USB controller, I have to reboot the ESXi. A real pain.
But in the end, it's the log file that matters, right? Well, it's a bit difficult here too, I'm afraid. I've contacted the support at Keelog, because way too often what I see in the log file does not match what I type. I'm not a fast typist, say about 50 to 55 words per minute. But it looks like it's too fast for the KeyGrabber which will happily drop letters, up to 4 letters in a 6 letters word (typed "jambon", logged "jb").
Here is a made-up phrase I've typed as a test:
c'est assez marrant parce qu'il ne me faut pas de modèle pour taper
And here is the result as logged by the device:
cesae assez ma[Alt][Ent][Alt]
rrant parc qu'l ne e faut pa de modèl pour taper
This can't be good. May be it's a matter of settings, some are not clearly described in the documentation, so I'm waiting for the vendor support to reply.
Overall, I'm not thrilled by this device. It's a 75€ gadget that won't work properly out of the box, and will crash my Win 10 system (and probably a part of the underlying ESXi). I'll update this post if the support helps me to achieve proper key logging.