The Raspberry Pi holds incredible promise for those looking to build a small mobile terminal that they can take with them on the go, something you can throw into your bag and pull out whenever there’s some hacking to be done. But getting the diminutive Linux board to that point can take quite a bit of work. You need to find a suitably small keyboard, design a custom case, and wire it all up without letting any of that pesky Magic Smoke escape.
But a recent project from [remag293] might make things a bit easier for those looking to get their feet wet in the world of custom mobile computers. The boxy handheld device has everything you need, and nothing you don’t. A basic case, a short parts list, and an absolute minimum of wiring. What’s not to love? Even if you don’t make an exact clone of this device, it’s an excellent reference to quickly bootstrap your own bespoke terminal.
So what’s inside the 3D printed case? Not a whole lot, really. Obviously there’s a Raspberry Pi, a 3.5 inch TFT touch screen display, and a miniature keyboard. The keyboard is of the Bluetooth variety, and other than being freed from its enclosure and wired into the header on the display module for power, it’s otherwise stock.
As for the parts you can’t see from the outside, there’s a 3.7 V 4400 mAh battery pack and an Adafruit PowerBoost 1000 module to handle charging and power distribution. Beyond the big lighted button on the side (which you could certainly replace with something more low-key should you chose), that’s about it. When it’s all together, you’ve got a battery powered computer that’s ready for the road with a minimum amount of fuss.
If you’re looking for something that’s a bit larger, and more than a little unconventional, you could start by printing out a full cyberdeck. After all, if you’re going to build your own non-traditional portable computer, you might as well go all out.
Want to take that annoyingly productive coworker down a notch? Yeah, us too. How dare they get so much done and be so happy about it? How is it possible that they can bang on that keyboard all day when you struggle to string together an email?
The Slippy Slapper is a useless machine that turns people into useless machines using tactics like endless distraction and mild physical violence. It presses your buttons by asking them to press buttons for no reason other than killing their productivity. When they try to walk away, guess what? That’s another slappin’. Slippy Slapper would enrage us by proxy if he weren’t so dang cute.
You’re right, you don’t need an Arduino for this. For peak inefficiency and power consumption, you actually need four of them. One acts as the master, and bases its commands to the other three on the feedback it gets from Slippy’s ultrasonic nostrils. The other three control the slappin’ servos, the speakers, and reading WAV files off of the SD card. Slap your way past the break to see Slippy Slapper’s slapstick demo.
Need to annoy a group of coworkers all at once? Slip a big bank of useless machines into the conference room while it’s being set up.
Due to uncertainties about the progress of the spread of the novel corona virus, it’s with a sad heart that we announce that we’re postponing the 2020 Hackaday Belgrade conference.
We will be rescheduling for later in the year, but for now we’ll be refunding conference tickets. We received a record number of incredible presenter proposals, and once we’ve rescheduled, we’ll get in touch with everyone who entered a proposal to check up on your availability.
We know how much you were all looking forward to Belgrade in May, and it pains us to have to take this step. When we get more details ironed out, we’ll be sure to let you know! See you all a little bit later in the summer?
We think of the mobile phone — well, what we would call a cell phone — as something fairly modern. Many of us can still remember when using a ham radio phone patch from your parked car would have people staring and murmuring. But it turns out in the late 1940s, Bell Telephone offered Mobile Telephone Service (MTS). It was expensive and didn’t work as well as what we have now, but it did let you make or receive calls from your automobile. After the break, you can see a promotional film about MTS.
The service rolled out in St. Louis in the middle of 1946. The 80-pound radios went in the trunk with a remote handset wired to the dashboard. At first, there were only 3 channels but later Bell added 29 more to keep up with demand. An operator connected incoming and outbound calls and if three other people were using their mobile phones, you were out of luck.
Hackaday editor Elliot Williams and contributor Jonathan Bennett discuss the past week of Hackaday. Freeman Dyson, who wanted to send us to space on the back of nuclear explosions, passed away. Only slightly less dangerous, we looked at self-balancing vehicles, 3D printed press brakes, and making rubies in the home lab. All the usual suspects make cameo appearances: robots, FPGAs, and open-source software.
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
A staple of today’s remote-controlled flight is the so-called FPV transmitter, allowing the pilot of a multirotor or other craft to see the world from onboard, as a pilot might do. It’s accessible enough that it can be found on toy multirotors starting at not much more than pocket money prices, and reliable enough that in its better incarnations it can send back high definition video at surprisingly long range.
In case you think of FPV flight as a recent innovation, the video below the break from [Larry Mitschke] should come as a revelation. In 1986 he was a bona-fide rockstar playing in a band, whose radio-controlled flight hobby led him into creating an FPV system for his planes and soaring above the Texas countryside at significant distance from his base while flying it watching a CRT screen.
The video is quite long but extremely watchable, all period footage with his narration here in 2020. We see his earliest experiments with a monochrome security camera and a video sender, and a whole host of upgrades until finally he can fly three miles from base with good quality video. 70 cm amateur TV makes an appearance with a steerable tracking antenna, he even makes a talking compass for when he loses himself. It’s an epic tale of hacking with what seems rudimentary equipment by our standards but was in fact the cutting edge of available video technology at a time when the state of the video art was moving rather fast. This is the work that laid the path for today’s $30 FPV toys, and for flying FPV from space.
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.