Je suis en pleine expertise informatique. Le magistrat m’a confié un ordinateur, des cédéroms, des disquettes et des clefs USB à analyser. Je sors toute ma panoplie d’outils d’investigation. Me voici enquêteur…
Je procède méthodiquement. Prise d’empreinte numérique avec HELIX à travers le réseau. Prise de notes sur un cahier d’écolier pour décrire chaque étape, tel un Gustave Bémont. Je note le nom du scellé, son numéro, sa description.
Un cédérom, une clef USB, un disque dur… Petit à petit tous les scellés y passent.
Vient le tour d’une petite clef USB sans inscription. Je la place dans ma machine de prise d’empreinte. Elle se met à clignoter. Bien. Seulement voilà, la machine d’analyse (sous Linux) ne voit pas la clef USB…
Ma machine d’analyse est sous GNU/Linux (HELIX) se qui veut dire que quasiment aucun périphérique ne lui résiste: toute la communauté open source se démène pour mettre au point des pilotes permettant d’exploiter tous les périphériques possibles et imaginables.
Par pure réflexe de Windowsien, je redémarre la machine. Toujours rien.
Je commence à transpirer: la clef USB est-elle grillée? Est-ce moi qui l’ai grillée? Aurais-je détruit une pièce à conviction?
J’essaye la clef sur tous les ports USB de tous les PC de la maison avec mon live-CD. Rien.
Je m’assois à mon bureau. Perplexe.
Mon regard tombe sur le cadre dans lequel j’ai placé ce dessin effectué par Monsieur Ucciani en dédicace.
Je prends une grosse loupe et regarde à travers le plastique de la clef USB pour voir si un composant a lâché. Je vois une minuscule inscription presque complètement effacée sur le dessus du plastique: Blue…tooth.
Cela fait une heure que je cherche à analyser le contenu d’une clef USB mémoire, alors que j’ai à faire à une clef USB radio…
Parfois je me félicite de bloguer sous pseudonyme.
$ tail -f /var/log/syslog
$ lsusb
Auraient pu t’aider? Ou bien le kernel ne disait vraiment rien?
@Colin: Mais si, le kernel savait tout! Mais, persuadé d’avoir à faire à une clef USB « normale », je n’ai pas cherché au bon endroit…
« On ne peut pas tout savoir, mais on doit savoir , que l’on ne sait pas tout »
Surtout quand on cherche au mauvais endroit…
Bonsoir (oui ici c’est deja le soir).
Il existe des cle USB encore plus muette. Pas de radio, pas de memoire et bien sur pas d’inscription.
Il s’agit dans ce cas la (probablement) d’un dongle. C’est une cle USB quais inerte qui fonctionne avec un pilote specifique. Ce dongle permet de faire fonctionner un logiciel car elle contient la licence d’utilisation.
Un exemple de cela est le produit que vend La Poste sur cdrom qui contient tous les codes postaux et villes de France. Impossible d’installer la mise a jour sans ce precieux dongle.
@BobCaTT: Je confirme. J’ai dans mes cartons plusieurs « clefs USB » qui n’ont rien à voir avec un support de mémoire: par exemple un décodeur TNT.
Ce qui me fait honte ici, c’est de ne pas y avoir pensé tout de suite, et d’avoir cru à une défaillance de clef mémoire – sans me rendre compte immédiatement que ce n’était pas une clef mémoire…
Et vive la loupe !
Bjr.
Rien n’est lpus traitre qu’un boitier vierge de toute inscription, comme le confirme mon token USB contenant mes certificats SSL qui, si les pilotes ne sont pas présents, ne dit rien du tout. Alors qu’en plus de mes certificats, il y a au moins 64 Ko de RAM libre…. 🙂
Vive les boitiers transparents.
Mon graal pour comprendre ce qui ne va pas avec un périphérique mobile:
sudo udevadm –monitor
Laisser le process tourner, puis plugger la salle bête: udev va cafter tout ce qu’il voit passer au sujet de ce périphérique.
C’est mon arme ultime quand ma patronne vient avec son fameux « c’est nul ça marche pas » et un outil acheté à un vendeur ambulant sans CD…
@ook? ook!
# udevadm –monitor
udevadm: unrecognized option '–monitor'
# udevadm monitor
monitor will print the received events for:
UDEV – the event which udev sends out after rule processing
KERNEL – the kernel uevent