[2n2r5] posted up a mechanism that we’d never seen before — a threadless ballscrew that turns rotational into linear motion with no backlash. It works by pressing the edge of three bearings fairly hard up against a smooth rod, at an angle. The bearings actually squeeze the rod a little bit, making a temporary indentation in the surface that works just like a screw thread would. As the bearings roll on, the rod bounces back to its original shape. Watch it in action in the video below.
Ubuntu just came out with the new long-term support version of their desktop Linux operating system. It’s got a few newish features, including incorporating the “snap” package management format. One of the claims about “snaps” is that they’re more secure — being installed read-only and essentially self-contained makes them harder to hack across applications. In principle.
[mjg59] took issue with their claims of increased cross-application security. And rather than just moan, he patched together an exploit that’s disguised as a lovable teddy bear. The central flaw is something like twenty years old now; X11 has no sense of permissions and any X11 application can listen in on the keyboard and mouse at any time, regardless of which application the user thinks they’re providing input to. This makes writing keylogging and command-insertion trojans effortless, which is just what [mjg59] did. You can download a harmless version of the demo at [mjg59]’s GitHub.
This flaw in X11 is well-known. In some sense, there’s nothing new here. It’s only in light of Ubuntu’s claim of cross-application security that it’s interesting to bring this up again.
And the teddy bear in question? Xteddy dates back from when it was cool to display a static image in a window on a workstation computer. It’s like a warmer, cuddlier version of Xeyes. Except it just sits there. Or, in [mjg59]’s version, it records your keystrokes and uploads your passwords to shady underground characters or TLAs.
We discussed Snappy Core for IoT devices previously, and we think it’s a step in the right direction towards building a system where all the moving parts are only loosely connected to each other, which makes upgrading part of your system possible without upgrading (or downgrading) the whole thing. It probably does enhance security when coupled with a newer display manager like Mir or Wayland. But as [mjg59] pointed out, “snaps” alone don’t patch up X11’s security holes.
[Sprite_tm] picked up some used VFD displays for cheap, and wanted to make his own custom temperature and air-quality display. He did that, of course, but turned it into a colossal experiment in re-design to boot. What started out as a $6 used VFD becomes priceless with the addition of hours of high-powered hacking mojo.
You see, the phosphor screen had burnt-in spots where the old display was left static for too long. A normal person would either live with it or buy new displays. [Sprite_tm] ripped off the old display driver and drives the row and column shift registers using the DMA module on a Raspberry Pi2, coding up his own fast PWM/BCM hybrid scheme that can do greyscale.
He mapped out the individual pixels using a camera and post processing in The Gimp to establish the degradation of burnt-in pixels. He then re-wrote a previous custom driver project to compensate for the pixels’ inherent brightness in firmware. After all that work, he wrapped the whole thing up in a nice wooden frame.
There’s a lot to read, so just go hit up his website. High points include the shift-register-based driver transplant, the bit-angle modulation that was needed to get the necessary bit-depth for the grayscale, and the PHP script that does the photograph-based brightness correction.
Picking a favorite [Sprite_tm] hack is like picking a favorite ice-cream flavor: they’re all good. But his investigation into hard-drive controller chips still makes our head spin just a little bit. If you missed his talks about the Tamagotchi Singularity from the Hackaday SuperCon make sure you drop what you’re doing and watch it now.
3D scanners don’t have to be expensive or high-tech because all of the magic goes on in software. The hardware setup just needs to gather a bunch of cross-sections. In perhaps the lowest-tech of scanners that we’ve seen, [yenfre]’s GotMesh scanner uses milk.
Specifically, the apparatus is a pair of boxes, one with a hole drilled in it. You put the object in the top box and fill it with milk to cover the object. A camera takes pictures of the outline of the object in the milk as it drains out the hole, these get stitched together, and voilà.
There are limitations to this method. The object gets soaked in milk, so it won’t work for scanning sand-castles. (It’s optimally suited for chocolate-chip cookies, in our opinion.) If the camera is located directly above, the objects have to get wider as the milk drains out. You can do multiple takes with the object rotated at different angles or use multiple cameras to solve this problem. The edge-detection software will have issues with white objects in milk, so maybe you’ll want to scan that porcelain figurine in coffee, but you get the idea. More seriously, the rate of milk drain will slow down a bit as the amount of milk in the upper box decreases. This could also be handled in software.
In all, we’re not surprised that we don’t see commercial versions of this device, but we love the idea. It’s based on this experiment where they dip a guy in a tank of ink! If you just drank all your milk, but still have a line-laser lying around, maybe this build is more your speed. What’s your cheapest 3D scanner solution?
This is a hacking and gaming tour de force! [Seth Bling] executed a code injection hack in Super Mario World (SMW) that not only glitches the game, but re-programs it to play a stripped-down version of “Flappy Bird”. And he did this not with a set of JTAG probes, but by using the game’s own controller.
There are apparently a bunch of people working on hacking Super Mario World from within the game, and a number of these hacks use modified controllers to carry out the sequence of codes. The craziest thing about our hack here is that [Seth] did this entirely by hand. The complete notes are available here, but we’ll summarize the procedure for you. Or you can go watch the video below. It’s really incredible.
Hacking for the Raspberry Pi Zero is a tricky proposition. Whatever you do, you’re working with a nominal five dollar board, so your hacks can’t be too highfalutin. For instance, a decent PS/2 to USB adapter will cost you as much as the Zero did, if not more. But if you just need to drive your Pi Zero from your old Model M (we hear you!) you’ve got to do it on the cheap.
So when prolific Pi hacker [mincepi] set out to build a PS/2 adapter, some corners were cut. PS/2 is a clocked data protocol, but the good news is that the clock doesn’t start and stop all the time as in I2C or SPI. This means that if you poll the data line at just the right frequency, at least in principle you’ll be able to ignore the clock.
So that’s what [mincepi] did. As you can see in the schematic and the banner image, there’s nothing to it. Two resistors provide the pullup voltage for the clock and data lines. And here’s a gem: a green LED with a drop voltage of about 2 V converts the 5 V data line down to something that the Pi Zero’s 3.3 V won’t get fried with. Cute, and very much in keeping with the spirit of the hack. You might be tempted to scrounge up a 3.3 V zener diode from somewhere just to be on the safe side, but remember, it’s a five dollar computer you’re protecting.
The last piece is a custom kernel module for the Pi that polls the PS/2 data line at just the right frequency. If you’re not a Linux person and “compiling a kernel module” sounds scary, [mincepi] has even put together a nice guide for the Raspbian distribution that he’s using. It should work with minor tweaks for any other distro.
We said [mincepi] is a prolific Pi hacker and here’s the proof: we’ve covered his quick-and-dirty VGA output hack and a scheme to get analog sound input into the Pi Zero just in the last couple of weeks. Hack on!
[virustracker] has been playing around with barcodes lately, and trying to use them as a vector to gain control of the system that’s reading them. It’s a promising attack — nobody expects a takeover via barcodes. The idea isn’t new, and in fact we’ve seen people trying to drop SQL attacks in barcodes long ago, but [virustracker] put a few different pieces together and came up with a viable attack.
The trick is that many POS terminals and barcode readers support command characters in their programming modes. Through use of these Advanced Data Formatting (ADF) modes, [virustracker] sends Windows-Key-r, and then cmd.exe, ftps a file down, and runs it. Whatever computer is on the other side of the barcode scanner has just been owned. ADF even supports a delay function to allow time for the command window to pop up before running the rest of the input.
The article details how they got their payload from requiring more than ten individual barcodes down to four. Still, it’s a suspicious-looking attack to try to pull off where other people (think cashiers) are looking. However, we have many automated machines in our everyday life that use barcodes. How many of these are vulnerable is an open question. [virustracker] suggests lottery machines, package-delivery automats, and even hospitals.
The defense is simple, and it’s the same as everywhere else: disable the debug and configuration modes in your production systems, and sanitize your input. Yes, even the barcodes.
