But the frontpage doesn't take you there.
I would love to do things like investigate how my water meter broadcasts its readings, but "latent" doesn't even begin to cover how inaccessible this stuff is. There are "tutorials", but they just say "Stick these parts together. There, now you have stuck these parts together!" (https://wiki.gnuradio.org/index.php/Simulation_example:_Narr...)
I know, open source, I should learn everything and then write better documentation.
Gnuradio was also new to me. However with two HackRFs I could do the entire thing. First replay attacks. Then trying to get the code by building up a set of processing blocks. Last synthesis of the complete signal.
Very nice to do! Felt great!
-Tom Sawyer
That seems like it would be a nice cheap one-two punch for getting started. AFAIR wifi uses the public (unregulated) bands so there should be lots of interesting stuff on those frequencies beyond wifi signals.
The only project that so far has managed to even partially use wifi hardware as a more generic SDR is nexmon[1] and even that is rather involved. Really cool project but not much heard since 2018.
For just experimenting with modems across a noisy path one could just use the built in microphone and speakers.
1. https://github.com/seemoo-lab/mobisys2018_nexmon_software_de...
In the US and other countries, it is to the best of my knowledge legal to modify firmware for hardware you own. The illegal part is broadcasting, most bandwidths are highly regulated. Listening on the other hand is mostly legal, or at the very least extremely likely to fly under the radar.
Few years back there was danger of FCC de facto banning alternative router firmwares like openwrt to prevent tampering with the wifi cards firmware.
This was the "only manufacturer signed firmware allowed" thing that thankfully was avoided.
FCC's motivation in this is to prevent people from using too much power or certain frequencies.
And as most manufacturers want to be able to sell in USA, it would have likely affected all versions. Kainda like how many wifi devices sold in Europe only go up to channel 11 on 2.4GHz, when the EU band goes up to channel 13. But ch12 and ch13 are not legal in usa, so they are blocked.
Once you have basic understanding of the topic, you can get better hardware: AirSpy (the same features as rtl-sdr, but MUCH better signal-to-noise ratio and bandwidth) or bladeRF (costly, but probably the best radio you can get now). For example I'm now building a weather radar based on bladeRF. The bladeRF has a FPGA with open-source HDL, so you can mess even with absolutely lowlevel and bleeding edge stuff.
Going back to your original question:
Most cards load firmware from a file when they are initializing (check "dmesg|grep firmware", on my machine, for example, it says it has loaded /lib/firmware/rtl_nic/rtl8153b-2.fw), you are free to modify it. However, all (or maybe almost all) wifi cards have the format of the blob completely undocumented so it would be very hard to make a modification that would allow you to transmit/receive arbitrary signals. Something similar has been achieved with GSM phones (see OsmocomBB), but it requires very complicated reverse-engineering.
Recently, there was a wifi stack released for a SDR, so the other way around: https://www.nuand.com/bladeRF-wiphy/.
https://github.com/chunkeey/carl9170fw/ https://github.com/qca/open-ath9k-htc-firmware http://netweb.ing.unibs.it/~openfwwf/
For my own use (on windows 10), I used the following device names for the microphone / speaker: Microphone: "Microphone Array (Realtek High Definition Audio)" Speaker: "Speaker/HP (Realtek High Definition Audio)"
Specific names on windows can be found in the Control Panel > System > Sound (as of the date of writing)
https://www.rtl-sdr.com/receiving-ads-b-jetliner-traffic-wit...
https://www.theverge.com/2019/11/26/20981630/raspberry-pi-pi...
This is somewhat related to the old difference between a "modem" and a "winmodem": proper telephone modems performed the de/modulation internally, winmodems did not and relied on the host processor to do so, resulting in generally lower performance but a much cheaper device. At modern network data rates it is not really feasible to do this and the general direction is towards offloading more and more of the work to the network adapter, outside of the host's control or view.
For gnuradio you need raw radio samples, often referred to as IQ data due to the nomenclature for amplitude and phase. Few devices that aren't specifically designed for software-defined radio use expose this data because it requires extra complexity in the device and tends to be rather high-bandwidth. The "RTL SDR" TV tuner dongles are so well known precisely because they contain an undocumented feature that allows a host to request raw IQ data, although at a poor sample rate and bandwidth since these devices were not really intended for it.
No. There's a LOT of stuff the wifi chip does to convert EM to data, including despreading and other computationally expensive operations.
Using an expensive SDR, you can follow this paper from 2013 to see the block diagram of what decoding wifi looks like:
https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9....
Also note that it’s easy to break FCC regulations and generally be disruptive if you mess around with this stuff and don’t know what you’re doing, and the FCC happily hands out five digit fines.
https://github.com/seemoo-lab/mobisys2018_nexmon_software_de...
https://github.com/chunkeey/carl9170fw/ https://github.com/qca/open-ath9k-htc-firmware http://netweb.ing.unibs.it/~openfwwf/
However cities are terribly noisy environments so loop antennas should work better for most people. Most amateur radio guides assume you are at least a homeowner but that is not realistic among people interested in a 20 eurodollar receiver.
Previous discussion on HN: https://news.ycombinator.com/item?id=24750588.
Ham Radio Workbench podcast on GNU Radio: https://www.hamradioworkbench.com/podcast/GNU-Radio.
In terms of hardware, there is a large spectrum, from inexpensive RTL-SDR (receive only, ~$25), PlutoSDR (transmit and receive, $229, which PySDR covers) all the way to $x000+ for USRP etc.
https://osmocom.org/projects/osmo-fl2k/wiki (repurposing a USB-VGA dongle as analog source)
https://github.com/F5OEO/rpitx (repurposing bitbang/PWM GPIO; we had weird problems with data corruption when we were trying to use it as a radio modem, but maybe you will have more luck)
https://bellard.org/dvbt/ (repurposing standard VGA card, but it's probably not worth it since fl2k is way better)
(beware that low quality of the transmitter usually means it will cause interference with other stuff. However, all of these have such a low power that if you will not use an amplifier, it will be OK, the interference will be probably undetectable outside of the room where the transmitter is)
https://www.dsprelated.com/showarticle/192.php https://www.katjaas.nl/home/home.html
We are maintaining a long list with theory/math: https://brmlab.cz/event/dsp#zdroje , and engineering stuff: https://brmlab.cz/project/sdr/start#links . However, I agree it is rather difficult to get into the topic. I'm playing with SDRs for almost 10 years (increasingly "fulltime" lately), and we still need to employ a professional mathematician to help me with some advanced problems.
the probem would be that the cheap dtv (RTL-SDR) only gets up to 2.4MHz of spectrum bandwith, a typical DVB-S mux can be around 20MHz or the DVB-T terrestrial standard, 8MHz
The device was originally intended only as a dtv receiver and not a general purpose software defined radio. The hobbyist/ hacker community discovered the hidden debug mode that allows raw data acquisition and wrote drivers for it.
The ECPA was always a complete legal atrocity, and I don't think it's been enforced for many years, and cell phones no longer use NBFM or anything else that an unauthorized receiver can decode, but...