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 ?

Bonsoir, Après avoir fouillé un peu partout dans les options de OBS et sur des forums de nginx, je n'ai pas réussi à diminuer la latence de mon stream ni à améliorer sa qualité. J'ai renvoyé mes boîtiers d'acquisition VGA USB, pourtant très bien pensés, mais inexploitable dans mon cas d'usage. Ma tentative de Proof of concept à échoué .

Mais tu utilise OBS en mode streaming (puis tu récupère le flux via un autre logiciel pour l'enregistrer dans un fichier), ou bien tu utilise OBS directement en mode record ? Parce que depuis la fenêtre d'OBS, il n'y a aucun lag ni drop par rapport à mes sources (je teste avec une webcam). Pour moi ça vient vraiment du côté serveur/client. La prochaine fois que je retourne sur site, j'essaierais ma configuration OBS/Nginx/VLC sur un PC du boulot pour savoir déjà si c'est mon PC perso qui complique les choses ou pas.

Hello, voilà où j'en suis avec vos excellentes suggestions : VLC : Si VLC utilise bien l'accélération matérielle pour décoder du contenu, il semble impossible de l'utiliser pour transcoder un live. En tout cas c'est le CPU qui bosse, pas le GPU via nvenc. La qualité du live est excellente, mais avec un lag identique, du genre 10 secondes et des frame drop à gogo. (malgré un CPU utilisé à 30%, donc avec de la marge). Nvidia Gforce experience est un service réservé au streaming de jeux. Il semble exclusivement dédié au straming vers les plateformes (FB/Twitch/Youtube) et nécessite un compte en ligne. Il ne semble donc pas pouvoir fonctionner hors ligne en LAN uniquement. Vu la confidentialité des écrans (appareils de mesure dans un milieu industriel), j'écarte l'option. Shoutcast semble exclusivement fait pour de l'audio, et on n'en a pas du tout (vidéo uniquement). Il reste la piste de Icecast que je vais tester à présent. EDIT: En fait, malgré la mention de support vidéo sur la page d’accueil de Icecast ("Icecast is a streaming media (audio/video)") il semble ne posséder aucune fonctionnalité pour streamer autre chose que de l'audio. Je précise aussi que mes sources vidéo sont vraiment très peu gourmandes en bande-passante : Les instruments de mesure ont des sorties vidéo VGA de 3 type seulement : 640x480 px 800x600 px 1920x1080 px mais dont le contenu utile n'est que de 800x600 px, le reste étant une bordure noire. 10 à 15 images par secondes suffisent largement (avec l'actuelle solution on limite même à 5 FPS souvent pour économiser de la bande-passante), car ce qu'on visualise n'est pas de la vidéo mais des signaux comme sur un oscilloscope. Maintenant, si on peut brancher 4 sources vidéos sur un même PC il y a 2 options : soit je crée 4 flux distincts, soit je crée un flux unique (avec OBS par exemple), dans lequel je divise le canva en 4 pour y incruster les 4 sources.

Très bonne suggestion, c'est vrai que VLC propose de diffuser du contenu. Je vais tester ça !

Je viens de tester avec un autre PC et je suis étonné du résultat. La latence est toujours présente dans le même ordre de grandeur, mais j'arrive à voir des bribes de vidéos de 1 ou 2 secondes au lieu d'avoir juste des images fixe. Je ne comprends pas pourquoi la lecture sur le même PC poserait problème. Même si le lecteur utilise l'accélération matérielle, le GPU reste sous les 20% d'utilisation. Qui plus est, il reste sur une fréquence GPU "2D" de 607 MHz, il ne switche même pas sur 1200 ou 1900 MHz. Dans les différents paramètres de nginx.conf que j'ai trouvé dans les différents tutos et topic sur le sujet, je n'ai pas trouvé grand chose. Les tutos sont plus souvent fait pour une application "live" et pas "stream", et bien que je ne saisisse pas la différence entre les 2, il semble que ça ne se comporte pas tout à fait pareil. J'ai vraiment l'impression que ce sont les lecteurs qui ne prennent pas la peine de se fournir en permanence des données ou que le serveur nginx ne les mette pas à disposition en permanence. OBS n'est effectivement pas capable de streamer en local, il ne possède pas de serveur RTMP. Il ne sert que de source du flux, c'est pour ça qu'un serveur comme Nginx est requis.

Bonjour, Je précise que je ne suis pas du tout un pro dans le domaine qui n'est pas le mien. Mais j'essaye d'être force de propositions sur toute la partie IT de mon équipe. Dans le cadre de mon travail, je cherche à mettre au point un démonstrateur de streaming vidéo sur un réseau local. Le but est d'étudier étudier la faisabilité technique d'une solution de remplacement à des boîtiers de streaming hardware tels que ceci https://www.epiphan.com/products/vgadvi-broadcaster/ et https://www.epiphan.com/wp-content/uploads/2014/07/epiphan-vga2ethernet-brochure.pdf (legacy). Nous avons plusieurs boîtiers de ce type depuis quelques années mais leur fiabilité commence à nous décevoir, et le prix ne cesse d'augmenter (1200 € en 2015, 1600 € en 2018, 2000 € en 2021...). Le but de ces boîtiers est de pouvoir avoir un affichage déporté de l'écran de divers appareils de mesure (qui disposent de sorties VGA), avec la latence la plus faible possible. La latence fournie par ces appareils Epiphan sont de l'ordre de 300 ms avec les anciens produits et 1 à 3 secondes avec les nouveaux (flux RTSP). La latence espérée est en-dessous de la seconde pour pouvoir travailler dans de bonnes conditions. Les consommateurs du flux seront toujours dans le même sous-réseau, et l'infrastructure réseau nous permet d'avoir plusieurs dizaines de flux à 2 ou 3 Mo/s sans congestion. J'ai donc fait l'acquisition de quelques boîtiers d'acquisition VGA USB (~50 €), et je me suis mis gaiement à me documenter et expérimenter OBS et NGinx. Ma machine de test (PC perso) dispose d'un i7 7700k bien O/C, d'une GTX 1080 et de 32 Go de RAM. De quoi être à l'aise avec ce que je lui demande. Le streaming OBS est configuré pour utiliser l'encodage matériel du GPU (NVENC) à un débit entre 5500 kbps et 10000 kbps. Lorsque j'active le streaming, le CPU est chargé à 6 %, le GPU à 15 %, et je peux monitorer la charge sur le réseau (localhost) avec NetLimiter qui se situe entre 700 Ko/s et 1,2 Mo/s. Bref il y a de la marge partout et aucun bottleneck en vue. Mon problème arrive quand je veux lire le stream, depuis ce même PC : Que ça soit avec VLC ou ffplay, la lecture est catastrophique. La vidéo se contente d'avoir 1 ou 2 images toutes les 15 à 20 secondes, avec une latence compriss entre 10 et 30 secondes ! L'audio est à peu près correct (peu de coupures) mais avec ce même délai. Je vois en effet que VLC & ffplay ne vont pas chercher le flux en permanence. Quand je regarde leur activité réseau, ils se permettent de fluctuer quelques secondes entre 50 Ko/s et 900 Ko/s, et ils font des pauses de 1 à 3 secondes à zéro ! Via VLC j'ai désactivé le network-caching (0 ms), et avec ffplay j'ai utilisé ces paramètres : ffplay -rtmp_buffer 0 -rtmp_live live rtmp://127.0.0.1:1935/stream/test Que puis-je faire d'autre ? Comment se fait-il que la latence ne soit pas quasi-nulle entre le rendu d'OBS et le lecteur sur la même machine ? Est-ce que c'est Nginx qui ne délivre pas toute la bande-passante demandée par le lecteur, ou ce sont les lecteurs qui sont incapable de faire mieux ?

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