This Week In Security: Anthropic, Coinbase, And Oops Hunting

Anthropic has had an eventful couple weeks, and we have two separate write-ups to cover. The first is a vulnerability in the Antropic MCP Inspector, CVE-2025-49596. We’ve talked a bit about the Module Context Protocol (MCP), the framework that provides a structure for AI agents to discover and make use of software tools. MCP Inspector is an Open Source tool that proxies MCP connections, and provides debugging information for developers.

MCP Inspector is one of those tools that is intended to be run only on secure networks, and doesn’t implement any security or authentication controls. If you can make a network connection to the tool, you can control it. and MCP Inspector has the /sse endpoint, which allows running shell commands as a feature. This would all be fine, so long as everyone using the tool understands that it is not to be exposed to the open Internet. Except there’s another security quirk that intersects with this one. The 0.0.0.0 localhost bypass.

The “0.0.0.0 day exploit” is a bypass in essentially all the modern browsers, where localhost can be accessed on MacOS and Linux machines by making requests to 0.0.0.0. Browsers and security programs already block access to localhost itself, and 127.0.0.1, but this bypass means that websites can either request 0.0.0.0 directly, or rebind a domain name to 0.0.0.0, and then make requests.

Continue reading “This Week In Security: Anthropic, Coinbase, And Oops Hunting”

160-core RISC V Board Is The M.2 CoProcessor You Didn’t Know You Needed

Aside from GPUs, you don’t hear much about co-processors these days. [bitluni] perhaps missed those days, because he found a way to squeeze a 160 core RISC V supercluster onto a single m.2 board, and shared it all on GitHub.

OK, sure, each core isn’t impressive– he’s using CH32V003, so each core is only running at 48 MHz, but with 160 of them, surely it can do something? This is a supercomputer by mid-80s standards, after all.  Well, like anyone else with massive parallelism, [bitluni] decided to try a raymarcher. It’s not going to replace RTX anytime soon, but it makes for a good demo.

Like his previous m.2 project, an LED matrix,  the cluster is communicating over PCIe via a WCH CH382 serial interface. Unlike that project, blinkenlights weren’t possible: the tiny, hair-thin traces couldn’t carry enough power to run the cores and indicator LEDs at once. With the power issue sorted, the serial interface is the big bottleneck. It turns out this cluster can crunch numbers much faster than it can communicate. That might be a software issue, however, as the cluster isn’t using all of the CH382’s bandwidth at the moment. While that gets sorted there are low-bandwidth, compute-heavy tasks he can set for the cluster. [bitluni] won’t have trouble thinking of them; he has a certain amount of experience with RISCV microcontroller clusters.

We were tipped off to this video by [Steven Walters], who is truly a prince among men. If you are equally valorous, please consider dropping informational alms into our ever-present tip line

Continue reading “160-core RISC V Board Is The M.2 CoProcessor You Didn’t Know You Needed”

A plywood box with a clear plastic front is shown. Three needle gauges are visible on the front of the box, as well as a digital display, several switches, and some indicator lights. At the right of the box, a short copper tube extends from the box.

Building An X-Ray Crystallography Machine

X-ray crystallography, like mass spectroscopy and nuclear spectroscopy, is an extremely useful material characterization technique that is unfortunately hard for amateurs to perform. The physical operation isn’t too complicated, however, and as [Farben-X] shows, it’s entirely possible to build an X-ray diffractometer if you’re willing to deal with high voltages, ancient X-ray tubes, and soft X-rays.

[Farben-X] based his diffractometer around an old Soviet BSV-29 structural analysis X-ray tube, which emits X-rays through four beryllium windows. Two ZVS drivers power the tube: one to drive the electron gun’s filament, and one to feed a flyback transformer and Cockroft-Walton voltage multiplier which generate a potential across the tube. The most important part of the imaging system is the X-ray collimator, which [Farben-X] made out of a lead disk with a copper tube mounted in it. A 3D printer nozzle screws into each end of the tube, creating a very narrow path for X-rays, and thus a thin, mostly collimated beam.

To get good diffraction patterns from a crystal, it needed to be a single crystal, and to actually let the X-ray beam pass through, it needed to be a thin crystal. For this, [Farben-X] selected a sodium chloride crystal, a menthol crystal, and a thin sheet of mica. To grow large salt crystals, he used solvent vapor diffusion, which slowly dissolves a suitable solvent vapor in a salt solution, which decreases the salt’s solubility, leading to very slow, fine crystal growth. Afterwards, he redissolved portions of the resulting crystal to make it thinner.

The diffraction pattern generated by a sodium chloride crystal. A slide is shown with a dark black dot in the middle, surrounded by fainter dots.
The diffraction pattern generated by a sodium chloride crystal.

For the actual experiment, [Farben-X] passed the X-ray beam through the crystals, then recorded the diffraction patterns formed on a slide of X-ray sensitive film. This created a pattern of dots around the central beam, indicating diffracted beams. The mathematics for reverse-engineering the crystal structure from this is rather complicated, and [Farben-X] hadn’t gotten to it yet, but it should be possible.

We would recommend a great deal of caution to anyone considering replicating this – a few clips of X-rays inducing flashes in the camera sensor made us particularly concerned – but we do have to admire any hack that coaxed such impressive results out of such a rudimentary setup. If you’re interested in further reading, we’ve covered the basics of X-ray crystallography before. We’ve also seen a few X-ray machines.

A man’s hand is visible holding a large, potato-shaped object in the foreground. A short, white, cylindrical structure is on the top of the potato, with black wires bending back into the potato. A smaller rectangular structure is to one side of it, and a red alligator clip connects to a nail protruding from the potato.

Building A Potato-based GLaDOS As An Introduction To AI

Although not nearly as intimidating as her ceiling-mounted hanging arm body, GLaDOS spent a significant portion of the Portal 2 game in a stripped-down computer powered by a potato battery. [Dave] had already made a version of her original body, but it was built around a robotic arm that was too expensive for the project to be really accessible. For his latest project, therefore, he’s created a AI-powered version of GLaDOS’s potato-based incarnation, which also serves as a fun introduction to building AI systems.

[Dave] wanted the system to work offline, so he needed a computer powerful enough to run all of his software locally. He chose an Nvidia Jetson Orin Nano, which was powerful enough to run a workable software system, albeit slowly and with some memory limitations. A potato cell unfortunately doesn’t generate enough power to run a Jetson, and it would be difficult to find a potato large enough to fit the Jetson inside. Instead, [Dave] 3D-printed and painted a potato-shaped enclosure for the Jetson, a microphone, a speaker, and some supplemental electronics.

A large language model handles interactions with the user, but most models were too large to fit on the Jetson. [Dave] eventually selected Llama 3.2, and used LlamaIndex to preprocess information from the Portal wiki for retrieval-augmented generation. The model’s prompt was a bit difficult, but after contacting a prompt engineer, [Dave] managed to get it to respond to the hapless user in an appropriately acerbic manner. For speech generation, [Dave] used Piper after training it on audio files from the Portal wiki, and for speech recognition used Vosk (a good programming exercise, Vosk being, in his words, “somewhat documented”). He’s made all of the final code available on GitHub under the fitting name of PotatOS.

The end result is a handheld device that sarcastically insults anyone seeking its guidance. At least Dave had the good sense not to give this pernicious potato control over his home.

fastener counter

Fastener Fusion: Automating The Art Of Counting

Counting objects is an ideal task for automation, and when focusing on a single type of object, there are many effective solutions. But what if you need to count hundreds of different objects? That’s the challenge [Christopher] tackled with his latest addition to his impressive automation projects. (Video, embedded below.)

[Christopher] has released a series of videos showcasing a containerized counting system for various fasteners, available on his YouTube channel. Previously, he built remarkable devices to count and sort fastener hardware for automated packaging, but those systems were designed for a single fastener type. He effectively highlights the vast complexity of the fastener ecosystem, where each diameter has dozens of lengths, multiple finishes, various head shapes, and more.

To address this, he developed a machine that accepts standardized containers of fastener hardware. These uniform boxes can hold anything from a small M2 countersunk screw to a large M8 cap head bolt and everything in between. To identify the loaded box and determine the appropriate operations, the machine features an RFID reader that scans each box’s unique tag.

Once a box is loaded, the machine tilts it to begin counting fasteners using a clever combination of moving platforms, an optical sensor, and gravity. A shelf first pushes a random number of fasteners onto an adjustable ledge. A second moving platform then sweeps excess fasteners off, leaving only those properly aligned. It’s no surprise this system has nine degrees of freedom. The ledge then moves into view of a sensor from a flatbed scanner, which detects object locations with an impressive 0.04 mm resolution across its length—remarkable for such an affordable sensor. At this point, the system knows how many fasteners are on the ledge. If the count exceeds the desired number, a sloped opening allows the ledge to lift just high enough to release the correct amount, ensuring precision.

The ingenuity continues after the initial count. A secondary counting method uses weight, with a load cell connected to the bin where fasteners drop. A clever over-center mechanism decouples the tilting system from the load cell to ensure accurate readings. We love automation projects, and this one incorporates so many ingenious design elements that it’s sure to inspire others for their future endeavors.

Continue reading “Fastener Fusion: Automating The Art Of Counting”

Hackaday Links Column Banner

Hackaday Links: July 6, 2025

Taking delivery of a new vehicle from a dealership is an emotional mixed bag. On the one hand, you’ve had to endure the sales rep’s hunger to close the deal, the tedious negotiations with the classic “Let me run that by my manager,” and the closer who tries to tack on ridiculous extras like paint sealer and ashtray protection. On the other hand, you’re finally at the end of the process, and now you get to play with the Shiny New Thing in your life while pretending it hasn’t caused your financial ruin. Wouldn’t it be nice to skip all those steps in the run-up and just cut right to the delivery? That’s been Tesla’s pitch for a while now, and they finally made good on the promise with their first self-driving delivery.
Continue reading “Hackaday Links: July 6, 2025”

Diagnosing Whisker Failure Mode In AF114 And Similar Transistors

The inside of this AF117 transistor can was a thriving whisker ecosystem. (Credit: Anthony Francis-Jones)
The inside of this AF117 transistor can was a thriving whisker ecosystem. (Credit: Anthony Francis-Jones)

AF114 germanium transistors and related ones like the AF115 through AF117 were quite popular during the 1960s, but they quickly developed a reputation for failure. This is due to what should have made them more reliable, namely the can shielding the germanium transistor inside that is connected with a fourth ‘screen’ pin. This failure mode is demonstrated in a video by [Anthony Francis-Jones] in which he tests a number of new-old-stock AF-series transistors only for them all to test faulty and show clear whisker growth on the can’s exterior.

Naturally, the next step was to cut one of these defective transistors open to see whether the whiskers could be caught in the act. For this a pipe cutter was used on the fairly beefy can, which turned out to rather effective and gave great access to the inside of these 1960s-era components. The insides of the cans were as expected bristling with whiskers.

The AF11x family of transistors are high-frequency PNP transistors that saw frequent use in everything from consumer radios to just about anything else that did RF or audio. It’s worth noting that the material of the can is likely to be zinc and not tin, so these would be zinc whiskers. Many metals like to grow such whiskers, including lead, so the end effect is often a thin conductive strand bridging things that shouldn’t be. Apparently the can itself wasn’t the only source of these whiskers, which adds to the fun.

In the rest of the video [Anthony] shows off the fascinating construction of these germanium transistors, as well as potential repairs to remove the whisker-induced shorts through melting them. This is done by jolting them with a fairly high current from a capacitor. The good news is that this made the component tester see the AF114 as a transistor again, except as a rather confused NPN one. Clearly this isn’t an easy fix, and it would be temporary at best anyway, as the whiskers will never stop growing.

Continue reading “Diagnosing Whisker Failure Mode In AF114 And Similar Transistors”