I know my viewers love a good TETRA decoding video. So here we are doing it in Linux this time, and not Windows! TETRA is a digital mode for two-way communication used most often in Australia and Europe. Because TETRA is mostly used for public safety critical communications in Europe (Police, Fire, Rescue and Ambulance), it is typically encrypted and not possible to listen to the broadcasts. But here in Australia, TETRA is mostly used in the private sector by commercial operators. And these companies typically don't enable encryption, which is good for me because I enjoy decoding UHF digital modes as part of my RF and SDR hobby. Please understand that as of the recording of this video, there is no PUBLICLY KNOWN method of decrypting secured TETRA communications. Team Midnight Blue researchers demonstrated a practical decryption attack against TETRA in 2023, but they did not release their method, or the software tools needed for the decryption process. It will probably never be possible for hobbyists like you and I to break the TETRA encryption algorithm. And why would you want to? It's illegal! Please don't comment or email me about this, thank you. COMMANDS: sudo /usr/src/tetra-kit/phy/gnuradio-3.10/pi4dqpsk_rx_packed.py sudo /usr/src/tetra-kit/decoder/decoder -P -w -t 42100 sudo tshark -Y '!icmp && gsmtap' -i lo cd /usr/src/tetra-kit/recorder sudo ./recorder -r 42100 cd /usr/src/tetra-kit/recorder/wav/ sudo ./raw2wav.sh cd /usr/src/tetra-kit-player sudo npm i; sudo npm run start HARDWARE: - Airspy R2 SDR - 25 Element Yagi Antenna - RCA Antenna Rotator - LCU400 Coaxial Cable - Lenovo Ideacenter PC SOFTWARE: - DragonOS FocalX R35 - TETRA-Kit - TETRA-Kit-Player - VLC Media Player

A viewer of mine requested help in getting DVBlast to stream a satellite TV channel to VLC media player. Naturally, I enjoy a challenge (it's not the easiest software to use), and had a play around in Linux last night. I eventually got it working streaming a single TV channel, and later figured out a method of streaming multiple TV channels encoded into the same satellite transponder signal. Using my TBS6908 tuner and satellite dish pointed at Intelsat-19, DVBlast tunes to the desired TV transponder and streams the incoming video and audio data to a multicast IP address of 224.0.0.1 in RTP format. This stream can be opened in VLC media player so the satellite TV channel can be watched. Satellite transponders containing multiple TV channels can be streamed by preparing a .conf format text file, and allocating one multicast IP address for each TV channel. Watch the video until the end for instructions on how to do this. Thanks very much for watching! DOWNLOADS: 'Channels.conf' File: https://drive.google.com/file/d/1GYUu7MUlKhv-y1TJ9Pvd8PCElPxVHtwc COMMANDS: sudo apt-get install dvblast -y dvblast -h dvblast -a 2 -u -f 12592000 -s 7200000 -v 13 -d 224.0.0.1:1234 vlc rtp://224.0.0.1:1234 (replace heart❤ symbol with greater-than sign) dvblast -a 2 -u -f 12606000 -s 30000000 -v 18 2❤&1 | grep -v 'scrambled' | grep -A 1 'service sid=' dvblast -a 2 -u -f 12606000 -s 30000000 -v 18 -c ~/channels.conf vlc rtp://224.0.0.1:1234

Are YOU tired of your Linux virtual machine performing poorly!? Are the frequent USB drop-out getting YOU down!? Well, look no further because bare-metal Linux is HERE! I am one of the many Linux enthusiasts out there who doesn't 'daily' a Linux distro on their PC for everyday use. A workaround for not dedicating an entire machine to occasional Linux use is to install your favorite distro into a virtualization host in Windows. However, in the case of RF hacking and software defined radio, the Linux software tools for this purpose typically require a more high performance and powerful computer to handle the demanding workload. This is where a user of a virtualized Linux instance will probably encounter degraded performance. Software defined radios and other USB-attached peripherals are commonly utilized in the hobby of RF hacking. The USB passthrough feature of a virtualization host is the underlying method of attaching a physical USB device to a virtualized instance of Linux. While the technology is amazing, it hardly performs to the level of a bare-metal Linux instance having direct access to the USB bus. Frequent drop-outs and malfunctioning SDR's are commonplace. Join me in this video today, where I detail all the hardware and software needed to construct a bootable USB thumb drive containing a persistent, native installation of DragonOS FocalX Linux. Providing the target machine has Legacy BIOS (CSM) support, this USB thumb drive can be booted on just about anything and is a great way of running Linux on bare-metal if you aren't a daily Linux user, like myself. Yeah, the video is long. This stuff takes time. Deal with it! Thanks for watching! SOFTWARE: - DragonOS FocalX R36 - VMWare Player 17 - QEMU Disk Image Utility - Win32 Disk Imager HARDWARE: - Sandisk 128GB USB Thumb Drive

Originally, this video was going to be a silent screen recording of myself demonstrating the usage of a particular software tool. However, I have heard the criticisms of my fans and they want to see my face and hear me talking. So, I hope you guys enjoy the new format, as clunky as it may be.... In this video, I am showing a practical rainbow table attack against the BISS satellite TV encryption algorithm. BISS is commonly used to secure point to point DVB-S links between a sporting match, or pay-per-view TV events and the TV station. Using 1.25 terabytes of pre-computed rainbow tables, a GTX1080 Ti graphics card and an application called 'CSA Rainbow Table Tool', it possible to retrieve the 64-bit CW (control word) value and decrypt the satellite TV transponders live video stream. I do not condone the use of this video to facilitate satellite TV piracy, and if you choose to do so, you will be using it at your own risk of potential legal ramifications. I have an interest in hobbyist-level amateur cryptography, and I in no way, shape or form intend to use this tool to steal pay-per-view television. Thanks very much for watching!

Viewers of my channel should know that I am a huge fan of the esoteric hobby of satellite television. But a common complaint amongst DVB-S enthusiasts is that blind scan capable TV decoding software for Linux operating systems doesn't exist. Blind scan is the capability of a satellite television receiver to search for, and lock onto a transponder signal that it doesn't have stored in its memory. Blind scan is a highly desirable feature for myself and others who love hunting for obscure and hidden signals that aren't intended to be decoded by the public. Meet NeumoDVB, developed by prolific satellite TV internet forum user 'DeepThought'. Released in the year of 2020, this software claims to bring the long-awaited blind scan feature to Linux machines that have a DVB-S tuner card or USB device installed. However, with all of NeumoDVB's complex features comes great difficulty in getting it working. Ubuntu is a great distribution for beginners to which myself and many others use as a first step into the world of Linux, and DeepThought states that NeumoDVB probably won't work on all on the latest versions of Ubuntu. And of course, as per usual, it's Aaron from@cemaxecuter7783to the rescue! After a mutual viewer of our channels contacted Aaron about getting NeumoDVB working in DragonOS FocalX, he got to work and figured out a method of building and installing NuemoDVB on the later versions of DragonOS FocalX, particularly R35 and R36. Join me in part two today, where I show my viewers the minimum amount of configuration needed to get NeumoDVB receiving satellite TV signals. After that task is complete, I demonstrate the software's blind scanning capability. And I conclude the video by showing my viewers how to stream live television from NeumoDVB to VLC media player. That will conclude my NeumoDVB video series for the time being. Huge thanks to @cemaxecuter7783for getting this working for us Satellite TV nerds! Make sure you give Aaron a sub, like, comment and share on his videos over at his channel, he would really appreciate it! Thanks very much for watching! COMMANDS: ~/neumodvb/gui/neumodvb.py vlc udp://@:9999

In yet another GSM focused video, I am demonstrating the usage of a piece of software called GSM Assessment Toolkit for Linux. GAT, as it is commonly known as, is a wrapper for gr-gsm and provides some extra functionality in addition to that provided already. While I haven't figured out how to use most of the functionality of this application yet, I demonstrate for my viewers how to scan for 2G base stations, how to capture and record GSM data to a file on a PC. I then show how it is possible to decode the captured data before finalizing the video by using GAT to analyze various details and extract useful information from the captured 2G data. GSM Assessment Toolkit is very old software that was released in 2017, therefore it requires an older version of Linux to run on. There are many more limitations to mention, but the main one appears to be the lack of support for decoding CFILEformat GSM capture files. Despite being advertised with the support for CFILE format, my preliminary testing has proven that only BFILE (burst file) format can be decoded with GAT. BFILE format has been deprecated in modern versions of gr-gsm, for a long while. The primary function that a majority people will be looking to use in GSM Assessment Toolkit is most probably the GSM encryption cracking support by linking it to the Kraken A5/1 utility. This is another function I have not figured out yet, as GAT requires Kraken to be accessible via a TELNET server. In my experience, Kraken is a binary that runs from the CLI, and is not accessible in TELNET. Deka on the other hand, can be accessed by a TELNET server. So, it may be possible to link GAT to that instead. Thanks very much for watching! SOFTWARE: - DragonOS LTS Final - GSM Assessment Toolkit HARDWARE: -RTL SDR Blog V3 PREREQUISITES: sudo apt-get install python-argcomplete python-beautifulsoup -y git clone https://github.com/romankh/gsm-assessment-toolkit.git ~/gsm-assessment-toolkit/gat.py SCANNING: sudo ~/gsm-assessment-toolkit/gat.py scan_rtlsdr -b P-GSM --speed 5 CAPTURING: ~/gsm-assessment-toolkit/gat.py (Replace ❤️heart symbol with greater-than sign) sudo tshark -Y '!icmp && gsmtap' -i lo 2❤️/dev/null capture_rtlsdr -b P-GSM -a 1 --bursts /home/username/capture.bfile --print-bursts --gsmtap DECODING: (Replace ❤️heart symbol with greater-than sign) sudo tshark -Y gsm_sms -T fields \-e gsm_sms.tp-oa -e gsm_sms.sms_text -i lo 2❤️/dev/null ~/gsm-assessment-toolkit/gat.py decode --bursts /home/username/call_sms.bfile --print-messages --print-bursts -m BCCH_SDCCH4 -t 0 ANALYZING: ~/gsm-assessment-toolkit/gat.py analyze system_info --burst /home/username/call_sms.bfile analyze immediate --burst /home/username/call_sms.bfile -m BCCH_SDCCH4 -t 0 --gprs-assignments analyze tmsi -v -m BCCH_SDCCH4 -t 0 --bursts /home/username/call_sms.bfile

Viewers of my channel should know that I am a huge fan of the esoteric hobby of satellite television. But a common complaint amongst DVB-S enthusiasts is that blind scan capable TV decoding software for Linux operating systems doesn't exist. Blind scan is the capability of a satellite television receiver to search for, and lock onto a transponder signal that it doesn't have stored in its memory. Blind scan is a highly desirable feature for myself and others who love hunting for obscure and hidden signals that aren't intended to be decoded by the public. Meet NeumoDVB, developed by prolific satellite TV internet forum user 'DeepThought'. Released in the year of 2020, this software claims to bring the long-awaited blind scan feature to Linux machines that have a DVB-S tuner card or USB device installed. However, with all of NeumoDVB's complex features comes great difficulty in getting it working. Ubuntu is a great distribution for beginners to which myself and many others use as a first step into the world of Linux, and DeepThought states that NeumoDVB probably won't work on all on the latest versions of Ubuntu. And of course, as per usual, it's Aaron from @cemaxecuter7783 to the rescue! After a mutual viewer of our channels contacted Aaron about getting NeumoDVB working in DragonOS FocalX, he got to work and figured out a method of building and installing NuemoDVB in the later versions of DragonOS FocalX, particularly R35 and R36. So, join me in this video today, where I will show my viewers a step-by-step process on how exactly to build and install NeumoDVB, and how to build and install the patched 'linux_media' drivers for TBS satellite tuner cards. Join me in part two at a later date, where I will demonstrate the configuration and practical usage of NeumoDVB in DragonOS FocalX R35. Huge thanks for @cemaxecuter7783 getting this working for us Satellite TV nerds! Make sure you give Aaron a sub, like, comment and share on his videos over at his channel, he would really appreciate it! Thanks very much for watching! NOTE: While I am using a virtualization for this tutorial, please understand that it is not possible to 'passthrough' a PCI-e device (DVB-S tuner card for example) to a virtual machine using a type-2 hypervisor (VMware Workstation, or VirtualBox). If you have a USB DVB-S tuner and are extremely lucky, you MIGHT be able to use it with a virtual machine, but I personally have had no luck doing this. I highly recommend installing Linux natively on your PC's internal storage, or onto a bootable USB thumb drive if you aren't a regular Linux user. Bare-metal is ALWAYS better than virtualization. PATCHED 'LINUX_MEDIA' DRIVER BUILD COMMANDS: sudo apt-get install patchutils ccache libproc-processtable-perl gcc-12 -y mkdir ~/blindscan_kernel cd ~/blindscan_kernel (remove the ' dot ' text in the URL and put a full stop instead) git clone --depth=1 https://github dot com/deeptho/linux_media.git ./media (remove the ' dot ' text in the URL and put a full stop instead) git clone https://github dot com/deeptho/neumo_media_build cd neumo_media_build make dir DIR=../media make distclean ./install.sh (remove the ' dot ' text in the URL and put a full stop instead) wget http://www.tbsdtv dot com/download/document/linux/tbs-tuner-firmwares_v1.0.tar.bz2 sudo tar jxvf tbs-tuner-firmwares_v1.0.tar.bz2 -C /lib/firmware/ sudo reboot NEUMODVB BUILD COMMANDS: sudo apt-get install -y libboost-all-dev libgtk-3-0 libgtk-3-dev curl libcurl4-gnutls-dev libwxgtk-media3.0-gtk3-dev gettext libexif-dev libavcodec-dev libavformat-dev libavutil-dev libswscale-dev python3-configobj python3-cachetools python3-jinja2 python3-pip clang-format python3-sip-dev libconfig-dev libconfig++-dev libdvbcsa-dev libmpv-dev freeglut3-dev libwxgtk3.0-gtk3-dev python3-wxgtk-media4.0 python3-wxgtk-webview4.0 python3-wxgtk4.0 python3-scipy clang lsb-core lsb-release python3-regex liblog4cxx12 liblog4cxx-dev freeglut3 espeak libfmt-dev -y sudo pip3 install mpl_scatter_density wget https://apt.llvm.org/llvm.sh chmod +x llvm.sh sudo ./llvm.sh 16 sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-16 100 sudo update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++-16 100 sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y sudo apt-get install gcc-13 g++-13 -y sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-13 13 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-13 13 sudo update-alternatives --config gcc sudo update-alternatives --config g++ (remove the ' dot ' text in the URL and put a full stop instead) git clone https://github dot com/alphafox02/neumodvb.git nano ~/neumodvb/CMakeLists.txt if(USE_CLANG) SET (CMAKE_CXX_COMPILER clang++-16) SET (CMAKE_C_COMPILER clang-16) endif(USE_CLANG) cd ~/neumodvb mkdir build mkdir build_ext cd ~/neumodvb/build cmake .. make -j`nproc` NEUMODVB LAUNCH COMMAND: ~/neumodvb/gui/neumodvb.py

It's been a while since I have visited any topic relating to GSM cellular technology in my videos, but many of my viewers have been requesting an in-depth tutorial on how exactly to deploy a 2G base station transceiver using software defined radio. Using a BladeRF xA4 and some software for Linux called YateBTS, it is possible to operate a small experimental cellular network which will allow two mobile phones in your lab environment to make telephone calls, send SMS messages and browse the internet via a GPRS data connection. Join me in part three today, where I demonstrate how to use YateBTS as an IMSI catcher. After that, I show my viewers how to tap useful information from the 2G base station using Wireshark. I also detail how the YateBTS welcome SMS can be changed to something less conspicuous. Towards the end of the video, I illustrate the possibility of recording and decoding phone calls being conducted over the 2G base station using gr-gsm and an RTL-SDR. And finally, I demonstrate a theoretical method of getting less secure cellular devices to attach to YateBTS. I am unsure if there will be a part four installment of this video series at the moment. I did promise my viewers that I would give out some troubleshooting hints and tips (believe me, you're going need them if you want to play around with YateBTS!) If that happens in the future, I'll see you then. If not, that will conclude my 2G base station series for now. Thanks very much for watching! DISCLAIMER: Deploying experimental cellular base stations using software defined radios will require you to transmit signals on portions of the radio frequency spectrum that you are not permitted to use. This CAN and WILL cause destructive interference to licensed radio services operating on those frequencies. I WON'T be held responsible for any legal trouble you get yourself into because you got a knock on the door from the spectrum regulation authority in your country. It is advisable to NEVER follow this tutorial, EVER! HARDWARE: - BladeRF 2.0 Micro xA4 software defined radio - Quad-band cellular 90-degree SMA antenna x 2 - Samsung S8 and S9 mobile phones - Sysmocom SysmoISIM-SJA2 SIM cards x 2 - Custom dual-Xeon CPU server PC SOFTWARE: - DragonOS FocalX R35 (bootable USB thumb drive) - YateBTS RC-2 (Nuand fork) COMMANDS: (Substitute heart ♥ symbol for 'greater-than' sign) sudo yate -vvvvv 2♥&1 | grep "clipping" telnet 127.0.0.1 5038 sniffer on sniffer filter user.register output on sudo wireshark -k -Y '!icmp && gsmtap' -i lo sudo wireshark -k -i sgsntun featherpad /usr/local/share/yate/scripts/nipc.js firefox localhost/nipc/custom_sms.php grgsm_capture -f 935.2M -s 1e6 -g 30 ~/capture_f935.2M_s1e6.cfile grgsm_decode -p -v -c ~/capture_f935.2M_s1e6.cfile -f 935.2M -s 1e6 -m TCHF -t 4 -o ~/speech.au.gsm grgsm_decode -p -v -c ~/capture_f935.2M_s1e6.cfile -f 935.2M -s 1e6 -m TCHF -t 5 -o ~/speech.au.gsm ./yatebts_telnet.sh | grep -B 4 "location-area-not-allowed" ./change_mcc_mnc.sh

It's been a while since I have visited any topic relating to GSM cellular technology in my videos, but many of my viewers have been requesting an in-depth tutorial on how exactly to deploy a 2G base station transceiver using software defined radio. Using a BladeRF xA4 and some software for Linux called YateBTS, it is possible to operate a small experimental cellular network which will allow two mobile phones in your lab environment to make telephone calls, send SMS messages and browse the internet via a GPRS data connection. Join me in part two today, where I demonstrate how to initialize the base station software and hardware. I then proceed to connect my two mobile phones to it, and I finish off the video by showing how it's possible to make telephone calls, send SMS messages and browse the internet (very slowly) via GPRS. Keep your eyes peeled for part 3, where I will show my viewers how to 'tap' the data flowing across the 2G base station. I will also detail how YateBTS can be used an experimental IMSI catcher. And if I have time, I'll also cover some hints and tips for troubleshooting common problems. Thanks very much for watching! DISCLAIMER: Deploying experimental cellular base stations using software defined radios will require you to transmit signals on portions of the radio frequency spectrum that you are not permitted to use. This CAN and WILL cause destructive interference to licensed radio services operating on those frequencies. I WON'T be held responsible for any legal trouble you get yourself into because you got a knock on the door from the spectrum regulation authority in your country. It is advisable to NEVER follow this tutorial, EVER! HARDWARE: - BladeRF 2.0 Micro xA4 software defined radio - Quad-band cellular 90-degree SMA antenna x 2 - Samsung S8 and Pixel 7A mobile phones - Sysmocom SysmoISIM-SJA2 SIM cards x 2 - Custom dual-Xeon CPU server PC SOFTWARE: - DragonOS FocalX R35 (bootable USB drive) - YateBTS RC-2 (Nuand) COMMANDS: SoapySDRUtil --probe sudo yate -vvvvv

It's been a while since I have visited any topic relating to GSM cellular technology in my videos, but many of my viewers have been requesting an in-depth tutorial on how exactly to deploy a 2G base station transceiver using software defined radio. Using a BladeRF xA4 and some software for Linux called YateBTS, it is possible to operate a small experimental cellular network which will allow two mobile phones in your lab environment to make telephone calls, send SMS messages and browse the internet via a GPRS data connection. Join me in part one today, where I list all the hardware and software requirements needed to follow this tutorial. I also walk my viewers through the entire software configuration step-by-step. Keep an eye out for part two in the coming days or week, where I will be demonstrating all the practical features of YateBTS. Thanks very much for watching! DISCLAIMER: Deploying experimental cellular base stations using software defined radios will require you to transmit signals on portions of the radio frequency spectrum that you are not permitted to use. This CAN and WILL cause destructive interference to licensed radio services operating on those frequencies. I WON'T be held responsible for any legal trouble you get yourself into because you got a knock on the door from the spectrum regulation authority in your country. It is advisable to NEVER follow this tutorial, EVER! HARDWARE: - BladeRF 2.0 Micro xA4 software defined radio - Quad-band cellular 90-degree SMA antenna x 2 - Samsung S8 and S9 mobile phones - Sysmocom SysmoISIM-SJA2 SIM cards x 2 - Custom dual-Xeon CPU server PC SOFTWARE: - DragonOS FocalX R35 (bootable USB drive) - YateBTS RC-2 (Nuand) COMMANDS: sudo /etc/init.d/apache2 start sudo iptables -A POSTROUTING -t nat -s 192.168.99.0/24 ! -d 192.168.99.0/24 -j MASQUERADE sudo lshw -class network | grep 'logical name:' (replace heart ♥ symbols with name of your network adapter) sudo iptables -A FORWARD -i ♥♥♥♥♥♥ -o sgsntun -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i sgsntun -o ♥♥♥♥♥♥-j ACCEPT

Satellite TV is a hobby that I am a relative newcomer to. One might assume that Satellite TV is all about..... Watching television. Of course, this isn't the case exactly. The DVB-S and DVB-S2 standards are interesting to me because so much more than just moving pictures can be sent over TV satellites. Examples of this are IP traffic, firmware updates, emails, VOIP telephone calls and television 'wild feeds'. A satellite television receiving device that was designed and sold for the purposes of finding obscure and interesting signals is the TBS6903, from Turbosight. It is a PCI-e card for your PC that is considered the best-in-class for the true satellite TV enthusiast. The TBS6903 is no longer manufactured and sold anymore. However, I was lucky enough to find a second-hand brand new one in an opened box for sale on eBay in the US. Join me in part two today, where I demonstrate how to use EBS Pro to blind scan the Intelsat-19 satellite in order find wild feeds, television and radio channels. After that, I show my viewers how to decode Generic Stream Encapsulation (GSE) IP traffic using GSExtract. And finally, before giving my review and final thoughts, I demonstrate how it is possible to decode Multiprotocol Encapsulation (MPE) IP traffic. That will conclude this two-part series about the TBS6903 and satellite TV decoding on PC. Thanks very much for watching! HARDWARE - TBS6903 - 90CM Offset Dish - Satking 10700 Quad LNB - RG59 Coaxial Cable SOFTWARE: - EBS Pro - TBS TS Recorder - GSExtract (Linux) - Tshark (Linux) - TBS IP Tool - Wireshark

Satellite TV is a hobby that I am a relative newcomer to. One might assume that Satellite TV is all about..... Watching television. Of course, this isn't the case exactly. The DVB-S and DVB-S2 standards are interesting to me because so much more than just moving pictures can be sent over TV satellites. Examples of this are IP traffic, firmware updates, emails, VOIP telephone calls and television 'wild feeds'. A satellite television receiving device that was designed and sold for the purposes of finding obscure and interesting signals is the TBS6903, from Turbosight in China. It is a PCI-e card for your PC that is considered the best-in-class for the true satellite TV enthusiast. The TBS6903 is no longer manufactured and sold anymore. However, I was lucky enough to find a second-hand brand new one in an opened box for sale on eBay in the US. Join me in part one today, where I give a brief overview of what satellite TV is, what 'feed hunting' is all about, why blind scan is such a desirable feature for a satellite TV receiver, and an unboxing and hardware review. I conclude the video with the actual installation of the TBS6903 into a PC. Keep an eye out for part two in the near future, where I will be demonstrating the actual usage of this PCI-e card and giving my honest review and final thoughts about it. Thanks very much for watching!

Recently I experienced an influx of emails in my inbox requesting help with Iridium decoding. So, I thought I would throw together a one or two part series on how to get started with receiving L-band signals from Iridium satellites using relatively cheap hardware and a couple of free software tools for Linux. What is Iridium exactly? Before there was Starlink, there was Iridium! It is a low earth orbiting constellation of communication satellites providing voice and data services to the surface of the Earth. Typical applications of the Iridium network are satellite phones and internet connectivity for aircraft and marine vessels. Join me in part two where I detail the usage of Iridium-Toolkit, which is the software that will allow us to extract useful information from the Iridium satellite data that we captured in part one. Towards the end of the video, I demonstrate the ability to decode Iridium voice and SMS transmissions. But, be sure to watch the entire video, because there is heaps of other cool data we can extract with Iridium-Toolkit! That will conclude my Iridium satellite decoding tutorial series for now. I hope you guys enjoyed it, and thanks very much for watching! DISCLAIMER: This video was made for the purposes of education and experimentation only! Intercepting private satellite data that wasn't intended for you is illegal and punishable by hefty fines and imprisonment! You have been warned! SOFTWARE: - DragonOS FocalX R35 - Iridium-Toolkit - PyPy3 - Google Earth - Wireshark/TShark COMMANDS: sudo apt-get install pypy3 -y pypy3 -m pip install crcmod (Replace heart ♥ symbol with greater-than sign) pypy3 /usr/src/iridium-toolkit/iridium-parser.py --harder ~/output.bits ♥ ~/output.parsed python3 /usr/src/iridium-toolkit/stats.py ~/output.parsed cd /usr/src/iridium-toolkit (Replace heart ♥ symbol with greater-than sign) grep ^IRA ~/output.parsed |perl mkkml tracks ♥ ~/tracks.kml (Replace heart ♥ symbol with greater-than sign) grep ^IRA ~/output.parsed |perl mkkml heatmap ♥ ~/heatmap.kml cd python3 /usr/src/iridium-toolkit/reassembler.py -i ~/output.parsed -m acars sed -n -e 's/^.* IP://p' ~/output.parsed | tr '\n ' ' ' (Replace heart ♥ symbol with greater-than sign) python3 /usr/src/iridium-toolkit/reassembler.py -i ~/output.parsed -m sbd | sed -n -e 's/^.*♥ //p' python3 /usr/src/iridium-toolkit/reassembler.py -i ~/output.parsed -m msg python3 /usr/src/iridium-toolkit/stats-voc.py ~/output.parsed (Replace heart ♥ symbol with greater-than sign) pypy3 /usr/src/iridium-toolkit/iridium-parser.py --harder ~/rob_voice.bits 2♥&1 | tee ~/rob_voice.parsed python3 /usr/src/iridium-toolkit/stats-voc.py ~/rob_voice.parsed (Replace heart ♥ symbol with greater-than sign) pypy3 /usr/src/iridium-toolkit/iridium-parser.py --harder ~/rob_sms.bits 2♥&1 | tee ~/rob_sms.parsed pypy3 /usr/src/iridium-toolkit/reassembler.py -v -i ~/rob_sms.parsed -m lap tshark -r ~/rob_sms.pcap -Y gsm_sms -T fields \-e gsm_sms.tp-oa -e gsm_sms.sms_text

'Play-iridium-ambe not found' is a common error many newbies run into when using the Iridium decoding tool 'Iridium-Toolkit'. This is caused by Linux not knowing where a particular bash script is located when trying to decode Iridium satellite voice transmissions. The README file of Iridium-Toolkit does instruct the user to run a command to fix this error before running the Iridium voice decoding command. But let's face it, nobody reads the documentation anymore! In addition to this, the README files' instructions are only temporary. The method I detail in this video is a permanent solution which only needs to be performed once. The instructions in this video are very specific to DragonOS Focal or FocalX. The path to the Iridium-Toolkit program files is '/usr/src/iridium-toolkit'. If you are using a different distribution of Linux and downloaded Iridium-Toolkit from GitHub into your home directory for example, the path to the program files could be '~/iridium-toolkit'. You might have to do a bit of sleuthing to figure out where exactly you downloaded or installed Iridium-Toolkit to. DON'T FORGET TO QUIT YOUR TERMINAL WINDOW AND RELAUNCH IT! COMMANDS: sudo nano ~/.bashrc export PATH=$PATH:/usr/src/iridium-toolkit

Recently I experienced an influx of emails in my inbox requesting help with Iridium decoding. So, I thought I would throw together a one or two part series on how to get started with receiving L-band signals from Iridium satellites using relatively cheap hardware and a couple of free software tools for Linux. What is Iridium exactly? Before there was Starlink, there was Iridium! It is a low earth orbiting constellation of communication satellites providing voice and data services to the surface of the Earth. Typical applications of the Iridium network are satellite phones and internet connectivity for aircraft and marine vessels. Join me in part one today, where I outline the hardware and software requirements for decoding Iridium and demonstrate the usage of the 'gr-iridium' software which is used for the actual capturing and recording phase of the decoding process. In the upcoming part two video, I will be demonstrating the usage of 'Iridium-toolkit' and how it can be utilized to extract useful data from recordings of Iridium satellite data. Thanks for watching! DISCLAIMER: This video was made for the purposes of education and experimentation only! Intercepting private satellite data that wasn't intended for you is illegal and punishable by hefty fines and imprisonment! You have been warned! HARDWARE: - Airspy R2 Software Defined Radio - RTL-SDR Blog L-Band Antenna - LMR-195 Coaxial Cable - PC/Computer SOFTWARE: - DragonOS FocalX R35 - GR-Iridium COMMANDS: sudo nano ~/.bashrc export PATH=$PATH:/usr/src/iridium-toolkit SoapySDRUtil --probe (Replace heart symbol with greater-than sign) iridium-extractor -D 4 /usr/src/gr-iridium/examples/airspy.conf ♥ output.bits

On the 15th of April 2024, users of the Thuraya satellite phone and packet data services in the eastern hemisphere were left without network coverage when an on-orbit failure occurred on the Thuraya 3 satellite. Launched to space in 2008, it made 98.5 degrees east it's new home in geostationary earth orbit soon after. Since then, it has been providing voice and data services to Australia and Asia reliably for the better part of two decades. By the 23rd of March, Thuraya 3's owner Yahsat informed stakeholders that the communications payload, or a subsystem that the communications payload relied upon had failed. Yahsat said it was working closely with Thuraya 3's manufacturer Boeing to troubleshoot the failure, and at least, restore a partial service with a reduced capacity. After a week or two of silence from Thuraya and Yahsat, along comes Thursday, the 2nd of May 2024. Pivotel, an Australian provider of satellite communications drops a bombshell via it's website: Thuraya had severed the 'Service Provider Agreement' between the two entities, and that it's voice and data service to Australia had been indefinitely suspended for the foreseeable future. As of the recording of this video, Yahsat has not made an official public announcement confirming that the Thuraya 3 satellite is unrecoverable. Perhaps they are trying to protect their stock price? Another weird detail in the saga is the fact that the serviceable lifespan of Thuraya 3 (and it's insurance contract) was due to expire in December 2023. It's remarkably rare for a geostationary communications satellite to experience mission ending failures in the exact year their design life was due to expire. Most satellites exceed their proposed lifespans by a number of years, to decades. Speculation aside, Thuraya 3 was a favorite of mine when it came to receiving and decoding L-band radio signals. Osmo-GMR is the software I am using in this video to decode a spot beam that provided coverage for China. This was the last recording of Thuraya data I ever made, and I figured for the purposes of archival, I would honor the memory of an old friend and record the entire 35 minutes the decoding tool takes to demodulate this very busy spot beam. There is no planned replacement for Thuraya 3 for the eastern hemisphere at the recording of this video. Satellite monitoring enthusiasts on this side of the world will have to look to GPS, Inmarsat, Iridium to get their fix of L-band decoding. The end of an era. Goodbye Thuraya 3, you will be missed! Thanks for watching!

Recently I went hunting for the Thuraya 3 satellite on L-band, which is located at 98.5 degrees east. Much to my surprise, I couldn't find it because the satellite experienced a severe failure on orbit in April 2024 and has officially ceased providing satellite phone service. No more using Osmo-GMR for me anymore, as another L-band satellite bites the dust! To my knowledge, a replacement satellite for Thuraya 3 has not been planned or announced. The end of an era. Inmarsat-4 F1 is another L-band satellite which is a favorite of us satellite enthusiasts here in the eastern hemisphere. Located at 143.5 degrees east, it is also reaching the end of it's usable life, with a highly publicized on-orbit failure occurring in the middle of 2023. This outage left the maritime and aviation industries of the Asia-Pacific region without communications for a considerable amount of time. The replacement satellite Inmarsat-4 F1 is Inmarsat-6 F1, which was launched in late 2021, and begun commissioning in 2023. It is currently located to the west of Australia at 83.8 degrees east, which is very close to Thuraya 3. Inmarsat-6 F1's very strong signals actually leak into my satellite dish when it is aimed at Thuraya 3. Join me in this video as I use my SDRPlay RSP1A to scroll through the portion of the L-band which is occupied by the new Inmarsat Asia-Pacific satellite. At the current time, there appears to be 600 and 10500 baud rate ACARS messaging channels and 8400 baud rate C-channel voice channels, to which both can be decoded with the software called JAERO. There is also an analog FM voice transponder, the signals of which are very weak and hardly usable, in my opinion. You will also see that there are a number of wideband carrier signals being downlinked, these are believed to be Inmarsat's BGAN internet connectivity service. As of the recording of this video, maritime services such as "Inmarsat-C" (a two-way email/messaging service provided via satellite for ocean-going vessels) have not been commissioned on 6 F1 at this time. At the beginning of the video, I display a picture of my L-band receiving setup. Most people will probably be wondering where I obtained my custom made left-handed circularly polarized helical antenna on my satellite dish. This was constructed by my good friend Ben in the US, who is a fellow Aussie that goes by the handle of 'thebaldgeek'. Ben has done a lot for the L-band satellite monitoring community and is a very knowledgeable and helpful dude. He doesn't construct these antennas anymore and he is a very busy guy, so please don't email him requesting one of these. Mine is one of only three or four he ever produced, and it works remarkably well on my tiny 90 cm PayTV satellite dish. Massive signal-to-noise ratios can be observed throughout the duration of this video. I will detail the list of hardware at the bottom of the description section, should you wish to emulate my setup. Thanks for watching! HARDWARE: - 90cm offset dish - 'thebaldgeek' L-band LHCP helical feed - Sysmocom L-band cavity filter - Mini-Circuits ZRL-2400LN+ amplifier - LCU-195 coaxial cable - SDRPlay RSP1A SOFTWARE: - SDR Sharp 1702 - ExtIO front-end interface plugin - JAERO 1.0.4.10 - VB Cable virtual audio cable - Windows 10

An unknown individual who is definitely not myself decrypting a BISS encrypted satellite TV feed. DO NOT ATTEMPT TO DECODE SATELLITE TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

Skip to 3 minutes and 42 seconds for the tutorial! Recently, I received a few inquiries via email from my viewers who were interested in a vintage 2G mobile phone that I showcased in one of my videos in 2023. That phone was, of course, the Blackberry Bold 9700. It was manufactured with a number of useful features hidden deep within an hidden menu which make it a great addition to your GSM security research toolkit. In this video, I perform the procedure required to unlock the hidden "engineering screen" of this vintage Blackberry mobile phone. Once that is completed, I demonstrate some of the most interesting features that will be most pertinent to my viewers. These handy features include retrieving the 2G decryption key of your phone, selecting and locking to a specific cell tower, choosing which voice codec to use when making a phone call, and more. Please be aware that you will need a SIM card inserted into your Blackberry with a valid subscription of the cellular provider you wish to conduct experiments with to take full advantage of the engineering screen. This is because the mobile phone will need to interact with the 2G base station in order to retrieve useful information from it. The easiest way to do that is by ejecting the SIM card from your modern smartphone and placing it in your Blackberry temporarily for conducting your experiments. Something that I forgot to mention in the video is that the Blackberry Bold 9700 appears to draw a standby current and if it is left in a powered-off state for a long period of time, you will find the battery will have been fully drained. I recommend pulling out the mobile phones' battery when it is not use, or when keeping it in storage for extended periods of time. Please do not use any of the information or demonstrations provided in this video for malicious activity. Performing practical hacking attacks on real-life operating cellular networks is very illegal and the penalties are harsh. When reproducing the steps in any of the videos on my channel, please ensure they are being done in a simulated lab environment only. I can not be held responsible for any legal trouble you get yourself into should you choose to disregard my disclaimers. Do this at your own risk! Thanks for watching! LINKS: Blackberry Bold 9700 in action: https://youtu.be/YRJPuf8oZ_E Engineering screen unlock code generator: https://web.archive.org/web/20160724010734/http://www.zibri.org/2009/08/hidden-things-are-usually-best.html OPENING 'HELP ME!' SCREEN: Alt + Left Shift + H RETRIEVING THE KC VALUE: Mobile Network Engineering Screens --- SIM Browser --- SIM_EF_KC LOCKING TO A SPECIFIC CELL: Mobile Network Engineering Screens --- Neighbor Cells --- Highlight the cell with the strongest signal --- Press the menu key --- Select "Lock to this cell" SETTING THE VOICE CODEC: Mobile Network Engineering Screens --- Voice Channel --- Voice Stats --- Highlight the on-screen button in the top right that says "Default" and press the trackpad button --- Scroll down to highlight FR and press the trackpad button --- Press the menu key and select 'Set Voice Codec' CHECK IF HOPPING IS IN USE: Mobile Network Engineering Screens --- Cell information --- Scroll down to 'ARFCNS' RETRIEVING THE TMSI VALUE: Mobile Network Engineering Screens --- Mobile identity --- TMSI

An unknown individual who is definitely not myself, decoding POP3 email transmissions on Ku-band DVB-S2 frequencies. DO NOT ATTEMPT TO DECODE SATELLITE TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

LTESniffer is a Linux application that can decode 4G base transceiver station downlink transmissions by utilizing software defined radios. Once the LTE signal is received by my BladeRF 2.0 Micro xA4, LTESniffer demodulates it and dumps the decoded packets to a Wireshark capture file. Instead of running the LTE decoder for a while and inspecting the .pcap file after, it is possible to use the 'tail' command in DragonOS FocalX to dynamically reload the Wireshark capture file as it is updated with new decoded packets from LTESniffer. This method of 4G decoding is reminiscent of how 2G GSM control channels are decoded in real-time using 'grgsm_livemon'. Although 4G is lightyears ahead of 2G in the technical sense, some of the decoded packets such as 'System Information' messages and the 'Security Mode Command' packets remind me of fond memories playing around with GSM. It just goes to show that the subsequent cellular communication generations really are just technological evolutions of their predecessors. There is still a tiny bit of 2G in there, somewhere! Please understand that LTESniffer can only ever decode public unencrypted information from an eNodeB downlink. It can not decrypt private subscriber data, such as voice calls and SMS messages. It can operate as an IMSI catcher, but only when receiving uplink data from a mobile phone/LTE-enabled device and it requires a $10,000 USRP software defined radio from Ettus to do. Way out of the price range of a hobbyist like me! At the present time of uploading this video, there is no publicly-known decryption attacks against the 4G mobile communication standard, or it's 128-bit EPS Encryption Algorithm (EEA-1). Yes, I know there has been some theoretical research papers from academia published on LTE security. But to my knowledge, no cracking methods have been detailed or software tools released. So please don't comment or email me asking about this. Check out my other LTESniffer video here: https://www.youtube.com/watch?v=9oO4xV64_kU Also, here is a video of me decoding a LTE base station control channel with FALCON: https://www.youtube.com/watch?v=XNB8BAdVgNA If you are interested in SDR-powered LTE fake base stations, check out my video about srsRAN: https://www.youtube.com/watch?v=-CBZnlaZhxw Thanks for reading and watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT!

Regular viewers of my channel will know that I am a huge fan of the Osmocom-BB toolset. In this video, I thought I would throw together a tutorial on how exactly Osmocom-BB is used in the context of hobbyist GSM security research. In part three today, I showcase the usage of GSMTK and how it can be used to converge all the hardware and software of Osmocom-BB, so that a functional amateur hobbyist GSM security research tool can be constructed. Firstly, I document all the hardware and software required, and then I show a complete installation and configuration of GSMTK and it's dependencies. Lastly, I show my viewers the practical usage of this tool with a complete GSM decoding workflow. This will conclude my series of Osmocom-BB tutorial videos. If you would like to learn more about this awesome software project, go and checkout my other videos on the subject in this playlist: https://www.youtube.com/playlist?list=PLqjhBzfQS7YL-vLIaXmD0-wGN5m8uhJwp You can also find parts 1 and 2 of this instructional video series in this playlist: https://www.youtube.com/playlist?list=PLqjhBzfQS7YJSlMOUx7BkDFWWwyr-7niN This video (and channel) wouldn't be possible without the amazing Linux distribution, DragonOS FocalX. Friend of the channel, Aaron from the @cemaxecuter7783 YouTube channel works far too hard to provide this incredible Linux distro for us, free of charge. So please, go and subscribe to his channel, like his videos and follow him on Twitter/X! Thanks for reading and watching! DOWNLOADS: Gsmtk: https://drive.google.com/file/d/1Du1l3Nczbuy3MHrNsf-HNDH7FV1OyU4w/view Burst Files: https://drive.google.com/file/d/1oGJnAP4B0e18G-NPeuxuzuZOc1WpykCG/view LINKS Virus Total Scan Report: https://www.virustotal.com/gui/file/f003fa2cc97d6fb5867bc79a61b54ac0bb86b25a3733889dc05eb07d50874da4?nocache=1 COMMANDS: sudo apt-get install tshark -y perl -MCPAN -e shell install DBD::SQLite sudo add-apt-repository -y ppa:linuxgndu/sqlitebrowser sudo apt-get install sqlitebrowser -y cp -r -v ~/gsmtk/.omgsm ~/.omgsm sudo iptables -A INPUT -p UDP --dport 4729 -j DROP sudo ip6tables -A INPUT -p UDP --dport 4729 -j DROP sudo leafpad ~/.bashrc export PATH=$PATH:/home/username/gsmtk/bin mkdir tktest cd tktest tkinit.sh tkadd.sh tkgenstat.pl -u -s . -o stat.db sqlitebrowser -R ~/tktest/keys.db sqlitebrowser -R ~/tktest/stat.db [Replace the 2x '▓' with a 'greater than' symbol] sudo tshark -i lo -Y "gsm_a.dtap.msg_cc_type" -V 2▓&1 | sed 's/^[ \t]*//;s/[ \t]*$//' 2▓&1 | grep "DTAP Call Control Message Type:" [Replace the 2x '▓' with a 'greater than' symbol] sudo tshark -i lo -Y "gsm_sms" -V 2▓&1 | sed 's/^[ \t]*//;s/[ \t]*$//' 2▓&1 | grep "SMS text:" sudo wireshark -k -Y '!icmp && gsmtap' -i lo tkplay.sh tkconvert -h tkconvert -4 -d -f ~/tktest/new/bursts_20230302_1332_0_2215354_0a.dat SOFTWARE: - DragonOS LTS Final 18.04 - VMWare Workstation 15.5.6 - GSMTK - Wireshark/TShark - DB Browser for SQLite A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT!

An unknown individual who is definitely not myself, decoding H.323 voice transmissions on Ku-band DVB-S2 frequencies. DO NOT ATTEMPT TO DECODE SATELLITE TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

Regular viewers of my channel will know that I am a huge fan of the Osmocom-BB toolset. In this video, I thought I would throw together a tutorial on how exactly Osmocom-BB is used in the context of hobbyist GSM security research. In part two today, I showcase how it is possible to construct an experimental GSM sniffer using the branch of Osmocom-BB called 'burst_ind'. I also show the process of how a CP2102-based serial cable can be reprogrammed to handle the higher data rate required by this branch. I then provide a short demo of 'burst_ind' features and functionality at the end of the video (not without technical difficulties, unfortunately). Part 3 of this video series will cover the topic of how to decode GSM burst files captured with Osmocom-BB's 'burst_ind' branch. Stay tuned for that in the coming weeks. In the meantime, go and checkout my other videos on the subject in this playlist: https://www.youtube.com/playlist?list=PLqjhBzfQS7YL-vLIaXmD0-wGN5m8uhJwp This video (and channel) wouldn't be possible without the amazing Linux distribution, DragonOS FocalX. Friend of the channel, Aaron from the @cemaxecuter7783 YouTube channel works far too hard to provide this incredible Linux distro for us, free of charge. So please, go and subscribe to his channel, like his videos and follow him on Twitter/X! Thanks very much for reading and watching! DOWNLOAD LINKS - BURST_IND FIRMWARE & BINARIES: https://drive.google.com/file/d/16UsnOd9eLsnXxTrp_TFaT6VxjlJRpe9d/view COMMANDS - REPROGRAMMING CP2102 SERIAL CABLE: sudo dmesg | grep tty sudo pip install git+https://github.com/VCTLabs/cp210x-program.git git clone https://github.com/VCTLabs/cp210x-program.git cd cp210x-program sudo chmod +x cp210x-program sudo rmmod cp210x sudo dmesg | grep tty sudo python3 ./cp210x-program sudo python3 ./cp210x-program -f eeprom.hex sudo python3 ./cp210x-program -p -F eeprom.hex -w --set-baudrate 812500:FFE2,FFF4,1 --set-baudrate 406250:FFC5,FFE9,1 --set-baudrate 203125:FF8A,FFD3,1 sudo python3 ./cp210x-program sudo dmesg | grep tty - OSMOCON AND CCCH_SCAN USAGE: cd burst_ind sudo chmod +x osmocon && sudo chmod +x ccch_scan sudo ./osmocon -s /tmp/osmocom_l2 -m c123xor -p /dev/ttyUSB0 layer1.compalram.bin cd burst_ind sudo ./ccch_scan -i 127.0.0.1 -s /tmp/osmocom_l2 -a 975 HARDWARE: - Core i5 4th Gen PC - Motorola C117 Mobile Phone - Sysmocom Serial Cable SOFTWARE: - DragonOS FocalX R31 - Osmocom-BB 'fixeria/burst_ind' A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT!

Regular viewers of my channel will know that I am a huge fan of the Osmocom-BB toolset. In this video, I thought I would throw together a tutorial on how exactly Osmocom-BB is used in the context of hobbyist GSM security research. In part one today, I list all the hardware and software requirements to work with this software suite. Then, I proceed showcase how Osmocom-BB can be utilized to scan for GSM base transceiver stations (cell towers) in the local area. Next, I show my viewers how the control channel of a 2G cell tower can be decoded and the data viewed in Wireshark. Finally, I demonstrate the usage of the 'mobile' application, which allows telephone calls to be initiated and SMS messages to be send from the command line interface. Part two of this video series will cover the usage of the GSM-sniffing variant of Osmocom-BB, called 'burst_ind'. Stay tuned for that in the coming days. In the meantime, go and checkout my other videos on the subject in this playlist: https://www.youtube.com/playlist?list=PLqjhBzfQS7YL-vLIaXmD0-wGN5m8uhJwp This video (and channel) wouldn't be possible without the amazing Linux distribution, DragonOS FocalX. Friend of the channel, Aaron from the @cemaxecuter7783 YouTube channel works far too hard to provide this incredible Linux distro for us, free of charge. So please, go and subscribe to his channel, like his videos and follow him on Twitter/X! Thanks for reading and watching! HARDWARE: - Core i5 4th Gen PC - Motorola C117 Mobile Phone - Sysmocom Serial Cable SOFTWARE: - DragonOS FocalX R31 - Osmocom-BB - Wireshark - TShark (Optional) COMMANDS: - Check if your serial cable is detected by Linux: sudo dmesg | grep tty - Upload firmware to calypso phone: sudo /usr/src/Osmocom-BB/Bin/osmocon -s /tmp/osmocom_l2 -m c123xor -p /dev/ttyUSB0 -c /usr/src/Osmocom-BB/Firmware/e88/layer1.highram.bin - Initiate 'cell_log' application: sudo /usr/src/Osmocom-BB/Bin/cell_log -i 127.0.0.1 -s /tmp/osmocom_l2 -l cell_log.txt - 'Tail' command to view GSM base station scan: sudo /usr/src/Osmocom-BB/Bin/cell_log -i 127.0.0.1 -s /tmp/osmocom_l2 -l cell_log.txt - Initiate 'ccch_scan' application: sudo /usr/src/Osmocom-BB/Bin/ccch_scan -i 127.0.0.1 -s /tmp/osmocom_l2 -a 975 - Launch 'wireshark': sudo wireshark -k -Y '!icmp && gsmtap' -i lo - Launch 'tshark': sudo tshark -Y '!icmp && gsmtap' -i lo - Initiate 'mobile' application: sudo /usr/src/Osmocom-BB/Bin/mobile -i 127.0.0.1 -c /usr/src/Osmocom-BB/Config/mobile.cfg - Login to telnet interface: telnet 127.0.0.1 4247 - Enable calypso phone radio hardware for 'mobile' application: en conf t ms 1 no shut write exit exit - 'Mobile' application telnet commands: list show ms 1 show sub 1 show cell 1 sms 1 0062942 Hello, from Osmocom-BB! call 1 0062942 call 1 hangup call 1 answer sim remove 1 sim reader 1 A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT!

Over the past month, the YouTube algorithm has been promoting my GSM cracking video very heavily. This has caused a massive influx of new subscribers to the channel. Due to the complex topics covered in my videos, I thought I would make a meet-and-greet style video explaining the primary subject matters of the videos that I upload. - I explain a little about myself and my background - What this channel is all about - What this channel isnt about - Rules of my channel - How to contact me - Why I won't cover the topic of SS7 - Where I obtained my skills and knowledge - Basic usage of Linux, and how to learn the command line interface - A brief overview of software defined radio technology - Disclaimers and warnings So, welcome to all the new subscribers, and I hope you found this video helpful and informative! Please visit the @cemaxecuter7783 YouTube channel, and give Aaron a sub while you are there!

Recently I have begun my journey into DVB-S satellite TV receiving. And, more specifically, wildfeed-hunting and IP-link hunting. So far, I have been playing around with Intelsat-19 and Optus 10/C1/D3. But, repositioning the dish and aligning it manually between the two orbital positions was growing tiring. So, I picked up a cheap H2H mount in order to motorize my 90cm offset dish and (hopefully) dynamically switch between 166 degrees east, and 156 degrees east as needed. I have no idea if this will work, so for the time being, I consider it an on-going project. Using my TBS5927 USB DVB-S receiver, I am able to send DiSEqC 1.2 commands to the motorized mount using EBS Pro's positioning console. DiSEqC is short for 'Digital Satellite Equipment Control' and is communication protocol used for controlling satellite TV equipment, such as LNB switches, or in my case, dish rotators. Eutelsat developed the standard in order for it's customers to switch between various TV satellites serving the European continent. DiSEqC has now been widely adopted and is commonly found in most consumer satellite TV hardware. Now that the hardware has been setup and the dish motor tested, I will now have to align the dish so it rotates along the Clarke belt (geostationary ring) which is where most of earths communications satellites orbit. I actually have no idea how to do this, and the included instruction manual was very vague on how to perform this alignment. I guess I will have to spend this evening searching google and reading up on this topic! Thanks for reading, and watching!

DVB stands for 'Digital Video Broadcasting' and is an international open standard for digital television. Conceptualized in the late 1990's and fully adopted by the public in the early 2000's, it has become the de facto standard for the transmission and reception of digital TV worldwide. DVB-S is the satellite TV variant of this standard and facilitates the delivery of television transmissions from geostationary orbiting satellites to customers on the surface of the earth equipped with adequate receiving hardware, such as satellite dishes and dedicated set-top boxes. In addition to the satellite TV broadcast's contained inside the MPEG transport stream container format, IP traffic can also be piggybacked on this transmissions. Electronic program guides, set-top box firmware updates and even internet connections can be beamed down from the satellites to earth for customers and subscribers. In the modern day of satellite IP traffic delivery, GSE, or 'generic stream encapsulation' is generally used for piggybacking data into these DVB-S downlinks. GSExtract is a python tool for Linux coded by James Pavur and released during his BlackHat 2020 presentation on satellite security. It was developed with the intention of unpacking GSE encapsulated packets and decoding their contents. So in this video, I am showing how unencrypted IP traffic can be captured from Intelsat 19 (location 166 degrees east) using an old 90cm offset dish, a Ku-band LNB and a USB attached DVB-S receiver box. I am using the software called 'EBS Pro' in Windows 10 to tune into the desired transponder and using it's 'TS dump' feature, I record the GSE encoded packets to a file. On my DragonOS Linux machine, I then use GSExtract's '--stream' argument to essentially decode the incoming GSE packets in almost real time, and view their contents in Wireshark with the aid of the 'tail' command. Tail will read the .pcap file and pipe the decoded the output to Wireshark at regular intervals. I was very surprised to see that there is basically little-to-no encryption on this internet traffic. This is obviously a major security and privacy risk. So, if any of my viewers are customers of Intelsat's internet service provider, they should definitely use a VPN solution to secure their networks. Or even better, bring it to the attention of Intelsat's customer service department that your internet traffic is being beamed down to a large portion of earth's surface completely open and unencrypted. Thanks for reading and watching. DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY! INTERCEPTING INTERNET TRAFFIC FROM SATELLITE DOWNLINKS THAT WASN'T INTENDED FOR YOU IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT. YOU HAVE BEEN WARNED!

Back in 2022 (last year) some wild weather experienced at my home resulted in the destruction of my dual-use 27 MHz CB and 10 meter band vertical antenna. My good friend and amateur radio colleague Cameron VK3SWL (@VictorianDxer on YouTube) had a SIRIO New Tornado laying around and graciously posted it up to Darwin for me. Using my MINI1300 analyzer and a satellite dish tripod, I remove two of the ground-plane radials and lower the antenna down to lengthen the telescopic top section incrementally until I reach my target resonant frequency 28.3 MHz. This is roughly in the middle of 27 MHz CB channel 1 and the top-end of the 10 meter ham band. The final SWR reading was 1.3, good enough for me! Most off-the-shelf antennas are sold with a 'tuning chart' which lists various lengths and resonant frequencies, but I prefer to do it the old school way with an antenna analyzer, or a radio and an SWR meter! Eventually, this antenna will be getting permanently mounted to a wall-mounted 5.5 meter tall mast attached to my garden shed. Of course, no antenna project ever goes smoothly! The patch cable I was using between the analyzer and the antenna appeared to have a fault, giving me infinite SWR readings. So you will see me disappear while I try to dig up another patch cable! At the end of the video, I run a short coaxial patch cable to my Airspy HF+ Discovery software defined radio and unroll a USB extension cable from my PC indoors out to the antenna/SDR. Then it was testing time! The antenna works extremely well, far better than my previous 27/28 MHz vertical! All music played in this video was produced by my brother, Pengü on Soundcloud: https://soundcloud.com/anthonygrey/tracks Thanks for watching!

Chinese Military HF Communications 11032 KHz USB as received in Darwin Australia on the 23rd of July 2023. The data mode at the beginning could possibly be MIL-STD-188-110 Serial, and the MFSK data bursts in the middle of video are MIL-STD-188-141A Automatic Link Establishment (2G ALE). The HF radio operator is speaking Chinese language and saying 接电话请回答 and 收到请回答 which roughly translates to "If you can hear this, please answer the telephone". Received via an Airspy HF+ Discovery software defined radio and a center-fed dipole.

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite. Well, we're up to part 7 now and the series is going longer than expected. But the subject of the video pertains to the holy grail of GSM decoding, SMS interception. No hardware is required, excluding a working PC. Please refer to part one for a comprehensive list of the software needed for this tutorial. The only additional pieces of software needed are Wireshark and it's command-line variant, Tshark. Make sure you stick around until the end of a video for a bonus segment on getting GSMEvil2 working in DragonOS FocalX! I am uncertain if there will be part 8, as I am confident I have covered most of the important features of gr-gsm. Thanks for watching! COMMANDS: sudo wireshark -k -Y '!icmp && gsmtap' -i lo sudo tshark -Y gsm_sms -T fields \-e gsm_sms.tp-oa -e gsm_sms.sms_text -i lo DOWNLOADS: https://drive.google.com/file/d/1KZLvYN1g75QWC6xWsxCrV_KkmILQIGtQ/view?usp=drive_link

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite. Well, we're up to part 6 now and the series is going longer than expected. But the subject of the video pertains to the holy grail of GSM decoding, voice call interception. No hardware is required, excluding a working PC. Please refer to part one for a comprehensive list of the software needed for this tutorial. The only additional pieces of software needed are Wireshark and VLC Media Player. Stay tuned for part 7 in the coming days or weeks, where I will be demonstrating how SMS messages can be extracted from GSM data capture files. Thanks for watching!

DISCLAIMER: The GSM data used in the making of this video was recorded and decrypted with unanimous consent from the owner(s) for the purpose of demonstrating the 2G decoding features of gr-gsm and for evaluating cellular network security. DO NOT reproduce the steps in this video, EVER! This video needs no introduction. Due to it's complexity and difficulty, decoding 2G phone calls is considered by most to be the hardest task to accomplish in the realm of GSM decoding. Differing voice codecs, varying channel data rates, arbitrary allocation of frequency hopping and carrier-specific network configurations add too many variables into the mix to make it a straight-forward enough goal to achieve. In this video, I showcase the entire 2G voice decryption process from start to finish, excluding the actual recording of the GSM data. Due to the subject of this content being very sensitive from a legal standpoint, I will not be responding to questions in the comment section of this video (or via email) asking how phone call interception is achieved. I have annotated most portions of the presentation with brief explanations, so please watch the video and read the annotations very carefully. ANOTHER (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

Last month when I gained access to a real 2G cellular network, I demonstrated how a passive IMSI catching device can be assembled with a software defined radio and a Linux PC. An alternative method of constructing one of these devices is to substitute the SDR for a OsmocomBB compatible GSM mobile telephone. Like in the previous IMSI catching video, I am showcasing Simple-IMSI-Catcher-Script and GSMEvil2 which are two separate software tools used to accomplish this task. Check out my SDR-based IMSI catcher video here: https://youtu.be/kl3vGevirGc It should be noted that the 'burst_ind' branch of OsmocomBB is not strictly necessarily for catching IMSI's. The master branch included with DragonOS FocalX will work just fine for this purpose, 'burst_ind' was just what I was using at the time. NOTE: To use the 'burst_ind' branch of OsmocomBB, a Calypso cable with a 'CP2102' USB-to-serial converter chip must be used, and it has to be programmed with custom BAUD rates using the following tutorial: https://osmocom.org/projects/baseband/wiki/HardwareCP210xTutorial A high quality pre-made cable that works very well for the 'burst_ind' branch can be purchased from Sysmocom here: https://shop.sysmocom.de/Sysmocom-USB-serial-cable-CP2102-with-2.5mm-stereo-jack/cp2102-25  Thanks for reading and watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

The first time I showcased GSMTK by Jan Hrach, I was experiencing an SQL database error that was preventing me from making any further progress in getting it working in 2023. The cause of this error appeared to be the fact that my GSM burst .dat files dumped by the 'fixeria/burst_ind' branch of OsmocomBB originated from YateBTS and OpenBTS SDR-based rogue base stations. Now that I have had the opportunity to try out various GSM decoding tools on real 2G networks, I have made further progress with GSMTK. However, just like in my first video, I am once again stopped by another SQL database error. So for now, it's back to lab to try and solve this issue. Check out my other GSMTK video here: https://www.youtube.com/watch?v=v0KqI2Gsnto Thanks for reading and watching!

Recently I got the opportunity to test the gr-gsm toolset on a real 2G cellular network with a software defined radio, so here is another A5/1 cracking demonstration where I am targeting data that was destined for my own GSM mobile phone (no other private user information was captured during the recording of this data) LAPDm stands for 'Link Access Protocol - D channel' and represents a part of the GSM air interface that connects a cellular subscribers mobile phone to a base transceiver station (cell tower). Traffic relating to LAPDm is commonly seen when decoding GSM signals, and one particular packet of this type that is of interest to 2G hackers and security researchers alike is the 'func=UI' packet. 'Func=UI' packets are transmitted frequently on downlink channels when a GSM cell has nothing to do (e.g. when it has no data it needs to send to a mobile phone). And because the contents of these packets are constant and do not vary, they make a suitable target for performing a Known-Plaintext Attack. KPA's are a type cryptographic attack where the hacker or security researcher has access to a portion unencrypted data, but also has the encrypted version of that same portion of data. By comparing the plaintext and ciphertext versions of a segment of data, encryption keys and other secret information can be revealed. In the case of A5/1 cracking, the contents of a unencrypted GSM packet and a encrypted version of that same packet are XORed with one another to produce a pure A5/1 keystream of 114 bits in length. Hidden within this keystream is a 64-bit segment which could potentially match a value stored inside the precomputed A5/1 rainbow tables. Fundamentally, this is how Kraken works while it is performing the lookup process. Using Deka, a superfast portable A5/1 cracker utility that can use NVIDIA GPU's to reduce cracking times and a custom bash script, I am able to perform an XOR function on a known plaintext version of LAPDm func=UI packet with a 'guessed' ciphertext version. After some false positives and negative results, I finally generate some valid input to feed to 'find_kc' and reveal the encryption key used to secure the GSM communications destined for my mobile telephone. Most of the modern 2G networks that I recently evaluated the security of were observed using randomization in an attempt to thwart known-plaintext attacks on GSM. I noticed that raw bursts that defined LAPDm 'func=ui' packets had some bits flipped (binary one's that were flipped into a zero instead, for example). So these types of cryptographical attacks may not work on the more modernized and secure GSM networks. Thanks for reading and watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

Recently, I had the opportunity to play around with a real 2G cellular network. So here is a video demonstration of real-time, over-the-air SMS interception using an old Motorola GSM phone and DragonOS Linux. Most viewers of this channel should be familiar with the incredible OsmocomBB project by now, as I have uploaded plenty of videos showcasing it in the past. Using an old Motorola C117 mobile telephone from the mid 2000's with custom firmware loaded on it, a USB-to-serial cable and some software called OsmocomBB, it is possible to sniff SMS messages being downlinked from a GSM base-transceiver station. But not all 2G networks were created equal, however. This particular network operator has not enabled encryption, and mobile subscribers private text messages are being transmitted freely throughout it's coverage area in plaintext! I imagine unencrypted GSM networks are very rare at the time this video was recorded. After confirming the ARFCN my 2G handset is currently operating on, I configure OsmocomBB to monitor that frequency and proceed to send two text messages from my LTE smartphone, which are then downlinked from the GSM cell to 2G mobile phone. By utilizing Tshark and some command-line wizardry, the first text message appears in a terminal window, with the second SMS appearing in GSMEvil2's web GUI. This happens in almost real-time, with only a slight delay in the text messages appearing on my PC after sending them from my smartphone. It still boggles my mind the thought of people still using 2G/GSM in the modern day, despite having been proven insecure and broken for more than 13 years. Banking OTP's, two-step verification and various other pieces of sensitive private information are conveyed over 2G SMS. A very scary thought. While intercepting and reading your own SMS messages is fun and should keep you on the right side of the law, I strongly urge any viewers of this video to NEVER, EVER intercept anybody else's private user data except that coming from your own telephone. Wiretapping laws are strict and penalties are harsh in most countries around the world. It should be noted that the 'burst_ind' branch of OsmocomBB is not strictly necessarily for intercepting SMS messages. The master branch included with DragonOS FocalX will work just fine for this purpose, 'burst_ind' was just what I was using at the time. NOTE: To use the 'burst_ind' branch of OsmocomBB, a Calypso cable with a 'CP2102' USB-to-serial converter chip must be used, and it has to be programmed with custom BAUD rates using the following tutorial: https://osmocom.org/projects/baseband/wiki/HardwareCP210xTutorial A high quality pre-made cable that works very well for the 'burst_ind' branch can be purchased from Sysmocom here: https://shop.sysmocom.de/Sysmocom-USB-serial-cable-CP2102-with-2.5mm-stereo-jack/cp2102-25   Stay tuned for more GSM security research videos in the coming days. Thanks very much for reading and watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

Recently, I had the opportunity to play around with a real 2G cellular network. So here is a quick video of how a GSM voice call is intercepted using DragonOS linux, a software defined radio and gr-gsm. A good addition to any cellular security researchers inventory is an older Blackberry handset, in my case, a Bold 9700. These phones have an 'engineering screen' which contain a number of useful features for evaluating the privacy features of a 2G network. Firstly, you will see me navigate to the 'Sim Browser' menu and check if a 'Kc' session key has been assigned to my SIM card. After sending this phone a text message and calling it, the field was empty indicating that this network operator has not enabled encryption. Yikes. Secondly, you will see me browse to the 'Neighbor Cells' menu to lock the phone to a particular ARFCN. This will prevent it from jumping to another GSM cell while the phone call is in progress, allowing me to capture and record the downlinked data. Thirdly, you will see me navigate to the 'Voice Channel' menu and change the audio codec from AMR Full-Rate to just plain old GSM Full-Rate. This mobile network carrier uses AMR on full-rate traffic channels to encode phone calls, which gr-gsm is not capable of decoding. However, it can decode GSM full rate traffic channels perfectly fine. Lastly, you will see a screen recording of the voice traffic decoding and audio replaying process. I was actually really lucky recording this GSM capture file, no private user data belonging to anybody else was being transmitted on this cell at the time I made the phone call. Unfortunately I missed the DTAP packets relating to the call setup and other traffic channel related data as well. Boo. Typically, this mobile carrier sends GSM phone calls over frequency hopping channels. But I predict that about one in twenty phone calls are sent over non-hopping channels, and I was lucky enough to be dialing the phone number at the time this cell decided to assign voice calls to non-hopping traffic channels. Decoding 2G voice traffic on frequency hopping channels with gr-gsm is generally known to be impossible, or very VERY hard to do. And as such, mobile carriers enable frequency hopping on their networks as an extra layer of security to increase difficulty in interception of GSM communications. While intercepting and listening to your own phone calls is fun and should keep you on the right side of the law, I strongly urge any viewers of this video to NEVER, EVER intercept anybody else's private user data except that coming from your own telephone. Wiretapping laws are strict and penalties are harsh in most countries around the world. Stay tuned for more GSM security research videos in the coming days. Thanks very much for reading and watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

Recently, I had the opportunity to play around with a real 2G cellular network. So, here is a quick video of how passive IMSI catchers are constructed using a couple of Linux software tools and an RTL-SDR dongle. It is a common misconception that mobile phones are tracked via their telephone numbers or the IMEI number of the handset. IMSI is an abbreviation that stands for 'international mobile subscriber identity' and is the unique identifier of a mobile phone subscribers SIM card on a cellular network. IMSI numbers are used in most mobile phone communication generations from 2G, all the way up until the more modern 5G. The IMSI number of a SIM card is very well protected in 3G, 4G and 5G. However, in the case of the 2G mobile communication standard GSM, these unique identifying values are not so well protected from the prying eyes of governments, militaries, law enforcement and spy agencies. If the IMSI number of a surveillance target/victim is known, it can be used to track and monitor movements of a mobile subscriber. Typically, an IMSI-catcher is some form of 'active' device, performing a man-in-the-middle, false base-station attack to fool the victims 2G mobile phone into thinking it is connecting to a legitimate GSM cell. These devices are called a "StingRay" and are deployed by police, spies and soldiers for the purposes of tracking and surveillance of a target. In order to show viewers of my channel how insecure 2G GSM is, I have constructed a 'passive'-type IMSI catcher using DragonOS Linux, an RTL-SDR dongle, Simple-IMSI-Catcher script and GSMEvil2. Passive IMSI-Catchers are distinct from StingRay's because they are 'receive-only' and collect mobile subscriber IMSI values that are being sent over the control channel of a 2G base station, whereas a commercial StingRay products sit in between the 2G base-station and the victims mobile phone, and are therefore required to transmit data. In the first half of the video I am showcasing 'Simple-IMSI-Catcher' which is the python script running in the bottom terminal window. In the final half of the video, I am using GSMEvil2 which has a nice web interface/GUI. The sniffed IMSI data is blurred out for obvious reasons. Oh, and please don't try this at home! Thanks for reading and watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite. In the fifth installment of this video series, I will be demonstrating how frequency hopping channels are handled by showing some example usage of 'grgsm_channelize'. For details on the hardware and software required to do this, please refer to part one. The only additional piece of hardware needed is a wideband software defined radio. Stay tuned for part 6 in the coming days or weeks, where I will be demonstrating how voice calls and SMS messages can be extracted from GSM data capture files. Thanks for watching!

Recently, my first GSM cracking tutorial video went viral. But unfortunately, it was riddled with various errors and mistakes. In addition to this, it also relied on the very old GSM decoding software toolset Airprobe which is notoriously hard to compile and get running on newer editions of Linux. I managed to find a method of 2G cellular cracking that can utilize the much newer GSM decoding software suite called gr-gsm. This eliminates the need to run Airprobe in an older version of Linux and earlier release of GNU-Radio. Using the latest version of DragonOS FocalX, I show a potential workflow of how GSM communications are cracked in real-time from start to finish. This particular method using gr-gsm has been streamlined and simplified compared to the previous method using Airprobe. Dropping Airprobe from the requirements will no doubt make this method more accessible to most people who follow my channel that have an interest in cryptography and cellular decoding. I tried to make the fonts in the terminal window, wireshark and the text document as large a possible. But for a more immersive experience, please full-screen this video. The actual cracking tutorial segment begins at the 5 minute and 15 second mark. Thanks for reading and watching! LINKS: Cfile Download: https://github.com/ptrkrysik/gr-gsm/issues/456 COMMANDS: sudo wireshark -k -Y '!icmp && gsmtap' -i lo grgsm_decode -c voicecall_f952.0M_s2e6.cfile -f 952.0M -s 2e6 -m SDCCH8 -t 1 -p -v ./find_kc 10749739382471168565x 48 1152173 1152140 111111010101111110100001101011111100000000111101011000011111101001100100111101100001100111000110011000010000000010

It's finally here, fellas! The long awaited Kraken installation and testing video that so many of you have emailed me and commented on my videos about. I recently purchased a 2 terabyte SSD to improve my current Kraken PC, so I may as well use this opportunity to document all the steps required to achieve a complete A5/1 cryptographical research system. In part two, we view the outcome of the Rainbow Tables hard drive creation process before finally testing out the usage of Kraken and utilizing the find_kc binary to extract a KC encryption key from real GSM data. This tutorial turned out to be rather long, so I opted to split it into two separate videos. Thanks very much for watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED! PART ONE: https://www.youtube.com/watch?v=8MWzFyE4k8s COMMANDS: LAUNCH KRAKEN: cd cd kraken/Kraken sudo ./kraken ../indexes/ KRAKEN USAGE: crack 100000110100111111001110010101110101011111111010111011101101100000001001101101100001111000111010000110110001110000 quit FIND_KC USAGE: cd .. cd Utilities ./find_kc 10749739382471168565x 48 1152173 1152140 111111010101101110100001101011111100000000111101011000011111101001100100111101100001100111000110011000010000000010

Deka is a GSM hacking software tool from BRMLab in the Czech Republic. Coded for Linux by Jan Hrach, it was originally intended to be a port of the A5/1 cracking tool Kraken. Subsequently, it was completely rewritten and became a standalone alternative to Kraken. Back in 2010 when Kraken was released as part of the A5/1 Cracking Project, it was envisioned that leveraging ATI/AMD graphics cards would greatly improve cracking performance, as GPU's are well suited for cryptographic purposes. As the years passed and Kraken began to start showing it's age, there was no further development or modernization of it's code, so only older ATI/AMD graphics cards of the Radeon HD 4000, 5000 and 6000 series were supported. Deka is an A5/1 cracker that is written in OpenCL, which means it can utilize more modern GPU's for doing the cryptographic functions. The speed in cracking time is vastly reduced compared to running Kraken in CPU mode. On my old A5/1 cracking machine, with Kraken in CPU mode and a 5400 RPM NAS hard drive, I was seeing keystream cracking times exceeding 2 minutes and 20 seconds. Without any performance tuning of Deka, pairing it up with my GTX 1080 Ti graphics card and a Samsung SSD, I am seeing blazing fast cracking times of 7-8 seconds! Very cool! Cracking times of less than 5 seconds could be possible with some fine tuning. But I am happy enough with the current performance. I should note that because Australia has no active 2G networks since 2018, I am only using example GSM bursts sourced from the internet for demonstrating Deka's cracking ability. I have no interest in cracking real GSM communications, I just find cryptography interesting. Learn more about Deka here: https://brmlab.cz/project/gsm/deka/start Thanks for reading and watching! THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI CATCHING, SMS SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED!

It's finally here, fellas! The long awaited Kraken installation and testing video that so many of you have emailed me and commented on my videos about. I recently purchased a 2 terabyte SSD to improve my current Kraken PC, so I may as well use this opportunity to document all the steps required to achieve a complete A5/1 cryptographical research system. In part one, I give a brief introduction to Kraken and explain what A5/1 encryption is used for in GSM communications. I also go into detail about the hardware and software you will be needing. And finally, I give a practical demonstration of the steps necessary to compile and test Kraken, while also showing how a SSD is configured for storing the rainbow tables. This tutorial turned out to be rather long, so I opted to split it into two separate videos. Part two should be uploaded the following day. Thanks very much for watching! A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED! PART TWO: https://www.youtube.com/watch?v=1KTSQOQWPsU COMMANDS: DOWNLOAD AND BUILD KRAKEN: git clone https://github.com/joswr1ght/kraken.git cd kraken sudo touch /usr/include/stropts.h make noati TEST KRAKEN CPU MODE: cd a5_cpu ./a5cpu_test LIST STORAGE DEVICES ON PC: sudo parted -l WRITE RAINBOW TABLES TO HDD: cd cd kraken/indexes/ sudo python2 Behemoth.py /media/username/F2BA-C598/DRIZZLECHAIR/

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite. In the forth installment of this video series, I will be demonstrating how a GSM capture file recorded with a software defined radio can be decoded with the 'grgsm_decode' utility and using Wireshark, view the GSM data in a nice human-readable format. For details on the hardware and software required to do this, please refer to part one. The only additional software tool we need is Wireshark, which can be launched with the following command: sudo wireshark -k -Y '!icmp && gsmtap' -i lo Stay tuned for part 5 in the coming days, where I will be showcasing the usage of 'grgsm_channelize' and demonstrating it's ability to contend with wideband capture files recorded from GSM cells with frequency hopping enabled. Thanks for watching!

I'd probably be careful with this one, boys.... Check out the authors research paper here: https://syssec.kaist.ac.kr/pub/2023/wisec2023_tuan.pdf Read section 5 titled 'Security Applications'. I take no responsibility for any trouble you get yourself into while playing around with LTESniffer. Use at your own risk! I am using a BladeRF 2.0 xA4 software defined radio and a high-gain quad-band cellular base antenna to receive a local LTE cell. Due to the high bandwidth of LTE channels, RTL-SDR based receivers will not work and a higher end software defined radio will be required. The flavor of Linux I am using is DragonOS FocalX. If you don't have LTESniffer installed already, you can download the .deb package here: https://github.com/alphafox02/focalx_ppa/raw/main/LTESniffer_1.3.6_amd64.deb (LTESniffer won't work on DragonOS Focal 20.04, only on FocalX 22.04) I imagine you will need quite a powerful computer, as an LTE downlink sends data at a whopping rate of 1000 frames per second! My i7 Laptop seems to be coping alright with it. It only dropped a handful of frames in a couple of minutes. I probably wouldn't use a virtual machine for this, either. Bare-metal natively on your PC will always perform better than a hypervisor. The whited-out censored parts of the video relate to the frequency of the cell, and various bits of information that can be used to identify it. And then after about 25 seconds or so, some RNTI's begin to be displayed (Radio Network Temporary Identifier) and they are also censored for obvious reasons. Please study README.md on the LTESniffer GitHub page: https://github.com/SysSec-KAIST/LTESniffer Find the following text inside the readme file and repeat it to yourself over and over and over again until it is drilled into your brain: "LTESniffer can NOT DECRYPT encrypted messages between the cell tower and smartphones" Do not email me asking how to decrypt LTE, it is NOT POSSIBLE, and it probably NEVER WILL BE. Please, and thank you.

Gsmtk is a fork of the BRMLab GSM Toolkit by Jenda Hrach. It's purpose was to converge OsmocomBB with the A5/1 encryption cracking tool, Kraken. Join me in this video while I demonstrate some of the progress I have made in getting this (very old) software toolset working in 2023! Both the BRMLab GSM Toolkit and Gsmtk were coded and released at a time when the only software defined radios capable of capturing and decoding GSM data were the USRP series of SDR's, whose price tag reached in the several thousands at the beginning of last decade. Buying an old Motorola 2G mobile phone from the early-to-mid 2000's for $10 on eBay, as long as it contained the Calypso baseband chipset, allowed for a low barrier to entry into the world of GSM security research and hobbyist 2G hacking. The software toolset that utilized these 'Calypso Phones" is called OsmocomBB. Although the gsmtk project has more-or-less been abandoned by the author in recent times, it has always intrigued me as to why such a convenient tool for GSM hacking didn't gain more traction and become very popular. Admittedly, the author does state that their tools are incomplete, broken and are provided with little-to-no documentation. The people over at BRMLab (a Czech hackerspace) state on their GSM Toolkit page that interest in their tools dissipated in response to the plummeting purchase prices of entry level software defined radios such as the RTL-SDR and HackRF. Cheap software defined radios became the industry standard choice when it came to GSM sniffing and nobody cared about OsmocomBB anymore. Taking advantage of the OsmocomBB 'burst_ind branch, gsmtk provides everything needed for sniffing GSM data, such as the ability to record raw GSM frames to a file, parse the captured GSM data, search for and provide known plaintext GSM frames and 'guess' possible A5/1 keystreams. All of this is performed before feeding Kraken with the required input to finally crack the captured GSM data and obtain the Kc value. Now for some explanation on my current progress in getting Gsmtk working: I managed to get the gsmtk tool itself compiled and working in DragonOS 18.04 LTS ( after resolving various dependencies) I couldn't get OsmocomBB sylvain/burst_ind compiled on this version of DragonOS (I think it is related to libosmocore dependency) So in order to provide burst.dat files to feed gsmtk, I am using DragonOS FocalX 22.04 where I got fixeria/burst_ind compiled successfully and working well. From memory, I compiled the 'fixeria/burst_ind' Calypso firmware successfully too, but I can't remember how I did it. It took a very long time to get the cross-compiler working! Everything else should be straight-forward enough and demonstrated adequately in the video. As you will see, steps 5 - 8 don't seem to work, as there is some kind of SQL database error preventing the gsmtk from proceeding any further. After some digging with SQLite, I have discovered at the keys.db file is essentially empty and contains no information. I am certain that this is related to the fact that my burst.dat files contain no ciphered data for guessing and cracking. This is due to my YateBTS rogue BTS not having encryption turned on (and I can't figure out how to get encryption turned on with the free version) If anyone can provide me with some OsmocomBB burst_ind .dat files captured from a real cellular network (preferably your own recorded data, not somebody else's....) Please get in contact with me via email. During some reverse engineering a while ago, I figured out which binary in gsmtk was responsible for actually making sense of the burst.dat files generated by OsmocomBB burst_ind. 'tkconvert' is it's filename, and I discovered that it's possible to use it independently to decode the burst files, print the raw GSM data to the terminal window or a text file, and even send decoded GSMTap packets to wireshark! Pretty cool! Thanks for reading and watching!

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite. In the third installment of this video series, I show how it is possible to utilize 'grgsm_capture' to receive a GSM base transceiver station's downlink signal with a software defined radio and store the data to a file on a PC. For details on the hardware and software required, please refer to part one as nothing additional is needed for this. Stay tuned for part 4 in the coming days, where I will be showcasing the usage of 'grgsm_decode' and demonstrating it's ability to decode a captured .cfile recording of a GSM downlink signal. Thanks for watching!

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite. In the second installment of this video series, I show how the Broadcast Control Channel (BCCH) of a GSM base transceiver station (cell tower) is decoded in real time with an application called 'grgsm_livemon'. For details on the hardware and software needed for this, please refer to part one. The only additional application you will need is Wireshark for viewing and analyzing the decoded GSM data packets. You can launch Wireshark from the terminal with the following command: sudo wireshark -k -Y '!icmp && gsmtap' -i lo Stay tuned for part 3 in the coming days, which will cover the usage of 'grgsm_capture' and it's role in recording GSM down-link signals and storing them as a file on a PC. Thanks for watching!

Ever since I associated an email address with my YouTube channel back in February of this year, I have been inundated with emails requesting help with decoding GSM data and questions about the usage of gr-gsm. So in response to this, I thought I would put together a four or five part video tutorial series on how exactly GSM cellular data is decoded in Linux with the gr-gsm software suite, starting with how to find GSM base transceiver stations (More commonly known as cell towers) with an application called 'grgsm_scanner'. But before we delve into the usage of the GSM cell scanning feature of gr-gsm, I go through the software and hardware requirements which will enable you to to be able to decode GSM cellular data. I need to make a distinction between decoding and decrypting here. There is plenty of unencrypted data that can be viewed on GSM control channels. But generally, private mobile subscriber data such as voice calls, SMS messages and GPRS data are sent over encrypted traffic channels. Unless you know the encryption key (known as the 'Kc' value) gr-gsm will not allow you to arbitrarily listen to voice traffic or read SMS messages, unless the cellular carrier doesn't enable encryption on their network (Very rare in the current day, I would imagine) Some older phones tell you the Kc encryption key via a special 'engineering screen' and you can decrypt your own traffic for experimentation purposes. If the 'Kc' value is not known to you previously, the method of obtaining it is called 'cracking'. I have done plenty of videos on that topic in the past and it is beyond the scope of this video. This instructional series will be a very basic tutorial on how to use the most commonly known features of gr-gsm and get your started in the world of GSM decoding. So please don't comment "bro how to get kc with gr-gsm" because it is not possible! Stay tuned for part 2 in the coming days, which will cover the usage of 'grgsm_livemon' and it's role in decoding a GSM base stations control channel in real time. Thanks for watching!

The LimeSDR Mini 2.0 is a software defined radio from Lime Microsystems. It is the successor to the original LimeSDR Mini which was discontinued in 2022 due to global chip shortages. I received mine in March, after backordering it in January of this year. Does it live up to the hype of the original LimeSDR Mini? Join me as I give a very surface-level review of this transmit-capable, full duplex software defined radio and do some very basic testing of it's functionality. Thanks for watching!

Once again I am re-visiting the amazing free and open-source software called Osmocom-BB. I won't cover the overview and history of the project this time around, as I gave a fairly good run down in my last Osmocom-BB video. So join me as I test my second Calypso phone which was sourced on eBay from the UK. My setup and configuration differs from the previous video on this subject. I am using a branch of Osmocom-BB called fixeria/burst_ind. The original burst_ind branch was coded by Sylvain Munaut, but it is over a decode old and hasn't been maintained in recent years. So it is recommended to use Fixeria's burst_ind branch, which compiles perfectly without too many headaches on DragonOS FocalX. So what is Burst_Ind exactly? I am not a cellular engineer or computer scientist, but it appears to be a dedicated GSM sniffing version of Osmocom-BB with the capability to monitor mobile phone downlink/uplink connections and extract GSM data bursts and record them to a file. For an explanation on GSM bursts, please see my previous GSM hacking videos. In this video, I run an OpenBTS rogue base station with my new LimeSDR Mini 2.0 and then use the 'osmocon' binary to upload the custom firmware to the Motorola C139 via a USB serial cable. Next, I proceed to execute the 'ccch_scan' binary to begin sniffing the GSM downlink and uplink. When I disable flight-mode on my Samsung S8, a number of burst files with a .dat extension are created in the working directory. I power on a second phone and make a brief voice call and conclude the demonstration. I then attempt to open the captured bursts .dat files with a text editor. The bursts don't appear to be stored as plain text, but rather some other format. It seems as though I will have to do a lot more reading on practical applications for these .dat burst files. After trying for months to get burst_ind compiled and running, I am happy with the progress I have made so far! In order to run the fixeria/burst_ind branch of Osmocom-BB, a CP210x based USB-to-serial cable must be used for interfacing the PC to the Calypso phone. This is due to the fact that burst_ind requires non-standard baud rates for sniffing GSM data and dumping frame bursts. A good choice for pre-made cables (in my own experience) is the Sysmocom CP2102 serial cable. I own two of them and they work perfectly on my C117 and C139 Calypso phones. Here is the link to the Sysmocom web shop: https://shop.sysmocom.de/Sysmocom-USB-serial-cable-CP2102-with-2.5mm-stereo-jack/cp2102-25 Unfortunately, these cables will not work out-of-the-box for burst_ind. To program the serial converters EEPROM with the non-standard baud rates, a small python utility called 'cp210x-program' is used. Instructions on how to perform this procedure can be found at the following link: https://osmocom.org/projects/baseband/wiki/HardwareCP210xTutorial Instead of installing 'cp210x-program' with 'pip install' (this didn't work for me) just download the zip archive from git, extract it, use a terminal to CD into the directory containing the binary and then run the commands from there. Do this at your own risk, I won't take responsibility for you bricking your cable! A slight modification to the source code of Osmocom-BB burst_ind is also required. This involves locating the 'osmocon.c' inside the source code folder (do a file search to find it) opening it with a text editor and adding the line '#define I_HAVE_A_CP210x' somewhere near the top (without the single quotes, obviously) Another slight modification must be made to the Makefile inside the /src/ directory, too. Open it with a text editor and remove the word 'gprsdecode' from the line 'nofirmware: layer23 osmocon trxcon gsmmap gprsdecode virtphy' because I couldn't get burst_ind to compile with that feature enabled. Once the above changes have been made and the serial cable reprogrammed, you can continue follow along with the Osmocom-BB 'Getting Started' instructions page and get the burst_ind branch compiled, Link to that page is here: https://osmocom.org/projects/baseband/wiki/Software_Getting_Started If you are struggling with compiling Osmocom-BB burst_ind, I have uploaded the folder containing the compiled osmocon and ccch_scan binaries, in addition to the firmware .bin file. Use these at your own risk, and the firmware image is for E88 board calypso phones only! Thanks very much for reading and watching! DOWNLOADS: Burst_ind folder, with compiled binaries and firmware. USE AT OWN RISK: https://drive.google.com/file/d/16UsnOd9eLsnXxTrp_TFaT6VxjlJRpe9d/view?usp=share_link COMMANDS: 1. Change directory into the 'burst_ind' folder: cd burst_ind 2. Use 'osmocon' binary to load firmware onto Calypso phone: ./osmocon -s /tmp/osmocom_l2 -m c123xor -p /dev/ttyUSB0 layer1.compalram.bin 3. Use 'ccch_scan' binary to scan ARFCN #0 and dump GSM frame bursts: ./ccch_scan -i 127.0.0.1 -s /tmp/osmocom_l2 -a 0

Topguw is a Java application developed by Bastien Jalbert in 2015 for the purpose of converging all the steps required for cracking 2G GSM communications. It automates the process of extracting unencrypted frames, guessing the locations of encrypted versions of those frames and XORing the bursts together for generating input for Kraken's cracking utility. In this video, I am demonstrating how Topguw is utilized during the known-plaintext attack phase of cracking and subsequently obtaining the Kc value from the famous vf_call6 capture file. Because grgsm_decode isn't capable of outputting GSM bursts in the correct format, Airprobe patched for GNU-Radio 3.7 is required by Topguw, along with gsmframecoder. The folders containing these software tools were copied to the /root/ directory, as required by Topguw (you can also point Topguw to the directory containing these tools via the 'config' menu). Because Airprobe requires a decimation rate to be inputted for decoding GSM and printing the raw bursts, 174 is entered via the config menu. If 174 doesn't deliver results, you can try entering 112 for USRP1 recordings, 64 for RTL-SDR recordings and 32 sometimes worked for me on other recordings. Only attempt to crack your own SMS messages and voice calls, or capture files uploaded with permission by the owner of the data for the purpose of demonstrating the use of these hacking tools. Never attempt to intercept private telecommunications from any other mobile network subscriber, but yourself! Thanks for watching! LINKS: Topguw Github Page: https://github.com/bastienjalbert/topguw Bastien Jalbert's Topguw Video: https://www.youtube.com/watch?v=QG2iIxv5smw

EDIT: Please see my latest GSM cracking video that showcases a more streamlined workflow and eliminates the requirement of Airprobe! https://youtu.be/-_jcGLlJTIk My GSM cracking content has been getting quite a lot of attention lately. Previous videos of mine relating to this topic were only boring screen recordings with no real explanation on what steps are required to crack the A5/1 stream cipher and decrypt GSM traffic by obtaining the Kc value. I was bored one day and decided to present a live-style workflow of how hackers and security researchers 'crack' 2G cellular communications in real-time. Be warned that if you don't have an interest in cryptography or cellular network security, you might find this video rather boring. The GSM capture file used in this video, to my knowledge, has never been publicly cracked before. 'capture_941.8M_112.cfile' was recorded and uploaded with permission by the owner of the data themselves as a decoding example for testing Airprobe. I make a few mistakes in the video that I can't be bothered editing out. But they are not critical, just myself misreading a number at the 10 minute mark somewhere, and saying the wrong name of a software tool at 17 minutes. Additionally, l am not a GSM technology engineer, nor a cryptography expert. I do my best to explain these concepts in a simple and easy to understand way. But due to my limited knowledge of these subjects, it's possible that some of this information may be incorrect or lacking context. However, this video will still allow you to crack a real GSM capture file if you are able to follow along with my flip-flopping style of presentation. Haha. But please, only replicate this tutorial on GSM data that originated from YOUR OWN mobile phone. Do not attempt to decrypt private telecommunications from any other cellular subscriber, EVER. Thanks for watching! Archive Download (GSM capture file, cracking notes etc.) https://drive.google.com/file/d/1yeMogszZU8221AVCyJ_DjsmwEZ3eCJAh LAUNCH WIRESHARK: sudo wireshark -k -Y '!icmp && gsmtap' -i lo AIRPROBE DECODING USAGE: cd /home/username/airprobe/gsm-receiver/src/python sudo ./go.sh capture_941.8M_112.cfile 112 0B sudo ./go.sh capture_941.8M_112.cfile 112 1S & bursts.txt (put a greater-than symbol after the '&') XOR.PY USAGE: cd /home/username/kraken/Utilities/ ./xor.py 000000011111010101010000100000010001010111010101000010100001010001111101010001000010000000000101110101010100000010 100011101110001001000110001101001001111100001001010110010011000010101111111010010011101101110000100110100111000111 KRAKEN USAGE: cd kraken/Kraken sudo ./kraken ../indexes/ crack 100011110001011100010110101101011000101011011100010100110010010011010010101011010001101101110101010011110011000101 FIND_KC USAGE: cd /home/username/kraken/Utilities/ ./find_kc 10931293685685996799x 11 2580567 2580534 100101111101011101100011100001001101001010111110000011110101110000010010011100000100001000100010111110010101100000 AIRPROBE DECYPTION USAGE: sudo ./go.sh capture_941.8M_112.cfile 112 1S 10A29FC292C8D7EF A (VERY STRONG) DISCLAIMER: THIS VIDEO WAS MADE FOR THE PURPOSES OF EDUCATION AND EXPERIMENTATION ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT!

GNU-Radio and the URSP, a software project and a programmable radio. The two concepts that started the affordable software defined radio revolution in the early-to-mid 2000's. Before the breakthroughs in cheap modified DVB-T dongle SDR's came the Universal Software Radio Peripheral, a product designed and assembled by Ettus Research in the year of 2005. While software defined radio is not a new concept (the idea of a software radio date back to the 1970s') SDR was an emerging technology in the late 20th century and was generally only available to researchers and governmental agencies with unlimited resources, such as defense departments. Fast forward to the year 2001 and GNU Radio was born. As an open-source and free software project, it's aim was to produce a development kit for implementing a RF signal processing framework for software programmable radios. What soon followed was the launch of the USRP1, a modular and expandable transmit capable SDR. Designed in 2003/2004 by Matt Ettus himself (founder of Ettus Research), it was touted as one of the first 'affordable' software programmable radios and it operated in perfect harmony with GNU-Radio. In 2010/2011, work was being conducted behind the scenes by Antti Palosaari, Eric Fry and Steve Markgraf of Osmocom on modifying cheap DVB-T tuner dongles to operate as a software defined radios. By 2012, the cat was out of the bag and suddenly, SDR's went from costing four figure digits amounts of money, to less than 30 dollars. The RTL-SDR was born. So join me in this video while we review and test this 18 year old example of SDR history that I acquired recently. I have no idea what I am going to use this thing for, but it is very cool, none-the-less! Thanks for watching!

In a previous video a few weeks ago, I showcased some preliminary usage of Osmo-gmr and it's role in capturing and decoding downlinked data from Thuraya satellites. After (a lot) more reading and experimentation, I have managed to learn more about Osmo-gmr and enhance the previous setup to greatly improve capturing and decoding downlinked data from Thuraya-3 at 98.5 degrees east (which services the eastern hemisphere) Instead of utilizing a very old GNU-Radio flowchart for capturing and recording GMR signals with an RTL-SDR, I am instead using the more modern gmr1_rx_sdr.py python script. Due to this script having not been updated for later versions of python, It isn't compatible with newer versions of DragonOS Linux. Therefore, I am using DragonOS 18.04 LTS instead. Gmr1_rx_sdr.py is capable of capturing and recording multiple ARFCN's simultaneously. In this example, I have observed that ARFCN 1062 (a spot beam that provides coverage to northern Western Australia) contains the GMR1 control channel and often assigns ARFCN's 1063, 1064, 1065 and 1066 for traffic channels. These channels may have data, voice or messages onboard, for example. After one gigabyte of data has been captured from each of the Thuraya satellite downlink ARFCN's, I utilize the gmr1_rx_live binary to decode all of the capture cfiles simultaneously. While the data is being demodulated and decoded, you will see Wireshark beginning to populate with packets of data. Similar to Iridium and GSM, these packets relate to the regular every day functions of a cellular network. The Thuraya satellite traffic wasn't that interesting today, compared to when I was playing around with osmo-gmr yesterday evening. But this video should give you a good idea of what you can expect if you replicate this! My next steps are to figure out 'gmr1_ambe_decode' for voice decoding (not decrypting), analyze some more packets in Wireshark, and monitor some ARFCN's from other spot beams. Thanks for watching! LINKS: Gmr1_rx_live Explanation By Sylvain Munaut https://www.mail-archive.com/[email protected]/msg00021.html Thuraya Spotbeam/ARFCN Map (Unknown Author) https://www.google.com/maps/d/viewer?mid=1nWqrcNvJimgAa1YTbobE9TAQ5T4 COMMANDS: ./gmr1_rx_sdr.py -s 10e6 -a 1062 -a 1063 -a 1064 -a 1065 -a 1066 -B L -f 155793e4 -g 30 --args 'airspy=0,bias=1' gmr1_rx_live 4 1062:arfcn_1062.cfile 1063:arfcn_1063.cfile 1064:arfcn_1064.cfile 1065:arfcn_1065.cfile 1066:arfcn_1066.cfile SOFTWARE: - DragonOS 18.04 LTS (bootable USB) - GNU-Radio 3.7 - Osmo-gmr (sylvain/live branch) - Wireshark HARDWARE: - Airspy R2 Software Defined Radio - RTL-SDR Blog Active L-Band Antenna - 90cm Offset Satellite Dish - RG58 Coaxial Feedline - 8th Gen i7 Laptop - USB Extension Cable

After many weeks of reading and tinkering, I have finally been successful in cracking the famous 'vf_call6' GSM capture file by SR Labs and acquiring the 'Kc' value, which is the decryption key that allows interception of 2G voice calls and SMS messages. I won't delve into the history and background of GSM security, Kraken or the A5 stream cipher as I covered that in a previous video. My goal of this video is to show a potential work flow of how 2G communications are 'cracked' and make it easy enough for anyone to follow along and replicate. Experts in the field of GSM hacking will have noticed that I omitted a critical step in this tutorial, the 'guesser' step. 'Guessing' is a stage of the known plaintext attack which involves predicting where the next encrypted data packet is after the ciphering begins. Typically, the target data packet (example, a 'system information type 5' packet) is located and recorded before the ciphering begins. When a phone call is initiated or an SMS sent, the A5/1 encryption starts and a 'system information type 5' will ultimately be repeated in an encrypted form, somewhere. By counting frame numbers, the encrypted version of the target packet can be 'guessed' and ultimately used to find the decryption key. This is referred to as the 'known plaintext attack vector' by experts. 'Guessing' involves moving a lot of data around manually and can be very time consuming, often failing more than being successful. Software tools have been developed to automate the guessing process such as pytacle, topguw, autokraken, brmlab gsm toolkit and gsmtk. But these are often incomplete, broken or have little to no documentation on how to use them. Hackers often write their own private guesser tool and neglect to share them with the community for fear of legal repercussions. Fair enough, in my opinion. Writing such a tool is far beyond my technical knowledge of coding. Because the SR Labs example data capture file is provided with the decryption key, we can compare an unencrypted packet (In this case, a LAPdm func=UI packet) to an encrypted version of the same packet. A user in the A51 mailing list did this and ultimately discovered which packet, frame and bursts were used to decrypt the vf_call6 capture file. Everything else should be self explanatory and easy enough to follow along with. I will upload a copy of the a5-1 directory I used to make this video (link below) containing the capture file, the burst output text file, the GSM audio file, the cracking notes, and a text file containing the exact commands to run. Place it in your /home/*username*/ directory. Thanks for watching! 'a5-1' folder download: https://drive.google.com/file/d/1DjALQKzJXaG2fuutnDC0WYT3XzMCUz4P/view?usp=sharing SOFTWARE: - DragonOS 18.04 LTS - GNU-Radio 3.7 - Airprobe Patched For GNU-Radio 3.7 - Wireshark - Kraken - Gr-gsm (Not strictly necessary, but better for extracting audio) LINKS: '[A51] Which Burst are XOR-ed in SRLABS test capture??' Jasper Kanbier https://www.mail-archive.com/[email protected]/msg01014.html '[A51] Finding Kc with Kraken (dotting the i's)' Frank A. Stevenson https://www.mail-archive.com/[email protected]/msg00654.html 'GSM Cracking: SMS w/ Kraken' Crazy Danish Hacker https://www.youtube.com/watch?v=PExa5sC4sbE GSM cfile download (rename to 'vf_call6.cfile') https://github.com/ptrkrysik/test_data/raw/master/vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile COMMANDS: STEP 1: cd /home/username/airprobe/gsm-receiver/src/python/ sudo ./go_usrp2.sh ~/a5-1/vf_call6.cfile 174 1S & ~/a5-1/vf_call6_bursts.txt (Put greater-than symbol after '&') STEP 4: cd /home/username/kraken/Utilities/xor.py 000000011111010101010000100000010001010111010101000010100001010001111101010001000010000000000101110101010100000010 110111100001010110000011011000100000001110100001001001011110111111001111111100101011101010110111100000000000000010 STEP 5: cd kraken/Kraken sudo ./kraken ../indexes/ crack 110111111110000011010011111000110001011001110100001011111111101110110010101101101001101010110010010101010100000000 STEP 6: /home/username/kraken/Utilities/xor.py 101010111111111101000000101010101111111111110100000000100010111111111111010101000000001010101011011101010000001000 101000110011111011000000011010001011010001111101100010010111001011001010000010101100101101101110111000101110010011 STEP 7: /home/username/kraken/Utilities/find_kc 3817426806014301180x 8 1331411 1331378 000010001100000110000000110000100100101110001001100010110101110100110101010111101100100111000101100101111110011011 STEP 8: grgsm_decode -c /home/username/a5-1/vf_call6.cfile -s $((100000000/174)) -a 725 -m TCHF -t 5 -e 1 -k 1EF00BAB3BAC7002 -d FR -o /home/username/a5-1/speech.au.gsm DISCLAIMER: THIS VIDEO WAS MADE FOR EDUCATIONAL AND EXPERIMENTATION PURPOSES ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON CELLULAR NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED.

'Music 4 Joy' Radio Show By Media Broadcast GmbH as received in Darwin, Australia on the 28th of February 2023 at 13650 kHz. Somewhat of a HF oddity, this radio station appears to broadcast on Tuesdays and Thursdays between 22:30 and 23:00 Australian Central Standard Time. Transmitted from Germany and beamed towards Asia, this broadcast typically repeats the same loop of audio over and over again and it is speculated that there is an underlying data transmission mixed into the music. The music loop changes from broadcast to broadcast and was previously observed transmitting a dead AM carrier with no audio modulation. A HF listening enthusiast from Japan who frequents the WRTH - World Radio TV Handbook facebook group ultimately discovered the radio shows name, media company and transmitter location. Many thanks to him for identifying this obscure HF oddity.

The Thuraya Telecommunications Company based in the United Arab Emirates is a provider of satellite voice and data services via it's two geosynchronous satellites, Thuraya-2 and Thuraya-3. Osmo-GMR is an open source software project from Osmocom that provides a set of tools used for capturing and decoding data downlinked from the Thuraya satellites to devices on earth. These may be satellite phones, or mobile data terminals. GMR stands for GEO (Geostationary Earth Orbit) Mobile Radio and is an ETSI standard similar to 2G/GSM, but intended for use on satellite phones, as opposed to terrestrial mobile telephony. Private user data such as voice calls and SMS messaging are encrypted with a flavor of the A5 stream cipher called 'A5-GMR-1' that closely resembles A5/2 from the GSM standard. Omso-GMR does not allow decrypting of Thuraya downlinked data unless the 'Kc' encryption key has been supplied, but it does allow decoding of the GSM layer via wireshark. It's a bit of a mess how I am managing to capture Thuraya satellite data at the present time. I have an premade Ubuntu 12.04 virtual machine image with GNU-Radio 3.6 installed and the 'osmo-gmr-rtl.grc' flowgraph for capturing the specified ARFCN/frequency with an RTL-SDR dongle. At a later date, I intend to figure out proper usage of 'gmr1_rx_sdr.py' in Ubuntu 20.04 with GNU-Radio 3.7 and test all my SDR's to see which is the best performer at capturing (Airspy R2, HackRF, BladeRF 2.0, RSP1A and my newly acquired USRP1) Osmo-gmr appears to use SoapySDR source for SDR connections, so it should possible to use most SDR radios! For decoding of the Thuraya satellite data, as you can see in this video, is a DragonOS 18.04 LTS virtual machine with GNU-Radio 3.7 installed and the sylvain/live branch of osmo-gmr compiled and installed. I first decode two separate data capture examples (2 files of each) provided by the Osmocom team and show the decoded packets in wireshark. Next, I show how a PCM .wav audio file of a Thuraya phone call is extracted from the sample data capture, but It was encrypted and I forgot to turn my volume up (whoops!) It just sounds like garbled rubbish anyway. You didn't miss much. Lastly, I show 6 packets of data decoded in wireshark which I pulled down from Thuraya-3 @ 98.5E on my 90cm offset dish, RTL-SDR blog L-band antenna and RTL-SDR v3 dongle. The capture file was only a minute of recording time, is about 100 mb in size and only contained 6 packets of data. Obviously I have a lot more to learn about the GMR mobile phone standard and how the decoding tools work. Thanks for watching!

WPA, or Wi-Fi Protected Access is a family of security protocols used for the purpose of encrypting data between Wi-Fi access points and client devices. Introduced to the Wi-Fi standard in the year 2000 and becoming widely deployed by 2003, it's creation had the purpose of replacing WEP (Wired Equivalent Privacy) security on wireless networks due to it's predecessor becoming more and more susceptible to security vulnerabilities. Just like in my previous WEP cracking video, I show how it is possible to utilize Aircrack-ng running in Linux to obtain the password of a WPA protected wireless hotspot. This time, I try my best to show what a possible workflow could like when cracking a Wi-Fi networks password. Unfortunately, I couldn't force Ubuntu's hotspot feature to use WPA2 security. This isn't a problem though, because the method of cracking WPA2 passwords is identical to WPA. I should also note that this hotspot was setup by myself, on the same PC that the cracking tools are running on using a second wireless adapter. I DID NOT attempt to break into my neighbor's, or anybody else's Wi-Fi network for the purpose of making this video. A Wi-Fi Deauthentication Attack is a kind of denial-of-service (DOS) performed by a malicious user that sends deauthentication packets to a target client on the access point. The purpose of this step is to force the client device to disconnect and then reconnect to the access point so that the authentication handshake can be recorded to a Wireshark packet capture file. A 'wordlist' generally consists of a text document containing a dictionary of plaintext passwords to be utilized during the brute force attack. These files can range from tens of megabytes in size, to multiple gigabytes. To speed up the cracking process, a text document was created containing the Wi-Fi hotspots password (password123). This phase of the cracking process will generally take a very long time, in the range of days to months, depending on the PC hardware and the size of the wordlist. Thanks for reading and watching! HARDWARE - Alfa AWUS036ACM Wi-Fi adapter SOFTWARE - DragonOS Linux - Aircrack-ng

A5/1 is a encryption algorithm developed in 1987 to provide secure communications over the GSM (2G) mobile telephone standard. Until the widespread adoption of A5/3 (KASUMI), it was considered to be the strongest form of encryption provided by the A5 family of security protocols. To my (very limited) understanding of how GSM security works, when private user data is about to be transmitted or received (e.g. voice call or SMS message from a cellular network subscribers telephone) an authentication request is sent by the base station (tower). If the users mobile phone responds in the correct way expected by the base station, a 64-bit 'session key' (commonly known as the 'Kc' value) is generated by the telephones SIM card and the base station tower independently. If these values match, the authentication is successful and encrypted communications can commence. Obtaining the 'Kc' value is easy if you have an older GSM phone such as a Blackberry, or an early iPhone or Samsung. SIM card readers can also obtain this value, as can Osmocom-bb. All of these methods make reading your own SMS messages and listening to your own voice calls easy with tools such as Airprobe and gr-gsm. If the 'Kc' encryption key isn't previously known, and some A5/1 secured GSM data has been captured via software defined radio, the process of obtaining the secret key is called 'cracking'. Kraken is a piece of free open-source software developed in 2009 and publicly announced in 2010. It enables a type of time/memory/data tradeoff attack using 1.5 Terabytes of pre-computed "rainbow tables" and can be used to obtain the 64-bit encryption key. It is a very technical and involved process and vast knowledge of cryptography and GSM authentication must be known before trying to attempt this. In this video, I am following instructions posted in the A5/1 mailing list by Frank, the author of Kraken. Using a sample GSM 'burst', I show how it possible to retrieve the 64-bit secret key. The PC I am running the A5/1 cracking tools on is a very old dual core i3 H61 machine and the hard drive containing the rainbow tables is a NAS 5400 rpm SATA HDD. Not the most optimal setup as you can see, since it requires more than two minutes to 'crack' the key. With modern PC's, it's possible to reduce this time to a minute or less. Thanks for reading and watching! LINKS: Kraken Tutorial: https://web.archive.org/web/20141227210334/https://lists.srlabs.de/pipermail/a51/2010-july/000688.html Kraken GitHub: https://github.com/0xh4di/kraken COMMANDS: 1. START KRAKEN: cd /home/username/kraken/Kraken sudo ./kraken ../indexes/ 2. TEST KRAKEN: test 3. CRACK GSM FRAME BURST: crack 111000110011110100011100001000100001011111010101110001101001111010011000010111110001110000101110111000111100111101 4. EXIT KRAKEN: quit cd 5. FIND_KC: /home/username/kraken/Utilities/find_kc 11917246171133803893x 37 3811424 3811417 011100101011101011101111110101101001110111110111010110111001111100101100010110000110100011010110010101110111101111

All the way back in 2010, Karsten Nohl of Security Research Labs in Germany delivered a talk at the Blackhat hacker convention. In this presentation, titled 'Breaking GSM Phone Privacy,' he showed how it was possible to decrypt and decode GSM data from cellular mobile networks. The software tools for Linux showcased in this presentation were titled 'Kraken' and 'Airprobe.' I intend to make a video about Kraken at a later date, but this video will focus on Airprobe to show how mobile phone hackers intercepted and monitored voice calls and SMS messages back in the early 2010s. Ultimately, Airprobe became obsolete due to the software not being updated for later versions of Linux and GNU-Radio. Later, an individual by the name of Piotr Krysik got busy expanding on the Airprobe codebase and modernized it to what would eventually become the software tools known as 'GR-GSM' to which I have showcased in videos previously. Using the SRLabs Airprobe tutorial (I had to use the Wayback Machine to access it, link below) I enter the various commands to decrypt and decode the famous 'vf_call6' data capture file of a real phone call on an actual cellular carriers' GSM network and towards the end of the video, I play the decoded voice traffic. I believe that this test file was recorded by the author of Airprobe themselves and was distributed voluntarily with the encryption key that he retrieved from his own telephone. So, I should reaffirm strongly that I have not, and will not EVER intercept any private communications because Australia has not had a 2G network operational since 2018. Decryption of the test file is possible because the encryption key (called 'Kc' in the GSM engineering speak) is supplied. There is a number of methods known for obtaining the Kc encryption key of your own mobile telephone and voice calls on GSM, mainly utilizing older telephones like a Blackberry which can display the value, or using SIM card readers to read it directly from the SIM card. Decrypting 2G voice calls and SMS's when the encryption key isn't known to you already (very naughty!) is called 'cracking' and involves using a software tool called 'Kraken' and the process of obtaining the key is a very involved and technical process that relies solely on the hope that a particular mobile phone carrier network uses the A5/1 cipher for protecting it's subscribers data. Whether there is any GSM cell phone networks still using A5/1 encryption operating in 2023 is anyone guess, but I highly doubt it. In the future, I hope to try and capture data from my own private test 2G network that uses YateBTS/BladeRF and use Airprobe to decode the voice and SMS messages sent between my own smartphones. But this version of Airprobe, GNU-Radio and Ubuntu is very old and only supports the outrageously expensive Ettus USRP software defined radios. There is a patched version of Airprobe for GNU-Radio 3.7 that supports the RTL-SDR and, with some tweaks, the HackRF and BladeRF of which I own all three. Another project for the future. Thanks for reading and watching! LINKS SRLabs.de Airprobe Tutorial https://web.archive.org/web/20160310053005/https://srlabs.de/airprobe-how-to/ Airprobe Compiling Tutorial https://www.rtl-sdr.com/rtl-sdr-tutorial-analyzing-gsm-with-airprobe-and-wireshark/ Ubuntu 12.04 ISO: (Pre-installed GNU-Radio 3.6 and Libosmocore) https://archive.midnightchannel.net/zefie/linux/ubuntu/ubuntu-12.04.2-custom-sdr-amd64.iso SOFTWARE: - VMWare Workstation 15 - Ubuntu 12.04 Virtual Machine - GNU-Radio 3.6 (Needed for Airprobe) - Libosmocore (Needed for Airprobe) - Random other dependencies? (libtalloc-dev 2.1.0, I think) - Libgsm-tools 1.0.13 (making GSM audio playable) THIS VIDEO IS MADE FOR EDUCATIONAL AND EXPERIMENTATION PURPOSES ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALLI NTERCEPTION ON GSM NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND PRISON TIME! YOU HAVE BEEN WARNED.

WEP stands for Wired Equivalent Privacy and was the primary Wireless LAN (Wi-Fi) security protocol from its inception in 1997 until 2004 where it was superseded by WPA (Wireless Protected Access.) In recent times, WPA2 and WPA3 are the preferred methods of securing a Wi-Fi network. Aircrack-ng is a software suite of tools used for penetration testing and wireless LAN network security assessment. Using DragonOS and Aircrack-ng, I demonstrate how it is possible to crack an ‘open’ key WEP secured Wi-Fi hotspot and retrieve it's password in a matter of minutes WEP was essentially rendered obsolete early last decade by its successor WPA and I highly doubt there would be any WEP secured Wi-Fi networks around in 2022. However, Aircrack-ng is a fun and well documented method of performing Wi-Fi password cracking experiments on your own hotspot. My next video on Wi-Fi hacking will constitute how a brute force dictionary attack on a WPA/WPA2 password is possible with Aircrack-ng. Thanks for reading and watching!

The newest addition to my cellular hacking inventory is an old Motorola C117 sourced from eBay and a serial cable from Sysmocom in Germany. The significance of this 2G GSM mobile phone from the mid 2000's is that it's onboard baseband chip (the processor that controls all the radio functions of a mobile telephone) is a Texas Instruments 'Calypso.' The classified internal documentation for the TI Calypso chip was publicly leaked via the internet and ultimately led to the extensive reverse engineering of it. OsmocomBB is a free and open-source software project from Osmocom that stemmed from these leaked documents and reverse engineering efforts. In addition to the C117, OsmocomBB supports many other GSM mobile telephones containing the Calypso chipset. In this video, I am taking a preliminary look at some of the basic functions of the OsmocomBB 'mobile app' which can be loaded after the custom Layer 1 firmware has been uploaded to the phone. Then commands can be sent via terminal to control the functionality of the phone, all from software! Very cool. I send some SMS messages and make some voice calls to a Samsung S8 phone, among other commands (mainly information about the cell, the subscriber etc.) Australia switched off all of it's GSM networks back in 2018, so I am running YateBTS with a BladeRF 2.0 xA4 to simulate a small 2G cellular network. Thanks to @cemaxecuter7783 his amazing DragonOS linux! NOTE: I have received a lot of emails recently from individuals having issues with uploading the firmware .bin files to Calypso phones. From what I can see, the contributing factor causing these issues appear to be that a virtual machine is being used, or a serial/USB cable that they constructed themselves is being used. Osmocom-BB will not work in a virtual machine and it is always better to install Linux directly onto your PC. If you aren't a regular Linux user, make a bootable USB to preserve whichever operating system is installed on your computer. Bare-metal Linux is always the better option for avoiding incompatibility issues with vitalization and USB passthrough. I don't have much experience with custom home-made Calypso data cables, however I recommend buying a pre-made CP2102 cable from Sysmocom. I own two of these cables and they are of very high quality and work perfectly for Osmocom-BB on bare-metal Linux. COMMANDS: sudo /etc/Osmocom-BB/Bin/osmocon -s /tmp/osmocom_l2 -m c123xor -p /dev/ttyUSB0 -c /etc/Osmocom-BB/Firmware/e88/layer1.highram.bin sudo /etc/Osmocom-BB/Bin/mobile -i 127.0.0.1 -c /etc/Osmocom-BB/Config/mobile.cfg telnet 127.0.0.1 4247 sudo tshark -Y '!icmp && gsmtap' -i lo HARDWARE: - Motorola C117 - Sysmocom Serial Cable - i7 8th Gen Laptop SOFTWARE - DragonOS Focal - OsmocomBB

Download OpenEar 1.7 here: https://drive.google.com/file/d/1IJsPDXn678yKm8GZs7u0MMTtX95zrPtx/view?usp=share_link Back in early 2020, there was a lot of hype in the Software Defined Radio scene about a standalone Windows application that could decode multiple commercial digital radio systems. And, it took direct control of the RTL-SDR to eliminate the need for an SDR program and virtual audio cables. Sounds good, doesn't it? Shortly after OpenEar's release, it became apparent the app used open-source code and was in direct violation of GPL software licensing. The source of this drama and controversy appeared to stem around the TETRA decoding component, which led the author of OpenEar to disable that functionality in the next release. Sometime in December of 2020, the project was officially cancelled removed from GitHub. As of 2022, the author claims to be still accepting and responding to emails that request a copy of their "banned" OpenEar 1.7 application. Which I believe is where my copy was sourced from (I downloaded it from a good Samaritan posting a download link in the RTL-SDR blog comments section) Here is a quick demo of the TETRA and DMR voice decoding functionality. In addition to that, I've shown how it can also read POCSAG pager messages. Find the download link at the top of the description for OpenEar 1.7. Thanks for reading and watching!

There isn't a lot information available on the internet about this particular maritime HF radio station from Vietnam, except for it's callsign of XVS and it's transmitter site of Ho Chi Minh City. Typically, weather conditions and other related information are broadcasted from this station. In this video, you will see that when I tuned to 8812 kHz USB I was greeted with what sounded like Vietnamese folk music with spoken-word lyrics. Luckily for me, my wife speaks Vietnamese and informed me that what I was hearing was something called "Cải Lương" which roughly translates to "reformed theater." A form of radio drama (no visual component) that blends folk music with spoken-word dialogue. My guess is that this broadcast is meant for the entertainment of lonely sailors out on the South China Sea perhaps? It is interesting, nonetheless! Thanks for watching.

Recently, I received a request to make a more in-depth video of decoding DECT voice traffic. So here it is. LINKS: @cemaxecuter7783's awesome channel! https://www.youtube.com/@cemaxecuter7783/featured DragonOS Focal download: https://sourceforge.net/projects/dragonos-focal/ Make a bootable Linux USB tutorial: https://www.tecmint.com/install-linux-os-on-usb-drive/ COMMANDS: volk_profile echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor gnuradio-companion /usr/src/gr-dect2/grc/dect2_Hackrf.grc HARDWARE: - i7 8th Gen Laptop - HackRF One Software Defined Radio - ANT500 Antenna - Sandisk USB Extreme Pro 3.1 256GB Flash Drive - Motorola MBP12 Digital Monitor SOFTWARE: - DragonOS Focal - gr-dect2 - volk_profile

GSM capture file download: https://drive.google.com/file/d/1jyepGlbBszo5WsBO46PawwRihWRMn5dQ/view?usp=share_link G'day YouTube, this will be a short demonstration of how it is possible to decode 2G GSM voice traffic with software defined radio and a PC running DragonOS Linux. I don’t have time to make a full length video detailing all the steps required to do this, but i will in about 15 or 16 days from now. I must stress the fact that this 2G GSM base station is a test cell I am running with YateBTS and the voice traffic is unencrypted. Extra steps are required to decode encrypted GSM voice but that is beyond the scope of this video. I will upload the capture file to Google drive and list the commands in the description if you want to have a play around with this. Thanks for watching! COMMANDS: Capture GSM data with HackRF: grgsm_capture -g 1 -f 935.0M -p 20 /home/username/gsm/gsm_capture.cfile --args hackrf Extract GSM Voice from timeslot 4: grgsm_decode -c /home/username/gsm/gsm_capture.cfile -f 935.0M -m TCHF -t 4 -d FR -o /home/username/gsm/gsm_voice_ts4.gsm Extract GSM voice from timeslot 5: grgsm_decode -c /home/username/gsm/gsm_capture.cfile -f 935.0M -m TCHF -t 5 -d FR -o /home/username/gsm/gsm_voice_ts5.gsm HARDWARE: HackRF One SDR (for capturing) BladeRF 2.0 xA4 (for GSM base station) Samsung S8 (sysmocom SIM card) Samsung S9 (sysmocom SIM card) i7 Laptop SOFTWARE DragonOS Focal Linux (bootable USB) YateBTS (base transceiver station) Gr-gsm (capturing and decoding)

Typically, a HF Phone Patch consists of a HF radio transceiver and a landline telephone and is most often used in maritime, aviation and even the Australian 4WD/Off-road radio network, VKS-737. Their purpose is to provide individuals who might be on a ship on the ocean or crossing the desert in a four-wheel drive with a method of making a telephone call via a HF radio. Indonesia is the worlds second largest fish producer, second only to China. The fishing vessels used are typically equipped with HF radios. Upper sideband transmissions from these vessels can be heard in Darwin Australia for nearly 24 hours per day around eight, nine and twelve megahertz. In addition to marine HF, Indonesia has about 6,000 inhabited islands and many of these have little to no communications infrastructure and as a result, HF radio is greatly utilized for talking to neighboring islands, friends, family and colleagues. This video appears to show a HF radio-telephone interface to what sounds like an Android smartphone (Samsung, maybe?) I say interfaced because the audio quality sounds too good for a smart phone being held close to the speaker and microphone of the HF transciever. But it could be a possibility. Due to my inability to speak Indonesian, I am only guessing that this phone patch is either from a fishing vessel, or someone with telecommunications infrastructure providing a phone patch service over HF to individuals who do not. The most interesting part of the videos are the Facebook Messenger application sounds and the Samsung/Android ringing tones, which I have time stamped in the pinned comment in the comments section below. Thanks for Watching.

Known for it's signature musical interlude, HSW Bangkok Meteorological Radio is a utility HF station whose primary purpose is for broadcasting weather reports and alerts to marine vessels. Typically, the weather reports are read in Thai language by a female. For the English language portion of the broadcast a text-to-speech male voice is used, as you can hear in this recording. The 'ice-cream truck' jingle is played in-between the different portions of the broadcast. Very odd indeed!

VC01 The Chinese Robot numbers station as received in Darwin Australia on the 8th of April 2022. Originating from China, this military numbers station is known for it's robotic computerized voice that sends numbers extremely fast.

One early morning last year, I was scrolling through the HF spectrum with my Airspy HF+ Discovery SDR and came across a Radio Purga DRM test broadcast from Russia at 12 mhz. The signal was weak but I managed to get roughly a minute of uninterrupted audio from DReaM DRM Decoder. This was the first time I had received DRM digital radio from Russia and was very happy about it!

An unknown individual who is definitely not myself, decoding POCSAG pager messages on VHF frequencies. DO NOT ATTEMPT TO DECODE PAGER TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

The Global Maritime Distress And Safety System (GMDSS) is a worldwide standard for facilitating safety and distress communications for ocean-going vessels and coast radio stations. It is quite often found occupying the satellite, VHF and HF radio bands. Using my Airspy HF+ Discovery software defined radio and a Windows application called YADD (Yet Another DSC Decoder) it is possible to decode and read GMDSS messages sent over HF radio between ships and/or shore stations. Generally, the contents of the decoded data consist of test messages and handshakes between ship and shore. When using an SDR, the best way to decode these messages is to set your SDR software to CW mode with a filter bandwidth of 400 hz, and then use VB Cable/Virtual Audio Cable to pipe the received audio to YADD. A list of HF frequencies to monitor are easily found at the sigidwiki.com article for GMDSS. HARDWARE - Airspy HF+ Discovery SDR - 7mHz Center-fed Dipole - LMR400 Coxial Feedline - Windows PC SOFTWARE - SDR Sharp 1777 - Virtual Audio Cable - YADD (Yet Another DSC Decoder) - Windows 10

G'day. Welcome to the VK8FOES YouTube channel. A few weeks ago, I showcased in a video how it was possible to intercept and monitor voice traffic on a DECT wireless b@by monitoring system due to the manufacturer not implementing encryption and security. In this video, I will be demonstrating how it is possible to do the same on an DECT cordless telephone. What you are seeing here is a VTech branded cordless telephone with the model number of CS6114. This is a North American market DECT 6.0 telephone that was manufactured in the year of 2017 according to the packaging box. The significance of this particular cordless telephone model is the fact that VTech neglected to implement encryption! DECT 6.0 is a slightly different frequency band to Europe/Asia/Australia and is therefore not legal to use in my location, so I will keep this video rather short. Using my smartphone, I proceed to dial the landline telephone number at my premises and answer the call. Gr-dect2 is a GNU-radio flowchart which can decode DECT voice traffic from cordless phones. I then find the carrier frequency the telephone is operating on which generally sits between channels 21 and 25) Australian DECT phones usually hover around channels one to eight. The next thing I do is find the 'part' A bit of explanation is needed for this, RFP stands for ‘radio fixed part’ and is the base station. Simply put, the cradle the handset sits in that is connected to the telephone line. PP stands for ‘portable part’ and is the handset. Gr-dect2 will display the letter 'v' next to each 'part' signifying that voice traffic is present. Selecting the base station part (RFP) will allow the audio from the party on the other end of the telephone call to be heard, and selecting the handset part (PP) will allow the audio being spoken into the cordless telephone to be heard. And here is where the fun begins, because the VTech CS6114 cordless phone does not implement security and encryption, once I select the RFP radio fixed part and speak into my smartphone, the DECT voice traffic is decoded and played back through my PC speakers. Remember, this phone was manufactured and sold back in 2017, not that long ago in the current year of 2022. There must be thousands of these unsecured cordless phone out there being used by unsuspecting people every day. This demonstration shows how much of a valuable tool a software defined radio and gr-dect2 can be for OPSEC. Now for the disclaimers: This video was made for educational purposes only, and to show cordless phone users the potential privacy risk of unsecured DECT and how to test if their voice communications are secure. Attempting to intercept and monitor private communications is illegal and punishable by hefty fines and imprisonment. You have been warned! HARDWARE - VTech CS6114 Cordless Telephone - HackRF One Software Defined Radio SOFTWARE - DragonOS Linux by @cemaxecuter7783 - gr-dect2 - volk_profile

The ISM radio bands (Industrial, Scientific and Medical) or LIPD bands as they are known as in Australia (Low Interference Potential Devices) are portions of the radio spectrum which are designated for use by wireless devices. Examples of ISM/LIPD devices are microwave ovens, smartphones, Wi-Fi routers, gate openers, car keyless entry remotes, Bluetooth devices, cordless phones, laptops and computers, the list goes on and on. Using an RTL-SDR software defined radio and the RTL_433 plugin for SDR Sharp, it is possible to demodulate and decode some of these devices operating on the 433 mHz ISM/LIPD bands. Examples of devices found at 433 mHz are home weather monitoring stations and car tyre pressure monitoring systems. Some of the information shown can be temperature, humidity, tyre pressure in PSI among other things. Thanks for watching!

The Iridium Constellation is a low-earth orbiting fleet of satellites providing global voice and data services to the entire surface of Earth. Designed and built by Motorola in the 90's, it's most notable use is for providing satellite telephone coverage. From Iridium Communications Inc. internal documents: “The complexity of the Iridium air interface makes the challenge of developing an Iridium L-Band monitoring device very difficult and probably beyond the reach of all but the most determined adversaries.” Security through obscurity is never a good philosophy. Gr-Iridium and Iridium-Toolkit are a pair of software tools for capturing iridium data and decoding it. Gr-Iridium is the detector and demodulator portion which outputs data into an 'output.bits' file. Iridium-Toolkit will sort the data into an 'output.parsed' file so that the decoding tools can extract usable information. The software defined radio used for capturing with gr-iridium is a BladeRF 2.0 Micro xA4 and the operating system is DragonOS running on an i7 8th gen laptop, bare metal via bootable USB. And for showcasing iridium-toolkit decoding features, I am using a pretty Ubuntu 20.04 virtual machine. Is it ethical to 'hack' iridium satellites? Definitely not, but some of the blame has to lie with Iridium for not securing their infrastructure and network with encryption. I made this video to spread awareness that your communications are open to eavesdropping if you use this system. Now for the disclaimers... THIS VIDEO WAS MADE FOR EDUCATIONAL AND EXPERIMENTATION PURPOSES ONLY. ALSO FOR SPREADING AWARENESS OF THE POTENTIAL PRIVACY AND SECURITY RISKS OF USING IRIDIUM. ATTEMPTING TO EAVESDROP ON PRIVATE SATELLITE COMMUNICATIONS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT. YOU HAVE BEEN WARNED!

Yet another video showcasing DragonOS by the wonderful @cemaxecuter7783. With a transmit-capable SDR such as the BladeRF, it is possible to create and operate a small 4G LTE cellular test network utilizing a Linux software suite called srsRAN (It used to be called srsLTE before it's name was changed) To my knowledge, voice calls (VoLTE) and SMS messaging aren't supported out of the box in srsRAN, but it is possible to enable Mobile Data and browse the web and use apps that require an internet connection. In addition to my BladeRF xA4 SDR, you also require a PC running DragonOS or some other Linux flavor of choice. Due to the immense computing power needed to run a software implemented cellular network, the host PC should be good enough. The laptop used in this video for running srsRAN has an i7 10th gen CPU. It is recommended to plug laptops into their AC adapter to ensure no battery optimizations are reducing CPU processing power and to also run the following command on any PC to ensure the performance CPU scaling profile is active: echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Loading the latest FPGA bitstream image to your BladeRF xA4 may or may not be required, but i did it anyway via the following command: (ensure you download the correct image for your BladeRF model and place it in home directory) bladeRF-cli -l /home/username/hostedxA4.rbf I acquired some SIM cards from Sysmocom due to the fact that my chinese USIMs purchased from aliexpress seem to be incompatible with srsRAN giving the error "MAC code failure" as the phones attempt to connect. With two old android smartphones (Galaxy S8 and an S9) I am able to demonstrate the phones connecting to the 4G LTE network and then utilize Mobile Data to run a ping test and use the internet browser to conduct a speed test. The BladeRF and smart phones are set up inside a faraday cage for the purpose of this educational video. If you are using real smartphones and SIM cards with srsRAN like I am (not the simulated software LTE modem 'srsUE') it's first necessary to edit the 'user_db.csv' file. It is located in /etc/srsran/user_db.csv. In this csv document you will need to add the IMSI, KI and OPC values of your SIM cards. The 'auth' field needs to be set as 'mil' as LTE/srsRAN uses the MILNAGE algorithm and not XOR. You can edit the user database with the command: sudo nano /etc/srsran/user_db.csv The first command to run is: 'sudo srsepc' EPC stands for Evolved Packet Core, which as the name suggests, is the core of an LTE network. The configuration file for the EPC is located in /etc/srsran/epc.conf. You can edit it with the command: sudo nano /etc/srsran/epc.conf The second command to run is: 'sudo srsenb' ENB is an acronym for eNodeB, which is the actual wireless base station component of an LTE network. The configuration file for the ENB is located in /etc/srsran/enb.conf. You can edit it with the command: sudo nano /etc/srsran/enb.conf Lastly, to ensure IP routing has been configured so that the smartphones can access the internet, a third command needs to be ran: sudo /usr/src/srsRAN-release_22_04_1/srsepc/srsepc_if_masq.sh wlp2s0 Because my laptop is connected via WiFi, my interface name is 'wlp2s0' and as such, you should substitute this for whichever network interface is supplying your PC with internet access. Some examples could be 'ens33' or 'enp3s0' for an ethernet connection. Now for the disclaimers: THIS VIDEO IS MADE FOR EDUCATIONAL AND EXPERIMENTATION PURPOSES ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE CALL INTERCEPTION ON LTE NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND IMPRISONMENT! YOU HAVE BEEN WARNED. WHEN TRANSMITTING WITH SDR'S, ALWAYS ENSURE YOUR EXPERIMENTS ARE CONDUCTED INSIDE AN RF CONTROLLED ENVIRONMENT SUCH AS A FARADAY CAGE.

G'day, welcome to the VK8FOES YouTube channel. In this video, I will be demonstrating how eavesdropping on cordless telephones is possible with DragonOS Linux and a HackRF SDR. DECT, or Digital enhanced cordless telecommunications (I will refer to it by the Acronym "DECT") is a standard developed by European Telecommunications Standards Institute. Originally developed for European nations, it has since been adopted in the United States, South America, Asia and Australia. For the most part of two decades, it has become the de facto communication standard for digital cordless telephones. The DECT standard does include encryption tools for securing voice traffic on DECT cordless phones. But early into its introduction, manufacturers of these products rarely included encryption for whatever reason, maybe cost. Fast forward to the current day, I believe most devices using DECT technology for voice communications are encrypted, but the cypher used was only 64-bit and was easily cracked in the year of 2010. Starting in 2012, the DECT standard allowed for 128 bit encryption so I doubt there are any unencrypted cordless phones out there anymore. An example of an unencrypted DECT source is the Motorola MBP12 digital audio b@by monitor. What you are hearing now is my voice as I speak into the b@by monitor, the DECT data stream is being received by a HackRF one SDR, voice traffic is being decoded by gr-dect2 and then finally played back through my laptops speakers. Essentially making it possible for eavesdroppers to listen in on conversations you may be having in your house hold. This is obviously a massive privacy risk. Because the Motorola MBP12 is made for the US Market, the frequency used is not licenced here in Australia, and as such I have these b@by monitors mounted in a faraday cage along with the receiving SDR. I have since become aware of a VTech branded cordless phone with the model number "CS6114" It is a US market DECT 6.0 phone which does not use encryption. I have ordered one of these telephones used on eBay, and when I receive it I will be exposing the poor security that some of these devices have with another DECT decoding video. Now for the disclaimers: This video was made for educational purposes only, and to show cordless phone users the potential privacy risk of unsecured DECT and how to test if their voice communications are secure. Attempting to eavesdrop on private communications is illegal and punishable by hefty fines and imprisonment. You have been warned! HARDWARE - Motorola MBP12 B@by Monitor - HackRF One Software Defined - Core i7 10th Gen Laptop SOFTWARE - DragonOS Linux by @cemaxecuter7783 - gr-dect2 - volk_profile

In Australia, the analog TV service (launched in 1956) was finally discontinued at 9 AM on the 10th December 2013 and co-existed with DVB Digital TV for 12 years up until the point of it's switch off. Utilising a HackRF software defined radio and a Linux application called "HackTV GUI" it is possible to relive the glory days of analog TV! I am using @cemaxecuter7783's DragonOS, but it's easy enough to set up in Ubuntu. Using a 1:1 amateur radio balun, I constructed a center-fed dipole tuned for 175.25 mHz which is PAL System B Channel 5. To show what Analog TV looks like on an SDR's FFT display, I have my Airspy R2 and SDR Sharp 1361 in conjunction with the PAL/SECAM TV plugin which is able to demodulate black and white TV only. My Icom amateur transceiver has had the TV mod performed on it, which allows me to watch analog colour TV with audio by pressing in and holding the volume knob for a short time. Changing between channels is achieved by the 'band' up and down buttons next to the larger VFO knob. The interesting thing about this feature is that it's completely undocumented by Icom! But, the catch with this mod is that it only allows you to view PAL VHF channels and not amateur TV which generally lives on the 70cm and 23cm bands here in Australia. Because I am not transmitting on amateur radio frequencies, the HackRF is mounted inside a faraday cage, along with the receiving antennas. THIS VIDEO IS MADE FOR EDUCATIONAL AND EXPERIMENTATION PURPOSES ONLY. TRANSMITTING ON RESTRICTED FREQUENCIES WITHOUT A LICENCE IS ILLEGAL AND PUNISHABLE BY HEFTY FINES! WHEN TRANSMITTING WITH SDR'S, ALWAYS ENSURE YOUR EXPERIMENTS ARE CONDUCTED INSIDE AN RF CONTROLLED ENVIRONMENT SUCH AS A FARADAY CAGE!

A lot of AIS decoding applications are paid software, but it's possible to use a combination of two free programs and track maritime ships for free! The demodulator part is an application is called 'AISmon' and can be fed with sound output from your SDR program via Virtual Audio Cable/VB Cable. Once the AIS packets are demodulated, they are forwarded via UDP port 29421. The decoding part is an application called 'AIS Decoder' and can be configured to use UDP port 29421 as an input. In the settings of this program, you can instruct it to only decode positioning information from the vessels. After a little while, two more windows will appear containing the information decoded from AIS transmissions from various ships. The two frequencies to monitor are 161.975 and 162.025 mHz. Being VHF, I imagine you would have to be located fairly close to a coastal region or near a busy shipping port to receive anything useful. AIS Decoder can supposedly output ship names and positions to a .KML file which can be used to overlay them on a Google Earth map, but I couldn't figure out how to do that. Thanks for watching. HARDWARE -Airspy R2 SDR -Diamond VX-1000 Antenna -LMR400 Feedline SOFTWARE -SDR Sharp 1702 -VB Cable -AISmon -AIS Decoder

It is a well know fact that the rollout of DAB+ in Australia hasn't gone as smoothly as predicted. The digital broadcasting standard has faced a lot backlash from the public due to poorer audio quality and inferior coverage compared to that of traditional analog FM radio. In addition to this, back in early days of DAB+ the radios were quite expensive to acquire. Several hundreds of dollars to achieve what a 20 dollar radio could aleady do. All of these reasons, I believe have contributed to the slow adoption of this technology. 13 years since it's rollout, it is claimed that 6 million DAB+ receivers have been sold in Australia, but what the statistics neglect to show often enough is the fact that 4 million of those were actually new car sales with DAB+ enabled radios. In my experience, I rarely hop into a friends/family/work/rideshare/taxi vehicle and observe DAB+ being used, it's nearly always exclusively the far-superior analog FM. In addition to that, there is only 9 major metropolitan areas in Australia which have active DAB+ broadcasting services and even then, it's still considered to be in 'trial' phase! So Instead of dropping $$$ on a DAB+ radio, it's possible to receive, decode and listen to digital radio on your PC with an RTL-SDR software defined radio. In this video, I am using the latest version of qt-DAB to receive a local commercial radio station called 104.1 Territory FM. No other applications are required, as the software takes control of the radio and handles the demodulating and decoding to play the audio through your PC's speakers. Thanks for watching.

In this video, I am decoding a 2G cellular base station and analyzing it's traffic with wireshark. But how? I hear you ask, because Australia switched off all of it's 2G networks all the way back in 2018, being one of the first countries to do so in the world. For good reason, too. GSM is broken and compromised in so many ways, it's difficult to fathom how it is still being used in 2022. I am running @cemaxecuter7783's amazing Linux distro called DragonOS to run a 2G GSM base station with my BladeRF transmit-capable SDR and some software called YateBTS. I have two old android smart-phones with some custom-programmed SIM cards (I have a SIM card writer) You can see these phones beginning to connect at the 1min 14sec mark. The BladeRF and smart phones are set up inside a faraday cage for the purpose of this educational video. Next, i use a software utility called grgsm_livemon to monitor the GSM850 band #128 which uses a downlink frequency of 869.2 mHz. Once the base stations begins transmitting, you can see the data starting to flow in the console window. Just to confirm that there is in fact a GSM base station broadcasting, i use an RTL-SDR with grgsm_scanner to scan for it (bottom console window) The decoded data from grgsm_livemon is piped by default to UDP port 4729, so I am able to instruct WireShark (a network traffic analyzer) to display the decoded GSMTAP packets flowing across the base station. So, what is the purpose of all this? Well, I am led to beleive that this is how IMSI catchers, SMS and voice call interception is possible. It should be noted that in 2022, there is most probably encryption on voice calls and SMS's on a commercial TelCo's 2G network. I believe the A5/1 cypher used for encrypting GSM is compromised if you want to go down that rabbit-hole, but I am not interested in that kind of thing.... The IMSI-catcher element to this, as I understand it, still works even to this day. IMSI stands for "international mobile subscriber identity" and is the unique identifying number of a mobile phone on a cellular network, the 'holy-grail' of information for a GSM hacker to obtain. But using GSMEvil2 or the ISMI-catcher.py python script, i could never catch IMSI's from a YateBTS base station. Nor could i sniff the SMS's sent between my two smartphones. Lastly, to hear what a 2G signal sounds like (us Aussies haven't have heard one for a long time!) I have an Airspy R2 tuned into 869.2 mHz and a RAW filter of 200 kHz opened-up. You can hear the base station begin to transmit at the 10 second mark, and stop transmitting at 5min 6sec. Now for the warnings: THIS VIDEO IS MADE FOR EDUCATIONAL AND EXPERIMENTATION PURPOSES ONLY. IMSI-CATCHING, SMS-SNIFFING AND VOICE TRAFFIC DECODING ON GSM NETWORKS IS ILLEGAL AND PUNISHABLE BY HEFTY FINES AND PRISON TIME! YOU HAVE BEEN WARNED. WHEN TRANSMITTING WITH SDR'S, ALWAYS ENSURE YOUR EXPERIMENTS ARE CONDUCTED INSIDE AN RF CONTROLLED ENVIRONMENT SUCH AS A FARADAY CAGE. Thanks for watching.

Recently I have been interested in the Osmocom project called 'OSMO-gmr' https://projects.osmocom.org/projects/gmr/wiki/OsmoGMR_Software From what I can see, it should allow decoding (NOT DECRYPTING, thats naughty) of Thuraya satellite phones! So, i went hunting for the Thuraya-3 satellite which services Australia. Using the RTL SDR Blog L-band antenna as a feed for a 90cm offset dish gives me excellent results and very strong signals from 1532.5 to 1554.5 mHz. The OSMO-gmr tools were released back in 2011, so it may require older versions of Linux or GNU-radio to work. I managed to get the source code to compile on @cemaxecuter7783's DragonOS FOCAL 20.04 perfectly, but I think it may be incompatible with GNU radio 3.8/3.9. If anyone can assist in getting osmo-gmr working, please get in touch with me, thanks!

In this video I am using @cemaxecuter7783's fantastic DragonOS Linux distribution to decode a nearby cellular towers downlink control channel. His easy-to-follow video tutorial is here: https://www.youtube.com/watch?v=Vks6lmv_GY8 Firstly, I am using an RTL-SDR with LTE-Cell-Search to find the towers control channel frequency and cell ID. After that information is obtained, I instruct Falcon GUI to monitor the found frequency and cell ID. The most interesting information shown, from my limited understanding of cellular networks, seems to be the waterfall visualization of the downlink channel, the towers throughput in Mbit/s and the UE Activity showing RNTI. Which I believe could be the random identifier given to a users phone on the network (maybe?) It should be noted that private information such as voice calls, SMS messaging, and internet traffic ARE NOT DECODABLE and probably never will be due to LTE security and encryption.

My residence is located extremely close to a cellular tower. Full strength LTE indoors and outdoors is great for my smart phone, but not so great for my radio hobby. This particular cellular tower is operated by Telstra and uses two LTE bands, 1800 mHz (DCS Band 3) and 700 mHz (APT Band 28) The 1.8 gHz LTE doesn't seem to affect my Airspy R2 since technically, it is outside of the SDR's receivable frequency range. 700 mHz on the other hand is overloading my SDR's receiver and causing the noise floor to jump up and down at various places in the spectrum, military airband and 460 mHz UHF to name a few. This makes it hard to decode weak digital voice modes such as TETRA. I purchased a Crystek CLPFL-0500 Inline 500 mHz Low Pass Filter in the hope it would attenuate the LTE signal and prevent front-end splattering of my SDR's. I am happy with the result, but obviously this isn't a perfect solution as now I am prevented from receiving anything meaningful above 500 mHz. An 800 mHz notch filter with about 100 mHz of stop-band bandwidth would be perfect. If anyone knows if these exist, or how to homebrew one, please let me know! Thanks.

TETRA is a popular UHF digital communication standard commonly utilized in various European countries and Australia. It is most often used in public safety or commercial environments and has not been adopted in the United States. In Australia, or more specifically my place of residence, TETRA repeater outputs can be found from about 463 to 466 mHz. The TETRA standard allows for encrypted voice, but I am yet to encounter any encryption on these systems so far. TETRA demodulator plugin for SDR Sharp is incredibly easy to use compared to the very clunky DSD plus. Set your mode as NFM with a 25 kHz bandwidth, tick the 'demodulator' box and the plugin handles everything else for you. Too easy! I am not sure if it is the fault of the plugin, or just the nature of TETRA, but it seems to need quite a good signal-to-noise ratio to get reliable and clear voice decoding. HARDWARE - Airspy R2 Software Defined Radio - 25 Element 477 mHz Yagi Antenna - LMR400 Coaxial Feedline SOFTWARE - SDR Sharp 1702 - TETRA Demodulator Plug-in

In this video I am using my Airspy R2 SDR to track the nightly weather balloon launch. Our local meteorological station utilizes Vaisala RS41 radiosondes and the telemetry can be decoded with a free Windows application called RS41Tracker. All the atmospheric sensor information can be viewed. But, the data that concerns weather balloon tracking enthusiasts the most is the GPS navigation coordinates which can be used to locate and retrieve a radiosonde once it has fallen to earth. The RS41 Radiosonde's themselves can be reprogrammed (re-flashed with custom firmware) by amateur radio operators to perform other duties such as being a makeshift home weather station or as a target for competitive radio direction finding. Even for amateur atmospheric research! HARDWARE - Airspy R2 Software Defined Radio - GME 8.1 dB 477 mHz Collinear Antenna - LMR400 Coaxial Feedline SOFTWARE - SDR Sharp 1702 - Virtual Audio Cable - RS41Tracker

An unknown individual who is definitely not myself, decoding Inmarsat-C text messages on L-band frequencies. DO NOT ATTEMPT TO DECODE SATELLITE TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

In this video, I am using SDR Sharp in conjunction with 'Fast Scanner' plugin to scan the Military Airband from 225.0 to 399.95 mHz. Normally, there isn't a lot of voice traffic on this band. But due to a training exercise being conducted in my home city right now, there is plenty of strong AM signals for listening to! I recently purchased an Airspy R2 and am extremely happy with the performance gains over an RTL-SDR. It is much, much better! EDIT: The noise floor is jumping up and down due to interference from a very close 700 MHz LTE tower, I have rectified this in recent times with a 500 MHz low pass filter. -SDR Sharp 1702 -Fast Scanner Plugin -Airspy R2 Software Defined Radio -GME 8.1 dB 477 mHz Colinear Antenna -LCU400 Coaxial Feedline Settings for 'Fast Scanner' plugin: Start: 225,000,000 End: 399,950,000 Detector: AM Bandwidth: 6,000 Step Size: 25,000

Indonesia has about 6000 inhabited islands spread across it's archipelago. The lack of communication infrastructure and ease of acquiring amateur radio equipment means that the residents of these islands utilise HF radios for communicating. Here is a few examples of the QRM (man-made inference) that we in the north of Australia experience on a nightly basis. Some of the ham band intruders we experience on the 40 meter band (7 MHz) are licenced amateur radio operators who rarely identify with their callsigns but most are unlicensed pirates. What are they saying? Who knows, I don't speak Indonesian. However, I have read forum topics online stating that they are repeating their island's name or provinces name over and over again. This is nothing new, people say they have heard the Indonesian "chanting" on 7 MHz for over 20 years. Online reports say that the Indonesian band intruders can be heard as far as North America and Europe if band conditions permit. The real problem lies with us folk here in northern Australia. The entire band is completely unusable, all day and night, and all year round! They occupy the lower CW and digital mode portions of 40-meters, forcing operators of these modes to move up to the SSB voice portions for Morse code and digital modes. It has a carry on effect that ruins the entire band. I have witnessed strong non-identifying Indonesian stations as high up in the band as to intrude into the shortwave portion of 7 MHz. What's worse is why don't the spectrum management bodies do anything about it? Where is the ITU on the issue? What about the IARU? Why isn't the WIA confronting ORARI? Why doesn't the ACMA do it's job and get in touch with KOMINFO? Why did the ITU hold it's 2017 preparatory meeting for Asia and the Pacific in Bali, knowing full well about the interference emanating from that country and lack of action to rectify it? Why did the ITU hold their 2005 Radiocommunication Seminar in a country with such blatant disregard for the RF spectrum in which they are tasked with managing globally? These are all questions that need to be answered. The only organisation that seems to actually do anything about this is RASA. But even then, their solution is just "build an Indonesian facing antenna array and operate normally at maximum legal power" in the hope that 6000 islands' residents will just switch off their radio or move to another frequency. Yeah right. I can guarantee with 100% certainty that if I was to tune my amateur transceiver to a military, aviation or maritime HF frequency and start screaming pointless unintelligible garbage into the microphone like our Indonesian friends do, there will be a platoon of ACMA radio inspectors knocking on my door within days ready to seize my equipment and throw the book at me! Why should amateur radio be any different? All of us VK amateurs had to study hard, sit a theory and practical exam, pay our exam fees and our yearly fees for retaining the right to use the amateur radio bands. We are your paying customers ACMA, so do something about it! I know there will be hams who'll say "hurr durr don't cry, QSY!" (QSY = change frequency) But when the entire band is being splattered by +60-over-9 sideband transmissions from 7.000 to 7.200, where are we supposed to go? It really is a shame, because 40-meters is considered to be the most reliable all-season DX band. It's completely unusable for those of us up here in Northern Australia. Thanks for reading and watching.

Automatic Link Establishment (ALE) is a military standard used for initiating and sustaining HF radio communications. ALE signals can be decoded using programs like MultiPSK and Sorcerer, but for this video I am using Sigmira. In my experience the decoded data is generally uninteresting, only showing 'to' and 'from' callsigns/addresses. But in this example, there was a lot more data being exchanged, possibly link control or handshake packets. I've been spending a lot of time away from my ham shack lately. But thanks to SpyServer, I can stream my SDR radio via the internet! -Airspy HF+ Discovery SDR -40m (7 MHz) Center-fed Dipole -SpyServer -SDR Sharp -Sigmira

Download DReaM DRM decoder With xHE and AAC codec here: https://drive.google.com/file/d/1URdl5jSjSqivGALP3h0lkJ8Xqs7R_tFk/view?usp=sharing Trans World Radio Pacific Digital Radio Mondiale broadcast received in northern Australia on the 31st of March 2022 at 9905 KHz. At the end of the video, you'll see that there is some kind of commercial/military HF data link behind the DRM signal. Obviously this is the cause of the intermittent audio. But still, another DRM station to add into the log!

Instead of using an SDR, it is possible to feed the DSD+ DMR decoding software with a scanner, providing that it has a discriminator output or modification. The Whistler TRX-2 has a discriminator output toggleable in the global settings menu. 'Program Menu' --- 'Global Settings' --- 'IF Out' and change the setting from 'Off' to 'HP'. Now, discriminator audio will be fed through the front headphone jack of the scanner. Because the headphone jack is a stereo output, using a mono AUX cable won't work (well, It didn't for me, anyway) And with a stereo AUX cable, I am feeding a Startech ICUSBAUDIO USB sound card. This is a very high quality sound card that works well with digital decoding. Then, just configure DSD+ as you would normally using an SDR, instead of using a virtual audio cable, point DSD+ to your USB sound card. What advantage does this have over just using an SDR? Probably not much. However, it is interesting to see what the scanner is doing behind the scenes while it's waiting for a signal.

HF Marine Weather Facsimile is transmitted from two locations in Australia. This particular video is recorded from the Charleville VMC in Queensland. The other station is in Wiluna, Western Australia. Usually, I can get both. But, it seems like 20 MHz was propagating a lot better as the image is very clear. 21st of March 2022. The decoding program I am using is "Black Cat HF Weather Fax" and is paid software, so I can't share it unfortunately.

Download DReaM DRM Decoder with AAC codec here: https://drive.google.com/file/d/14s_vgcIxdOBlLd-A1jBolJWrAoqW2rkt/edit Radio Kuwait Digital Radio Mondiale broadcast received in northern Australia on the 20th of March 2022 at 15105 KHz. (Excuse the incorrect date in the video) I had previously been hunting this signal for a long time. It was always too weak to get a good decode with DReaM. For the first time I've witnessed, a monster signal was making it's way to northern Australia and I finally got audio. Very happy with this one!

This is a short demo of a GSM base station running on DragonOS with YateBTS and a BladeRF software defined radio. I used a SIM card reader/writer and blank SIM cards from China for customizing the MCC's, MNC's and IMSI's. Thanks to @cemaxecuters' tutorial, I could get SMS messaging and calling working. But didn't have any luck with GPRS data. HARDWARE - BladeRF 2.0 Micro xA4 Software Defined Radio - 4 x Mini Quad Band Cellular Antennas - SIM Card Reader/Writer - Blank SIM cards SOFTWARE -DragonOS By @cemaxecuter -YateBTS DO NOT ATTEMPT TO RUN A CELLULAR BASE STATION UNLESS INSIDE A CONTROLLED RF SHIELDED ENVIRONMENT!

HFGCS is the US Military's HF radio communication network and is frequently used to broadcast encoded voice messages in the form of EAM 's (Emergency Action Messages) I was lucky enough to catch one of these transmissions on 15016 KHz from a station that signed off as FIREOPAL.

French Navy STANAG 4285 signal received with an Airspy HF+ Discovery and decoded with SORCERER. "Voyez vous le brick geant que j examine pres du grand wharf" is supposed to be the french equivalent of the english saying "The quick brown fox......"

An unknown individual who is definitely not myself, decoding Iridium voice transmissions on L-band frequencies. DO NOT ATTEMPT TO DECODE SATELLITE TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

An unknown individual who is definitely not myself, decoding Inmarsat voice transmissions on L-band frequencies. DO NOT ATTEMPT TO DECODE SATELLITE TRANSMISSIONS, EVER! I WOULDN'T DO IT, AND NEITHER SHOULD YOU!

Scanning Local UHF DMR Radio Signals with an RTL-SDR, SDR Sharp, DSD Plus and 'Fast Scanner' Plug-in. NOTE DSD+ plus plays slot 1 DMR audio through the left speaker and slot 2 DMR audio through the right speaker. HARDWARE RTL-SDR Blog V3 Dongle FM Broadcast Blocker GME 8.1 dB Vertical Base Antenna LCU400 Coaxial Cable SOFTWARE SDR-Sharp DSD+ Fast Scanner Plugin Virtual Audio Cable Windows 10

C.M Obrecht Radio 15730 KHz Received in Darwin Australia 25-02-22. This evening's broadcast was not as good for me as the previous, unfortunately. The 15 MHz band was quite noisy in northern Australia, complete with static crashes, ionosondes and a local Ham operator possibly transmitting at 14 MHz very close to my location, wiping out my SDR. I rectified this by reducing the sample rate of the Airspy, in combination with some SDR Sharp DSP trickery. So, the last 10 or so minutes were decent enough! It's really a treat to hear electronic music on shortwave radio! I love C.M Obrecht's music!

Airspy HF+ Discovery SDR 7 Mhz (40m) Center-fed Dipole SDR-Console V3 (4 Receivers) PC-HFDL (Paid Version) Virtual Audio Cables (VAC1-4) Google Earth (For Aircraft Tracking)

C.M Obrecht Radio 11735 KHz Received In Darwin Australia 28-01-22 Airspy HF+ Discovery SDR 40m Center-fed Dipole Antenna SDR Sharp Software

Download DReaM DRM Decoder with AAC codec here: https://drive.google.com/file/d/14s_vgcIxdOBlLd-A1jBolJWrAoqW2rkt/view?usp=sharing A somewhat depressing segment of BBC's Digital Radio Mondiale world service broadcast. Received in Northern Australia on Tuesday 25th of January 2022. Airspy HF+ Discovery SDR 7MHz (40m) Center-fed Dipole Dream DRM Decoder SDR Sharp Virtual Audio Cable

Brian Cox and Julia Zemiro give a shoutout to my brother on Stargazing live May 22nd 2018

My brother being informed live on national TV he has discovered a 4 planet solar system 600 light years from earth.