Nozalys

Dans le cas des voitures, les constructeurs auto devraient être reconnus pénalement co-responsable d'un défaut de sécurisation adéquat. Et le gouvernement Québécois devrait pouvoir les obliger à faire des rappels pour mises à jour du protocole d'échange, avec remplacement des clés. Pour un véhicule dont le coût est en moyenne > 20 k€, il est acceptable, IMHO, de supporter un coût de mise à jour de 100 €, admettons : L'ECU habitacle n'a pas à être remplacé : vu les capacités de calcul débordantes dont il dispose, il pourra sans problème accepter du code cryptographique un peu plus complexe via une mise à jour Le seul coût hardware est celui de la clé, si son microcontrôleur ne peut pas être reprogrammé. En revanche, pour la domotique, ce n'est pas envisageable, car le coût d'un moteur de porte étant en moyenne < 1000 €. Sur ce marché qui plus est, il semble y avoir beaucoup plus d'acteurs exotiques qui cassent les prix et dont les préoccupations de sécurité sont très loin comparé à celles des constructeurs de voiture. Toujours est-il que dans les 2 cas, ça casse la confiance qu'on peut avoir dans ce système omniprésent.

Bonjour, Suite à cet article Next, j'avais décidé de m'acheter un Flipper Zero, au cas où ici aussi, ce genre d'appareil soit interdit à la vente. Depuis que j'ai fait installer une porte de garage sectionnelle, en 2019, je me suis toujours posé la question de la robustesse du protocole d'échange radio pour les télécommandes. Et, à juste titre : dans mon logement précédent, mes voisin d'en face avaient un portail électrique + une porte de sous-sol électrique. Un jour, alors qu'un de mes oncles passait le week-end chez moi, avec sa nouvelle voiture (une Suzuki Swift), on s'est rendu compte que leur portail s'ouvrait et se fermait à chaque appui sur la clé de la Suzuki... Et leur porte du sous-sol s'ouvrait régulièrement sans raison (des interférences ?). Fort de cette expérience, jusqu'ici la seule réflexion que je pouvais me faire c'était : "bah faut espérer que maintenant les systèmes sont sécurisés". Mais j'ai actuellement un voisin qui connait bien le secteur et le métier, pour y avoir travaillé un temps, et qui m'a toujours dit : "si tu savais comme c'est pas fiable"... Car quand on y pense, j'ai beau avoir une porte d'entrée de haute volée, s'il suffit d'un peu de bidouille pour ouvrir mon sous-sol, l'idée n'est pas plaisante. Bref : me voilà équipé d'un Flipper Zero. Et j'ai testé ma porte de garage (et d'autres trucs). Le moteur et les télécommandes sont de marque MAGUISA. Le protocole utilisé est du KeeLoq 64bit. C'est un protocole qui appartient à Microchip, donc facile à intégrer avec des microcontrôleurs pas cher. Le protocole est plutôt bien fichu, mais il date. Et par conséquent, il est aujourd'hui plutôt aisé de le casser dans un temps raisonnable. En 2012, une équipe de chercheurs ont cassé le protocole ... après 8 jours de calcul sur 64 cœurs de CPU, et en étant resté près de 1h40 proche de l'émetteur pour récupérer un "seed" initial. Autant, avec ce type de délai, je me sentirai serein, ça serait réservé à des cibles d'intérêt, ce que je ne pense pas être 🙂 Mais, c'était il y a 12 ans déjà. En 12 ans, la puissance des CPU n'a plus rien à voir. Considérer un facteur 10 est une hypothèse plus que raisonnable, donc je pense qu'aujourd'hui, quelques heures de calcul sur un CPU "accessible" suffiraient. Une autre attaque a été menée par une autre équipe, en 2022, mais en analysant le firmware d'un récepteur, donc ce n'est pas applicable ici. Je n'ai pas installé le firmware alternatif du Flipper Zero, je ne sais pas ce qu'il pourrait faire de plus. Je suis déjà rassuré de voir que le protocole n'est pas juste un rolling code classique, comme celui utilisé par mes volets électriques (Somfy Telis), et je pense qu'il faudrait vraiment chercher quelque chose de particulier pour monter ce genre d'attaque. Qu'en pensez-vous ?

Effectivement, une WU vient d'arriver sur le CPU. ça veut dire quoi ? Qu'ils ont plus de capacité de calcul que de calcul à effectuer en ce moment ?

Bonjour à tous, je suis nouveau sur le projet, je viens de me créer un comte "[inpact]_Nozalys/team 51", mais 'jai comme l'impression que F@H ne télécharge aucune tâche. Dans le panneau "advanced control", GPU & CPU sont bien listés, et 2 tâches sont dans la file d'attente : seulement la première tâche a un Work server & Colleciton server à 0.0.0.0, et la 2ème tâche a un work server à 128.252.203.10 & Colleciton server à 0.0.0.0. J'ai laissé le sélecteur sur "Any disease". J'ai bien ajouté la règle au pare-feu, l'install me l'a demandé. Il faut configurer quelque chose de plus ?

C'est à n'y rien comprendre, car j'utilise VirtualBox 6.1.2, donc ça aurait dû fonctionner sur ma "fresh install" quand j'avais Hyper-V + hypervisorlaunchtype=Auto + les VM de VBox configurées sur "paravirtualisation hyper-V". En tout cas, la nouvelle situation me convient, et si je souhaite utiliser un jour WSL2, je sais où venir chercher l'information 🙂

Ah, désolé, j'ai fait une erreur dans mon sujet -c'est corrigé-, je ne suis pas sous Win 7 mais sous Windows 10 bien évidement, en 1909. Du coup ça aurait dû fonctionner sans modification spéciale

Waou, merci ! Tu as résolu mon problème. Ça fait environ 2 mois que je tourne en rond et je n'ai jamais croisé, dans mes recherches, quelqu'un parler de bcdedit... En l’occurrence, sur mon PC perso, je ne fais pas de dév, donc pas de VS, et je n'utilise pas WSL... qui n'est pas activé non plus.

Bonjour, J'essaie en vain d'utiliser Virtualbox, mais celui-ci n'accepte plus aucune VM que j'avais créée avant la réinstallation totale de mon système il y a environ 1 an. Quand je veux démarrer une VM j'ai l'erreur suivante : VMMR0_DO_NEM_INIT_VM failed // "VT-x is not available (VERR_VMX_NO_VMX)" // Error code E_FAIL (0x80004005) J'ai vérifié dans le BIOS, les options de virtualisation sont pourtant bien activées, voici quelques-uns des paramètres dans la section CPU Features du BIOS : Hyper-Threading: enabled Active Processor Cores: all Limit CPUID Maximum: disabled Intel Virtualization Tech: enabled Intel VT-D Tech: enabled Hardware Prefetcher: enabled Adjust Cache Line Prefetch: enabled CPU AES Instructions: enabled Intel Adaptive Thermal Monitor: enabled Intel C-State: auto C1E Support: disabled Package C State Limit: auto CFG Lock: enabled SW Guard Extensions (SGX): software controlled J'ai suivi un conseil répété à plusieurs endroits sur le web, j'ai désactivé la fonctionnalité Hyper-V de Windows J'ai suivi d'autres conseils comme réduire le nombre de CPU et de RAM alloué à la VM J'ai testé avec 4 types d'O.S. VM : Windows XP, Windows 7, Windows 10, Ubuntu, ainsi qu'avec une nouvelle VM, donc vide. Je suis sous Windows 10 1909 avec un core i7-7700K, 32 GB de RAM, sur une MSI Z270 gaming M5 et ça fonctionnait avant de réinstaller WIndows VirtualBox ne me laisse pas cocher la case "Activer VT-x/AMD-V imbriqué" qui est grisée, dans les paramètres processeur de mes VM. La différence comparé à la situation avant réinstall, c'est que j'ai maintenant un compte admin et mon compte user, pour améliorer la sécurité. Ceci dit, même quand je lancer VirtualBox en mode administrateur, les VM ne démarrent pas. Quelqu'un a-t-il une idée du problème ? Merci, Nozalys