Tag Archive for: Hackaday

CNC Dummies For Routers | Hackaday

/in


[This Old Tony] has a few videos that have made appearances on Hackaday. His latest one is CNC Dummies for Routers (see below). The subtitle, CNC Basics, is an honest one. If you’re already well versed in GCode and Mach 3, you probably won’t make it through the 14 minute video (although Tony is pretty entertaining even if you know what he’s talking about).

By his own admission, this is really CNC basics for hobby-grade CNC routers and mills. He starts off talking about his custom-built machine along with some common machines in the $500-$5000 range. He then gives a simple sketch of what GCode looks like.

The last part of the video talks about software for CAD and CAM. He talks about Fusion 360 and Mach 3, although the point to the video isn’t to provide a tutorial for any specific tools. You do get to watch over [Tony’s] shoulder as he creates pig-shaped cutting boards.

If you’ve done 3D printing, you won’t find much new here. If you have any experience with CNC, you’ll find nothing new here. But that isn’t really the point. This would be a great video for introducing students, new hackerspace members, or anyone who doesn’t know anything about CNC to the general workflow required.

If you watch close, you might pick up a few tips, especially if you are only used to 3D printing. For example, the pig cut out gets tabs to keep it from flying out before the cutting completes and he uses a sacrificial spoilboard to avoid cutting into the router’s work table.

[Tony] apparently stays busy since we’ve seen him build, among other things, vortex tubes. We also know he likes to play with fire.


Source…

Hardware Hacking | Hackaday

/in


Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.

Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.

You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.

[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.

To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.

Source…

USB-C: Introduction For Hackers | Hackaday

/in


We’ve now had at least five years of USB-C ports in our devices. It’s a standard that many manufacturers and hackers can get behind. Initially, there was plenty of confusion about what we’d actually encounter out there, and manufacturer-induced aberrations have put some people off. However, USB-C is here to stay, and I’d like to show you how USB-C actually gets used out there, what you can expect out of it as a power user, and what you can get out of it as a hobbyist.

Modern devices have a set of common needs – they need a power input, or a power output, sometimes both, typically a USB2 connection, and often some higher-speed connectivity like a display output/input or USB 3. USB-C is an interface that aims to be able to take care of all of those. Everything aforementioned is optional, which is a blessing and a curse, but you can quickly learn to distinguish what to expect out of a device based on how it looks; if ever in doubt, I’d like to show you how to check.

Communicating Capabilities, Configurations and Caveats

We all know that USB-C can be rotated – it lets you insert the cable whichever way around — which was a significant improvement over USB-B. Let’s get down to how this works. To make this possible, there’s a CC (Configuration Channel) connection – a single-wire line in every USB-C cable that attaches to one of the two CC pins in the Type-C connector, and it is essential to making USB-C work. For simple USB-C usecases, like “get USB 2.0 and 5 V out of a port, follow a simple recipe – attach a 5.1 kΩ pulldown to each CC pin, and you will have a USB-C port that will work with all reasonable devices out there.

There’s support for stuff beyond 5 V and USB 2.0 in USB-C, of course. You can get a variety of voltages out of a USB-C port, which is quite handy for charging things like laptops. You can get USB 3, DisplayPort, and Thunderbolt. Most laptops will let you connect a docking station taking advantage of USB-C as much as possible, giving you a high-resolution display, plenty of USB ports and charging all over the same cable. Now, how does that work?

For usecases like voltages larger than 5 V (USB-PD) or high-speed connectivity…

Source…

Wireless Hacking | Hackaday

/in


If you use PHP, you likely use the Composer tool for managing dependencies, at least indirectly. And the good folks at SonarSource found a nasty, potential supply chain attack in this tool, when used in the Packagist repository. The problem is the support for arbitrary README filenames. When a package update shows up on Packagist, that service uses a Version Control Service (VCS) like Git or Mercurial to pull the specified readme location. That pull operation is subject to argument injection. Name your branch --help, and Git will happily run the help argument instead of doing the pull intended. In the case of Git commands, our intrepid researchers were unable to weaponize the issue to achieve code execution.

Composer also supports projects that use Mercurial as their VCS, and Mercurial has a --config option that has… interesting potential. It allows redefining a Mecurial command as a script snippet. So a project just has to contain a malicious payload.sh, and the readme set to --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. For those keeping track at home, the vulnerability is that this cursed string of ugly is accepted by Composer as a valid filename. This uses the --config trick to redefine cat as a bit of script that executes the payload. It ends in .txt because that is a requirement of Composer.

So let’s talk about what this little hack could have been used for, or maybe still used for on an unpatched, private install of Packagist. This is an unattended attack that jumps straight to remote script execution — on an official package repository. If discovered and used for evil, this would have been a massive supply chain attack against PHP deployments. Instead, thanks to SonarSource, it was discovered and disclosed privately back in April. The official Packagist repo at packagist.org was fixed the day after disclosure, and a CVE and updated packages went out six days later. Great work all around.
Continue reading “This Week In Security: PHP Attack Defused, Scoreboard Manipulation, And Tillitis” →

Source…