Many of the SDR projects we see use a cheap USB dongle. They are great, but sometimes you want more and — especially — sometimes you want to transmit. The Analog Devices ADALM-Pluto SDR is easily available for $200 and sometimes as low as $100 and it both transmits and receives using an Analog AD9363 and a Zynq FPGA. Although you normally use the device to pipe IQ signals to a host computer, you can run SDR applications on the device itself. That requires you to dig into the Zynq tools, which is fun but a topic for another time. In this post, I’m going to show you how you can use GNU Radio to make a simple Morse code beacon in the 2m ham band.
I’ve had one on my bench for quite a while and I’ve played with it a bit. There are several ways to use it with GNU Radio and it seems to work very well. You have to hack it to get the frequency range down a bit. Sure, it might not be “to spec” once you broaden the frequency range, but it seems to work fine. Instead of working from 325 MHz to 3,800 MHz with a 20 MHz bandwidth, the hacked device transceives 70 MHz to 6,000 MHz with 56 MHz bandwidth. It is a simple hack you only have to do once. It tells the device that it has a slightly better chip onboard and our guess is the chips are the same but sorted by performance. So while the specs might be a little off, you probably won’t notice.
Nowadays, resin printers are highly accessible and can do some great stuff. But between isopropyl alcohol for part rinsing and the fact that some resins have a definite smell to them, ventilation can get important fast. The manufacturers don’t talk much about this part of the resin printing experience, but it’s there nevertheless. So what can be done when smells become a problem?
I recently had to deal with this when I printed several liters of resin worth of parts. That’s a lot of resin, and a lot of alcohol for part washing. Smells — which had never been much of a problem in my work area — suddenly became an issue.
Thanks to some clever Arduino-driven automation, [Gurpreet] can maintain a safe distance from his slide whistle while interacting with it. Slide whistles need two things — air coming in from the top, and actuation at the business end. The blowing force now comes from a focused fan like the ones that cool your printed plastic as soon as the hot end extrudes it. A stepper motor moves the slide up and down using a printed rack and pinion.
Here’s a smooth touch — [Gurpreet] added a micro servo to block and unblock the sound hole with a cardboard flap to make the notes more distinct. Check out the build video after the break, which includes a music video for “My Heart Will Go On”, aka the theme from Titanic. It’s almost like the ship herself is playing it on the steam whistles from the great beyond.
No doubt some purists in the audience will call this one cheating, since this Amiga 500 from 1987 isn’t technically connecting to Spotify and playing the music by itself. But we also suspect those folks might be missing the point of a site called Hackaday. With all the hoops [Daniel Arvidsson] hopped through to make this happen, what else could it be if not a hack?
This one starts, like so many projects these days, with the Raspberry Pi. Don’t worry Amiga aficionados, this classic machine hasn’t been gutted and had its internals replaced with a diminutive Linux board. But thanks to an expansion card known as the A314, you could say it’s received a penguin infusion. This clever board allows an internally mounted Raspberry Pi to communicate with the Amiga 500 through shared memory, making all sorts of trickery possible.
In this case, the Raspberry Pi is actually the one connecting to the Spotify Connect service with raspotify and decoding the stream. But thanks to a few pipes and an ALSA plugin, the audio itself is actually pushed into the Amiga’s sound hardware. In the video after the break, the process is demonstrated with tunes that are befitting a computer of this vintage.
Drivers with a lead foot more often than not have Waze open on their phone so they can see if other drivers have spotted cops up ahead. But avoiding a speeding ticket used to involve a lot more hardware than software. Back before the smartphone revolution, that same driver would have had a radar detector on their dashboard. That’s not to say the gadgets are completely unused today, but between their relatively high cost (one of the top rated models on Amazon as of this writing costs over $300) and the inevitable false positives from so many vehicles on the road having their own radar and LIDAR systems, they’ve certainly become a less common sight over the years
The subject of today’s teardown is a perfect example of “Peak Radar Detector”. Manufactured back in 2007, the Cobra XRS 9740 would have been a fairly mid-range entry offering the sort of features that would have been desirable at the time. Over a decade ago, having an alphanumeric display, voice alerts, and a digital compass were all things worth shouting about on the box the thing was sold in. Though looking like some kind of Cardassian warship was apparently just an added bonus.
As the name implies these devices are primarily for detecting radar activity, but by this point they’d also been expanded to pick up infrared lasers and the strobe beacons on emergency vehicles. But false positives were always a problem, so the device allows the user to select which signals it should be on the lookout for. If you were getting some kind of interference that convinced the detector it was being bombarded with IR lasers, you could just turn that function off without having to pull the plug entirely.
But it’s important to remember that this device was built back when people were still unironically carrying around flip phones. Detecting laser and multi-band radars might sound like something pulled from the spec sheet of a stealth fighter jet, but this is still a piece of consumer electronics from more than a decade in the past. So let’s crack it open and take a look at what goes on inside a radar detector that’s only a few years away from being old enough to get its own driver’s license.
Betteridge’s Law of Headlines holds that any headline ending in a question mark can be answered with a resounding “No”. But as the video below shows, a Lego machine that twists steel asunder is not only possible, it’s an object lesson in metal fatigue. Touché, [Betteridge].
In pitting plastic against metal, the [Brick Experiment Channel] relied on earlier work with a machine that was able to twist a stock plastic axle from the Technics line of parts like a limp noodle. The steel axle in the current work, an aftermarket part that’s apparently no longer available, would not prove such an easy target.
Even after beefing up the test stand with extra Technics struts placed to be loaded in tension, and with gears doubled up and reinforced with extra pins, the single motor was unable to overcome the strength of the axle. It took a second motor and a complicated gear train to begin to deform the axle, but the steel eventually proved too much for the plastic to withstand. Round Two was a bit of a cheat: the same rig with a fresh axle, but this time the motor rotation was constantly switched. The accumulated metal fatigue started as a small crack which grew until the axle was twisted in two.
Ready for more speculative execution news? Hope so, because both Intel and AMD are in the news this week.
The first story is Load Value Injection, a different approach to reading arbitrary memory. Rather than try to read protected memory, LVI turns that on its head by injecting data into a target’s data. The processor speculatively executes based on that bad data, eventually discovers the fault, and unwinds the execution. As per other similar attacks, the execution still changes the under-the-hood state of the processor in ways that an attacker can detect.
What’s the actual attack vector where LVI could be a problem? Imagine a scenario where a single server hosts multiple virtual machines, and uses Intel’s Secure Guard eXentensions enclave to keep the VMs secure. The low-level nature of the attack means that not even SGX is safe.
The upside here is that the attack is quite difficult to pull off, and isn’t considered much of a threat to home users. On the other hand, the performance penalty of the suggested fixes can be pretty severe. It’s still early in the lifetime of this particular vulnerability, so keep an eye out for further updates.
AMD’s Takeaway Bug
AMD also found itself on the receiving end of a speculative execution attack (PDF original paper here). Collide+Probe and Load+Reload are the two specific attacks discovered by an international team of academics. The attacks are based around the reverse-engineering of a hash function used to speed up cache access. While this doesn’t leak protected data quite like Spectre and Meltdown, it still reveals internal data from the CPU. Time will tell where exactly this technique will lead in the future.
To really understand what’s going on here, we have to start with the concept of a hash table. This idea is a useful code paradigm that shows up all over the place. Python dictionaries? Hash tables under the hood.
Imagine you have a set of a thousand values, and need to check whether a specific value is part of that set. Iterating over that entire set of values is a computationally expensive proposition. The alternative is to build a hash table. Create an array of a fixed length, let’s say 256. The trick is to use a hash function to sort the values into this array, using the first eight bits of the hash output to determine which array location each value is stored in.
When you need to check whether a value is present in your set, simply run that value through the hash function, and then check the array cell that corresponds to the hash output. You may be ahead of me on the math — yes, that works out to about four different values per array cell. These hash collisions are entirely normal for a hash table. The lookup function simply checks all the values held in the appropriate cell. It’s still far faster than searching the whole table.
AMD processors use a hash table function to check whether memory requests are present in L1 cache. The Takeaway researchers figured out that hash function, and can use hash collisions to leak information. When the hash values collide, the L1 cache has two separate chunks of memory that need to occupy the same cache line. It handles this by simply discarding the older data when loading the colliding memory. An attacker can abuse this by measuring the latency of memory lookups.checking
If an attacker knows the memory location of the target data, he can allocate memory in a different location that will be stored in the same cache line. Then by repeatedly loading his allocated memory, he knows whether the target location has been accessed since his last check. What real world attack does that enable? One of the interesting ones is mapping out the memory layout of ASLR/KASLR memory. It was also suggested that Takeaway could be combined with the Spectre attack.
There are two interesting wrinkles to this story. First, some have pointed out the presence of a thank-you to Intel in the paper’s acknowledgements. “Additional funding was provided by generous gifts from Intel.” This makes it sound like Intel has been funding security research into AMD processors, though it’s not clear what exactly this refers to.
Lastly, AMD’s response has been underwhelming. At the time of writing, their official statement is that “AMD believes these are not new speculation-based attacks.” Now that the paper has been publicly released, that statement will quickly be proven to be either accurate or misinformed.
Closed Source Privacy?
The Google play store and iOS app store is full of apps that offer privacy, whether it be a VPN, adblocker, or some other amazing sounding application. The vast majority of those apps, however, are closed source, meaning that you have little more than trust in the app publisher to ensure that your privacy is really being helped. In the case of Sensor Tower, it seems that faith is woefully misplaced.
A typical shell game is played, with paper companies appearing to provide apps like Luna VPN and Adblock Focus. While technically providing the services they claim to provide, the real aim of both apps is to send data back to Sensor Tower. When it’s possible, open source is the way to go, but even an open source app can’t protect you against a malicious VPN provider.
Does the word “#backdoor” seem frightening? That’s because it’s often used incorrectly – sometimes to deliberately create fear. Watch to learn the truth about backdoors and other types of network access. #cybersecuritypic.twitter.com/NEUXbZbcqw
[Robert Graham] thought the whole story was fishy, and decided to write about it. He makes two important points. First, the Wall Street Journal article cites anonymous US officials. In his opinion, this is a huge red flag, and means that the information is either entirely false, or an intentional spin, and is being fed to journalists in order to shape the news. His second point is that Huawei’s redefinition of government-mandated backdoors as “front doors” takes the line of the FBI, and the Chinese Communist Party, that governments should be able to listen in on your communications at their discretion.
Graham shares a story from a few years back, when his company was working on Huawei brand mobile telephony equipment in a given country. While they were working, there was an unspecified international incident, and Graham watched the logs as a Huawei service tech remoted into the cell tower nearest the site of the incident. After the information was gathered, the logs were scrubbed, and the tech logged out as if nothing had happened.
Did this tech also work for the Chinese government? The NSA? The world will never know, but the fact is that a government-mandated “front door” is still a back door from the users’ perspective: they are potentially being snooped on without their knowledge or consent. The capability for abuse is built-in, whether it’s mandated by law or done in secret. “Front doors” are back doors. Huawei’s gear may not be dirtier than anyone else’s in this respect, but that’s different from saying it’s clean.
Abusing Regex to Fool Google
[xdavidhu] was poking at Google’s Gmail API, and found a widget that caught him by surprise. A button embedded on the page automatically generated an API key. Diving into the Javascript running on that page, as well as an iframe that gets loaded, he arrived at an ugly regex string that was key to keeping the entire process secure. He gives us a tip, www.debuggex.com, a regex visualizer, which he uses to find a bug in Google’s JS code. The essence of the bug is that part of the URL location is interpreted as being the domain name. “www.example.com\.corp.google.com” is considered to be a valid URL, pointing at example.com, but Google’s JS code sees the whole string as a domain, and thinks it must be a Google domain.
For his work, [xdavidhu] was awarded $6,000 because this bit of ugly regex is actually used in quite a few places throughout Google’s infrastructure.
SMBv3 Wormable Flaw
Microsoft’s SMBv3 implementation in Windows 10 and Server 2019 has a vulnerability in how it handles on-the-fly compression, CVE-2020-0796. A malicious packet using compression is enough to trigger a buffer overflow and remote code execution. It’s important to note that this vulnerability doesn’t required an authenticated user. Any unpatched, Internet-accessible server can be compromised. The flaw exists in both server and client code, so an unpatched Windows 10 client can be compromised by connecting to a malicious server.
There seems to have been a planned coordinated announcement of this bug, corresponding with Microsoft’s normal Patch Tuesday, as both Fortinet and Cisco briefly had pages discussing it on their sites. Apparently the patch was planned for that day, and was pulled from the release at the last moment. Two days later, on Thursday the 12th, a fix was pushed via Windows update. If you have Windows 10 machines or a Server 2019 install you’re responsible for, go make sure it has this update, as proof-of-concept code is already being developed.
