A few weeks ago we published an article on the newly released Keysight 1000X, an oscilloscope that marks Keysight’s late but welcome entry into the hacker-centric entry-level market. Understandably, this scope is causing a lot of excitement as it promises to bring some of the high-end pedigree of the well-known 2000X and 3000X models down to a much affordable price. Now couple that with the possibility of hacking its bandwidth lock and all this fuss is well justified.
[Dave Jones] from the EEVblog got his hands on one, and while conducting a UART dump saw the scope report 200 MHz bandwidth despite being labelled as a 100 MHz model. He then proceeded to actually hack the main board to unlock an undocumented 200 MHz bandwidth mode. This created a lot of confusion: some said [Dave] got a “pre-hacked” version, others assumed all 100 MHz versions actually have a stock bandwidth of 200 MHz.
Alongside the question of bandwidth, many wondered how this would fare against the present entry-level standard, the Rigol 1054Z. Is the additional cost and fewer channels worth the Keysight badge?
Keysight’s response to our queries and confusion was the promise to send us a review unit. Well, after receiving it and playing around with it, clearly a lot of Keysight’s high-end excellence has trickled down to this lower end version. However, this machine was not without some silly firmware issues and damning system crashes! Read on the full review below. Continue reading “Scope Review: Keysight 1000 X-Series”→
Betteridge’s Law of Headlines states, “Any headline that ends in a question mark can be answered by the word no.” This law remains unassailable. However, recent claims have called into question a black box hidden deep inside every Intel chipset produced in the last decade.
Yesterday, on the Semiaccurate blog, [Charlie Demerjian] announced a remote exploit for the Intel Management Engine (ME). This exploit covers every Intel platform with Active Management Technology (AMT) shipped since 2008. This is a small percentage of all systems running Intel chipsets, and even then the remote exploit will only work if AMT is enabled. [Demerjian] also announced the existence of a local exploit.
Intel’s ME and AMT Explained
Beginning in 2005, Intel began including Active Management Technology in Ethernet controllers. This system is effectively a firewall and a tool used for provisioning laptops and desktops in a corporate environment. In 2008, a new coprocessor — the Management Engine — was added. This management engine is a processor connected to every peripheral in a system. The ME has complete access to all of a computer’s memory, network connections, and every peripheral connected to a computer. The ME runs when the computer is hibernating and can intercept TCP/IP traffic. Management Engine can be used to boot a computer over a network, install a new OS, and can disable a PC if it fails to check into a server at some predetermined interval. From a security standpoint, if you own the Management Engine, you own the computer and all data contained within.
The Management Engine and Active Management Technolgy has become a focus of security researchers. The researcher who finds an exploit allowing an attacker access to the ME will become the greatest researcher of the decade. When this exploit is discovered, a billion dollars in Intel stock will evaporate. Fortunately, or unfortunately, depending on how you look at it, the Managment Engine is a closely guarded secret, it’s based on a strange architecture, and the on-chip ROM for the ME is a black box. Nothing short of corporate espionage or looking at the pattern of bits in the silicon will tell you anything. Intel’s Management Engine and Active Management Technolgy is secure through obscurity, yes, but so far it’s been secure for a decade while being a target for the best researchers on the planet.
Semiaccurate’s Claim
In yesterday’s blog post, [Demerjian] reported the existence of two exploits. The first is a remotely exploitable security hole in the ME firmware. This exploit affects every Intel chipset made in the last ten years with Active Management Technology on board and enabled. It is important to note this remote exploit only affects a small percentage of total systems.
The second exploit reported by the Semiaccurate blog is a local exploit that does not require AMT to be active but does require Intel’s Local Manageability Service (LMS) to be running. This is simply another way that physical access equals root access. From the few details [Demerjian] shared, the local exploit affects a decade’s worth of Intel chipsets, but not remotely. This is simply another evil maid scenario.
Should You Worry?
This hacker is unable to exploit Intel’s ME, even though he’s using a three-hole balaclava.
The biggest network security threat today is a remote code execution exploit for Intel’s Management Engine. Every computer with an Intel chipset produced in the last decade would be vulnerable to this exploit, and RCE would give an attacker full control over every aspect of a system. If you want a metaphor, we are dinosaurs and an Intel ME exploit is an asteroid hurtling towards the Yucatán peninsula.
However, [Demerjian] gives no details of the exploit (rightly so), and Intel has released an advisory stating, “This vulnerability does not exist on Intel-based consumer PCs.” According to Intel, this exploit will only affect Intel systems that ship with AMT, and have AMT enabled. The local exploit only works if a system is running Intel’s LMS.
This exploit — no matter what it may be, as there is no proof of concept yet — only works if you’re using Intel’s Management Engine and Active Management Technology as intended. That is, if an IT guru can reinstall Windows on your laptop remotely, this exploit applies to you. If you’ve never heard of this capability, you’re probably fine.
Still, with an exploit of such magnitude, it’s wise to check for patches for your system. If your system does not have Active Management Technology, you’re fine. If your system does have AMT, but you’ve never turned it on, you’re fine. If you’re not running LMT, you’re fine. Intel’s ME can be neutralized if you’re using a sufficiently old chipset. This isn’t the end of the world, but it does give security experts panning Intel’s technology for the last few years the opportunity to say, ‘told ‘ya so’.
The Teensy is a powerful ARM-based development board with loads of features that can do fun stuff with USB as well. Like many dev boards, it uses a less powerful processor as an interface. Teensy designer [Paul Stoffregen] added a debug header to allow direct SWD JTAG access to the main chip, but the interface microcontroller has to be silenced for that to work, and the code to do so is still in progress.
Impatient, [Erich Styger] documents the changes he made to add support for the J-Link SWD protocol by removing the offending NXP Kinetis KL02Z that serves as the as the onboard interface and bootloader that helps the Arduino IDE talk to the K64F which is the main chip. After the KL02Z was removed, [Erich] populated the debug headers and then wired up the Segger J-Link to the board and tested it out with Eclipse, GDB, and standard SWD debug tools.
The end result is a Cortex M4F board that can work with standard tools at a third of the price of the Kinetis’ development board. [Paul Stoffregen] confirms that the debugging functionality will be added to the bootloader code soon but until then, a hardware hack is a working, if brutal, approach to debugging on the platform.
SCSI devices were found in hundreds of different models of computers from the 80s, from SUN boxes to cute little Macs. These hard drives and CDROMs are slowly dying, and with that goes an entire generation of technology down the drain. Currently, the best method of preserving these computers with SCSI drives is the SCSI2SD device designed by [Michael McMaster]. While this device does exactly what it says it’ll do — turn an SD card into a drive on a SCSI chain — it’s fairly expensive at $70.
As far as the hardware goes, this is a pretty simple build. The 40-pin GPIO connector on the Pi is attached to the 50-pin SCSI connector through a few 74LS641 transceivers with a few resistor packs for pullups and pulldowns. The software allows for virtual disk devices – either a hard drive, magneto-optical drive, or a CDROM – to be presented from the Raspberry Pi. There’s also the option of putting Ethernet on the SCSI chain, a helpful addition since Ethernet to SCSI conversion devices are usually rare and expensive.
Officially, [GIMONS] built this SCSI hard drive emulator for the x68000 computer, developed by Sharp in the late 80s. While these are popular machines for retrocomputing aficionados in Japan, they’re exceptionally rare elsewhere — although [Dave Jones] got his mitts on one for a teardown. SCSI was extraordinarily popular for computers from the 70s through the 90s, though, and since SCSI was a standard this build should work with all of them.
It’s no secret that a vast amount of American infrastructure is in great need of upgrades, repairs or replacements. The repairs that are desperately needed will come, and they will come in one of two ways. Either proactive repairs can be made when problems are first discovered, or repairs can be made at considerably greater cost after catastrophic failures have occurred. As was the case with the I-35 bridge collapse in Minnesota, we often pay in lives as well. Part of the problem is that infrastructure isn’t very exciting or newsworthy to many people outside of the civil engineering community which leads to complacency and apathy. As a result, it’s likely that you may not have heard about the latest struggle currently playing out in California even though it involves the largest dam in the United States and its potential failure.
Surprisingly enough, the largest dam in the US isn’t the famous Hoover Dam but the Oroville Dam at the base of the Sierra Nevada mountain range in California. At 235 meters, it is almost 15 meters taller than the Hoover Dam. It can store over four cubic kilometers of water but whether or not it will keep storing that water into the future is currently under question. In February of this year during a flood control operation damage was observed on the dam’s spillway where a massive hole had formed which only got larger as the dam was forced to continue releasing water. The hole quickly grew, and the floodwaters eroded much of the lower half of the spillway embankment, forming a canyon. Continue reading “Another California Water Crisis”→
The Pine A64 was a 64-bit Quad-Core Single Board Computer which was kickstarted at the tail end of 2015 for delivery in the middle of 2016. Costing just $15, and hailed as a “Raspberry Pi killer,” the board raised $1.7 million from 36,000 backers. It shipped to its backers to almost universally poor reviews.
Now they’re back, this time with a laptop—a 11.6-inch model for $89, or a 14-inch model for $99. Both are powered by the same 64-bit Quad-Core ARM Cortex A53 as the original Pine A64 board, but at least Pine are doing a much better job this time around of managing user expectations.
[Yingtao Zeng], [Qing Yang], and [Jun Li], a.k.a. the [UnicornTeam], developed the cheapest way so far to hack a passive keyless entry system, as found on some cars: around $22 in parts, give or take a buck. But that’s not all, they manage to increase the previous known effective range of this type of attack from 100 m to around 320 m. They gave a talk at HITB Amsterdam, a couple of weeks ago, and shown their results.
The attack in its essence is not new, and it’s basically just creating a range extender for the keyfob. One radio stays near the car, the other near the car key, and the two radios relay the signals coming from the car to the keyfob and vice-versa. This version of the hack stands out in that the [UnicornTeam] reverse engineered and decoded the keyless entry system signals, produced by NXP, so they can send the decoded signals via any channel of their choice. The only constraint, from what we could tell, it’s the transmission timeout. It all has to happen within 27 ms. You could almost pull this off over Internet instead of radio.
The actual keycode is not cracked, like in a HiTag2 attack. It’s not like hacking a rolling key keyfob either. The signals are just sniffed, decoded and relayed between the two devices.
A suggested fix from the researchers is to decrease this 27 ms timeout. If it is short enough, at least the distance for these types of attacks is reduced. Even if that could eventually mitigate or reduce the impact of an attack on new cars, old cars are still at risk. We suggest that the passive keyless system is broken from the get-go: allowing the keyfob to open and start your car without any user interaction is asking for it. Are car drivers really so lazy that they can’t press a button to unlock their car? Anyway, if you’re stuck with one of these systems, it looks like the only sure fallback is the tinfoil hat. For the keyfob, of course.
