Regain Some Trust In Unknown USB Drives

July 27, 2026 by Bryan Cockfield 23 Comments

For how useful USB thumb drives are for quickly toting around and copying files from one computer to another, they can be a bit of a security headache. Programs can be loaded on them with all kinds of malware; they can be obscured in some ways that are difficult to detect, and they can be set up to execute certain programs when they’re plugged in. The general wisdom is to simply avoid untrusted USB devices completely, but that sort of abstinence-only policy rarely works in the real world. If, for some reason, an untrusted USB device absolutely needs to be used, many of these security issues can be mitigated with this tool.

Built by [Novamostra], the device is simple on the surface: it’s a Raspberry Pi Pico mated to a 2-in-1 USB splitter cable. But with the USB Neutralizer software they have written loaded onto the Pico, it automatically destroys the ability of any connected USB thumb drive to load files. The program works by deleting the first and last 34 Logical Block Addressing (LBA) sectors on the drive immediately when it’s plugged in, without doing anything else. This effectively corrupts the drive bad enough to prevent malicious software in the partitions from doing anything, allowing the user to (relatively) safely put the USB drive into their computer and format it for re-use. The code for this tool is also open-source and reviewable on the project’s GitHub page.

Of course, this isn’t a perfect security solution for all USB attacks. It doesn’t erase or replace the firmware on the drive itself, and although firmware-level attacks are rare they’re not out of the question for all users, all the time. It also won’t prevent a malicious physical attack like this high-voltage one, and it may also not stop hidden or obscured partitions or devices programmed for storage and some other nefarious purpose simultaneously, like a USB HID. But still, this solves a great many of the problems associated with getting new drives from semi-untrustworthy sources, like retailers or friends whose computer skills we don’t fully trust.

Flipped Bit Could Mark The End Of Voyager 1‘s Interstellar Mission

February 9, 2024 by Dan Maloney 95 Comments

Sometimes it’s hard to read the tea leaves of what’s going on with high-profile space missions. Weighted down as they are with the need to be careful with taxpayer money and having so much national prestige on the line, space agencies are usually pretty cagey about what’s going on up there. But when project managers talk about needing a “miracle” to continue a project, you know things have gotten serious.

And so things now sit with Voyager 1, humanity’s most distant scientific outpost, currently careening away from Mother Earth at 17 kilometers every second and unable to transmit useful scientific or engineering data back to us across nearly a light-day of space. The problem with the 46-year-old spacecraft cropped up back in November, when Voyager started sending gibberish back to Earth. NASA publicly discussed the problem in December, initially blaming it on the telemetry modulation unit (TMU) that packages data from the remaining operable scientific instruments along with engineering data for transmission back to Earth. It appeared at the time that the TMU was not properly communicating with the flight data system (FDS), the main flight computer aboard the spacecraft.

Since then, flight controllers have determined that the problem lies within the one remaining FDS on board (the backup FDS failed back in 1981), most likely thanks to a single bit of corrupted memory. The Deep Space Network is still receiving carrier signals from Voyager, meaning its 3.7-meter high-gain antenna is still pointing back at Earth, so that’s encouraging. But with the corrupt memory, they’ve got no engineering data from the spacecraft to confirm their hypothesis.

The team has tried rebooting the FDS, to no avail. They’re currently evaluating a plan to send commands to put the spacecraft into a flight mode last used during its planetary fly-bys, in the hope that will yield some clues about where the memory is corrupted, if indeed it is. But without a simulator to test the changes, and with most of the engineers who originally built the spacecraft long gone now, the team is treading very carefully.

Voyager 1 is long past warranty, of course, and with an unparalleled record of discovery, it doesn’t owe us anything at this point. But we’re not quite ready to see it slip into its long interstellar sleep, and we wish the team good luck while it works through the issue.

Update: Flash_Destroyer Final Destroys EEPROM

June 14, 2010 by Mike Szczys 17 Comments

The Flash_Destroyer finally succeeded in rewriting that EEPROM until its demise. When we originally looked at the device it had already recorded 2.5 million successful rewrites. The first appearance of corrupt data occurred at 11,494,069 but that doesn’t tell the whole story. The chip kept working for another 200,000 rewrites before finally showing repeated data corruption.

We do find the writeup pretty interesting. There’s one thing that we can’t stop coming back to though. In the discussion of our original article [Tiago] pointed out that long-term data retention isn’t being tested here. If the abuse of that EEPROM had ended after say five million rewrites, would it have been able to hold the data long-term without corruption? Let us know what you think in the comments.

[Thanks Drone377]