De nos jours, quand un mec chelou avec des lunettes cheloues nous fixe, on ne sait plus si c’est parce qu’il nous trouve irrésistible ou s’il est en train de balancer notre tronche à une IA pour savoir qui on est. Bon, pour vous, la question se pose peut-être moins, mais vous voyez l’idée ^^.

Heureusement, pour lutter contre ça, y’a maintenant un projet open source pour détecter ces petits curieux équipés de Ray-Ban Meta ou d’autres lunettes-caméras. Ce projet s’appelle Ban-Rays (jeu de mots avec “banned”, roh roh roh) et le but c’est de créer des lunettes capables de repérer les smart glasses équipées de caméras.

Et pour arriver à cela, le dev derrière ce projet utilise deux approches complémentaires.

La première, c’est l’approche optique basée sur un principe physique assez marrant. En effet, mes capteurs CMOS des caméras ont la particularité de renvoyer la lumière infrarouge directement vers sa source. C’est ce qu’on appelle l’effet “cat-eye” ou rétro-réflectivité, du coup, en balançant des impulsions IR vers une paire de lunettes suspecte et en analysant le signal réfléchi, on peut théoriquement détecter la présence d’une caméra. Et les capteurs produisent des pics de signal bien nets et rapides, contrairement aux surfaces réfléchissantes classiques qui génèrent des ondes plus longues.

Pour le moment, les tests avec les Ray-Ban Meta montrent des résultats un peu inconsistants à courte distance (genre 10 cm), mais le principe est là et ça s’améliore. Ah oui et le matos utilisé c’est un Arduino Uno, des LEDs infrarouges (940nm et 850nm), une photodiode et un transistor. Rien de bien méchant donc niveau budget.

Et la deuxième approche, c’est côté réseau avec la détection Bluetooth Low Energy. Les Ray-Ban Meta utilisent un identifiant fabricant spécifique (0x01AB pour Meta) et un Service UUID bien particulier (0xFD5F). Le souci c’est que pour le moment, ça ne détecte les lunettes que pendant l’allumage ou le mode appairage. Pour une détection continue pendant l’utilisation normale, faudrait du matos plus costaud genre modules nRF pour sniffer les paquets CONNECT_REQ. Mais bon, ça viendra puisque c’est dans la roadmap du projet.

Alors oui, vous allez me dire que les Ray-Ban Meta ont une petite LED qui s’allume quand elles filment, donc c’est pas discret. En théorie oui auf que cette LED est tellement minuscule que la Data Privacy Commission irlandaise a carrément remis en question son efficacité comme protection de la vie privée. Et surtout, un bidouilleur propose maintenant de désactiver cette LED pour une soixantaine de dollars. Meta a bien prévu une protection qui empêche les lunettes de fonctionner si on couvre la LED avec du scotch, mais le gars a trouvé comment contourner ça et sa liste de clients s’allonge…

Et l’autre truc que j’ai remarqué avec ces lunettes connectées, c’est qu’elles se déclenchent tout le temps pour tout et n’importe quoi. Comme ça écoute en permanence pour répondre aux commandes vocales, impossible d’avoir une conversation normale sans que le machin réagisse à un mot qui ressemble vaguement à “Hey Meta”. C’est encore pire que Siri ou Alexa qui font déjà des déclenchements intempestifs. Perso, c’est pour ça que je ne veux pas de ce genre de lunettes, même si je reconnais que c’est pratique pour photographier ou filmer des choses (dans le cadre de mon boulot hein…)

Et les inquiétudes sont d’autant plus justifiées qu’une étude de 2024 a montré qu’en combinant des Ray-Ban Meta hackées avec de la reconnaissance faciale en temps réel, on pouvait identifier des inconnus dans la rue. Encore plus récemment, l’Université de San Francisco a dû alerter ses étudiants après qu’une personne mystérieuse ait utilisé ces lunettes pour filmer des femmes sur le campus et partager les vidéos en ligne. Sympa l’ambiance de parano.

Bref, si vous êtes inquiet par ça (ou juste soucieux de votre vie privée), le projet Ban-Rays est sur GitHub avec tout le code en C++, Python et un peu de C. C’est encore expérimental mais les deux approches sont prometteuses et si vous voulez contribuer, y’a plein de trucs à améliorer comme les patterns de balayage IR, la fusion des données multi-longueurs d’onde, l’interrogation active BLE…

Source

TwoFace est un outil développé par Synacktiv qui permet de créer des binaires Linux ayant 2 comportements bien distincts. Un comportement parfaitement inoffensif qui s’active dans 99% des cas et un comportement malveillant qui ne se déclenche que sur une machine ciblée spécifiquement pour l’occasion.

Comme ça, votre sandbox verra toujours la version “propre” parce qu’elle n’aura pas le bon UUID de partition.

D’après la doc de Synacktiv, voici comment ça fonctionne : Vous avez deux binaires en fait… Y’en a un qui est inoffensif et un autre malveillant. TwoFace les fusionne alors en un seul exécutable. Ainsi, au moment du build, le binaire malveillant est chiffré avec une clé dérivée depuis l’UUID des partitions disque de la machine cible. Cet UUID est unique, difficile à deviner, et stable dans le temps ce qui est parfait pour identifier une machine spécifique.

Ensuite au lancement, quand le binaire s’exécute, il extrait l’UUID du disque de la machine. Pour ce faire, il utilise HKDF (Hash-based Key Derivation Function) pour générer une clé de déchiffrement depuis cet UUID et tente de déchiffrer le binaire malveillant caché. Si le déchiffrement réussit (parce que l’UUID match), il exécute le binaire malveillant. Par contre, si ça échoue (parce que l’UUID ne correspond pas), il exécute le binaire inoffensif.

Le projet est écrit en Rust et c’est open source ! Et c’est une belle démo (PoC) d’un problème que tous ceux qui font de l’analyse de binaires ont. En effet, d’ordinaire, pour révéler le vrai comportement d’un malware on l’exécute dans une sandbox et on peut ainsi observer en toute sécurité ce qu’il fait, les fichiers qu’il crées, les connexions réseau qu’il établit etc…

Mais avec TwoFace ça casse cette façon de faire. Et c’est pareil pour les antivirus qui verront toujours la version inoffensive tant que l’UUID ne correspond pas.

Techniquement, TwoFace utilise memfd_create() pour exécuter le binaire déchiffré en mémoire, sans toucher au disque, ce qui veut dire zéro trace sur le système de fichiers. Le binaire malveillant apparaît directement en RAM, s’exécute, puis disparaît. Et si vous utilisez io_uring pour l’écriture mémoire, il n’y a même pas de trace syscall visible via strace.

Et ça, c’est la version basique car le document de Synacktiv mentionne également d’autres techniques avancées possibles comme du déchiffrement dynamique page par page du binaire ELF, des mécanismes anti-debugging, des chained loaders multi-niveaux…etc…

Le parallèle avec la backdoor XZ Utils backdoor est très instructif car celle-ci a failli compromettre des millions de serveurs Linux parce qu’un seul mainteneur a poussé du code malveillant dans une lib compressée. Elle a alors été découverte parce qu’un dev a remarqué un ralentissement SSH bizarre et a creusé… Et TwoFace montre qu’on peut faire encore pire sans toucher à la supply chain.

Pas besoin de corrompre un mainteneur de projet, de pousser un commit suspect chez Github. Là suffit d’écrire du code parfaitement propre, de le compilez avec TwoFace pour une machine spécifique, et de le déployez. Le code source sera alors auditable ainsi que le binaire mais l’audit ne révèlera rien parce qu’il se fera dans un environnement qui n’aura pas le bon UUID.

Après, techniquement, une défense existe. Vous pouvez par exemple détecter les appels à memfd_create(), monitorer les exécutions en mémoire, tracer les déchiffrements crypto à la volée…etc., mais ça demande du monitoring profond, avec un coût performance non-négligeable. Et ça suppose aussi que vous savez ce que vous cherchez…

Bref, si ça vous intéresse, c’est dispo sur GitHub !

AI error leads police to handcuff teen after mistaking Doritos for a gun, raising new concerns over ethics in school surveillance systems.

The post AI Misfire: Teen Handcuffed After AI Mistakes Doritos for Gun appeared first on TechRepublic.

Ce serait cool non, si on pouvait transformer n’importe quelle lampe de bureau en détecteur de deepfakes, non ?

Car le problème avec les deepfakes aujourd’hui, c’est qu’on court constamment après les faussaires. Ils ont accès aux mêmes vidéos authentiques que nous, aux mêmes outils d’édition ultra-sophistiqués, et l’IA apprend tellement vite qu’elle produit des faux quasi-indétectables. Il leur est donc très facile de reprendre une vraie vidéo et de la trafiquer légèrement pour manipuler les opinions.

Il faudrait donc une sorte de bouclier anti-manipulation-IA pour empêcher toute manip ultérieure d’une captation vidéo. Et bien c’est exactement ce que viennent de réussir des chercheurs de l’université Cornell, et leur technique est brillante… sans mauvais jeu de mots, vous me connaissez ^^.

Abe Davis, à gauche, professeur adjoint d’informatique au Cornell Ann S. Bowers College of Computing and Information Science, et Peter Michael, étudiant diplômé.

Comme l’explique Abe Davis de Cornell : “La vidéo était considérée comme une source de vérité, mais ce n’est plus une hypothèse qu’on peut faire”. Donc, plutôt que de jouer éternellement au chat et à la souris avec la connerie des gens et le talent des faussaires, l’équipe de Cornell a eu une idée géniale : Et si on marquait les vidéos dès leur création, avec un code secret planqué dans la lumière elle-même ?

Leur technologie, baptisée NCI pour “noise-coded illumination”, fonctionne en ajoutant des fluctuations microscopiques à l’éclairage. Ces variations sont totalement invisibles à l’œil nu car votre cerveau les interprète comme du bruit lumineux normal. Mais une caméra, elle pourra tout capter.

Le truc vraiment cool, c’est que chaque source lumineuse peut avoir son propre code secret comme ça vous pouvez programmer votre écran d’ordinateur, vos lampes de bureau, même l’éclairage d’une salle de conférence entière. Et pour les vieilles lampes qui ne sont pas connectées, une simple puce de la taille d’un timbre-poste suffit à les transformer en watermark lumineux.

Mais ensuite, comment ça détecte les fakes ? Et bien c’est là que ça devient vraiment intéressant car le watermark enregistre en permanence une version basse résolution de ce qui se passe sous cet éclairage, avec un horodatage. Les chercheurs appellent ça des “code videos”. Ainsi, quand quelqu’un manipule la vidéo, que ce soit pour insérer un deepfake, changer la vitesse, ou ajouter des éléments, les parties modifiées ne correspondent plus aux code videos. C’est comme si la lumière gardait un registre secret de tout ce qui s’est vraiment passé.

Comme ça, si un petit malin essaie de générer une fausse vidéo avec l’IA à partir d’une vraie vidéo, les code videos ressembleront alors à du charabia aléatoire, ce qui trahira immédiatement la supercherie. Et même si le faussaire connaît la technique et arrive à décoder les codes secrets, il devrait falsifier chaque code video séparément, et s’assurer qu’ils correspondent tous parfaitement entre eux. Autant dire que c’est mission impossible.

Peter Michael, l’étudiant qui a mené les travaux, a présenté cette innovation au SIGGRAPH 2025 à Vancouver et les tests sont vraiment impressionnant car la technique résiste aux compressions vidéo agressives, aux mouvements de caméra, aux flashs, et fonctionne même en extérieur avec différents tons de peau.

Pendant ce temps, la course à l’armement anti-deepfake continue. Le MIT a son projet Detect Fakes actif depuis 2020. Microsoft a son Video Authenticator qui analyse les pixels pour détecter les anomalies. Intel mise sur son FakeCatcher qui atteint 96% de précision en détectant les variations de flux sanguin dans les vidéos (parce que oui, même les meilleurs deepfakes n’arrivent pas encore à reproduire parfaitement les micro-changements de couleur de la peau dus à la circulation sanguine).

Reality Defender, de son côté, utilise une approche multi-modèle qui n’a pas besoin de watermarks préalables. Ils analysent images, vidéos, audio et texte en temps réel pour repérer les manipulations… C’est impressionnant, mais ça reste une approche défensive qui court après les faussaires et n’empêche pas leur “travail”.

Et c’est ça qui rend la solution de Cornell vraiment prometteuse… C’est parce qu’elle est proactive. Plus besoin d’analyser après coup si une vidéo est truquée puisque la preuve d’authenticité est encodée dedans dès le départ. On pourrait sécuriser comme ça des salles de presse équipées de ce système, des interviews officielles protégées par défaut, ou même le siège de l’ONU avec un éclairage anti-deepfake intégré.

Bien sûr, ce n’est pas la solution miracle et Davis lui-même admet que “c’est un problème qui ne va pas disparaître, et qui va même devenir plus difficile” car les faussaires trouveront de nouvelles parades, c’est certain. Mais pour l’instant, cette technologie donne une longueur d’avance cruciale aux défenseurs de la vérité.

Qui aurait cru qu’on combattrait les deepfakes avec une simple lampe de bureau ??

Source

Neo dans Matrix avait le choix entre pilule rouge et bleue et nous, c’est entre fermer les yeux sur les domaines qui s’inspire des nôtres pour nous voler du trafic, ou ouvrir dnstwist et voir jusqu’où va le terrier du lapin.

Après avoir testé plusieurs scanners anti-phishing qui promettent monts et merveilles, j’étais sceptique, mais dnstwist fait partie des rares qui tiennent leurs promesses. J’ai lancé un scan sur korben.info pour voir ce que ça donnait, et là… 434 permutations générées, 19 domaines déjà enregistrés ce qui est pas mal pour un site qui existe depuis des temps immémoriaux ^^.

ThreatDown 2024 Report: Malwarebytes reveals ransomware trends, showing most attacks occur at night when security staff are off duty.