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.
Being able to rescue you motherboard isn’t a “vulnerability”
If you own it, you’re responsible for knowing the password. A hole allowing someone to bypass secure boot, especially on a laptop, isn’t a good tradeoff for a physical backdoor that lets you recover keys you were responsible for managing.
That said, this is good if you want to score a deal on a used enterprise laptop.
Being able to break your own lock is a vulnerability.
Untrue and shows a lack of understanding of the subject.
All locks are breakable.
A Lock’s job is to prevent the likely kinds of attacks against it for a specific amount of time.
In the security community we constantly preach the CORRECT level of security for the application.
Security is always a trade off.
Convenience of use and recovery from loss are always important parts of the equation.
A car that pairs all components and cannot be started without the correct key, which cannot be replaced, is not the correct level of security for a car.
No one should argue that losing your keys should mean having to pay for disposal of the car and the purchase of a new one.
Trying to make physical hardware impervious to attacks and obscured against analysis is not the correct level of security.
There is always a balance to be had between usability and longevity of the equipment. And we need to stop letting this equipment be classified as disposable assets to a company.
Just because it is good for them to have a locked down box that they can use for 4 years and chuck in a landfill, does not mean the rest of us should have no say.
We all share that landfill and the source of materials used to make their parts.
That BIOS password is mind boggling to me, why only encrypt after the 12th character on the password, and how was it not caught?! It is so strange, and the 12 character seems very oddly arbitrary, but more like it was a deliberate choice than an accident, as surely accidentally it would be only the first byte or two that could slip through accidentally and justifiably not be noticed – 12 Character is just too huge a mistake to have passed even the most basic validation your code works…
And now I’m curious if the motherboard even allows you to unenroll the MS secure boot keys, last time I fought with secure boot stuff it seemed to be way way too much work to get that system to actually do what I darned wanted, so I did just turn the secure boot off (frankly don’t need it, was just curious if I could get secure boot to deny Windon’t etc).
“For longer passwords, characters beyond the first 12 are encrypted”…. Indeed, what was that feature meeting like at Dell? Is there a test plan that makes sure the first 12 bytes are not encrypted? Is it encryption when the key material is the first byte, or obfuscation?
Probably some lame attempt at backwards-compatibility and “ticking the box” of the passwords being encrypted. I doubt they ever believed it to be secure, and I bet most BIOS implementations don’t bother encrypting the password at all.
Yeah yeah yeah, 100%. I’m thinking bios rollback test had to pass.
Yeah I could see one or two character of the password slipping through – this password string has n bytes with the first x planned on being being housekeeping related to the encryption key section in memory used, length of actually used key, or maybe in fancier cases the company and the user can have their own bios passwords with different permissions so the permission for each level of user is defined along with the password. But in the end it worked out to be x-2 bytes and the guy’s doing that housekeeping section released them shifting all the data on compile without the security side knowing/noticing…
But 12 characters is so so much and should never have slipped through – honestly I can’t think I’ve ever seen a 12 character password outside of my own personal ones – not that many folks are really good touch typists, especially in the more technical fields – hunt’n’peck is fast enough for many system/network admin types.
(My passwords tend to be “CorretHorseBatteryStaple” style memorable but with my own rules for substitutions and misspellings (beyond the accidental dyslexic ones I repeatedly make anyway) so a dictionary attack would still really struggle – still really quick for me to type and most of them I can just remember even to things I’ve not used in a while).
I’d imagine they divided the user base into two:
1) idiots who set bios passwords and forget them, then call support. They set short passwords, because idiots.
2) other people set longer passwords. They remember them.
They used the wrong size key for the text they were trying to encrypt (as well as the wrong KDF, and wrong algorithm entirely, but I digress…). 32 bytes of password – 20 bytes of key = 12. I imagine they 0-extended the key out to 32 bytes, then XORed it with the password. 0 XOR anything returns the original thing, so the first 12 bytes are unprotected.
So… a teenage moron wanted to make it big in cyber-crime by spreading malware and extorting big companies but he didn’t have enough skill to realize all the risks? Maybe getting v& will teach him a thing or two.
Remember when hacking was about posting goаtse, making fun of incompetent admins and web coder or simply having a laugh? As usual money and greed destroys everything that’s good.
LAME and BLADE at least used to be different encoders. Was that a typo?
Yeah, that’s gotta be wrong. Lame was based off Blade to allow for easy transition from what I remember.
Nice to know one piece of software I use has not become a bloated, corporate-owned shell of code a decade later.
What’s to stop someone from writing a program that randomizes the GDID every hour? And when does this ID get shared?
Something like this?
https://github.com/gd03gd031/Windows-GDID-Changer
Oh, hi there, Murphy’s Law.
Yay, a non-ai written writeup! Thanks
The one the article linkes to is written by Claude; I could tell by the the time I was a few paragraphs in. Scrolled to the bottom and at least the author acknowledges it.