As more and more of the technology that we paid for turns becomes a subscription, there’s slowly been a momentum shift in the open source world of building replacements for these intrusive rent-seekers. We see this all of the time for self-hosted media and communications servers, but now we’re starting to see it in hardware as well. The OOMWOO robotic vacuum cleaner is completely open source, from hardware to software, and requires no cloud services whatsoever.

Although it’s open source, not every component is something one could buy off the shelf. It does require a 3D printer for most of the parts, but assuming that requirement is met most of the rest of the build comes together easily enough. For compute it relies on a Raspberry Pi running ROS 2 software and is set up to integrate easily with other existing open tools and projects such as Home Assistant. Like its proprietary cousins it can sense and map the rooms its placed in, but this platform uses an inexpensive 2D lidar system to keep costs down.

Right now the project is not quite complete, so we’ll all have to keep our eyes on this one as the team building it progresses. But they do have most of the software development done and the bill-of-materials is in progress. As an open project it’s being developed by many volunteers and there are a lot of areas available to contribute to as well, all currently set up on the project’s GitHub page. Right now many of those areas of effort are adapting the 3D printer files to off-the-shelf parts.

With the rocky status of the Roomba ecosystem, projects like this are more important than ever.

AI chatbots are everywhere these days, and they seem to “know” about everything. But while that is a strength, it can sometimes be a weakness because it isn’t laser-focused on one topic. Not so with this Ham-radio-centric chatbot called HamGPT. The service is clearly built on another GPT engine but understands how to retrieve data from common ham radio sources, such as the FCC database, propagation reports, and the like. It didn’t, however, seem to have access to ham radio-related books, magazine articles, or other “static” data that we could tell.

You do have to sign up for an account, which includes providing your callsign and location. There is a free tier that allows a limited number of queries per day, so you can try it to see if it is useful for you without subscribing.

Here’s a typical session:

                What band will have the best propagation to Japan from my QTH right now?

The best band for Japan from your QTH right now is 30 meters, which shows good propagation reliability. 20 meters is also active and providing a viable path.

Real-time data confirms activity on both bands, primarily using FT8. While the path is open, the signals are relatively weak (typical for this long-haul path), making digital modes like FT8 or CW your best bet for a successful contact.

Would you like me to check if your current antenna setup is suitable for these bands, or perhaps help you calculate dimensions for a 30m or 20m antenna?

In addition, bubbles at the bottom of the screen showed me the busiest band in my area and how many repeaters were nearby.

In all fairness, we asked ChatGPT the same question, but did say “ham radio band” just to give it some idea of scope. It gave a much more detailed answer with sources, even provided headings, and made a suggestion about another location I sometimes operate from because it remembers things from previous unrelated chats.

We understand reactions will be mixed. If you’ve been a ham for a long time, you probably could have guessed that a path from the US to Japan in the morning was likely to be on 20 or 30 meters. You probably also know how to look things up yourself.

We didn’t try any more sophisticated queries that might make it more worthwhile. For example, what if you could send it an ADIF log file and ask it what awards you qualified for? Or to process contest logs for duplicates and fill out a scoring worksheet? What would you like a ham radio-aware AI to do for you?

Ham radio — at least parts of it — has become inextricably linked with computers.

Following the reports last week using the Windows Global Device ID (GDID) in tracking a malware operators behavior, here is a comprehensive write-up about what goes into the GDID and how it is used. It’s worth noting that the GDID itself was not used to catch the malware operator, however once a suspect was identified, the GDID was used to correlate behavior across various Microsoft products on the Internet.

The GDID is generated and assigned during a Windows install, but a re-install of Windows will generate a new GDID. Developer [SmtimesIWndr] tracks the generation and tracking of the GDID through the various Windows libraries and services, identifying where it appears to be created and how it is passed to other services like Azure.

Worth noting is your GDID is a unique, personally identifiable piece of information; if you go exploring and extract it from your Windows install, be sure to keep it private!

LAME mp3 updates

Those of us who were around for the dawn of MP3 files may remember the LAME encoder and library. After almost 10 years, there is a new LAME release.

Notably, this includes two security fixes, one for a stack buffer overflow based on malicious input to the Blade encoder, and an integer underflow in the AIFF header parser. Both of the fixed bugs feel very old-school, which seems appropriate given the age of the library and most of the related code.

Buffer overflows impacting the stack are some of the simplest and most direct forms of vulnerabilities, where it is possible to write past the end of a buffer and control how the function returns and instead execute arbitrary code. Integer under-flows, similarly, impact memory management; usually caused by allowing a variable that stores the size of a buffer to go negative. Since sizes are typically unsigned positive numbers, a negative is interpreted as an enormous positive number, writing past the proper buffer length.

Despite the new findings, the LAME codebase has been extremely resilient over the years, and considering the number of programs that likely still use LAME under the covers to process audio, seeing the project wake up with security fixes is great news.

Recovering Passwords from BIOS

Researchers have found a vulnerability in Dell BIOS code that allows extraction of the administrator password from the BIOS flash chips, either with physical access via a flash programmer, or via administrator or root level access to the operating system and reading the contents of the flash chip.

Dell used a 20 byte key to encrypt a 32 byte password field: for any admin password of 12 characters or fewer, the password is stored in completely plaintext. For longer passwords, characters beyond the first 12 are encrypted – but the random bytes are computed from the first character of the password mixed with fixed device data, yielding only 256 possible encryption seeds for the remaining bytes.

Using the BIOS admin password for evil requires local access, so the attack surface is small, however as the researchers note it controls the boot order and may allow an attacker with physical access to then boot an unsigned OS or bypass full-disk encryption, so it’s serious.

Patch Tuesday Crushes Records

Last month, Microsoft broke records for the number of security fixes in the June monthly Patch Tuesday roundup. This month, Microsoft broke records for the number of security fixes in the July monthly Patch Tuesday roundup.

This month includes a record 60 plus patches for critical vulnerabilities in Windows, as well as fixes for previous Bitlocker bypasses, and an AI prompt injection which could allow web sites to trigger Copilot in Microsoft Edge on Android and execute arbitrary prompts. Another bug patched this month allowed privilege escalation and code execution over DHCP, potentially impacting all Windows installs on the same physical network or public hotspot.

Microsoft credits AI assisted tooling with the record-breaking number of bugs discovered, and indicates it’s unlikely to slow down next month.

LegacyHive Windows Vulnerability

It’s a week with a Patch Tuesday, which now seems to mean it’s a week with a new exploit from NightmadeEclipse, the researcher who previously made news for being quite upset with the responses from the Microsoft security group. After then creating a public outcry by threatening prosecution, Microsoft recently has seemed simply to be fixing bugs disclosed by NightmareEclipse in the next series of security updates.

This month, we have LegacyHive, an exploit which allows loading the “hive”, or collection of registry settings and configuration files, of another user. The Windows registry is typically used to store preferences, settings, auto-launched applications, and other important settings, so being able to access other users registry groups seems significant.

Fairlife Dairy Suspends Production

Fairlife Dairy, owned by Coca-Cola, has suspended US operations due to a ransomware attack. Filings with the SEC simply say that production facilities are impacted and will be temporarily suspended, with no estimate as to when they will be restored.

Typically when a food-processing facility goes offline, the delays for restoring service can be significant due to the sanitization requirements.

CPAN and Perl April Task Force

The April Task Force has been announced (yes, in July) with a focus on enhancing the security posture of Perl and the CPAN library.

Given the absolute havoc wreaked on the NPM and PyPi repositories in 2026, proactive measures to protect other repositories seem prudent. Funded by the Perl and Raku Foundation and the Linux Foundation, the April Task Force will be focused on supply chain security, vulnerability patching, and processing reported vulnerabilities and CVEs.

Perl may not be the juggernaut language it once was, but it’s still used widely, so any preventative measures are good news.

Secure Boot vulnerable

Researchers from ESET enumerated 11 boot loaders signed by Microsoft that can be used to bypass secure boot protections and execute arbitrary code.

Secure Boot was designed to only boot code signed by trusted organizations (in this case, Microsoft). Those of us running Linux typically know it as “the option in the BIOS to turn off to get a kernel to run properly”, but for corporate fleets, Secure Boot protections help protect disk encryption and prevent malware installs.

During boot, a Secure Boot protected system validates the code it is about to launch to ensure it is signed by a trusted organization, establishing a chain of trust where each component then validates the next before launching. Often, to enable other tools or Linux distributions to boot, a “shim” boot loader is created and signed by an organization trusted by the UEFI install, which then loads and validates the actual boot loader or kernel.

Over the years, many such shims have been signed, but updates have lagged and security vulnerabilities have been found. Even unused old boot loader code remains signed and viable, allowing attackers to replace a modern version with a vulnerable, still valid, old version.

Microsoft has removed several of the vulnerable boot loaders via recent Windows patches, however systems that are not updated and systems that do not run Windows will still likely be vulnerable.

There are a lot of ESP32-based development boards out there– and why not? It’s a versatile chip that can be used in all sorts of situations, and people want boards to match them. Not finding one to his liking that was specifically built for solar powered IoT projects, [Narrow Studios] rolled his own. Well, designed it; like most these days, he’s outsourced the manufacturing to PCBWay, which is where you’ll need to go if you want one.

Why might you want one? Well, if you have similar goals in mind to [Narrow Studios]. He’s put an ESP32-C6 Mini on the board, which means it’s got most of the IoT communications protocols you might be interested in — bluetooth, wifi, Matter, Thread, and Zigbee, too. Ten 10 IO pins have been broken out, plus I2C on a QWIIC connector, which gets you a whole ecosystem of sensors to easily plug into. The “solar” part is justified by the inclusion of a BQ25186 linear battery charging IC from Texas Instruments, with the designated solar power input protected against reverse voltage in case you– like this author– have let magic smoke out by hooking things up backwards. Is it embarrassing? Yes. Does it happen? Also yes, so putting protection on the board is a nice feature. [Narrow Studios] released a video that we’ve embedded below discussing his design choices and demonstrating the device, but the project page can give you the gist.

Of course there’ve been plenty of solar-powered projects to feature the ESP32 here before– you can even use it for maximum power point tracking— but this dev board might be exactly what someone is looking for to build their next IoT project, so we’re thankful to [Narrow Studios] for the tip.

Like so many large and popular open source projects these days, the Godot game engine struggles with an influx of pull requests. The situation has become increasingly dire due to the advent of AI-generated code. More specifically, the issue involves the inverse relationship between PR code quality and the number of PRs, which wastes a lot of time on the side of a limited number of (volunteer) reviewers. This has now forced the project to update its contribution policy.

An interesting point raised in the announcement article is that of the demoralizing effect of AI-generated PRs on reviewers. Often the human behind such a PR isn’t interested in being educated, or may even be an automated agent which isn’t capable of productive discussion on pros and cons of certain coding approaches — never mind in becoming a more permanent maintainer for the project.

This problem has led to new rules being instated, which include a ban on autonomous AI agents and vibe coding, a ban on substantial AI generating of code, and a ban on AI-generated text in human-to-human communication. It also codifies the requirement that all PRs are to be reviewed and approved by a human being before merging.

In many ways this new policy is similar to that of the Mesa project, which demands code comprehension on the side of the submitter, although it doesn’t go as far as NetBSD, which just outright treats LLM-generated code as ‘tainted’ due to potential licensing and other concerns. Other projects like the Linux kernel opt to make the human submitter responsible for any AI tool usage by forcing them to declare it.

Meanwhile there are also indications that such ‘AI tool’ usage is reducing useful interactions with open source projects. What the future will bring here remains to be seen, but at least as far as open source projects go these tools are clearly increasingly being banished.