If you watch old science fiction or military movies — or if you were alive back in the 1960s — you probably know the cliche for a radar antenna is a spinning dish. Although the very first radar antennas were made from wire, as radar sets moved higher in frequency, antennas got smaller and rotating them meant you could “look” in different directions. When most people got their TV with an antenna, rotating those were pretty common, too. But these days you don’t see many moving antennas. Why? Because antennas these days move electrically rather than physically using multiple antennas in a phased array. These electronically scanned phased array antennas are the subject of Hunter Scott’s talk at 2018’s Supercon. Didn’t make it? No problem, you can watch the video below.
While this seems like new technology, it actually dates back to 1905. Karl Braun fed the output of a transmitter to three monopoles set up as a triangle. One antenna had a 90 degree phase shift. The two in-phase antennas caused a stronger signal in one direction, while the out-of-phase antenna canceled most of the signal and the resulting aggregate was a unidirectional beam. By changing the antenna fed with the delay, the beam could rotate in three 120 degree steps.
Today phased arrays are in all sorts of radio equipment from broadcast radio transmitters to WiFi routers and 5G phones. The technique even has uses in optics and acoustics.
The explosion of cheap LED lighting products has given a never-ending array of opportunities for the resourceful hacker. A few dollars can secure strings of colourful illumination, but without further expenditure they lack the extra utility of electronic control. This is something that [Albert David has addressed] with his simple ESP8266-based WiFi switcher that he’s added to a string of USB-powered LEDs, and he’s neatly mounted the ESP-12 module it used atop a USB plug.
The circuitry is pretty straightforward, with only a couple of I/O lines being used. A transistor takes care of the heavy lifting, and the software comes courtesy of the Tasmota firmware for Sonoff (and similar) devices. We suspect with this economy of connection, the same task could be achieved even with the limited resources provided by the lesser ESP-01 module.
There was a time not so long ago when performing a task such as controlling a light over a wireless network involved significant cost, power, and complexity. In the nearly five years since we reported on the arrival of the ESP8266 we have progressed to the point at which that task is a simple project using commodity components, and that represents something of a miracle.
5G is gearing up to be the most extensive implementation of mesh networking ever, and that could mean antennas will not need to broadcast for miles, just far enough to reach some devices. That unsightly cell infrastructure stuck on water towers and church steeples could soon be hidden under low-profile hunks of metal we are already used to seeing; manhole covers. This makes sense because 5G’s millimeter radio waves are more or less line-of-sight, and cell users probably wouldn’t want to lose connectivity every time they walk behind a building.
At the moment, Vodafone in the UK is testing similar 4G antennas and reaching 195 megabits/sec download speeds. Each antenna covers a 200-meter radius and uses a fiber network because, courtesy of existing underground infrastructure. There is some signal loss from transmitting and receiving beneath a slab of metal, but that will be taken into account when designing the network. The inevitable shift to 5G will then be a relatively straightforward matter of lifting the old antennas out and laying the new hardware inside, requiring only a worker and a van instead of a construction crew.
Sometimes the best hacks come from the most basic of questions. In this case, [CNLohr] was wondering what would happen if he started to reduce the clock speed of the ESP8266’s Baseband PLL (BBPLL) while still trying to communicate with it. You know, as one does. The results ended up being fairly surprising, and while it’s not immediately clear if there’s a practical application for this particular trick, it’s certainly worth some additional research.
The idea here is that the BBPLL is the reference clock for the entire system, including all of the peripherals. So underclocking it doesn’t just slow down code execution as you might expect, but it also slows down the chip’s interactions with the outside world. [CNLohr] demonstrates this concept in the video below, showing how the baud rate used to view the serial output from the ESP8266 needs to be adjusted to match the chip’s frequency or else you’ll only get garbage on the line.
But what happens to the WiFi? As [CNLohr] discovered, while the center frequency itself doesn’t change, the channel width gets narrower as the clock rate is lowered. When viewed on the waterfall display of a software defined radio (SDR), the transmission can be seen “compressing” in a step pattern as the clock rate is reduced. As one might expect, the 802.11 packets become indecipherable to a normal WiFi device running in monitor mode. The signal is still at the correct frequency, but the devices can no longer understand each other.
Now it was time for another of those basic questions. What would happen if you did the same thing to a second ESP8266? Much to his surprise, [CNLohr] discovered that the two devices could still communicate successfully as long as their BBPLL clock speed was the same. From an outsider’s perspective it looked like gibberish, but to the two ESPs which had been slowed by the same amount, everything worked as expected even though the 802.11 standards say it shouldn’t.
So what can you do with this? The most obvious application is a “stealth” WiFi connection between ESP8266s which wouldn’t show up to normal devices, a communications channel invisible to all but the most astute eavesdropper. [CNLohr] has made all the source code to pull this trick off public on GitHub, and it should be interesting to see what kind of applications (if any) hackers find for this standards-breaking behavior.
If adding a cell modem is dealing with a drama queen of a hardware component, then choosing from among the many types of modules available turns the designer into an electronics Goldilocks. There are endless options for packaging and features all designed to make your life easier (or not!) so you-the-designer needs to have a clear understanding of the forces at work to come to a reasonable decision. How else will Widget D’lux® finally ship? You are still working on Widget D’lux®, aren’t you?
OK, quick recap from last time. Cell modems can be used to add that great feature known as The Internet to your product, which is a necessary part of the Internet of Things, and thus Good. So you’re adding a cell modem! But “adding a cell modem” can mean almost anything. Are you aiming to be Qualcomm and sue Apple build modems from scratch? Probably not. What about sticking a Particle Electron inside to bolt something together quickly? Or talk to Telit and put a bare modem on a board? Unless you’re expecting to need extremely high volume and have a healthy appetite for certification glee, I bet you’ve chosen to get a modem with as many existing certifications as possible, which takes us to where we are today. Go read the previous post if you want a much more elaborate discussion of your modem-packaging options and some of the trade offs involved. Continue reading “Finding the Goldilocks Cell Module”→
The general public thinks there is one thing called a radio. Sure, they know there are radios that pick up different channels, but other than that, one radio is pretty much like the other. But if you are involved in electronics, you probably know there are lots of ways a radio can work internally. A crystal set is very different from an FM stereo, and that’s different still from a communications receiver. We’d say there are several common architectures for receivers and one of the most common is the superheterodyne. But what does that mean exactly? [Technology Connection] has a casual explanation video that discusses how a superhet works and why it is important. You can see the video, below.
Engineering has always been about building on abstractions. This is especially true now when you can get an IC or module that does most of what you want it to do. But even without those, you would hardly start an electronics project by mining copper wire, refining it, and drawing your own wire. You probably don’t make many of your own resistors and capacitors, neither do you start your design at the fundamental electronic equations. But there’s one abstraction we often forget about: architecture. If you are designing a receiver, you probably don’t try to solve the problem of radio reception; instead you pick an architecture that is proven and design to that.
[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.
In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.
As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the address handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.
All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.
Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.