A Simple Robot For Learning About Robotics

December 9, 2024 by Lewin Day 6 Comments

Robots are super interesting, but you probably shouldn’t start learning about them with a full-sized industrial SCARA arm or anything. Better to learn with something smaller and simpler to understand. This simple Arduino-powered robot is called Bug, and it aims to be just that.

The design comes to us from [Joshua Stanley]. It’s based around the ubiquitous Arduino Uno, paired with a motor control and I/O shield for more connectivity. The robot uses treads for locomotion—each side has two wheels wrapped in a belt for grip. The robot has a small DC gearmotor driving each belt so it can be driven forwards, backwards, and steered differentially. To perceive the world, it uses an off-the-shelf ultrasonic transceiver module, and an NRF24L01 module for remote control. All this is wrapped up in a basic 3D-printed housing that positions the ultrasonic modules effectively as “eyes” which is kind of cute, all in all.

Despite its small size and simple construction, Bug gets around perfectly well in testing on an outdoor footpath. It even has enough torque to flip itself up at full throttle. For now, [Joshua] notes it’s a glorified remote control car, but he plans to expand it further with more functionality going forward.

We see lots of educational robots around these parts, like this nifty little robot arm. Video after the break.

Continue reading “A Simple Robot For Learning About Robotics” →

Nix + Automated Fuzz Testing Finds Bug In PDF Parser

November 9, 2024 by Donald Papp 4 Comments

[Michael Lynch]’s adventures in configuring Nix to automate fuzz testing is a lot of things all rolled into one. It’s not only a primer on fuzz testing (a method of finding bugs) but it’s also a how-to on automating the setup using Nix (which is a lot of things, including a kind of package manager) as well as useful info on effectively automating software processes.

[Michael] not only walks through how he got it all up and running in a simplified and usefully-portable way, but he actually found a buffer overflow in pdftotext in the process! (Turns out someone else had reported the same bug a few weeks before he found it, but it demonstrates everything regardless.)

[Michael] chose fuzz testing because using it to find security vulnerabilities is conceptually simple, actually doing it tends to require setting up a test environment with a complex workflow and a lot of dependencies. The result has a high degree of task specificity, and isn’t very portable or reusable. Nix allowed him to really simplify the process while also making it more adaptable. Be sure to check out part two, which goes into detail about how exactly one goes from discovering an input that crashes a program to tracking down (and patching) the reason it happened.

Making fuzz testing easier (and in a sense, cheaper) is something people have been interested in for a long time, even going so far as to see whether pressing a stack of single-board computers into service as dedicated fuzz testers made economic sense.

Bats Can No Longer Haunt Apple VR Headsets Via Web Exploit

June 26, 2024 by Donald Papp 33 Comments

Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.

Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.

Hackaday Links: June 23, 2024

June 23, 2024 by Dan Maloney 9 Comments

When a ransomware attack targets something like a hospital, it quickly becomes a high-profile event that understandably results in public outrage. Hospitals are supposed to be backstops for society, a place to go when it all goes wrong, and paralyzing their operations for monetary gain by taking over their information systems is just beyond the pale. Tactically, though, it makes sense; their unique position in society seems to make it more likely that they’ll pay up.

Which is why the ongoing cyberattack against car dealerships is a little perplexing — can you think of a less sympathetic victim apart from perhaps the Internal Revenue Service? Then again, we’re not in the ransomware business, so maybe this attack makes good financial sense. And really, judging by the business model of the primary target of these attacks, a company called CDK Global, it was probably a smart move. We had no idea that there was such a thing as a “Dealer Management System” that takes care of everything from financing to service, and that shutting down one company’s system could cripple an entire industry, but there it is.

Continue reading “Hackaday Links: June 23, 2024” →

Chip Mystery: The Case Of The Purloined Pin

April 25, 2024 by Dan Maloney 29 Comments

Let’s face it — electronics are hard. Difficult concepts, tiny parts, inscrutable datasheets, and a hundred other factors make it easy to screw up in new and exciting ways. Sometimes the Magic Smoke is released, but more often things just don’t work even though they absolutely should, and no amount of banging your head on the bench seems to change things.

It’s at times like this that one questions their sanity, as [Gili Yankovitch] probably did when he discovered that not all CH32V003s are created equal. In an attempt to recreate the Linux-on-a-microcontroller project, [Gili] decided to go with the A4M6 variant of the dirt-cheap RISC-V microcontroller. This variant lives in a SOP16 package, which makes soldering a bit easier than either of the 20-pin versions, which come in either QFN or TSSOP packages.

Wisely checking the datasheet before proceeding, [Gili] was surprised and alarmed that the clock line for the SPI interface didn’t appear to be bonded out to a pin. Not believing his eyes, he turned to the ultimate source of truth and knowledge, where pretty much everyone came to the same conclusion: the vendor done screwed up.

Now, is this a bug, or is this a feature? Opinions will vary, of course. We assume that the company will claim it’s intentional to provide only two of the three pins needed to support a critical interface, while every end user who gets tripped up by this will certainly consider it a mistake. But forewarned is forearmed, as they say, and hats off to [Gili] for taking one for the team and letting the community know.

SSH Can Handle Spaces In Command-line Arguments Strangely

July 15, 2023 by Donald Papp 48 Comments

One of the things ssh can do is execute a command on a remote server. Most of us expect it to work transparently when doing so, simply passing the command and its arguments on without any surprises in the process. But after 23 years of using OpenSSH on a nearly daily basis, [Martin Kjellstrand] got surprised.

It turns out that the usual rules around how things are parsed can have some troublesome edge cases when spaces are involved. [Martin] kicks off an example in the following way:

One would reasonably expect the commands figlet foobar bar\ baz and ssh localhost figlet foobar bar\ baz to be functionally equivalent, right? The former ultimately runs the command “figlet” with arguments “foobar” and “bar baz” on the local machine. The second does the same, except with ssh being involved in the middle. As mentioned, one would expect both commands to be functionally identical, but that’s not what happens. What happens is that ssh turns bar\ baz into two distinctly separate command-line arguments in the process of sending it for remote execution: “bar” and “baz”. The result is mystification as the command fails to run the way the user expects, if it runs at all.

What exactly is going on, here? [Martin] goes into considerable detail tracking down this odd behavior and how it happens, but he’s unable to ultimately explain why ssh does things this way. He suspects that it is the result of some design decision taken long ago. Or perhaps a bug that has, over time, been promoted to entrenched quirk.

Do you have any insights or knowledge about this behavior? If so, [Martin] wants to hear about it and so do we, so don’t keep it to yourself! Let us know in the comments, below.

Bluetooth Vulnerability: Arbitrary Code Execution On The ESP32, Among Others

September 23, 2021 by Lewin Day 21 Comments

Bluetooth has become widely popular since its introduction in 1999. However, it’s also had its fair share of security problems over the years. Just recently, a research group from the Singapore University of Technology and Design found a serious vulnerability in a large variety of Bluetooth devices. Having now been disclosed, it is known as the BrakTooth vulnerability.

Full details are not yet available; the research team is waiting until October to publicly release proof-of-concept code in order to give time for companies to patch their devices. The basic idea however, is in the name. “Brak” is the Norweigan word for “crash,” with “tooth” referring to Bluetooth itself. The attack involves repeatedly attempting to crash devices to force them into undesired operation.

The Espressif ESP32 is perhaps one of the worst affected. Found in all manner of IoT devices, the ESP32 can be fooled into executing arbitrary code via this vulnerability, which can do everything from clearing the devices RAM to flipping GPIO pins. In smart home applications or other security-critical situations, this could have dire consequences.

Other chipsets are affected to varying degrees, including parts from manufacturers like Texas Instruments and Cypress Semiconductor. Some parts are vulnerable to denial of service, while audio devices may be frozen up or shut down by the attack. The group claims over 1400 products could be affected by the bug.

Firmware patches are being rolled out, and researcher [Matheus E. Garbelini] has released code to build a sniffer device for the vulnerability on GitHub. If you’re involved with the design or manufacture of Bluetooth hardware, it might pay to start doing some homework on this one! Concerned vendors can apply for proof-of-concept test code here.