Hackaday editors Mike Szczys and Elliot Williams cover the hacks that made us happy over the past week. There’s an incredible cable-driven robotic elbow hack whose quality is only eclipsed by the fantastic explanation of how it works (like a block and tackle). Getting data like WiFi credentials into your embedded project may be just a blinking Android app away. Try your hand at digital solargraphy with creative use of f-stop and post processing. And Mike ogles an RC F-35 project while Elliot goes gaga for the deepest of all submarine designs.
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!
Sophos firewall appliances are actively being attacked by a 0-day exploit chain that originates with a SQL injection. That injection is a nasty one, as it can be launched from the WAN user portal. The observed attack used that vulnerability to inject a shell command into the device database, where it would eventually be run automatically. If you have an affected Sophos device, go check that the hotfix was automatically installed.
While the vulnerability was a bad one, Sophos’ response here is laudable. They publicly disclosed the attack less than 24 hours after they were notified of it’s existence in the wild, and began rolling a fix out within three days. Additionally, Sophos engineers did a really detailed write-up (linked above) giving us all the details of the attack. The hotfix that closes the vulnerability also attempts to clean up the infection, although there are some additional manual steps that are suggested if your device was compromised. Continue reading “This Week In Security: Firewall 0-day, Apple’s Response, And An Android Bluetooth Bug”→
Over the past few months there has been a battle waging in the world of domain names; the overseeing body ICANN had hatched a plan to transfer the entire .org registry to a private company, to significant opposition from .org domain holders, concerned citizens, and the Electronic Frontier Foundation. Part of the process before the deadline for handover on the 4th of May was a due dilligence process during which the ICANN board would review submissions related to the deal, and after completing that task the board have witheld their consent for it to go ahead. As you might expect the EFF are declaring a victory, but they also make the point that one of the reasons the ICANN board rejected the deal was a potential risk of a debt liability for the organisation.
It’s tempting to frame this as a rare victory for the Little Guy in the face of The Man, but the reality is probably more nuanced. When the deal was hatched the world had not yet come to terms with the COVID-19 pandemic, meaning that the thought of a post-virus economic slump would not yet have been on their minds. It’s thus not unexpected that the ICANN board would think about the financial aspects of it as well as the many objections, because in a time of economic pain the possibility of it going sour would be significantly increased. The future of the .org and other registries should remain a concern to internet users, because after all, this is not the first time such a thing has happened.
It seems not a day goes by that we don’t see somebody cramming a Raspberry Pi into some unwilling piece of consumer electronics. But despite being a pretty obvious application for the diminutive ARM board, we don’t often see it installed in an actual computer. Which makes this very clean Raspberry Pi laptop conversion by [Sherbethead2010] all the more interesting.
The first step involved taking a Dremel to the Dell’s chassis and essentially leveling out the entire internal volume. The only component that got reused was the fan, and even that appears to be relocated, so all the mounting posts were just standing in the way of progress.
[Sherbethead2010] mounted the Raspberry Pi towards the rear of the case so its USB and Ethernet ports would be available from the outside, and installed a driver board for the original Phillips LP171 LCD panel in the old drive bay. Power is provided by two custom 18650 battery packs connected to dedicated buck converters, along with an onboard charge controller to safely top them off.
Rather than trying to adapt the original input devices, [Sherbethead2010] decided to take the easy route and installed a Rii K22 wireless keyboard with integrated track pad into the top of the laptop. It turned out to be an almost perfect fit, and beyond the keys being slightly off-center, at first glance it looks like it could be stock.
The last time we saw a Raspberry Pi so well integrated into a real laptop, it was to create a functioning version of one of the props from Hackers. While that build was a joy for its own reasons, it’s hard not to be impressed with how unassuming this computer looks after all the work that’s been done to it.
Everyone has a stack of old infra-red remote controllers lying around, for devices that have long since shuffled off this mortal coil. Containing little more than an application-specific encoder chip, keyboard, and IR LED, they’re of little use unless you happen to have another device that uses the same encoding scheme. For [RiYa] though they represent an opportunity, to be repurposed into controllers for other devices. How? Hijack the bitstream with an ATtiny13 microcontroller, re-encode it, and send it out afresh into the ether from the LED. It’s a gloriously simple solution which we can’t help applauding, and has the potential to cheaply replace all those universal remotes.
The ATtiny itself along with a buffer to drive the LED is mounted on a small breakout board and concealed within the shell of the remote. We don’t learn much about the power supply arrangement, but we’d expect the ATtiny to be on its most power-sipping behaviour as anything which would shorten the battery life of a remote would be unlikely to be popular with a couch potato forced to change AA cells every few weeks. There’s a plan for a learning mode to make it more like a commercial universal remote, but for now the translation is hard coded.
After trying out hardware hacking using an FPGA to interface with target hardware, [Grazfather] was inspired to try using the iCEBreaker (one of the many hobbyist FPGAs to have recently flooded the market) to build a UART-controllable glitcher for the Olimex LPC-P1343.
FPGA Modules (The cmd module intercepts what the host computer sends over UART, the resetter holds the reset line until the target is reset, the delay starts counting on reset and waits for a configured number of cycles before sending its signal, the trigger waits for the delay to finish before telling the pulse module to send a pulse, and the pulse works similar to the delay module and outputs to the power multiplexer.)
When the target board boots up, the bootROM reads the flash and determines whether the UART goes to a shell and if the shell can be used to read out the flash. This is meant for developing firmware and debugging it in the bootloader, only flashing a version when the firmware is production-ready. The vulnerability is that only a specific value read from address 0x2FC and the state of a few pins can lock the bootloader in the expected way, and any other value at the address causes the bootROM to consider the device unlocked. Essentially, the mechanism is the opposite of how a lock ought to work.
The goal is to get the CPU to misread the flash at the precise moment it is meant to be reading the specific value, then jumping to the bootloader in the unlocked state. The FPGA can be used as a tool between the host machine and target board, communicating via UART. The FGPA can support configuring the delay between resetting the target board and pulsing a ‘glitch voltage’, as well as resetting the target board and activating the glitch. The primary reasons for using the FPGA over a different microcontroller are that the FPGA allows for precise timing (83.3ns precision) and removes worries about jitters (a Raspberry Pi might have side effects from OS scheduling and other processes and microcontrollers might have interrupts messing up the timing).
The logic analyzer view
To simulate the various modules, [Grazfather] used Icarus Verilog as well as GTKWave to observe the waveforms generated. A separate logic analyzer observes the effects on real hardware.
With enough time, it is possible to brute force any combination of delay and width until you get a dump of the flash you’re not meant to read. You can check out how the width of the pulse gets wider until the max, when the delay is incremented and the width values are tried again.
The Air Force is again holding its annual “Space Security Challenge” where they invite you to hack into a satellite to test their cybersecurity measures. There are actually two events. In the first one, $150,000 is up for grabs in ten prizes and the final event offers a $100,000 purse divided among the three top participants (first place takes $50,000).
Before you get too excited, you or your team has to first qualify online. The qualification event will be over two days starting May 22. The qualifying event is set up a bit like the TV show Jeopardy. There is a board with categories. When a team solves a challenge in a category it receives a flag that is worth points as well as getting to unlock the next challenge. Once a challenge is unlocked however, any team could potentially work on it. There are more rules, but that’s the gist of it. At the end of the event, the judges will contact the top 10 teams who will then each have to submit a technical paper.
