Infineon Buys Cypress For $10B

Infineon will acquire Cypress Semiconductors for nearly $10 Billion dollars. This is the latest merger or acquisition in the semiconductor industry, and these mergers and acquisitions show no sign of stopping anytime soon.

Infineon’s market currently consists mostly of products aimed at the automotive market and power management and control. Cypress, likewise, has a wide portfolio of automotive electronics, from the guts of instrument clusters to the brains of infotainment systems. The automotive electronics industry is going gangbusters right now, and companies in the market are flush with cash; Infineon acquiring Cypress allows both companies to focus their R&D to develop products for the same market.

As with all mergers and acquisitions, there is the question of what may be lost, or what may go out of production. Cypress is most famous for their PSOC microcontrollers, but for now those uCs, and their CapSense capability, seem safe. Cypress is also noteworthy for manufacturing old-school memories, but again it looks like you’ll still be able to buy these years down the line; in any event, Alliance memory is still around stuffing DRAMs in DIPs.

This acquisition of Cypress by Infineon is one of the largest in recent memory. Apple recently bought a $600 Million stake in Dialog, and Microchip acquired Microsemi for $8.35 Billion. Tesla bought Maxwell Technologies for a mere $218 Million. This deal between Infineon and Cypress puts the company in the upper echelon of recent mergers and acquisitions.

The UK Drone Community Fights Back, Gains FOI Admission Of No Tangible Drone Evidence

Regular Hackaday readers will have noted a succession of stories following the reports of drones in the air over British airports and in proximity to aircraft. We’ve consistently asked for a better quality of investigation and reporting into these cases, because so far the absence of reported tangible evidence of a drone being present casts doubt on the validity of the official reaction. For too long the official records of air proximity incidents have relied upon a shockingly low standard of proof when apportioning blame to drone operators, and this situation has contributed to something of a panic over the issue.

It seems that some members of the British drone flying community are on the case though. Airprox Reality Check are a group analysing air proximity reports and linking them to contemporary ADS-B and weather records to identify possible explanations. They have devised a rating system based upon a number of different metrics in an attempt to quantify the reliability of a particular report, and they are tabulating their analysis of air proximity reports on a month by month basis. This includes among many analyses such gems as Airprox Report #2019046, in which an Embraer 170 flying at 9000 feet and 20 km offshore reported a drone in close proximity. The Airprox Reality Check analysis points out that no known drone could manage that feat, and refers to a passing Boeing 737 revealed through ADS-B data as a more likely culprit.

Their latest news is that they have made a Freedom of Information request to the Air Proximity Board, asking for what evidence the Board has of a drone having been involved in any of the over 350 incidents in UK airspace having been reported as involving drones. The official response contains the following quote:

in all cases UKAB has no confirmation that a drone has flown close to an aircraft other than the report made by the pilot(s). Similarly, other than from the report of the pilot(s), UKAB has no confirmation that a drone was involved.

This confirms the view of the multirotor and drone community that has been reported by Hackaday in the past, that the whole British drone panic has been based upon unreliable and uncorroborated reports from eyewitnesses with little direct experience of multirotors. If any irresponsible drone operator is flying into close proximity with aircraft or otherwise into protected airspace then it goes without saying that they should be prosecuted, yet it seems that the community is being punished as though this had happened when the reality is that no such acts are proven to have occurred.

This Week In Security: Baltimore, MacOS Zipfile Security, And App Store Monopolies

Baltimore. The city was breached, crippled and held for ransom. The ransomware attack was discovered on May 7th, shutting down a major portion of the city’s infrastructure. The latest news is that an NSA-written tool, EternalBlue, is responsible for the attack. Except maybe it isn’t? First off, digging back through the history of an attack is challenging. It’s often hard to determine the initial attack vector with certainty.

The “initial attack vector” is the patient zero of the attack — how the first machine was compromised. An organization generally has a firewall separating the outside internet from the internal network. Once an attacker has found a way to access a machine inside the network, the separation is not nearly so strict. This takes many forms, but the most common is phishing. Close contenders are RDP and SMB (Remote Desktop and Windows File Sharing). A report at Ars Technica indicates that the initial vector into the Baltimore network was a phishing email.

The second step to consider is what’s called “lateral movement”, which describes an attacker using the compromised machine to target other machines in the organization. Often an attacker will have an entire toolkit of exploits to attempt to compromise other machines. One of the exploits used in this case was the same exploit contained in the NSA tool, EternalBlue. A clever program called psexec is usually part of any lateral movement campaign. While the exploit associated with EternalBlue was probably used to compromise a few of the machines on the Baltimore network, placing all the blame on the shoulders of the NSA is missing the point. The tool is only a small part of this attack.

MacOS and NFS Shares Inside Zipfiles

MacOS has a sometimes irritating feature, Gatekeeper, that only allows running signed binaries by default. The point of Gatekeeper is to prevent a user from running a malicious binary that has been downloaded from the internet. While it is sometimes an annoyance, it is helpful for some users. [Filippo Cavallarin] announced an exploit that completely bypasses Gatekeeper on the 24th. This exploit takes advantage of the fact that Gatekeeper considers network shares to be trustworthy, and doesn’t run the normal check before executing a binary located there. While interesting, this isn’t useful unless there is a way for an attacker to mount a malicious location as a network share. Enter the Mac’s ability to automatically mount network locations through the use of the /net path. The last piece of this puzzle is the fact that zip files can contain symbolic links. A zip file can be built with a link to the /net location, automounting an arbitrary NFS location. If binary files are located in this location, the OS will happily allow the user to execute those binaries whether signed or not.

This exploit may not be the most serious of the year, but it’s still a problem that needs fixing. [Filippo] contacted Apple back in February and disclosed the problem, even getting an assurance that they would fix it within 90 days. 90 days have passed, and Apple has begun ignoring his emails, so he has made the announcement and published steps to reproduce on his website.

There has been discussion in the comments of this column about vulnerability disclosure and publishing proof of concept code. This is a perfect example of why researchers publish their work. As far as [Filippo] knows, Apple has no intention of fixing the issue he discovered. He also has no reason to believe that no one else has stumbled on this discovery before he did. We mentioned EternalBlue above. The NSA discovered the SMB vulnerability that exploit targeted and used it silently for up to five years before it was stolen and finally disclosed to Microsoft and fixed. Make no mistake, public disclosures and proof of concepts get vulnerabilities fixed. For any given vulnerability, there is no guarantee that someone else hasn’t already found it.

Just a Little Document Leak

OK, maybe not so little. A Fortune 500 company, First American, managed to host millions of private documents in an accessible format. Imagine you upload a document to a company, and get a confirmation link that looks like “test.com/documents.php?id=0252234”. If you’re like me, you’re very curious what is at id=0252233. [Ben Shoval] is a real estate developer who apparently also wanted to know the answer to that question. To his surprise, millions of uploaded documents were available for anyone to view. He tried reaching out to First American, and when there was no response to his emails, he forwarded his findings on to Krebs on Security. After what was likely years of exposure, the database was finally taken offline Friday the 24th.

Walled Garden Monopolies

Staying on the Apple train, the App Store is pretty obviously a monopoly. Someone has finally asked whether it’s an illegal monopoly. As most of these questions go, it’ll take a drawn out court battle to decide. How is this security news? If the court finds that Apple has been violating antitrust laws, one possible remediation is to allow alternative app stores. While there is always the potential for a high quality alternative store like F-droid, sketchy app stores and downloaded are a real possibility. On the other hand, it would be nice to have an iOS app store that is compatible with the GPL.

Making Autonomous Racing Drones Lean And Mean

Recently the MAVLab (Micro Air Vehicle Laboratory) at the Technical University of Delft in the Netherlands proudly proclaimed having made an autonomic drone that’s a mere 72 grams in weight. The best part? It’s designed to take part in drone races. What this means is that using a single camera and onboard processing, this little drone with a diameter of 10 centimeters has to navigate the course, while avoiding obstacles.

To achieve this goal, they took an Eachine trashcan drone, replacing its camera with an open source JeVois smart machine vision camera and the autopilot software with the Paparazzi open UAV software. Naturally, scaling a racing drone down to this size came at an obvious cost: with its low-quality sensors, relatively low-quality camera and limited processing power compared to its big brothers it has to rely strongly on algorithms that compensate for drift and other glitches while racing.

Currently the drone is mainly being tested at a four-gate race track at TU Delft’s Cyberzoo, where it can fly multiple laps at a leisurely two meters per second, using its gate-detecting algorithms to zip from gate to gate. By using machine vision to do the gate detection, the drone can deal with gates being displaced from their position indicated on the course map.

While competitive with other, much larger autonomous racing drones, the system is still far removed from the performance of human-controlled racing drones. To close this gap, MAVLab’s [Christophe De Wagter] mentions that they’re looking at improving the algorithms to make them better at predictive control and state estimation, as well as the machine vision side. Ideally these little drones should be able to be far more nimble and quick than they are today.

See a video of the drone in action after the link.

Continue reading “Making Autonomous Racing Drones Lean And Mean”

Please Meet ‘Capability Inquiry’, Part Of The MIDI 2.0 Standard

It may have passed you by in the news, but the MIDI Manufacturers Association (MMA) has recently unveiled more details about the upcoming MIDI 2.0 standard. Previously we covered the prototyping phase start of this new standard. The original Musical Instrument Digital Interface standard was revealed all the way back in August of 1983, as a cooperation between companies including Moog Music, Roland, Yamaha, Korg, Kawai and others. It was the first universal interface that allowed one to connect and control all kinds of musical instruments.

Over the years, MIDI has seen use with the composing of music, allowing instruments to be controlled by a computer system and to easily share compositions between composers. Before MIDI such kind of control was limited to a number of proprietary interfaces, with limited functionality.

The MMA lists the key features of MIDI 2.0 as: Bidirectional, Backwards Compatible, and the enhancing of MIDI 1.0 where possible. Using a new technology called MIDI Capability Inquiry (MIDI-CI), a MIDI 2.0 device can exchange feature profiles and more with other 2.0 devices. 1.0 is the fallback if MIDI-CI finds no new functionality. MIDI-CI-based configuration can allow 2.0 devices to automatically configure themselves for their environment.

Suffice it to say, MIDI 2.0 is a far cry from the original MIDI standard. By transforming MIDI into a more versatile, bidirectional protocol, it opens new ways in which it can be used to tie musical devices and related together. It opens the possibility of even more creative hacks, many of which were featured on Hackaday already. What will you make with MIDI 2.0?

See a brief demonstration of this feature of MIDI 2.0 in the below video:

Continue reading “Please Meet ‘Capability Inquiry’, Part Of The MIDI 2.0 Standard”

This Week In Security: Zombieload, And Is Your Router Leaking?

Do you know what your router is doing? We have two stories of the embedded devices misbehaving. First, Linksys “Smart” routers keep track of every device that connects to its network. Right, so does every other router. These routers, however, also helpfully expose that stored data over JNAP/HNAP.

Some background is needed here. First, HNAP is the Home Network Administration Protocol, designed to manage routers and network devices. Originally designed by Pure Networks, HNAP is a SOAP based protocol, and has been part of security problems in the past. You may also see the term JNAP. It seems that JNAP is the JSON Network Administration Protocol, identical to HNAP except for using JSON instead of SOAP.

The odd part is that this is an old problem. CVE-2014-8244 was disclosed and fixed in 2014. According to the writeup at Badpackets.net, the problem was re-discovered as a result of observing active network attacks targeting JNAP. When Linksys was informed of the rediscovered problem, they responded that the problem was fixed in 2014, and devices with updated firmware and default settings are not accessible from the public internet. The presence of over 20,000 devices leaking data casts doubt on their response. Continue reading “This Week In Security: Zombieload, And Is Your Router Leaking?”

Hacker Dosed With LSD While Restoring Historical Synth

[Eliot Curtis] found himself a little too close to 1960’s counterculture while restoring a vintage modular synthesizer — he began tripping out on acid. The instrument in question is a Buchla Model 100. The Buchla is a modular synth. Instead of a keyboard, it used capacitance-sensitive touch plates. This particular model 100 was purchased by California State University East Bay Campus. The synth was popular for a while, but eventually fell into disuse, and was stored in a classroom closet.

Modular synths are experiencing a renaissance, as can be seen right here on Hackaday. The Buchla was pulled out of storage and given a proper restoration. [Eliot Curtis] is the Broadcast Operations Manager at KPIX 5, the San Francisco CBS TV station. He also is the hacker who volunteered to restore the Buchla.
During the restoration, [Curtis] found residue and crystals stuck under one of the knobs of the Control Voltage Processing Module. Was it flux, conformal coating, or something else? [Eliot] hit the board with contact cleaner and wiped it down. Within 45 minutes, he was feeling a strange tingling. It was the beginning of a nine-hour LSD trip. Three independent tests on the module came back positive for LSD.

Lysergic acid diethylamide (LSD for short) can be readily absorbed through the skin, which is exactly what happened to [Eliot]. Synth designer [Don Buchla] was friends with [Owsley Stanley], who worked for the Grateful Dead and allegedly cooked up some very potent LSD. Some of Buchla’s modules even found their way into Ken Keesey’s hands, where they wound up on his famous bus “further”. As it turns out there were rumors that modules had been dipped in LSD back in the ’60s. Why someone would do that to an electronic module, we’re not sure — they must have been on drugs. [Eliot] recovered from his brush with the ’60s and continued with the restoration with gloves on.

If there is a moral here, it should be to take precautions when working on equipment which might contain dangerous substances. We’ve learned this lesson ourselves cracking open broken laptops. You might find anything from coffee to soda, to pet urine or worse. A box of nitrile gloves definitely should be standard equipment in any hacker’s lab.