Cette chaine vous propose de nombreux contenus basés sur les radiocommunications PMR (Professional Mobile Radio).
Vous y trouverez notamment des vidéos sur : - Les normes numériques (DMR, dPMR, NXDN, TETRA, TETRAPOL...) - Le fonctionnement des radios (Motorola, Hytera, Icom, TYT, AnyTone...) - La sécurité des réseaux (chiffrement, cryptage/décryptage...) - La décodage SDR (Software Defined Radio) en utilisant SDRSharp et DSD (Digital Speech Decoder) - La technique radio en général
Retrouvez-nous sur : Notre site Internet : www.1geniesup.fr Twitter : twitter.com/LouisErigHerve LinkedIn : www.linkedin.com/in/louiserigherve/ GitHub : github.com/LouisErigHerve
Pour tout prise de contact ou demande de renseignements, merci de privilégier LinkedIn : www.linkedin.com/in/louiserigherve/
Si t'as moyen de configurer un proxy via le CPS pour le redescendre sur ta radio, il y a peut être moyen de déchiffrer les trames TLS. Je dis peut être car il n'est pas exclu que Motorola ai intégré des sécurités supplémentaires (SSL pinning, Nonce...). En revanche ça pourrait être intéressant de récupérer le binaire qui est envoyé OTA sur les devices et d'essayer de le reverse pour essayer de retrouver les requêtes en question et savoir exactement ce qu'il envoie sur Azure.
Pour info... Il suffit de rouvrir le nouveau codeplug dans "l'ancien" CPS 3.02 et les clés sont de nouveau parfaitement visibles... Il est aussi possible d'utiliser la fonction d'export du CPS 3.02 pour obternir le CSV avec toutes les clés d'encryptions qui sont réimportables dans le CPS 3.03.
Bjr Louis- Erig dans la vidéo "Expérience amusante avec SDRSharp + clef USB RTL-SDR : Le repliement de spectre" vous demandez de relater nos expériences... mais les commentaires sont désactivés ... Donc....
Est ce que ça veut dire que le poste connecté peut être neutralisé à distance sans intervention du propriétaire et "contaminer" les autres postes, y compris si ceux-ci ne sont pas connecter en WIFI? S' agissant d' un matériel qui peut être impliqué dans le domaine de la sécurité ou du secours, ça me laisse perplexe...
Franchement Motorola en a rien a foutre de ce que disent les gens sur leurs appareils, par contre motorola a offert une technologie et des moyens pour l'etat, les flics, les SS (services secrets) de faire de l'espionnage... Marre d'entendre que ce sont les marques qui espionnent le plus, ceux qui espionnent le plus sont tous les petit agents de la komandantur aux ordres de l'etat!!!!
Parceque l'europe dont la France et surtout Israel avec leur logiciel pegasus sont des parfaits gentils incapables de faire de l'espionage??? Mais tous ces pays oxydentaux moisis espionnent bien plus leurs habitants que ceux des autres pays... Nos dirigeants francais sont mis sous surveillance massive technologiquement!!! En coree du nord c'est tehnologiquement moins pire c'est dire...
Je possède un EADS THRI9 ET je n'arrive pas à trouver le logiciel pour le paramètrer et l'activer et apparemment il faut un DONGLE AVEC LE LOGICIEL. TU serais pas où je pourrais trouver le logiciel merci pour la réponse 😅 73 Le logiciel est pas LE LOGICIEL TÉTRA MAIS LE LOGICIEL TETRAPOL😊 😊😊
Salut, pourrais-tu faire des vidéos sur les solutions cryptographiques pour éviter les injections par fautes par électromagnétisme, par horloge, par laser ou par voltage.
Tiens les commentaires sont permis sur cette vidéo, contrairement à celle sur la réquisition de nos fréquences radioamateur durant les JOs ? De toute évidence, trois hypothèses, soit vous n'etes pas radioamateur donc pas concerné, ou vous etes licencié et inconscient, ou bien vous avez été payé par les autorités pour faire de la propagande ! Sachez que depuis un bon moment les vendeurs de portables VHF et UHF font de très grosses affaires avec les sociétés de gardiennage entre autre qui une fois l'évènement passé ne vont pas jeter tout ce matériel à la poubelle mais vont belle et bien continuer à l'utiliser sur nos bandes ! Il est grave de constater que certaines personnes se prostituent alors que d'autres et des organismes se battent pour défendre nos droits durement acquis. Je signe mes propos : Olivier Di donato / F1PVU
Thank you for the informative video. I think a more fair example would be where you want to do the sequential operation with a few million different (sequential) seeds and not just one sequential loop. Even if the GPU takes 40 times longer, if it can do a few thousand of these in parallel then it may still be more efficient for iterating multiple instances of RC4 or even AES A long time ago you mentioned it takes you maybe 30 days to determine a 40 bit RC4 key with a CPU but when I run multiple instances in parallel on a single CPU then I find it takes a maximum of 48 hours (so 1 day on average). I have recently started to investigate the GPU approach and your code examples will be a useful starting point for me to progress this to see if this can be reduced even further.
@@49rekcaH I don't think I said it is a standard home CPU but it is a consumer laptop that I have in my home! Although, it is slightly higher specification as I use it for various radio, coding and video projects. My machine uses a 12th Gen Intel(R) Core(TM) i9-12900HK 2.90 GHz processor with 32GB RAM under Windows 10 and I have written very efficient C++ code optimised specifically for this task. I normally run about 40 instances in parallel with a custom batch file which creates the parallel processes that churn through the required combinations. As I said, it does take up to 48 hours (maybe very slightly more) and completely ties up my machine but unless the key is somewhere near the every end then it obviously will finish long before that so it works well for me. I'm not sure if I should be offended or complimented by the fact that you don't appear to believe this to be possible. As a real-world comparison, maybe you can advise how long your own code takes to execute? I wrote this tool by myself and for myself (and I use it for educational and research purposes only). The basic algorithm is fairly straightforward and I'm sure there are many many people who have written their own versions like me (including Louis obviously). I have over four decades of coding experience and I believe that getting it to work efficiently is what takes the skill which is why I was interested in this video. Anyway, I am simply using my personal experiences to support the point that it would be interesting to build on the concepts in this video and better explore more parallel CPU processing versus parallel GPU processing to compare these approaches more fairly when dealing with large volumes of potential keys. The video does a great job of explaining the different restrictions that apply to the potential approaches but could go a but further about how this might work best specifically in a PMR Research context where there is better opportunity for parallelisation that maybe suggested in the video.
@@Cagiest No offense, writing the previous post I did not mean to hurt you. By writing home cpu I meant a regular processor, not a server one (like xeon or epyc). I am still learning new things on my own. In my case I tested it on an i7-11850H, writing in C, and I wasn't even close to your 48 hour result. Looks like there is a space for improvements. May I ask you why are you running ~40 instances (cpu-bound threads?) on your cpu - isn't it inefficient?
No offense taken and thanks for your reply! No individual process takes 100% CPU, in an OS like windows anyway. And most processors do some elements of parallel processing within their chips so there is an advantage to running more than one instance of an algorithm. A single individual thread definitely runs much faster by itself but if I ran them one after another then it would probably take over a month. I experimented to see where I got the best balance and after about 40 threads I started to get diminishing returns. In reality I use 42 or 43 threads so that I can get through 6 smaller runs in total giving me 256 instances of a program which processes 16777215 keys at a time... On an i5 I have it was much much slower and I couldn't run more than a few threads but memory is probably a big factor there also. Anyway, we are probably getting slightly off-topic and I don't want to detract from the great content that Louis is providing here...
@49rekcaH Inspired by the original contents of the video and the discussions above, I have made a CUDA version of my code to run on my graphics card GPU for comparison and it runs a little quicker overall than the CPU-based version. It is only a first stab though so I hope to optimise it further. So even though the instructions run a lot lot slower, there are theoretically around 1000 kernels actively running at any given time so it balances out and gets through about 1/256 of the keyspace in 11 minutes. The great news though is that it only slightly slows down the CPU version if that is also running at the same time on the same laptop and so I can actually split the workload and do half on each now which gets me down under 24 hours maximum elapsed (so 12 hours on average). The actual configuration is 40 CPU processes in parallel by 1/256 of keys executed 3 times in succession which searched 120/256 keys and then 1 GPU process also in parallel doing 1/256 keys which I execute 136 times to search the remaining 136/256 keys. And I can run that with one overall batch file. Again, all of this is just for research and educational purposes! The graphics card in my laptop is just a built-in Nvidia RTX 3080 which is in addition to the CPU spec mentioned above. Also, theoretically I could even add an additional external GPU (using thunderbolt or USB-C) and reduce the overall GPU execution time by 50% again if desired. @LouisErigHERVE I don't know if that informs the question that you ask "CPU ou GPU, lequel va calculer le plus vite ?" Maybe the answer is actually "CPU et GPU!" I don't mean to undermine your conclusions in this regard and no offense is intended. Thank you for the information and background that you have provided. I hope that the fact that you have prompted some research and discussion around this question is a positive thing.
Ce calcul me rappelle celui fait en 1969 à l'Ecole d'Application de Transmisdions en cours de crypto pour casser le code d'une Myosotis, 1ère "machine à chiffrer" électronique. De basant sur un ordi virtuel inexistant à l'époque, je ne me souviens plus des caracteristiques, mais c'était plusieurs milliers de fois l'existant de l'époque, il fallait plusieurs siècle. Le délai de sécurité de la Myo était d'un mois ....
Merci pour les encouragements. J'ai testé sur mon GPU (un NVIDIA Quadro T2000 [petit GPU embarqué dans un PC portable]), verdict (avec un code assez peu optimisé) : 1 316 545,689 clés/s, soit 29 milliards d'années pour parcourir l'ensemble des combinaisons (ouch !). A tester sur un plus gros GPU.
Sur NVIDIA Quadro T2000 (petit GPU embarqué dans un PC portable) ==> 1 316 545,689 clés/s, soit 29 milliards d'années pour parcourir l'ensemble des combinaisons.
Merci pour la vidéo cela est toujours très intéressant je suis un tout petit peu plus que néophyte mais je possède un baofeng DM 5h plus et un scanner Whistler trx-1 j'ai une clé SDR mais étant aveugle c'est compliqué
@@airhalo Le respect est de s'adresser dans la langue du locuteur en premier. Vous demandez de l'aide à quelqu'un dans une autre langue que la sienne en lui demandant en plus de faire l'effort de vous traduire et de traduire son message en retour. Aucun effort! Les gens veulent avoir ton cru dans la bouche! Assez particulier!
Bonjour Herve Louis Erig je vous suis de la Corse super toutes les vidéos et très bien le passage sur BFM Business je vous souhaite une très bonne réussite (André)
