Greetings from SensorFu and thanks for a good question! Sending DNS query via broadcast is a hack to escape from isolated environments and it takes advantage of operating system IP-stack's shortcomings. Since this is probably not conforming to any specifications anything could happen.
I'd say return channel might work and it depends on the device used to exfiltrate out. In case of proper DNS server like Active Directory mentioned in the article it's likely that it could work. But we have not yet done testing.
We have also seen devices that are not DNS servers and still just forward broadcast packets from one network interface to another. In such case the return channel might not be possible.
The minimal effort included hours of studying electrical engineering and radio technology at university including all the math and physics needed. Studying for amateur radio license. And after founding this issue delving deep into radio interference literature and datasheets of various components. Then setting up a test environment to replicate the issue and do tests trying to eliminate the interference. After a success write a blog post describing the solution in short and hopefully interesting way.
The issue was confirmed with two separate MagSafe chargers and three or four separate AC/DC chargers. The lab test in the post was done using laboratory DC power supply powering a DC to USB converter.
Also if the interference didn't come from the disc side of charger then the issue wouldn't be resolved with ferrite bead on that end. If the issue was on the USB connector side then the bead should be placed there.
You can be using a device and it might not harm you personally, but it could harm anyone around you using these frequencies. This includes airplanes and ground control, and boats. Your device's interference could cause problems or even life threatening dangerous situations. That's why it's illegal in many countries to cause too much radio interference (there's always some).
Sorry - I can clarify a little. If it complies with regulations, Apple is definitely not at fault.
I was just replying to the above comment which could read “a little noise from a single device isn’t a big deal.”
It is definitely up to regulators to decide what is acceptable, and up to Apple to meet those regulations. It’s still a little unclear from the OP whether or not the spurious emissions meet transmission requirements, but it definitely a good place to do further lab tests for compliance.
> but it could harm anyone around you using these frequencies.
Not really. Part of the FCC certification process is that devices need to accept interference from other devices operating within the limits.
Go read the FCC sticker on the bottom of any nearby device if you don’t believe me. It’s spelled out in the text.
The only reason the author had a problem is they put it right next to, quite literally, a highly sensitive receiver tuned to the exact frequency. It doesn’t mean the device was exceeding FCC limits, it means the ham operator needed to carefully set up their environment more tightly then even the FCC limits.
> Part of the FCC certification process is that devices need to accept interference from other devices operating within the limits
Note that only some classes of device have this requirement to accept all interference from devices operating within the limits. For some classes of devices if a consumer device interferes with then the consumer device's owner is responsible for stopping the interference even if the consumer device is operating entirely within limits.
The FCC regulations are divided into several parts, covering different devices and services. For example Part 87 covers various aviation radio services and devices, Part 97 covers Amateur Radio, and Part 20 covers mobile phones.
For any given frequency there might be devices or services covered under several different parts that can radiate on that frequency. There will generally be some kind of hierarchy among them where devices are not allowed to interfere with devices higher in the hierarchy and must accept interference from devices higher in the hierarchy.
The Part that covers much of consumer electronics other than mobile phones is Part 15. For most common consumer devices, if it is not a mobile phone and you did not need to get a license from the FCC to use it it probably falls under Part 15. This includes "intentional radiators", which are devices that are intended to emit radio such as WiFi routers, "unintentional radiators", which are devices that intentionally generate radio frequency energy within the device but it is meant to stay within wires or within the device, and "incidental radiators", which are devices that aren't intended to generate radio frequency energy but do so as a side effect such as DC motors and mechanical light switches.
Part 15 is at the bottom of the hierarchy.
For Part 15 devices, 47 CFR 15.5(b) says:
> Operation of an intentional, unintentional, or incidental radiator is subject to the conditions that no harmful interference is caused and that interference must be accepted that may be caused by the operation of an authorized radio station, by another intentional or unintentional radiator, by industrial, scientific and medical (ISM) equipment, or by an incidental radiator.
Other Parts can have quite different rules. For example Part 95 Subpart C, which covers radio control such as is commonly used in RC models, says this:
> (a) RCRS stations must not cause interference to:
> (1) Authorized radio operations in the 72–76 MHz band, including radio remote control of industrial equipment on the same or adjacent channels; or,
> (2) Broadcast television reception on TV Channels 4 or 5.
> (b) RCRS operations are not afforded protection from interference caused by the operation of:
> (1) Industrial, scientific or medical devices (see part 18 of this chapter) operating in the 26–28 MHz band; and,
> (2) Fixed and mobile stations in other services operating on the same or adjacent channels.
For Amateur ("ham") Radio, the interference rules are much more extensive, because hams are authorized to use a lot of frequency bands that overlap other services. Here's a link if anyone is curious [1].
RouterOS by default doesn't have container support. It's a separate package which has to be installed on the system. And it is still in testing / beta phase.
I have been back-and-forth between Time Machine and switching to something else. I'm still using TM, but what alternatives do I have? Any recommendations?
Arq is great, but my quibble with it is that, like all third-party backup solutions, it relies on scanning the file system. Any such program, Arq included, will take a very long time to run on a hard drive where absolutely nothing has changed.
What Time Machine does is use macOS's local database of pending changes, FSEvents. On the next backup cycle, it knows what's changed and doesn't need to scan unless the FSEvents database is missing or corrupt.
I'm looking forward to a time when Time Machine can take advantage of file system snapshotting, which apparently was a design goal for APFS. Snapshotting is used for Apple's Software Restore function now, but the Time Machine parts weren't ready for Catalina [1].
I have been using Arq for years. Locally over SSH to our NAS, remotely with B2 as well. I have done many restores over those years, both when installing a new machine or when I lost some file. It's really awesome, especially because it's decoupled from any storage vendor. You just buy a license and choose where you want to store backups.
On Linux I use restic, which is also great, but on macOS Arq is just more seamless.
Indeed! I also have a setup where the secrets come from the pass password manager, which I use with a hardware OpenPGP token. So, I get these global PIN dialogs once gpg-agent expires the PIN, which is quite annoying :(. Not sure though how to solve this nicely without making the secrets to visible to the rest of the system.
Also using Arq + B2, though it's much better with a high speed internet connection. On a 1Mbps max upload speed it was sometimes painful and had problems, with my new 20Mbps upload it's great.
I trust my SuperDuper local backups much more though. SuperDuper is amazing.
The software in question (called Beacon) is designed to call home. The binary has built-in cryptographic keys and it sends traffic encrypted. The receiving end, called Home, receives these packets, decrypts it and verifies the sender and after that gives an alert.
The exe must have been running to be able to generate the proper encrypted payload and send it to right place. In this case ports 20 and 1025 over TCP.
Disclaimer: I am one of the people who wrote the software.
> Library order randomization: In rc(8), re-link libc.so, libcrypto, and ld.so on startup, placing the objects in a random order. Theo de Raadt and Robert Peichaer, May 2016, enabled by default since OpenBSD 6.0 and 6.2.
and
> Kernel relinking at boot: the .o files of the kernel are relinked in random order from a link-kit, before every reboot. This provides substantial interior randomization in the kernel's text and data segments for layout and relative branches/calls. Basically a unique address space for each kernel boot, similar to the userland fork+exec model described above but for the kernel. Theo de Raadt, June 2017.
