Every now and then, along comes an awesome hack from years past that we missed at the time. We kick ourselves for somehow missing such amazing work, and since it’s that good, we share it with you with apologies. Such is the case with [Andrei Anatska]’s faithful replication of the Pioneer CDJ-2000 user interface as an upgrade to the earlier CDJ-1000 DJ controller, a piece of work of such quality that you could almost mistake it for being a commercial product.

At its heart is the STM32F746G Discovery board, which for some reason it pleases us greatly in this context that he refers to as the Disco board. If you’re hazy on the details of the various STM dev boards, this is the all-singing all-dancing one with the fancy colour LCD display. Out comes the VFD on the CDJ-1000 and a set of wires are soldered to its main board, then the Disco board is hooked up with the project firmware installed. The piece de résistance is the case, for which he eschews 3D-printing and instead cuts out from black plastic. Full instructions can be found in this PDF, so should you happen to have a CDJ-1000 that’s seen better days, you can join in the fun. See it in action in the video below.

DJ controllers may be run-of-the-mill today, but to those of us whose DJing days were in the era of a pair of Technics SL1200s and a stack of vinyl to the sound of early ’90s house music they are still nothing short of miraculous. We’ve featured plenty of hacks involving them here but they don’t always involve professional kit. Even a game controller can be pressed into service.

Thanks [Niklas Fauth] for the tip.

source https://hackaday.com/2020/08/08/why-buy-the-newer-model-when-you-can-just-replicate-its-user-interface/

There was a magic moment for a few years around the end of the 1980s, when home computers were better than professional ones. That’s a mighty grand pronouncement, but it refers to the crop of 16-bit home computers that genuinely were far better than nearly all PCs at the time for multimedia tasks. You could plug a sampler cartridge into your Amiga and be in the dance charts in no time, something which sparked a boom in electronic music creativity. As retrocomputing interest has soared so have the prices of old hardware, and for those still making Amiga music that cart can now be outrageously expensive. it’s something [echolevel] has addressed, with an open-source recreation of an Amiga sampler.

As anyone who peered inside one back int he day will tell you, an Amiga sampler was a very simple device consisting of a commonly-available 8-bit A to D converter, a CMOS switch for right and left samples, and maybe an op-amp preamplifier. This is exactly what he’s produced, save fpr the CMOS switch as he points out that Amiga musicians use mono samples anyway. At its heart is an ADC0820 half-flash ADC chip, and the whole thing is realised on a very retro-looking through-hole PCB.

For a Hackaday scribe with a Technosound Turbo still sitting in a box somewhere it’s a real trip down memory lane. It was a moment of magic to for the first time be able to edit and manipulate audio on a computer, and we’re glad to see that something of those days still lives on. See it in action in the video below the break.

source https://hackaday.com/2020/08/08/an-amiga-sampler-30-years-later/

While these days we’re blessed with the magic of always-on internet connections and cloud services, back in the day software was delivered on physical media. Some of the most reviled media were data tapes, much maligned for their glacial loading times. However, the tangibility did give them some charm, and [JamHamster] decided to recreate this with his self-contained virtual tape loader.

The guts of the loader is a TZXDuino, a Spectrum tape emulator related to the Arduitape. It uses an Arduino Nano to store tape data files and replay them to load software on the retro platform. [JamHamster] combined this with a cassette tape shell and the head from a cassette audio adapter to make a digital tape emulator. The TZXDuino is crammed in the shell with a few mods, including a sensor that detects the play head moving inside the cassette to trigger playback. This stemmed from an earlier mod that did the same, just without an onboard battery.

It’s a tidy hack, and a very cool way to load games on your retro computer. With a firmware flash, it should be compatible with other systems too, thanks to the various computers supported by the wider Arduitape project. Tape emulators are popular with the community, thanks to eliminating the hassles of working with a now-obsolete format. Video after the break.

source https://hackaday.com/2020/08/07/self-contained-tape-loader-for-the-zx-spectrum/

Software defined radio or SDR has changed the radio landscape forever. But to use one you need to buy some kind of hardware right? Maybe not. As [Tech Minds] shows in a recent video there are plenty of SDRs publically available on the Internet. We know that isn’t news, but the video does cover several different methods of finding and using SDR receivers including many that run totally in the browser.

Of course, there are a lot of reasons you might want to borrow an alien radio receiver, even if you have your own hardware. Maybe you don’t have a great antenna or maybe you want to hear a signal — maybe even your own — from a different location.

Some of these methods even have the ability to pipe audio data out to another program if you want to do some sort of decoding or processing.  The SPY network uses the SDR# software, so you will have to install something for that. On the other hand, the program doesn’t really treat local hardware and remote any differently, so you can do lots of different things. But many of the programs will work inside a normal browser. SDR Console also needs some software, as well.

WebSDR works totally in the browser. KiwiSDR uses the very cool OpenWebRX interface and apparently it decodes radio signals on the server side, making it easy to listen to different signals in the browser.

With everyone having a bit more free time at home lately, this is a great way to take up listening to the radio with zero extra investment. Of course, if you have the inclination and the antennas, you can get a cheap dongle, although you’ll need an HF converter to listen to the shortwave bands. Or you can hack a QCX transceiver.

source https://hackaday.com/2020/08/07/virtual-software-defined-radio/

Wind turbines are a great source of renewable energy, and a great DIY project, too. They can be built with all kinds of materials and the barrier for entry is low for the beginner. [Fab] has built just such a device, taking advantage of modern construction techniques, and dubbed it the WinDIY.

The WinDIY design is mostly 3D printed, with a familiar three-bladed design. The diameter of the rotor is 1.2 m, meaning that braking and regulating the turbine is required for safety in high winds. [Fab] is aiming to achieve this control with a combination of mechanical and electronic braking, as well as variable-pitch blades. The benefit of 3D printing the design is it allows iterations to be made quickly, particularly of parts with complex geometries that would be too time-consuming or expensive to machine otherwise.

[Fab]’s writeup goes into great detail on topics like the design of the pitch control systems and other minutae, which should serve as a great reference for anyone else working on a similar project. If you’re looking for something with more of a sci-fi future vibe, consider attempting a vertical-axis build instead.

source https://hackaday.com/2020/08/07/hawt-wind-turbine-is-mostly-3d-printed/

This year, at DEF CON 28 DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?

To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.

There are several scenarios where interference can occur, the main ones are:

• Two radio systems occupy neighboring frequencies and carrier leakage occurs
• The harmonics of one transmitter fall on frequencies used by another system
• Two radio systems share the same frequencies

To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.

Spectra

Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.

Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.

Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.

Denial of Service

This happens when one wireless core denies transmission to the other core. DoS attacks are possible if one core is able to claim spectrum resources of the other core. As this is the basic working principle of any coexistence interface, all of them are vulnerable by definition, as long as one core keeps constantly claiming the resource for himself. Other DoS opportunities arise from one wireless core being able to crash another via shared RAM abuse.

Information Disclosure

One wireless core can infer data or actions of the other core. One example is when connecting an HID device like a keyboard. Timings and contents of keypresses can be observed on the host that receives those keystrokes. However, an attacker who has only code execution on a WiFi chip should not be able to make such observations. While the content of the keypresses are missing, it is possible for code running on the WiFi chip to infer timing statistics about the keys pressed in the Bluetooth side. This becomes interesting for inferring passwords and password lengths.

Code Execution

One wireless core can execute code within the other core. The security researchers demonstrate that it is possible to execute an arbitrary WiFi address with controlled contents via Bluetooth. This happens because when both cores are running, they share a RAM region which contain, among other information, a large function table. By overwriting a specific address, it is possible to control the WiFi core program counter. This means that a Bluetooth subsystem exploit can turn into a WiFi exploit. In addition, writing to the WiFi buffer and executing addresses produces various kernel panics on Android and iOS, indicating that further escalations into the host are possible and probably it’s just a matter of time until someone pops calc.

Conclusion

Although the research was centered on Broadcom and Cypress combo chips (which cover, by the way, all iPhones, MacBooks, iMacs, older Apple Watches, Samsung S and Note series, some Google Nexus, Raspberry Pi and so forth…) advisories were sent to Intel, MediaTek, Qualcomm, Texas Instruments, Marvell, NXP and they all mention similar coexistence interfaces in their devices. So, mutatis mutandis, and because of its very nature, some Spectra class vulnerabilities probably exist in other vendors too.

And since [Jiska] has a history breaking wireless stuff, we can probably expect a follow-up on this research and this class of inter-chip privilege escalation vulnerabilities. Can’t wait!

source https://hackaday.com/2020/08/07/separation-between-wifi-and-bluetooth-broken-by-the-spectra-co-existence-attack/

On July 23, multiple services related to Garmin were taken offline, including their call center and aviation related services. Thanks to information leaked by Garmin employees, we know that this multi-day outage was caused by the Wastedlocker ransomware campaign. After four days, Garmin was able to start the process of restoring the services.

It’s reported that the requested ransom was an eye-watering $10 million. It’s suspected that Garmin actually paid the ransom. A leaked decryptor program confirms that they received the decryption key. The attack was apparently very widespread through Garmin’s network, as it seems that both workstations and public facing servers were impacted. Let’s hope Garmin learned their lesson, and are shoring up their security practices.

KeePass

KeePass released an update this week addressing a couple flaws in the KeePassRPC service. The update announcement is light on the details, but thankfully we have the full story directly from [Philipp Danzinger], the student that discovered the vulnerabilities. Both vulnerabilities are in the implementation of the SRP-6(a) key exchange protocol.

The vulnerable component is the RPC. KeyPass is essentially a simple database containing passwords. That database is encrypted using the user’s password, so the contained passwords cannot be retrieved without that master password. When a user launches KeePass, he or she is first prompted for this master password, and the database is decrypted using that password. The KeePassRPC service allows other processes, like a browser plugin, to access the now-decrypted database. The first time a new client attemps to access the RPC service, a keypair is generated, and the user is prompted whether to allow the new connection. The public key is stored and marked as trusted, allowing that client to request passwords again in the future, so long as the database had been unlocked.

The authentication protocol is similar to a DH key exchange. A shared value is raised to the power of the secret key resulting in a value called A. This is sent as part of the key exchange, and the formal specification states that it is never allowed to be 0. The problem is that KeePassRPC doesn’t properly check that A != 0. When A is set to 0, the entire key exchange breaks down, as all the values end up equaling 0, as 0^x is always 0. This means that any client can spoof an already authorized client.

The second vulnerability is a weak random number generator used on the server side to generate the secret key b. That key is based on the current date and time, run through a pseudo-random function. Because that function is known, if an attacker can guess the exact time value used, then the secret key is easily calculated. It’s not quite as simple as it seems, as the time value is measured in “ticks”, each tick being 100 nanoseconds. It would take a bit of guesswork and a few thousand guesses to land on the right value, but without any rate limiting, that process would just take a few seconds.

What makes this attack very serious is the fact that modern web browsers allow Javascript running on a webpage to attempt to connect to localhost. If your KeePass database is unlocked, and you load a page running malicious JS, it could access the RPC port and spoof the authorized KeePass browser plugin and download your entire KeePass database. Thankfully this bug was disclosed privately and KeePassRPC has been updated to 1.12.1, which closes both vulnerabilities. Additionally, 1.13 has since been released with additional safeguards against this and similar attacks.

Twitter

Twitter has started displaying a security warning for some users. The details are extremely scarce, but lets see what details we can tease out. First, the warning specifies that the issue in question was a vulnerability in the Twitter Android app, but that it was related to an Android vulnerability, and then links to the October 2018 Android security update. Looking through the vulnerabilities disclosed, there doesn’t seem to be an obvious candidate for the related vulnerability.

KDE Ark

We’ve seen a very simple technique show up in countless security stories: path transversal. It’s simple, you can include a “..” as part of a file path to move up a directory. Often times this can be included in unexpected places to bypass security restrictions, or do other unintended things. Archive files are no exception, and there is nothing preventing a zip archive from having such paths. Most archive programs catch this behavior and don’t allow the archive to extract as it’s written. The venerable unzip command complains like this:

# unzip relative2.zip 
Archive:  relative2.zip
warning:  skipped "../" path component(s) in tmp/../../moo
 extracting: tmp/moo

KDE Ark, until recently, didn’t treat those paths as special, and would happily extract files to whatever path it was instructed to. The update doesn’t seem to be officially released at the time of writing, so be wary of blindly extracting archives until that update is available. There is a useful repository of archives that can be used to test for various transversal issues, and I’ve confirmed that one in particular (harmless zip file containing tmp/../../moo) does demonstrate the issue in Ark.

And Finally…

Remember Boothole? Multiple vendors pushed fixes to this Linux secure boot vulnerability, and a handful of unbootable systems was the result. For the case of RHEL and CentOS, another round of updated packages have been released, fixing the problem and making for bootable systems again.

And what does a criminal do with a database breach? Apparently after selling them, they release them for free. If it wasn’t stolen data, I’d call it a win. Once a breach has made as much money as the seller thinks it’s likely to make, it’s not uncommon for the data to be released for free. These aren’t very popular sites or services, but it might be worth a check to see if your data was included in the release.

source https://hackaday.com/2020/08/07/this-week-in-security-garmin-ransomware-keepass-and-twitter-warnings/