This Robot Picks Locks, If You’re Very Patient

We all know the Hollywood trope of picking a lock with a paperclip, and while it certainly is doable, most reputable locks require slightly more sophisticated tools to pick effectively. That’s not to say that wire is off the table for locksports, though, as this cool lock-picking robot demonstrates.

The basics behind [Sparks and Code]’s design are pretty simple. Locks are picked by pushing pins up inside the cylinder until they line up with the shear plane, allowing the cylinder to turn. Normally this is done a pin at a time with a specialized tool and with a slight bit of torque on the cylinder. Here, tough, thin, stiff wires passing through tiny holes in a blade shaped to fit the keyway are used to push all the pins up at once, eliminating the need to keep tension on the cylinder to hold pins in place.

Sounds simple, but in practice, this looks like it was a nightmare. Getting five wires to fit into the keyway and guiding them to each pin wasn’t easy, nor was powering the linear actuators that slide the wires in and out. Applying torque to the lock was a chore too; even though tension isn’t needed to retain picked pins, the cylinder still needs to rotate, which means moving the whole picking assembly. But the biggest problem by far seems to be the fragility of the blade that goes into the keyway. SLA might not be the best choice here; perhaps the blade could be made from two thin pieces of aluminum with channels milled on their faces and then assembled face-to-face.

The robot works, albeit very slowly. This isn’t [Sparks and Code]’s first foray into robot lock picking. His previous version attempted to mimic how a human would pick a lock, so this is really thinking outside the box.

Continue reading “This Robot Picks Locks, If You’re Very Patient”

Screenshot of the GitHub Marketplace action listing, describing the extension

Giving Your KiCad PCB Repository Pretty Pictures

Publishing your boards on GitHub or GitLab is a must, and leads to wonderful outcomes in the hacker world. On their own, however, your board files might have the repo look a bit barren; having a picture or two in the README is the best. Making them yourself takes time – what if you could have it happen automatically? Enter kicad-render, a GitHub and GitLab integration for rendering your KiCad projects by [linalinn].

This integration makes your board pictures, top and bottom view, generated on every push into the repo – just embed two image links into your README.md. This integration is made possible thanks to the new option in KiCad 8’s kicad-cli – board image generation, and [linalinn]’s code makes KiCad run on GitHub/GitLab servers.

For even more bling, you can enable an option to generate a GIF that rotates your board, in the style of that one [arturo182] demo – in fact, this integration’s GIF code was borrowed from that script! Got a repository with many boards in one? There’s an option you could make work for yourself, too.

All you need to do is to follow a couple of simple steps; [linalinn] has documented both the GitHub and GitLab integration. We’ve recently talked about KiCad integrations in more detail, if you’re wondering what else your repository could be doing!

How Does The Raspberry Pi Rack Up Against A Mini PC?

When the first Raspberry Pi came out back in 2012 it was groundbreaking because it offered a usable little Linux machine with the proud boast of a $25 dollar price tag. Sure it wasn’t the fastest kid on the block, but there was almost nothing at that price which could do what it did. Three leap years later though it’s surrounded by a host of competitors with similar hardware, and its top-end model now costs several times that original list price.

Meanwhile the cost of a “real” x86 computer such as those based upon the Intel N100 has dropped to the point at which it almost matches a fully tricked-out Pi with storage and peripherals, so does the Pi still hold its own? [CNX Software] has taken a look.

From the examples they use, in both cases the Intel machine is a little more expensive than the Pi, but comes with the advantage of all the peripherals, cooling, and storage coming built-in rather than add-ons. They rate the Pi as having the advantage on expandability as we’d expect, but the Intel giving a better bang for the buck in performance terms. From where we’re sitting the advantage of the Pi over most of its ARM competition has always been its good OS support, something which is probably exceeded by that on an x86 platform.

So, would you buy the Intel over the high-end Pi? Let us know in the comments.

Hackaday Podcast Episode 269: 3D Printed Flexure Whegs, El Cheapo Bullet Time, And A DIY Cell Phone Sniffer

This week, it was Kristina’s turn in the hot seat with Editor-in-Chief Elliot Williams. First up in the news — the results are in for the 2024 Home Sweet Home Automation contest! First and second place went to some really gnarly, well-documented hacks, and third went to the cutest pill-dispensing robot you’ll probably see before you hit the retirement home. Which was your favorite? Let us know in the comments.

A collection of multimeter probe extenders from Radio Shack.
Kristina’s lil’ wallet of extender probes, courtesy of Radio Shack.

Then it’s on to What’s That Sound. Kristina failed once again, but you will probably fare differently. Can you get it? Can you figure it out? Can you guess what’s making that sound? If you can, and your number comes up, you get a special Hackaday Podcast t-shirt.

Then it’s on to the hacks, beginning with a DIY cell phone sniffer and a pen that changed the world. Then we talk bullet time on a budget, the beautiful marriage of 3D printing and LEGO, and, oh yes, flexure whegs. Finally, we get the lowdown on extender probes, and posit why it’s hard to set up time zones on the Moon, relatively speaking.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download and savor at your leisure.

Continue reading “Hackaday Podcast Episode 269: 3D Printed Flexure Whegs, El Cheapo Bullet Time, And A DIY Cell Phone Sniffer”

This Week In Security: Default Passwords, Lock Slapping, And Mastodown

The UK has the answer to all our IoT problems: banning bad default passwords. Additionally, the new UK law requires device makers to provide contact info for vulnerability disclosures, as well as a requirement to advertise vulnerability fix schedules. Is this going to help the security of routers, cameras, and other devices? Maybe a bit.

I would argue that default passwords are in themselves the problem, and complexity requirements only nominally help security. Why? Because a good default password becomes worthless once the password, or algorithm leaks. Let’s lay out some scenarios here. First is the static default password. Manufacturer X makes device Y, and sets the devices to username/password admin/new_Complex_P@ssword1!. Those credentials make it onto a default password list, and any extra security is lost.

What about those devices that have a different, random-looking password for each device? Those use an algorithm to derive that password from the MAC address and/or serial number. That may help the situation, but the algorithm can be retrieved from the firmware, and most serial numbers are predictable in one way or another. This approach is better, but not a silver bullet.

So what would a real solution to the password problem look like? How about no default password at all, but no device functionality until the new password passes a cracklib complexity and uniqueness check. I have seen a few devices that do exactly this. The requirement for a disclosure address is a great idea, which we’ve talked about before regarding the similar EU legislation.

Continue reading “This Week In Security: Default Passwords, Lock Slapping, And Mastodown”

NASA Is Now Tasked With Developing A Lunar Time Standard, Relativity Or Not

A little while ago, we talked about the concept of timezones and the Moon. It’s a complicated issue, because on Earth, time is all about the Sun and our local relationship with it. The Moon and the Sun have their own weird thing going on, so time there doesn’t really line up well with our terrestrial conception of it.

Nevertheless, as humanity gets serious about doing Moon things again, the issue needs to be solved. To that end, NASA has now officially been tasked with setting up Moon time – just a few short weeks after we last talked about it! (Does the President read Hackaday?) Only problem is, physics is going to make it a damn sight more complicated!

Continue reading “NASA Is Now Tasked With Developing A Lunar Time Standard, Relativity Or Not”

FLOSS Weekly Episode 781: Resistant To The Wrath Of God

This week Jonathan Bennett and Doc Searls sit down with Mathias Buus Madsen and Paolo Ardoino of Holepunch, to talk about the Pear Runtime and the Keet serverless peer-to-peer platform. What happens when you take the technology built for BitTorrent, and apply it to a messaging app? What else does that allow you to do? And what’s the secret to keeping the service running even after the servers go down?

Continue reading “FLOSS Weekly Episode 781: Resistant To The Wrath Of God”