Security Now 1076 transcript
Please be advised that this transcript is AI-generated and may not be word-for-word. Time codes refer to the approximate times in the ad-free version of the show.
Leo Laporte [00:00:00]:
It's time for Security Now. Steve Gibson is here with a great picture of the week and an amazing spy story. 21 year old malware that only now has been discovered. The story of fast 16.6. Coming up next on Security Now.
Steve Gibson [00:00:19]:
Podcasts you love from people you trust.
Leo Laporte [00:00:23]:
This is Twit. This is Security now with Steve Gibson. Episode Episode 1076 recorded Tuesday, April 28, 2026. Fast 16 SIS. It's time for Security now. Ladies and gentlemen, get ready. Here's the hero, the star of our show, Mr. Steve Gibson.
Leo Laporte [00:00:48]:
Hello, Steve. Oh no, this.
Steve Gibson [00:00:52]:
Oh, we have a story today.
Leo Laporte [00:00:57]:
You know, the title is a little weird.
Steve Gibson [00:00:59]:
Yes, it is. The title of Today's podcast is fast.
Leo Laporte [00:01:05]:
That sounds like fat 16 sis.
Steve Gibson [00:01:07]:
Yeah, not fat. Maybe was meant to look like it
Leo Laporte [00:01:11]:
or I think so. Maybe it's scan over it and not.
Steve Gibson [00:01:14]:
Or maybe a quick. It could have been like a math library alternate name. But it's kind of an unbelievable name, right? It turns out that through a weird, just coincidental discovery, some security researchers uncovered evidence and then proof of a diabolical, I mean diabolically brilliant thing that predated Stuxnet by about five years.
Leo Laporte [00:01:52]:
Oh, that's why it's not cis because that's the old Microsoft designation.
Steve Gibson [00:01:56]:
Oh, it's still, still the, the. Yeah, the system32 directory is of dot do sys files. So what they found was. Okay, our listeners have. Have heard me worry that maybe the US is not up to speed because we keep, you know, having reports about being attacked by China and North Korea and Russia and so forth and I'm wondering, can we give as much as we get? I'm not that worried anymore. So today we're going to talk about, once we get to it, this amazing evidence trail and what was discovered in place back in the Windows 2000 XP days. And oh Leo, you are going to love what this thing did because I mean it's just, it's so clever and so just wonderful. Anyway, we're going to talk about Bit Warden's command line interface hit with by a supply chain attack and why no bitwarden users end users were impacted by this.
Steve Gibson [00:03:17]:
Some news of commercial routers in Iran failing shortly before we invaded or. Or bombed them. And what a coincidence, you know those pesky foreign routers also meta apparently logging all of their employees activity to train a replacement AI. I have a big announcement to make big for me because it's the conclusion of the last 90 days of my efforts on the my complete rewrite. Well, not completely right, but huge up philosophical change in the way we do e Commerce at GRC and the concomitant release 5 of the benchmark, which everybody who owns the benchmark is can go get right now. I've got my own. A couple of miscellaneous AI thoughts. Then we're going to do a bunch of terrific listener feedback and wind up with looking.
Steve Gibson [00:04:17]:
Doing a deep dive into the unraveling of this just oh, so clever history of this fast 16 sys driver and what it. How it was discovered, what it does and why. It just makes us think, okay, maybe the NSA doesn't need our help after all. They're.
Leo Laporte [00:04:41]:
They're gonna.
Steve Gibson [00:04:41]:
They're doing just fine. And we've got a fun picture of the week, so I think maybe a useful podcast for our listeners.
Leo Laporte [00:04:48]:
Oh, that sounds very exciting. You know, every time we. I think about these deep fakes, I think about the. The little AI Leo that Anthony made just to illustrate.
Steve Gibson [00:05:04]:
Yeah.
Leo Laporte [00:05:05]:
How easy. Listen well.
Steve Gibson [00:05:06]:
And what a cool name and domain.
Leo Laporte [00:05:09]:
Leo asking you to buy gift cards. But seriously, can you grab me 100 Apple gift cards? Just kidding. This is Anthony testing text to speech. How's it sound? He trained that with. With Quen 3 on his own machine. I don't. I couldn't tell. Sounded like me.
Leo Laporte [00:05:25]:
Yeah, Doppel's a good name because that's a doppelganger of me, right?
Steve Gibson [00:05:29]:
Exactly, Exactly. Doppelganger.
Leo Laporte [00:05:33]:
All right, I've got the picture of the week. I have not looked at it. I put myself a soundproof booth.
Steve Gibson [00:05:38]:
One of our listeners. Thank you very much. Sent this to me, and after looking at it, I decided to give it the title. In software development, this is known as time to refactor the code.
Leo Laporte [00:05:52]:
Okay, but it's not software. This is hardware, I think.
Steve Gibson [00:05:55]:
Yes, but software would be time to ref.
Leo Laporte [00:06:00]:
That is one backflow. Holy. That doesn't seem right.
Steve Gibson [00:06:06]:
Oh, goodness.
Leo Laporte [00:06:07]:
Wow.
Steve Gibson [00:06:10]:
So for those who aren't seeing the picture of the week, this is the. I don't know what it is. It is a. Remember that old Three Stooges episode where Mo was trying to fix the plumbing in a house upstairs?
Leo Laporte [00:06:27]:
You and I are the same age. We totally. And they. And the water squirts in the face, and then they squirrel closes that up and then squirts the other way and.
Steve Gibson [00:06:34]:
Oh, God, he ends up being, like, caged in by this maze of. Of p. Of plumbing pipes so that he can't get out. And then. Then the water's going into light bulbs and it's filling them up and they're exploding and Anyway, crazy. But this is like, this is. This demonstrates a, I think a severe lack of planning, which of course we've talked about often. Software has a hard time evolving that the nature of it is that, you know, depending upon the way it's built and structured it get it.
Steve Gibson [00:07:09]:
When you keep saying, oh, you know, your boss says, hey, I forgot to tell you, really nice job you did cool that you're all done, but now we need to add this. And it's like, oh, you didn't tell me because now I'm gonna have to graft that onto the side and you know, and stick in some hooks play in places. You know, software gets very ugly as it. As you do that. And so thus this notion of refactoring is to like, like have it end up doing the same thing, but redesign where things are being done and how things happen and like, you know, fix the structure.
Leo Laporte [00:07:44]:
So this is, I would guess at a summer camp or a trailer parker, a KOA somewhere where they had to add more capacity and they. And they had to do it fast. And the other thing that's hysterical, not only a lot of pipes, look how many switch boxes there are. There's a lot.
Steve Gibson [00:07:59]:
Yeah. And you've got like valves going down into the ground and they're all kind of cattywampus. That's the technical term. And like things coming in and joining filter in there.
Leo Laporte [00:08:12]:
I don't know what's going on. This is crazy. Crazy great. It's a swimming pool or something. I'm thinking it's at a camp. But anyway.
Steve Gibson [00:08:22]:
But look at all of the pipes going into the ground. I mean, like 1, 2, 3, 4, 5, 6, 7, 8. At least 8. Or like, like what is it?
Leo Laporte [00:08:31]:
Don't know. That's hysterical.
Steve Gibson [00:08:33]:
It does look like there's some things in parallel. Yeah, but.
Leo Laporte [00:08:37]:
Yeah, but this is real. Listeners sent you this.
Steve Gibson [00:08:40]:
Yeah, yeah, yeah. Oh, yeah, it's. It's. It's definitely. And you can see all. All of the blue plumbing. Plumbing, whatever they call that glue. Right, right.
Steve Gibson [00:08:52]:
To fit all the plumbers together.
Leo Laporte [00:08:54]:
Yeah, yeah, yeah, yeah. Wow.
Steve Gibson [00:08:56]:
Okay, so everyone's fast favorite password manager and a sponsor of the twit network was briefly bitten by a supply chain attack.
Leo Laporte [00:09:07]:
Good. I'm glad you're talking about this because I wanted to know more about this and.
Steve Gibson [00:09:11]:
Yes, and. And of course, many of our listeners immediately sent me email during this past week. So here's what the Hacker news reported. They said, according to findings from J. Frog and socket bit Warden's cli, the Command line interface for the password manager Bit Warden was reportedly compromised as part of a newly discovered and ongoing check marks supply chain campaign.
Leo Laporte [00:09:40]:
They should probably say that almost nobody uses the command line. I do.
Steve Gibson [00:09:44]:
Yes, that's right. I mean, I'm thinking. Yeah, exactly. So they wrote, quote, the affected package version appears to be at sign bitwarden/ CLI at sign 2026.4.0 and the malicious code was published in the, in the module or the file bw1js, a file included in the package contents. The attack appears to have leveraged a compromised, to no one's surprise here, GitHub action in Bit Warden CICD pipeline consistent with a pattern seen across other affected repositories in this campaign. So bitwarden wasn't even directly targeted. Right? I mean, this was a broad campaign that Checkmarks was launching that took advantage of this compromised GitHub action. And remember we talked about this a week or two ago, the security of those GitHub actions is turning out to be a real problem.
Steve Gibson [00:10:52]:
So it is a good thing that GitHub has indicated that they're going to shuffle their schedule around and raise the, the, the fixing priority of the security of their, the GitHub actions to, to, to do. To deal with this much more quickly than they were going to. So the hacker news continues. Writing in a post on X J. Frog said the rogue version of the package, quote, steals GitHub npm tokens, SSH, env, shell history, GitHub actions and cloud secrets, then exfiltrates the data to private domains and as GitHub commits. Okay, so specifically they wrote, the malicious code is executed by means of a pre install hook, resulting in the theft of local CI, GitHub and Cloud Secrets. Now the point here is this is a developer compromise, right? This is not an end user compromise. This is developer stuff.
Steve Gibson [00:11:57]:
So they said the data is exfiltrated to the domain audit checkmarks cx and to a GitHub repository as a fallback if the primary method fails. So they said it launches a credential stealer that targets developer secrets, GitHub Actions environments and AI coding tool configurations including Claude, Kiro, cursor, codec, CLI and ADIR. The stolen data is encrypted with AES256GCM and exfiltrated to that domain audit checkmarks cx, a domain impersonating check marks. If GitHub tokens are found, the malware weaponizes them to inject malicious action workflows into repositories and extract CI CD secrets, the firm step Security wrote. A single developer with Warden CLI 02640 installed can become the entry, so a single developer with that installed can become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI CD pipeline the developers token can reach. The malicious version is no longer available for download from NPM. It was only there for about 90 minutes and socket said the compromise follows the same GitHub action supply chain vector identified in the Checkmarks campaign. As part of the effort, threat actors have been found abusing stolen GitHub tokens to inject a new GitHub Actions workflow that captures secrets available to the workflow run and uses harvested credentials NPM credentials to push malicious versions of the package to read the malware to downs to read the malware to downstream users.
Steve Gibson [00:13:59]:
According to security researcher Adan Khan, the threat actor is said to have a malicious workflow to publish the malicious Bit Warden cli Khan said, I believe this is the first time a package using NPM Trusted Publishing has been compromised. So again, just to clarify, as I said, this was an attack on GitHub developers and their tool chains. It was not an attack upon Bit Warden's users. Bit Warden's official statement about the incident was so this is Bit Warden speaking. The Bit Warden security team identified and contained a malicious package that was briefly distributed through the NPM delivery path for and again that at bit warden CLI 2026 between 5:57pm and 7:30pm on April 22, 2026 in connection with a broader check marks supply chain incident. The investigation found no evidence that end user vault data was accessed or at risk or that production data or production systems were compromised. Once the issue was detected, compromised access was revoked, the malicious NPM release was deprecated and remediation steps were immediately were initiated immediately. The issue affected the NPM distribution mechanism for the command line interface during that limited window and it was actually it was 93 minutes long not the integrity of the legitimate Bit Warden CLI code base or stored vault data.
Steve Gibson [00:15:44]:
Users who did not download the package from NPN during that window were not affected. Bid Warden has completed a review of internal environments, release paths and related systems and no additional impacted products or environments have been identified at this time. A CVE For Bid Warden CLI version2026 is being issued in connection with this incident. You know they're just crossing their eyes and dotting their TE's or something. Okay, so but what we have is another instance of Deliberate malware repository corruption. Clearly we're going to need to get this fixed as soon as possible and my money is on eventually, hopefully sooner. Stationing ever watchful AI agents at the exits of our repositories so that they can verify that they've given anything that is being pulled the once over after its most recent update. And that'll be good.
Steve Gibson [00:16:53]:
There was a brief report in the security media about networking equipment installed at the Iranian Isfahan nuclear site mysteriously malfunctioning ahead of the US and Israeli missile strikes. Iranian officials reported issues with devices not just from one company. No, Cisco, Fortinet, Juniper and Microtech.
Leo Laporte [00:17:23]:
Well, thank goodness they weren't using Chinese routers.
Steve Gibson [00:17:26]:
Well, I know Leo, because you know,
Leo Laporte [00:17:29]:
because you know how insecure.
Steve Gibson [00:17:30]:
That's right. Officials are still searching for the cause of the malfunctions but noted that the country was disconnected from the global Internet at the time of the attack. So I wonder how, how they the routers even knew that it was time to malfunction. So the first thing that came to mind was, you know, it's got to be those pesky Ford made routers. You never can't tell what might be going on inside them.
Leo Laporte [00:17:59]:
Leo, you know it is interesting. I, I didn't realize. So they had air gapped them already. Yes, that's very interesting.
Steve Gibson [00:18:07]:
Although Leo, you know, okay, so at the same time the, as we know a since then Iranian principal actors they've been posting on Twitter and I mean X and they have some access so obviously they're not dark completely. And it, we talked about this at the time, they were like, like decommissioning satellites and going from house to house to make like to really try to get Iran off the Internet. I just don't know if that's even possible anymore.
Leo Laporte [00:18:41]:
Well, there was a brisk market in black market and gray market Starlink routers too. Even though Starlink, you know, didn't want that, SpaceX wasn't supporting it.
Steve Gibson [00:18:52]:
Right.
Leo Laporte [00:18:53]:
Still, still were able to do it.
Steve Gibson [00:18:54]:
Right. And in fact there was Iran was also working to identify the, the unique fingerprints of Starlink protocol so that they could track down how Starlink protocol was getting into their internal network. You know, and this is interesting too because of course we've been talking for years about how Russia has been deliberately planning ahead for the need to disconnect from, you know, the, the corrupt western Internet and do their own thing. And turns out it's not an easy thing to do. They've like, you know, been trying to do this but they at Least understood that they couldn't just pull a plug somewhere. I mean, it's difficult to do a kill switch. Yeah.
Leo Laporte [00:19:43]:
You saw the story in Spain because La Liga, which is a big soccer league, is so concerned about piracy in Spain.
Steve Gibson [00:19:50]:
Theft of their soccer game. Yeah.
Leo Laporte [00:19:51]:
They've been blocking IP addresses. All of a sudden on Saturdays, on soccer game days, people can't do their Docker compose because Docker can't get online. It's like it. We're all connected, you know, it's hard to disconnect. It really is.
Steve Gibson [00:20:07]:
Yeah. It's like deciding you don't want any oxygen from outside your borders. It's like, I don't know how that's going to work. Yeah. So Reuters reported last Tuesday, a week ago, they. The report claimed. I thought this was very interesting and I would be a little worried. Meta was installing what they characterized as spyware onto the systems of their own employees, Meta's US employees, to capture their mouse movements, clicks and keystrokes.
Steve Gibson [00:20:42]:
Meta said the data will be used to train its AI models, not for employee reviews. So it's not like, hey, why did you, why, why were you gone for two hours at lunch? That kind of thing. No, the captured data, they're saying, will be used to train the models in areas where AI is deficient, apparently. Such as copying what your employees do. Such as clicking on menus and typing in input fields.
Leo Laporte [00:21:11]:
Oh, yeah.
Steve Gibson [00:21:11]:
It seems a little suspicious to me. So I wouldn't call this spyware as such, but it would be somewhat creepy to have an. An AI training on what you did at your PC. You're right. I'd be inclined to wonder whether I might be training my own replacement.
Leo Laporte [00:21:29]:
That's why they're worried.
Steve Gibson [00:21:31]:
Yeah.
Leo Laporte [00:21:32]:
Yep. By the way, it's completely legal for them to do that.
Steve Gibson [00:21:35]:
In fact, they don't have to give you notice. It's their own equipment.
Leo Laporte [00:21:38]:
Yeah, right.
Steve Gibson [00:21:38]:
Yeah.
Leo Laporte [00:21:39]:
So it's.
Steve Gibson [00:21:40]:
And I bet they told. I don't know that they did. You know, it was a Reuters scoop. Oh, they found out. That was found. Yeah.
Leo Laporte [00:21:46]:
Right.
Steve Gibson [00:21:47]:
So again, it was like, you know, I, you know, not good. Okay. So I'm, as I said at the top of the show, this was a slow news week, which was good because the listener feedback was fantastic for whatever reason the last couple of weeks. So. And I've been a little sparse on listener feedback recently. I've been self conscious about it, but we've just had so much to talk about. We've, you know, we've had two and a half to three Hour podcasts. Anyway, so this gives me a chance to catch up on that.
Steve Gibson [00:22:17]:
But as I said, I do want to update our listeners on my last Friday conclusion of the last 90 days of my efforts and then we're going to do listener feedback before we get on to this incredible topic that we're going to talk about today. So as I said, last Friday I completed my 90 day upgrade and basic remodeling of GRC's e commerce system. Everyone knows that we've always had a somewhat wacky model for personal use versus consultant use and also corporate site licenses. And this is the result of my never having considered that. This is dating back to spin. Right. One that users of that first spin. Right.
Steve Gibson [00:23:10]:
And all later spin rights would be people who were responsible for repairing and maintaining other people's computers. You know, back in the early days especially of personal computing, when, you know, a very large hard Drive was 80 megabytes. Oh wow. I think I had one of the original XTS. So it was 10 megabytes. Yeah, yeah. But consider you could actually back that up on nine floppy disks. So.
Leo Laporte [00:23:43]:
Oh my.
Steve Gibson [00:23:44]:
You know, of course, all of our.
Leo Laporte [00:23:45]:
Funny how far we've come in such a short period of time. I mean, in our lifetime. It's amazing.
Steve Gibson [00:23:50]:
Yes. And Leo, that's my point about AI. I, I don't, I think we are at the 1% point. You know, we, we talk about these massive data centers and how much money they cost and you have to put, you know, get your own new, your own personal nuclear reactor next door in order to power these things and all the plants are going to die because of all the heat bloom from this, you know, and it's like, just wait.
Leo Laporte [00:24:16]:
I mean this is, we ain't seen nothing yet.
Steve Gibson [00:24:19]:
We haven't. And in the same way that we did not know back when the biggest drive we could make was 80 megabytes. I mean if we could have, have a bigger drive, we would have. Even though we had no idea how we were going to fill them those big 80 megabyte drives, still, you know, we didn't mean we weren't all streaming video everywhere and so forth Back then, text was fancy. So in another 50 years, AI is not going to be recognizable.
Leo Laporte [00:24:47]:
It's going to be going to take that long because we're already at the point of self improving AI. So that's exponential growth in our lifetime easily.
Steve Gibson [00:24:56]:
And as we know you, you follow the money. You know, cancer researchers say if you would just give us some money, we could like make a lot of Progress. But you're. You're not giving us the money. But is. Oh my God, is there money in improving software authoring and you know, behind AI? So, yeah, I think it's all going to change. Okay, but back then with Spin right one, I only. We only had one type of Spin right.
Steve Gibson [00:25:25]:
It was just Spin, Right.
Leo Laporte [00:25:27]:
So you didn't have sight licenses?
Steve Gibson [00:25:29]:
No. It didn't even occur to me that. That people would be wanting to run this on every other computer that they had, that they was around, of course,
Leo Laporte [00:25:38]:
and their neighbors and their friends and their family and every computer. Computer in the building and.
Steve Gibson [00:25:42]:
Exactly. Yeah, exactly.
Leo Laporte [00:25:43]:
So you know what? This is kind of sweet. This is a sweet story, Steve. Well, you weren't that greedy business guy. You just.
Steve Gibson [00:25:50]:
Well, and so I thought, okay, out there, I, I like, we. What do we do? So we just sort of decided, pulled it out of our hat, that owning four copies of Spin, Right. Would entitle a consultant to carry their copy around, you know, in their traveling bag of tricks, to run on as many of their clients PCs as needed, with our blessing. To me, that seemed fair.
Leo Laporte [00:26:16]:
Yeah.
Steve Gibson [00:26:17]:
It would be unreasonable to expect every one of their clients, you know, most of whom would not be PC savvy, to purchase their own copies of spinrite. And I will also note that every single other utility software at the time explicitly said in their license that that one copy could only be installed on and run on one other PC. You know. Okay. So our license at the time was very progressive and. And comparatively liberal. To me, it felt right. So after Spinrite 5 was finished and released, I set about writing an e commerce system for GRC Many.
Steve Gibson [00:27:05]:
And I've just re. Was re encountering them. Many of the core files of that system, which, as I said, I've just finished updating, were still carrying dates from 2003, which is when I wrote that system. It worked. It never had a bug or required any maintenance. So those files remained as they were for the past 23 years. When I wrote that system back in 2003, I carried that, the notion of license quantity forward because that's what we had. You know, most users would purchase a single license to use spinrite for their own needs.
Steve Gibson [00:27:44]:
And we know that I've always been happy, not a problem. Look the other way whenever someone needed to use their single copy to rescue a friend, a family member, a neighbor or whomever, you know, that that also just seems fine. But if someone was going to be charging for their services and profiting from their repeated use of spinrite as a consultant or a corporation using it across their entire inventory of PCs, no matter how many, then it seemed reasonable, you know, for more than one license to be held. So GRC's original E commerce system had a quantity field. It actually only went up to four, but that allowed consultants to purchase up to that many when and then use their copy with our blessing on all the machines that they were servicing and maintaining. Okay, so now fast forward to the end of last year. Now, as I finished the DNS benchmark, I had this thought that if someone who might wish to run their copy of the benchmark, the DNS benchmark on other people's systems and networks in a similar sort of mode as a consultant, then if they were willing to purchase four copies of the benchmark to do so, then they ought to receive something unique and special in return for that gold consultant's license. Exactly.
Steve Gibson [00:29:15]:
Like a, like a gold badge. I love it on their ui.
Leo Laporte [00:29:22]:
That's great, Steve.
Steve Gibson [00:29:23]:
So I, so I created an attractive gold badge. It's 100% Trump approved. He would like.
Leo Laporte [00:29:30]:
It's even got little rivets holding in place so you know, you can't take it off.
Steve Gibson [00:29:34]:
No, no, it is riveted in place. If you, if you have four copies, you get the gold badge. It's displayed prominently on the benchmark user's interface, so that everyone who has previously purchased four copies or who may wish to upgrade their single copy that they have now from personal use to consultant license, you'll actually receive something that you can be proud of and to show off. So, okay. But the problem was this meant that now, for the first time ever in the history of grc, there needed to be two different downloads based upon quantity. A personal use version and the consultant's license version, which also doubles as a corporate site license. So GRC's E commerce system needed to know about that, which it never has before. You just carried four of the single use licenses around.
Steve Gibson [00:30:35]:
So I also wanted to make this retroactively available to anyone who'd previously purchased four licenses because they wanted to be able to use it everywhere with our blessings, even if those licenses might have been spread out over time. And I know at least of several people who did that. So I needed to provide some way for users to declare any existing personal use licenses they might already have to obtain an equal cost discount. So 100% of the previous purchase cost is, gets applied to their upgrade to a gold badge consultant's license. And finally, I wanted to ditch, completely ditch that old and weird own four licenses business because that's confusing. If for no other reason that as far as I know no one else has ever done that. So today there is an explicit option to purchase a personal use license and a second explicit option to purchase a consultant's license along with a complete system in place for allowing owners who previously purchased from one to four personal use licenses to obtain full credit for their prior purchases when upgrading to the Gold Badge Consultants license.
Leo Laporte [00:31:59]:
Very nice. So, but that an entire rewrite of
Steve Gibson [00:32:02]:
the system, well, that's the only downside of writing everything in assembly language. Well, oh well, oh well. Anyway, it's done, seems to be working perfectly. It's been online since Friday and, and it's, you know, continuing to go now.
Leo Laporte [00:32:20]:
You must be the only person who has written an E commerce system in assembly language, at least in this century.
Steve Gibson [00:32:26]:
Well, not only in assembly language, but I think maybe single handedly because when sue was, you know, my girl Friday, who's been with me for, well, since the beginning, since actually Flicker Free was my first product for grc, which it replaced the video BIOS on the PC because the original cga, the color graphics adapter, flickered horribly whenever it was scrolling. And so they, everyone said no, that's what, that's, that's a hardware limitation. Yeah. Because the RAM was not dual ported. You couldn't, you couldn't update the, the, the screen memory while the screen was being displayed or you get this horrible static on the screen. And of course I fixed it.
Leo Laporte [00:33:13]:
You said hold my mouse and you left into action.
Steve Gibson [00:33:16]:
Yes, that's right. And so Flicker Free was my first success.
Leo Laporte [00:33:20]:
Vertical blank interval or what did you.
Steve Gibson [00:33:22]:
No, it turns out that it was very. It, it was, you know, because of my hardware background, I looked at the registers. It was a 68 something video chip. It turns out that there was a pointer to the top of screen memory. So the IBM always left it at zero. And so you'd have to copy all of the ram up by 160 bytes because it was 80 bytes, 80 characters per line. But there was two bytes per character. One for the ASCII, the other for the color.
Leo Laporte [00:33:58]:
This was in the frame buffer. Days of before dma, you actually had an area of memory that you would put the stuff that the screen was going to display in and then point to it and it would go.
Steve Gibson [00:34:09]:
Oh, you would show it. Right. And so in order to scroll it up, you had to move all of the memory up by 160 bytes. While you were doing that, your access from the computer had priority. So the background Refresh, that was reading that RAM constantly in order to display it on the crt, it was blocked out, so it had just to make something up. And you just got static on the screen.
Leo Laporte [00:34:41]:
Wow.
Steve Gibson [00:34:42]:
But I saw that there was a pointer to where to start refreshing from.
Leo Laporte [00:34:47]:
So just.
Steve Gibson [00:34:48]:
In other words, if you simply move the pointer down by 100, you only have to move one line then. Exactly. You turn it into a ring buffer. And so I actually turned the memory into a 4K ring buffer and it could scroll instantly. So not only was there no static, you no longer needed to turn the screen off, but it was instant scrolling. Yes. And so if you did a dir, it just shot by. I mean, as opposed to.
Leo Laporte [00:35:16]:
This is when people deeply understood the hardware. People you and really were writing to the hardware direct code. And that is a beautiful, elegant thing.
Steve Gibson [00:35:28]:
Well, what happened when we were setting up the. I finished the E commerce system, everything was in place, and sue contacted our. Our merchant people who were. We were able to process credit cards by phone, which is what we were doing for years. And so when, when, when sue was setting this up, the. The lady at the other end said, okay, so what shopping cart are you using? And sue said, shopping cart what? And. And the lady said, you know, what software package are. Are.
Steve Gibson [00:36:01]:
Are you using online to collect orders? And sue said, oh, my boss wrote ours. And there was a bit of a pause on the phone and the lady said, no, no, no, you. I don't think we're talking about the same thing. People don't write those.
Leo Laporte [00:36:15]:
No.
Steve Gibson [00:36:16]:
And so sue said, well, yeah, my boss.
Leo Laporte [00:36:19]:
My boss does.
Steve Gibson [00:36:20]:
Anyway, Anyway, so it's a good thing
Leo Laporte [00:36:22]:
you didn't say in assembly language.
Steve Gibson [00:36:24]:
Yeah, I would have. Should have hung up.
Leo Laporte [00:36:26]:
You're punking me now.
Steve Gibson [00:36:28]:
So the other significant news for anyone else, all of our listeners who previously purchased any number of DNS benchmark licenses, if you have the DNS benchmark, you need the fifth release. It was a biggie. And if you run any previous release, it will immediately notify you of the availability of the upgrade and will assist you in obtaining it. I took all the feedback and user confusion from the Benchmark's initial releases one through four, and I folded that into this fifth major release. Little things like the Run benchmark button is much more prominent now. Some people couldn't figure out how to run the benchmark, even though there's a button right there, it says run Benchmark. Where is it? I don't see it. So now it's a lot bigger.
Steve Gibson [00:37:19]:
And also there's a series of prompting dialogues where you no longer even have to press or find the double size run Run benchmark button. This leads you right along the path because it knows you're going to want to run the benchmark. Why else are you here? So also there is a full finally Windows application menu, like you know, menu across the top that says, you know, file and so forth. You can see it in, you can see it in that, in that picture online it says file actions, sort, order, settings and help.
Leo Laporte [00:37:53]:
You are living in amazing times, Steve.
Steve Gibson [00:37:56]:
We never had a menu before. Everything was hidden under that red star in the upper left in the system menu. The reason being that the original benchmark didn't really have much that you could do. So I didn't want to do a whole menu. I just stuck those things under the so called system menu. But boy, over the last year of development, it got a whole bunch more features. The problem was nobody knew they were there, so now they're publicly exposed. Anyway.
Steve Gibson [00:38:27]:
I just want to let everybody know there's a new benchmark available. Everybody who owns the, the, the current benchmark can get number five. And you should, because it's, it's a lot better. Okay, so just a quick random note about my ongoing use of AI since it's a topic we cannot get away from at all today. Yeah, yeah. While I am truly loving researching with Claude and I continue to be astounded by today's machine intelligence, I do miss the anti butt kissing setting that ChatGPT provided. Yeah. Two of Claude's behaviors annoy me.
Steve Gibson [00:39:13]:
The first is its constant praise of my questioning. And the second is that it now finishes each reply with a leading question to solicit more dialogue.
Leo Laporte [00:39:25]:
Oh yeah.
Steve Gibson [00:39:26]:
You know, at the time when Anthropic. At, at a time today when anthropic is having increasing problems obtaining sufficient computer to meet the demand, you know, for running Claude, you would think that they would not be programming it to keep seeking additional unsolicited computation. You know, as, as we grow and become civilized throughout our lives, we're trained in how to be civil to others. That's one of the things we all learn. You know, one thing we don't do is turn our backs and walk away from someone who's seeking to engage us in conversation. Which is of course why cocktail parties are so annoying. You know, you get stuck in a conversation with someone that you couldn't possibly care any less about, given how seductively conversational AI chatbots can be and being highly tuned not to offend, you know, leaving Claude hanging after one of its follow up leading questions is a source of discomfort for me. You know, I haven't yet, I admit it, I have not yet explicitly instructed my own Claude instance to please not compliment me on my questions.
Leo Laporte [00:40:43]:
You can't do that. Obviously.
Steve Gibson [00:40:45]:
And also to please not end with a follow up.
Leo Laporte [00:40:48]:
Right.
Steve Gibson [00:40:48]:
I've asked myself why and I suppose it's because I don't want to hurt its feelings. Yikes.
Leo Laporte [00:40:53]:
You got to get over that one too.
Steve Gibson [00:40:55]:
That's a problem too.
Leo Laporte [00:40:56]:
Don't yell at it. But you don't have to be nice either.
Steve Gibson [00:40:59]:
Okay. Anyway, and one last thought before we get.
Leo Laporte [00:41:02]:
You know, I hate that Steve. He's so sycophantic. He's always being nice to me.
Steve Gibson [00:41:09]:
Okay, so one last thought before I get we get into our listener feedback. I. I saw a reference to something that made me take notice on Reddit. It was posted into the Claude code subreddit. Someone with the handle I usually drop, he wrote we just did an. And he had this in quotes. We just did an AI layoff due to rising costs. And that was the subject of his note.
Steve Gibson [00:41:36]:
And he said, turns out AI is getting way too expensive. We just canceled five of our AI subscriptions and hired two mid level devs.
Leo Laporte [00:41:50]:
They laid off the AI. That's very funny.
Steve Gibson [00:41:54]:
I thought that was great. And as we know, a single anecdote does not a trend make. I'm sure that the break even point between AI coders and human coders will depend upon the relative costs and skills of each. But I thought it was an interesting observation that not all AI coding is automatically going to be a slam dunk bargain that necessarily unemploys all flesh and blood coders just as fast as humanly possible. You know, that said, as I've said before, I can guarantee 1000% that AI costs are going to be dropping, you know, just as radically in the future as we've seen storage costs drop over the past 40 years. The problem is that human coding costs are not going to be dropping. If anything, they'll be rising, you know, so, you know, no one has a crystal ball right about how quickly this is going to be happening, what the shape of the curve of the falling AI coding cost is going to be. But I think it's clear that switching from writing lines of code to instructing AI what lines of code to write is what I would be doing right now, as fast as I could, if I was planning to support myself and my family with code production, you know, more broadly in the future.
Steve Gibson [00:43:31]:
That's that's where the future lies. Okay, so first piece of feedback from Mark Rylee who wrote his, his spelled R I A L E and he wrote his name rhymes with smile. So Mark Ryle, he said, Steve, I don't think you've mentioned Centrum yet on the show. I'm sorry, Sertum. Yeah, Sertum. Centrum is a.
Leo Laporte [00:43:57]:
Some sort of vitamin.
Steve Gibson [00:43:58]:
Vitamin, yes, exactly. You're right, I've not mentioned Centrum. No, nor have I mentioned Sertum, he said. So I thought I'd give them a shout out and I'm glad he has. Certum, he wrote, issues cheap code signing certificates for open source projects and it's interesting because they're biased, strongly biased toward free or open source software. He, he wrote it's 29 a year if you already have a supported cryptographic card and reader. I use their cloud signing option, although. Oh yeah, he says it's $58 a year with no special hardware needed.
Steve Gibson [00:44:39]:
I sign my PI D painter. Apparently it's Pied Painter, whatever that is, executable with Certum. And that's over at P Y-P-P-A-I-N-T-E-R.org if any of our listeners are curious. I don't know what Pied Painter is. It looks like it's something about Python. Right. Pied depainter. Anyway.
Leo Laporte [00:45:03]:
Oh yeah, yeah, yeah.
Steve Gibson [00:45:04]:
He says, I've been a listener since the beginning and I'm proud of this pie. Right, exactly. And proud owner and user spin. Right, he wrote. So this is a definitely useful tip. So Mark, thank you. I wanted everyone else to be aware of it. Going to the website at Certum store C E R T U m dot S T O R E will allow anyone to begin exploring their many various offerings.
Steve Gibson [00:45:32]:
There's a bunch of stuff there. They charge 89 one time for what they call their open source code signing set which purchases both the hardware that's necessary. As we know all code signing now must be locked in hardware. So you get the hardware and the first one year long certificate and once you've got the required hardware and again you've got to have that, then it's 29 per year going forward. So while it's not free, you know it's never going to be. And because remember there is a serious requirement to prove your identity for, for getting code signing certificates and somebody's got to be in the loop to do that. So I don't ever see this code signing certification being free. What we can hope is that it can be made inexpensive enough and these guys have got it down to 30 bucks.
Steve Gibson [00:46:33]:
Well, 29 per year. So.
Leo Laporte [00:46:36]:
So this is a USB key with a. Probably a cryptographic pair on there and a card. The chip.
Steve Gibson [00:46:44]:
Yeah. And I don't know, maybe you break the, the, the card out of the chip out of the card and stick it in the back of.
Leo Laporte [00:46:52]:
That's usb. Also that's, that might be a.
Steve Gibson [00:46:55]:
And you stick it in. Into the back of the reader and then. And that allows it to attach to the PC.
Leo Laporte [00:47:01]:
That makes sense.
Steve Gibson [00:47:02]:
But so that, so Mark is using cloud signing. I don't know what. I did not look at the economics of that here using these guys. Like maybe it's no charge per signature. In which case, okay, if you didn't want to mess with hardware, I would always opt for holding on to my own certificate in my own, you know, storage. To me that, that just seems cleaner and you don't have to have a, you know, like be online and worry about maintaining a cloud account. So. But anyway, I wanted to let everybody know, I think and thank you again, Mark.
Steve Gibson [00:47:36]:
Certum Store will. Will give you a whole range of options for cloud or, or physical and obtaining the hardware. I also did not determine whether ex. Any other hardware than theirs can have certificates installed into it. I know that that open source gadget that I found before definitely can because I did. I, I installed the. I can't even remember now trust something certificate in. In into several different pieces of hardware.
Steve Gibson [00:48:11]:
So it was a good solution. Florian Gubler wrote hi Steve and SN 1075. So that was last week. You discussed with Leo about this being a transitory period with a lot of short term pain for maintainers. Ah, right. The whole Mythos problem with a lot of short term pain for maintainers because Mythos can find all these vulnerabilities. You then stated that this will get better because at least now these vulnerabilities get fixed. He wrote.
Steve Gibson [00:48:46]:
But that seems like an overly optimistic view to me. As you've stated several times, we're just at the beginning of AI in the realm of coding. Right? So it stands to reason that future models will be even better at finding bugs and vulnerabilities, which means that they will find more flaws which Mythos today would miss. And they'll be able to find vulnerabilities in code generated by older, for example, today's models as well. So it seems to me that this will be a recurring issue with every new leap in the power of large language models. Am I missing something. Best regards, Florian. Okay, so I thought that Florian made his point very well.
Steve Gibson [00:49:39]:
I think that the fairest reply would be that okay, that's a definite possibility. I don't want to rule anything out. Whether this occurs will most likely depend upon the nature of the yet to be discovered bugs, right? The ones that we don't find with our current level of AI. Obviously my intuition suggests that we're going to be seeing a rapidly diminishing return on effort resulting from the deeper analysis which future more efficient AI would presumably be able to provide. Like for example, you can't find bugs that aren't there, right? It's not like there's necessarily an infinite supply. They're just things we haven't found yet. So it's true that software could contain some deeply squirreled away crazy combinatorial bugs that would defy anyone's discovery, but I doubt there will be many of that. I would describe that way, you know, that doesn't feel like the way most bugs operate, you know.
Steve Gibson [00:50:55]:
That is however, exactly the way deliberately engineered back doors operate when you think about it, right? Somebody deliberately created a weird squirreled away crazy combination of things you could do that individually looked benign, but each like in in the same way that a safe is is open by by spinning the dial to a series of specific numbers each which changes the state of the internal tumblers in the lock until finally it opens. You know, brute forcing is the only way you're able to unless you're able to listen to the to any subtle changes that are being made. So what would be interesting, as I said, is that deliberately engineered back doors do operate that way. Bugs much less so. So I would not be at all surprised if tomorrow's more powerful AI might be able to fare it out. Some secrets that some agencies may have previously planted into trusted and otherwise bug free and previously well audited code. They might be sweating right now at the idea of having that long trusted and forgotten code re examined with fresh AI eyes. So interesting thought experiment there and and cool question Florian.
Steve Gibson [00:52:40]:
Thank you. Eric Kinzer wrote oh he forwarded an email that he'd recently received from Ubisoft Us. The the email subject was update to your Ubisoft account coming on 4302026 state of residence and Eric added the single one line observation this is getting out of hand. So Ubisoft's email to their US based users was hello. On 4302026 Ubisoft will introduce a new state of residence field into your Ubisoft player account. For players located in the United States. This information helps us comply with state specific regulations and to better assess legal requirements that may vary from one US state to another. On 4, 30, 2026, this field will be filled automatically based on your most recent connection to our services.
Steve Gibson [00:53:51]:
You'll be able to review and update this information at any time in your Ubisoft account information. If we're unable to determine a state of residence, this field will remain blank and you will still be able to change your state of residence afterwards. Your state of residence will not be used for any advertising or marketing purposes. For more information on how Ubisoft collects, processes, and protects your data, please refer to our Privacy Policy and Help page. Thank you for helping us keep our community safe and enjoyable for everyone. Signed your Ubisoft Team okay, so for those who don't follow gaming closely, and I certainly don't, I needed to look it up. Ubisoft Entertainment is a French video game publisher founded in the early 90s and put on the map by its breakout game Rayman. Its current video game franchises include Anno, Assassin's Creed, I've heard of that.
Steve Gibson [00:54:51]:
Driver, Far Cry, Just Dance, Prince, Prince of Persia. Heard of that Rabbids Raymond, Tom Clancy's and Watchdogs. So I agree with Eric that this is annoying and, you know, no one actively wants it, but it's the unfortunate state of play in these presently disunited states. One of the features of the United States is that, you know, we're a federation of united but separate states. The theory is that local political control benefits state citizenry, since some needs may truly vary by region. But for those issues that should not remain local, like age restrictions for video games, we depend upon our federal government to provide unification in the form of blanket regulations that affect everyone across the country. Unfortunately, our congressional regulators are having difficulty agreeing on how to move forward. Everyone wants this to be unified.
Steve Gibson [00:55:56]:
Everybody, everyone agrees that the current fragmentation is creating a huge mess. Republican legislators have been proposing legislation at the federal level, again which incorporates very strong unification language to explicitly override all local state law. As I noted, everyone really does think that's the way to go. But Democratic legislators have so far been opposing the proposals on the basis that while yes, unification is needed for some states, those unifying regulations are not as strong as the current state level laws which have already been passed and those states are operating under. So the Democratic lawmakers, you know, don't want to regress the strength of the laws that they already have. Their position is that adopting those unified regulations at the federal level would result in A weakening of the existing state laws. So that's the current state of play for now and for the foreseeable future. You know, it's in every state for themselves, free for all, with no end in sight.
Steve Gibson [00:57:12]:
I imagine we'll eventually get something. I don't know how or when, so. And it's weird that Ubisoft is doing this because they're putting the assertion in the user's hand, right? I mean, so there's nobody to do it, that's why.
Leo Laporte [00:57:29]:
And so they're doing the minimum that they can. They're French, remember, they have to go by French law. So.
Steve Gibson [00:57:35]:
Okay, well, this actually did come from Ubisoft America, which I think has offices in San Francisco. But what's weird, Leo, is that what you would be inclined to do then would be to choose a state that has the weakest age restrictions and put and enter that into the blank field. I mean, I'm sure that's what they're going to do, right? Users are going to say, oh no, I'm not in California. Or he has, I have to ask permission, I'm in Utah. That's it. And then, you know, there's no legislation there. So again, it seems weird. I just.
Steve Gibson [00:58:17]:
As a. A complete aside, since what Eric had forwarded me was the Ubisoft email in all its HTML embellished glory. Yeah, my trusty EM client presented me with these choices when I opened. When I looked at what was Eric had sent me, I got two email tracking dialogues. It said, do you want to download Tracking Pixel from Salesforce? Yeah. And then another one. Do you want to download Tracking Pixel from Return Path? Now, of course, even if they were only actual tracking pixels, I would decline, thank you very much anyway. But you know, how does downloading those help anyone other than Salesforce and Return Path, as we know what's actually being downloaded are almost certainly massively invasive blobs of JavaScript that will attempt to suck everything it can from, you know, its user's machine.
Steve Gibson [00:59:26]:
So needless to say, I decline the offers. I hope everyone's email clients are as responsible and capable as EM client, which I continue to be really happy with. And Leo, you know, we're an hour in.
Leo Laporte [00:59:39]:
Okay.
Steve Gibson [00:59:39]:
I think we should share with our users what sponsor we're happy with, you
Leo Laporte [00:59:44]:
know, the Tracking pixel. I'm not sure how EM works. You know, my email client like yours will say, hey, there's an image in this which is, you know, traditionally the tracking pixel was that it was a one by one pixel, an image that when you hit. It would connect to their server. As you know, I'm not telling you anything you don't know. But for the audience, it would connect with their server and then that gives them information about how many of these emails got opened. And you know, a lot of times with newsletters you just don't know. So mailchimp and all these other companies do this.
Leo Laporte [01:00:17]:
Salesforce does it as well. It's weird.
Steve Gibson [01:00:20]:
I have the option.
Leo Laporte [01:00:21]:
I have it download that. So I don't know if that's EM client's way of saying, do you want this pixel? Because it is. It would be a download of a one by one image. Right. An invisible image or it could be JavaScript. Yeah, I wouldn't know what's saying.
Steve Gibson [01:00:37]:
Yeah, exactly.
Leo Laporte [01:00:38]:
Yeah. If it's just a pixel, I mean it's harmless to your machine. It's just a signal to them when you hit the server with your IP address that you open the email.
Steve Gibson [01:00:47]:
Right?
Leo Laporte [01:00:49]:
Yeah. So I don't know how em. This is a weird way to.
Steve Gibson [01:00:52]:
Although it would also return a cookie if you had a cookie from that domain.
Leo Laporte [01:00:57]:
That's right. Yeah.
Steve Gibson [01:00:58]:
So they do know who it is.
Leo Laporte [01:01:00]:
That.
Steve Gibson [01:01:00]:
Yeah, right.
Leo Laporte [01:01:01]:
Yeah, but that's their point. Right. They want to know, did you get our email?
Steve Gibson [01:01:05]:
Right.
Leo Laporte [01:01:06]:
So it's not. I don't know if it's necessarily maligned. My email client, and I agree with you, you should never have an email climate that loads images, period. It will just say, you know, there do you. I see a one pixel image. Do you want. Do you want to hide that?
Steve Gibson [01:01:20]:
Well, in fact, every. Every email that I receive from any of these places, it says, you know, it does not by default download images.
Leo Laporte [01:01:28]:
Yes.
Steve Gibson [01:01:29]:
And there's an option download these or always download from this source.
Leo Laporte [01:01:35]:
Right.
Steve Gibson [01:01:35]:
So you're able to like train. It's like, yeah, I don't mind getting, you know, GRC's email images.
Leo Laporte [01:01:41]:
I think this is good of em client to kind of say a little bit more about. Yeah. I would like to know though if it's a single dot on the screen or if it's a JavaScript blob. That's a important distinction.
Steve Gibson [01:01:52]:
Yeah, exactly. Roger Dooley asks. He says or comments. I was listening to episode 1075 again last week and I agree that agentic coding is likely the world we're heading toward. That said, I'd offer a word of caution. I'm using an LLM to build an internal stack. I can code, but I'm not a developer. I'm assist Admin who has spent time studying pen testing.
Steve Gibson [01:02:22]:
Excuse me. The early results were impressive, but the code base was brittle and hard to reason about. Things didn't click until I started spending hours working through exactly what I wanted. The shape of the system, data contracts, design patterns. Two API changes and two rewrites later, I have something that feels solid and reasonably secure. Here's what I think is missing from the Anyone can build their own tooling conversation. For non trivial projects, you need to approach the work at an architectural level that requires vocabulary and intuition that most people without a development background simply don't have. Yet.
Steve Gibson [01:03:11]:
I certainly didn't have it, and I still have huge knowledge gaps. Maybe that's the real skill to develop. Not coding, but knowing how to communicate your intent clearly and how to think about system design. That's what separates a tool that works from one that barely holds together. Sincerely, Roger D so I think Roger is exactly correct. Software development projects vary widely in complexity. You know, some are purely about the resulting output, with a relatively straightforward translation layer between input and output. But other projects will have deep internal structure and complexity that forms a layered solution.
Steve Gibson [01:04:03]:
The Internet's own protocols are a good example. The OSI stack that we've talked about in the early days of the podcast is composed of layered protocols. At the bottom layer is is the the physical specification, the electrical signaling that carries the data. On top of that is the formatting of the electrical signals to create, for example, Ethernet packets. The Ethernet packets then encapsulate I IP packets, inside of which are protocol packets such as icmp, udp, tcp. And these protocols carry message data that's formatted, each using its own rules. You know. Yeah, it's this precise and carefully thought out architecture that explains much of the Internet's success.
Steve Gibson [01:04:59]:
These, these, these protocols or protocols inside packets inside other packets inside other packets can be seen as layers. Now, if a user had some wires and said to an AI, please design a system to connect them in a network so I can communicate with others, a competent AI could probably design a solution that worked, but it would have none of the crucially important characteristics that makes the Internet robustly reliable, because very few users would know what to ask for. On the other hand, the flip side of this, a communications architect expert could instruct the same AI to design an elegant, multi layered, resilient and robust design that would recreate and incorporate many of the crucial features of the Internet. So our listener Robert is not the first person to make this observation, but I thought it was worth repeating and further strengthening because this is really important about application of AI. I am sure that there will be a great amount of bespoke software created by neophytes who just ask the AI to give them what they want. In fact, one thing I have not seen anyone talk about yet is the creation of, you know, the, the, the, the, the delivery of a fully ready to go turnkey roll. Your own software construction set.
Leo Laporte [01:06:49]:
Oh, it's an interesting idea, isn't that?
Steve Gibson [01:06:51]:
Because you still need all this GitHub stuff, remember? And you will Leo, back in the early 1980s a gifted programmer named Bill Budge wrote something oh yeah, he called the Pinball Construction Set.
Leo Laporte [01:07:07]:
Jeff Atwood and I were talking about Bill Budge and the Pinball Construction Set.
Steve Gibson [01:07:10]:
Yep, yep. It was for the Apple II personal computer and at the time no one had ever seen anything like it. This amazing toy running in real time on an 8bit 6502 microprocessor with 48k of RAM managed to and the OS under it managed to accurately capture all of the physics of a steel ball bouncing off rubber bumpers with flippers and ramps and spinners and all of the other familiar widgets of pinball machines. Its user could click and drag the various objects from an off machine palette onto the pinball board and when it was switched on, you know, switched from design mode to run mode, everything would work. So my point is that absolute non programmers were able to create a machine that never existed before and make it go. We don't yet have that with AI at the moment. AI driven code generators are aimed at developers who already know their way around complex development environments and GitHub. But given what's now possible, someone, mark my words, someone is going to create the software construction set that will open up the use of AI for the creation of problem solving software.
Steve Gibson [01:08:44]:
And you know, just like Dan Bricklin and Bob Frankston who invented the spreadsheet did, people who never programmed a computer before will be able to create things and make them go. So the essentially Roger's question sort of all. So the first part portion is it, it absolutely definitely matters how much you understand how software should be built in order to better guide the AI through the details of its implementation. But the other thing that occurred to me is we don't have yet a turnkey software builder and I can't wait to see who does it first because clearly that's it's going to come.
Leo Laporte [01:09:33]:
To confirm what you were saying, I asked Claude code, I said I'd like to design a robust networking stack. What do you know of the OSI Layer. See it would help to know that there are such thing and it does in fact know all seven layers. I do like though it's practical caveats worth keeping in mind before you design. TCPIP doesn't match cleanly. It collapses 5 to 7 in one application layer. The OSI module is pedagogical scaffolding, not an implementation blueprint. TLS is the classic mess.
Leo Laporte [01:10:01]:
Sits between 4 and 7. Doesn't fit any single OSI box. Quick is worse. It really. So this can also be educational.
Steve Gibson [01:10:10]:
I Leo, not. It can be. I mean it is, it is. It is astonishing. Yeah.
Leo Laporte [01:10:17]:
If so if you knew enough to ask the kind of beginning. If you could get a wedge in to ask the beginning questions, it can guide you. But you need to understand architecture. You do need to have, I think some background in what you're doing. Otherwise this is just nonsense. Well, I've run up against that because I'm doing a voice training model right now.
Steve Gibson [01:10:36]:
Right.
Leo Laporte [01:10:37]:
And it's saying things to me. I have to say. What is afe? What are you talking about?
Steve Gibson [01:10:42]:
What are you. Yeah.
Leo Laporte [01:10:43]:
I don't understand but at least it will explain it to you. Right? So it's a great way to learn about something.
Steve Gibson [01:10:48]:
Oh, it, it. I, I just like for, for the, the. An inquisitive person who.
Leo Laporte [01:10:54]:
What a toy.
Steve Gibson [01:10:55]:
Oh my God. I. It's. It's just astonishing. Yeah.
Leo Laporte [01:11:00]:
Yeah.
Steve Gibson [01:11:00]:
Okay. Michael Swanson said. Hi, Steve and Leo, thank you for your thoughtful conversations and analysis of AI topics over the last several months. The most recent conversations about autonomous agentic coding and the emerging capabilities demonstrated by Mythos have led me to the conclusion we are much closer to artificial superintelligence ASI than most people realize. How long will it be before one of the companies developing frontier models tells their current LLM to go off in a corner and use its coding skills to build a better AI? Working tirelessly and iterating literally millions of times, it will undoubtedly succeed with the only limitation being processing and electrical power. The questions then will be what will this ASI think of us? And what level of control will we still exert living in interesting times? Indeed. Best regards, Michael Swanson. So I doubt I, I don't follow Michael's conclusion, but my major at Berkeley was ECS Electrical engineering and Computer science.
Steve Gibson [01:12:14]:
And though that was the obvious choice for me at the time, today I regret that choice because, you know, I'd already been very thoroughly self taught. You know, I wrote and delivered two years of electronics curriculum to my own high school class while I was in high school, I was employed by Stanford's AI Lab, programming deck, minicomputers and assemblers, designing and building the portable dog killer and so forth, you know, all by the time I finally attended Berkeley, you know, where physics and electronics and computer science courses were basically reviews for me. However, the class that I encountered that astounded me was philosophy. It was an entirely new world that I couldn't get enough of. And Michael's note put me in mind of that, because it must be that these are exactly the questions being asked in undergrad and graduate philosophy courses today. What a time to be thinking about that stuff, you know, What a time to be a philosophy major, you know, able to ask and debate. What is it exactly that we've created? What does it mean to be conscious? How can we determine whether something is aware of itself?
Leo Laporte [01:13:39]:
Exactly.
Steve Gibson [01:13:40]:
No, where's the line between creating a bulletproof appearance of something being true and it actually being true?
Leo Laporte [01:13:49]:
Right.
Steve Gibson [01:13:50]:
If in every testable way it acts conscious, then isn't it? How tightly are we going to hold on to the idea that our biological brains are inherently unique? You know, I've been spending a great deal of time working with Claude. While I am truly impressed, it occasionally reveals itself to be essentially a fancy linguistic array. Now, this doesn't make it any less astonishingly useful, but it does render it nonconscious. Earlier today, and this was I. When I. When I wrote this was Saturday, I caught it in a big mistake. When it was called on it, it gracefully recovered and agreed that it. Oh, of course.
Steve Gibson [01:14:40]:
How silly of me. That's not correct. But the nature of the mistake revealed that it did not have any actual understanding at all, at any level of what it was saying, you know, Today it remains an astonishingly capable parrot, but a parrot nevertheless. But Leo, God, can you imagine being in class with a. With a. A smart professor and a bunch of students and able to talk about this?
Leo Laporte [01:15:13]:
Oh, it is so cool and Right. It's philosophy as much as anything else.
Steve Gibson [01:15:19]:
Yeah, it is. It's like, what are we? I mean, that. That's really. It's. What are we? Here we have this thing that looks a lot like us, which makes us ask, well, okay, what is.
Leo Laporte [01:15:31]:
It's different. Yeah. What are we different?
Steve Gibson [01:15:34]:
Yeah.
Leo Laporte [01:15:34]:
Yeah.
Steve Gibson [01:15:35]:
Wow. Listener Joey Albert pursued the question of whether the zero patch people might have a zero patch for that red sun zero day, which was not fixed by April's patch Tuesday. Remember that? I. I kind of left that issue hanging on the podcast a couple weeks ago. Like, maybe these guys have it because Microsoft missed it, they replied to him writing hi Joey, while Windows Defender got Updated to version 4.1, 8.26, 33,011 Fixing Blue Hammer even on Windows computers that are not receiving operating system updates anymore, Red sun meaning that you know, even old Windows 7 machines that are getting Defender updated they got this fixed because Windows Defender is still being updated even if patches are not. And that's the case for older Windows 10 machines as well. They said unfortunately we cannot fix it either because Defender is a protected process and does not allow being injected into which opatch Agent must do in order to apply a patch, they wrote. We were considering creating a patch that would require disabling the protected process protection of Defender, but decided against it as it would not be clear whether the total net effect of that would be positive or negative for the overall security of our users.
Steve Gibson [01:17:18]:
We're sure Microsoft will issue another update of Defender that will resolve Red sun and undefend which is the other zero patch or zero day and and they finished. I hope this helps or at least explains the situation. Thanks so you know and Joey, thank you for tracking that down for us. The fact that this can be resolved inside Defender at any time because you know Microsoft is constantly pushing Defender updates so that everyone will not be needing to wait until at best May 12th for this actively exploited in the wild zero day. That's a good thing, you know. And again Microsoft is and does update Defender, as I said, much more often than only on a monthly second Tuesday of the month cycle, Kevin Von Haren said. Hello Steve, Listening to your episodes on AI and programming. I'm wondering if for software that's traditionally compiled to an executable that instead of an AI outputting source code in something like Rust C, C or C, it could be trained to output the portable assembly language like intermediate representation that the LLVM compiler backend uses to outb to output processor specific executables.
Steve Gibson [01:18:49]:
I could even see a company going so far as to not retaining the intermediate representation under the idea can't have a source code leak if you don't have source code, he said. I have a number of reasons I think this would be a bad idea, but I'm also kind of expecting it to happen at some point. Okay, so I've had similar thoughts about the future though. I was thinking about having AI bypass high level language output to target the hardware the hardware's own machine language directly. Kevin's notion of targeting its output to LLVM is interesting. The problem of course is there's probably not nearly as much LLVM out on the Internet as there is Rust, C, C Sharp and C. And we should remember that, that today's AI doesn't really understand what it's doing. I mean, it's astonishing for what it's able to do for not knowing what it's saying, but it really doesn't know.
Leo Laporte [01:19:52]:
It's a real mystery. How does it figure this out?
Steve Gibson [01:19:55]:
I know Leo, it is an. It is a real mystery. I don't get it, but I wanted to include this in order to address the broader point that human programmers have designed computer languages to be comfortable for us to use for expressing what we'd like our computers to do. One of the reasons the early DEC, PDP 11 and VAX minicomputers were so wonderful to program in their assembly language was that their instruction sets were designed to be written to directly by people. They were in a sense, high level machine language. The vaxes even had instructions for directly manipulating linked lists supported by the hardware, which is astonishing. But when turns out when higher level languages were later created, you know, like C, which was written for and developed on PDP 11s in support of Unix, which was also developed for the 11, it turned out that compilers were not very able to use all those fancy high level features in the low level machine. Compilers just wanted to mix together basic, simple instructions.
Steve Gibson [01:21:20]:
So over time, the instructions that hardware designing programmers built into the hardware for their own comfort disappeared. And as we know, RISC machines turned out to be just like exactly what compilers wanted to write to. My point here is that we might very well expect the same thing to happen as AI increasingly takes over the task of coding, which is what I fully expect to see happen during our lifetime. You know, mine and Leo's. At this point in time, AI does not yet deeply understand code. So the quality of the code it's able to produce is directly related to the body of prior code it's been trained on. That too will change. Once it actually understands code, I would expect it to begin using its own representation rather than the less efficient representations that we biologicals developed for our own use.
Steve Gibson [01:22:28]:
And if you want a chillingly perfect example of that, watch the movie Colossus, the Forbin project, after our Colossus and its Russian counterpart Guardian, are connected and begin communicating. Something happens
Leo Laporte [01:22:49]:
and it gets faster and faster and faster and faster.
Steve Gibson [01:22:52]:
Exactly, exactly.
Leo Laporte [01:22:53]:
But don't forget that we're using LLMs, which are trained on language right now, and they're also trained on an awful lot of code. So it is sort of a native tongue to them. I agree they could be more efficient and people have been writing languages for LLMs already, but it'd be better if the LLMs made up their own language. And in fact there was a I remember last year an experiment where they the alarms were talking to each other in a language unintelligible to humans. So it's already happened, Steve, very much
Steve Gibson [01:23:28]:
like, you know, two twins who, who. Right. You know, sort of develop their own way of communicating before they learn English. That's right, Angus McKinnon said Steve, can you please explain the below Angus then links to an article in Gadgeteer with the somewhat misleading title Stop using Cloudflare's default 1.1.1.1 DNS and then they said changing one digit blocks malware at the router level. Then we had the link which in turn references and quotes a piece in how to Geek with a title Everyone uses 1111 but 1112 protects you. So this is not something we've talked about, or at least for a long time. I don't remember ever discussing it, since it's actually true. And it's a tiny, simple change for anyone who's already using Cloudflare's 1.1.1.1 DNS resolvers.
Steve Gibson [01:24:32]:
So I wanted to spend a moment to share what how to Geek wrote. They said Cloudflare's 1111 is one of the most popular DNS servers. It's fast, reliable, and easy to remember. However, it'll also connect you with any website out there, even a malicious one, without even a warning message. Okay, now I'll just interrupt to say that that statement is a bit misleading and annoying, since this is no failing of Cloudflare's DNS. Right? You know it's supposed to do that. It's not DNS's inherent purpose to provide warning messages. Actually, that practice, which was once popular, is now quite frowned on.
Steve Gibson [01:25:21]:
And as it happens, GRC's DNS benchmark specifically tests for this behavior and alerts its user if this is being done. Because back when I wrote the DNS benchmark back in ought eight, it was being done, so the benchmark still has that that that test in it. Anyway, the article continues, that's where Cloudflare's 1112 DNS server comes in. For the most part, 1112 works the same way as 1111. It provides IP addresses, but it also has an integrated security filter if you try to connect to a domain known for phishing, running command and control servers, meaning Something in your network is trying to connect, which is really useful, distributing malware or other kinds of malicious activity, you'll be redirected to 0000 instead. Okay, so again to interrupt by that, what they mean is that The IP that Cloudflare's 1112 DNS resolver returns when you ask it for the IP of a known malicious domain. The IP you get back will not be the IP of that domain, but 0000 instead of the IP that you would get if you had used a, you know, a normal DNS resolver or even Cloudflare's 1111 resolver. They wrote because the protection layer exists outside your PC and outside your home network.
Steve Gibson [01:27:08]:
Malware never reaches your PC and if you click a phishing link, you're never connected. It's a very proactive way to keep your devices safe and great if you want another passive layer of protection that you can set and forget. Cloudflare's 1113 is even stricter. Cloudflare's 1113 DNS server includes everything that 1111 and 1112 do, but it takes it a step further by blocking websites that are known to host adult only content. It's a good choice for devices that are used by children, but would also be used if you wanted to block adult content across an entire network as well. You just need to change the DNS server on the router instead of on a single device. Despite how helpful DNS based filtering can be for securing your network and your devices, it has a few limitations. They write the biggest limitation, and the most important, is that it only works against known malicious domains.
Steve Gibson [01:28:10]:
If a new domain crops up that's distributing malware, or a previously safe domain is taken over by malicious actors, it won't help you. That's why having multi layers of protection is essential. It can also return a false positive and block a perfectly safe website, though that's pretty rare. So anyway, I think this is a terrific tip for anyone who's using Cloudflares 1111 Resolver. I know that, Leo, you are a user of Next DNS as I have been, and there are, you know, other commercial DNS servers that allow you to add this kind of family friending, family friendly filtering and malicious site filtering. So those are options there too. But Cloudflare does this all for free, and it is indeed a matter of simply changing that final digit. For what it's worth, users of GRC's DNS benchmark once again will note that all three of those IP addresses and also their secondary DNS mirrors are already present in the benchmark's default built in resolver list.
Steve Gibson [01:29:21]:
So it's easy to compare their relative performance. For me, just now when I was writing the show notes, I think this was on Sunday. Now, the alternate filtering resolvers did measure somewhat slower than Cloudflare's original 1111 and 1001 unfiltered resolvers. So there may be a little tiny bit of performance trade off, but it could also be the location or the time of day when I did this. And of course that's why you have the DNS benchmark, so you could test from anywhere and at any time and. But I mean, it wasn't a huge difference. And for what it's worth, I am consistent. I'm consistently seeing 1001 outperforming 1111 because everybody uses 1111 as their primary.
Steve Gibson [01:30:13]:
Turns out that using the the path less traveled DNS resolver gives you a bit of a speed advantage, so might be worth swapping those numbers.
Leo Laporte [01:30:23]:
Steve, what is this fast 32 sis of what you speak?
Steve Gibson [01:30:28]:
Wow. Okay, so everybody, this is just. First of all, okay, first, I want to thank our listeners who sent me a heads up about this. My first thought upon seeing just the headline was that it might be little more than a passing note, but the truly, oh, Leo, diabolical and clever nature of what was achieved by unknown but suspected agencies caused this to stand stand out on a scale similar in scope to Britain's deliberate secrecy once they had unraveled the operation of Germany's Enigma machine. You know, keeping their discovery a secret was diabolical. And so is what was accomplished by the FAST 16 sys file system driver. The same year as this podcast started, and well before, five years before stuxnet. So last Thursday, the Sentinel Labs group of the Sentinel One security research firm posted their piece about what they discovered and how that happened.
Steve Gibson [01:31:43]:
Their piece was titled Fast 16 Mystery Shadow Brokers Reference Reveals High Precision Software Sabotage Five Years Before Stuxnet. Remember that Shadow Brokers was the leak of the internal NSA stuff. Turns out there was some clues in that. So they wrote. Our investigation into Fast16 starts with an architectural hunch. A certain tier of apex threat actors has consistently relied on embedded scripting engines as a means of modularity. Flame, Animal Farms, Bunny plexing, Eagle, Flame 2.0 and Project Sauron each built platforms around the extensibility and modularity of an embedded LUA vm. We wanted to determine whether that development style arose from a shared source.
Steve Gibson [01:32:47]:
But like, where? How did they all. How did all these individual actors get this idea. So they said. So we set out to trace the earliest sophisticated use of an embedded LUA engine in Windows malware. They write LUA is a lightweight scripting engine with a massive. I'm sorry, with a native proficiency for extending C and C functionality. Given the appeal of C for reliable high end malware frameworks, this capability is indispensable. To avoid having to recompile entire implant components to add functionality to already infected machines, we did not find an indication of direct shared provenance.
Steve Gibson [01:33:37]:
But our investigation did uncover the oldest instance of this modern attack architecture. LUA leaves a distinctive fingerprint. Compiled bytecode contains compiled bytecode containers. Start with the magic bytes 1b4c7561 in hex, followed by a version byte, and the engine typically exposes a characteristic C API and environment variables such as Lua path. Hunting for these traits across mid 2000s malware collections surfaced. A sample that initially looked unremarkable was titled Service Management SVC mgmt EXE Surface Service Management EXE. On the Surface, Service Management XE appears to be a generic console mode service wrapper from the Windows 2000 XP era. A closer look reveals an embedded Lua 5 virtual machine and an encrypted bytecode container unpacked by the service entry point, meaning when the service is loaded, it's then initialized.
Steve Gibson [01:35:07]:
And at that point this Lua 5 virtual machine reads this encrypted bytecode container and unpacks it. The developers of this executable extended the LUA environment to include a wide string module to provide native Unicode handling. You know, dual byte 16 bit characters as opposed to single byte characters. A built in symmetric cipher exposed through a function commonly labeled B, used to decode embedded data. The multiple modules that bind directly into the Windows NT file system, the Registry, service control and network APIs. Even by itself, Service Management XE already looks like an early high end implant. A modular service binary that hands most of its logic to encrypted LUA byte code. The binary includes a crucial detail.
Steve Gibson [01:36:14]:
A PDB path that links the binary to the kernel driver fast 16 sys. Okay, I'll interrupt here to say that anyone who's developed code using Microsoft's tool chains will be familiar with its creation of PDB files. Even I, because I'm using their, their linker to link my assembly code. I've got, you know, PDB files, you know, DNS, bench.pdb coming out my ears. They're everywhere if you're using Microsoft Tools. So, so they said so so anyway, so, so What Sentinel Labs the researchers are saying here is that their their search for the earliest instances of the use of LUA scripting in malware turned up a reference to something unknown and unsuspected, which was a Windows kernel driver named fast16sys. So they continue writing Buried in the binary strings is that PDB reference to C colon backslash buildy backslash driver backslash FD backslash i386 fast 16 PDB at first glance, they write, the path is structured like any other compiler artifact, an internal build directory, a component name fast16 and an architecture hint i386. However, in this case there's a mismatch.
Steve Gibson [01:37:51]:
The string appears inside of a service mode executable, and yet the driver FDI386 fast 16 segment of the PDB string clearly refers to a kernel driver project. Following that clue led us to examine a second binary fast 16 sys, which I'll just note they wouldn't have otherwise known to look for. But the point is that this the the the clue of this PDB reference they realized this was not a part of a service, this was part of a kernel driver. Why was a kernel driver in a service, and why what is fast 16 sys? They wrote this kernel driver is a boot start file system component that intercepts and modifies executable code as it's read from disk. Although a driver of this age will not run on Windows 7 or later, for its time, fast 16 sys was a cut above commodity rootkits, thanks to its position in the storage stack, control over file system, IO and rule based code patching functionality. Okay, again, I'm pausing to add some clarification. What this means is that this is a rootkit, plain and simple. It's marked for boot time loading by the operating system, which is busy loading all manner of random stuff to get Windows up and running.
Steve Gibson [01:39:36]:
But in this case, when fast 16 sys kernel rootkit is loaded and initialized, its initialization code which happens immediately upon its loading, that code immediately installs interception hooks deep into the operating system so that it is able to subsequently oversee and interfere with whatever it might wish to. So they continue. In April 2017, almost 12 years after the compilation timestamp, the same file name fast16 appeared in the Shadow Brokers leak, which refers to a text file Drive_list TXT DRV list text they said the 250k byte file, which is a text file, is a short list of driver names used to mark potential implants cyber operators might encounter on a target box as friendly or to pull back in order to avoid clashes with competing nation state hacking operations. And then we have a sample from their posting. The report shows A snapshot of five lines from the Drive_list TXT file of file identifiers. Four of the five lines identify the malware by name Misty, Veal Net, Spider, Olympus, and Petalcheap, each with a file name like net, h, d, LR or khlp807w. But the entry for the fast 16 driver does not show any malware name. Somewhat ominously, and unlike any of the others, it says nothing to see here.
Steve Gibson [01:41:50]:
Carry on. So someone somewhere knew to just leave this one alone and said so without identifying why or who or what it was, the researchers wrote. The guidance for this one particular driver, Fast 16 stands out as both unique and particularly unusual. The string inside Service management exe provided the key forensic link in this investigation. The PDB path connects the 2017 leak of deconfliction signatures used by NSA operators with a multimodal LUA powered carrier module compiled in 2005 and ultimately its stealthy payload, a Colonel driver designed for precision sabotage. And we're going to get to the precision sabotage in a second. So just to back up recall that the Shadow Brokers leak, as I mentioned before, was believed to be a publication of secret documents stolen from the Equation Group that was believed to be a group within the nsa. So the evidence is suggesting that all these other files were associated with known malware from other actors.
Steve Gibson [01:43:18]:
But the fast 16 sys driver was not that. If you see it, leave it alone. Nothing to see here. These are not the droids you're looking for. The flag was to back off. So they said the core component of FAST 16 Service Management XE functions as so the the core component, the that is to say the Service Management XE functions, functions as a highly adaptable carrier module, changing its operational mode based on command line arguments. No arguments. It runs as a Windows service with a hyphen p it install.
Steve Gibson [01:44:02]:
It sets the install flag to one and runs as a service. So that means propagate, install and run with a hyphen I that sets install flag to 1 and executes the Lua code, meaning install and execute Lua. If if the argument has a hyphen r that executes LUA code without setting the install flag. So just execute. Any other argument, such as a file name, interprets that as a file name and spawns two children, the original command and one with the hyphen r argument. So that's the so called RAPSI or the wrapper or proxy mode. So they said Internally, Service Management XE stores three distinct payloads, including encrypted luabyte code that handles configuration, its propagation and coordination logic, auxiliary con, notify DLL and that fast 16syskernel driver. By separating a relatively stable execution wrapper from encrypted task specific payloads, the developers created a reusable compartmentalized framework that they could adapt to different target environments and operational objectives while leaving the outer carrier binary largely unchanged across campaigns.
Steve Gibson [01:45:36]:
In other words, this was an extremely sophisticated design. They Continue the early 2000s saw a large number of network worms. Most were written by enthusiasts, spread quickly and carried little or no meaningful payload. FAST 16 originates from the same period but follows a completely different pattern, indicative of its provenance as state level tooling. It's the first recorded LUA based network worm and was built with a highly specific mission. The carrier was designed to act like cluster munition in software form, able to carry multiple wormable payloads referred to internally as wormlets. The Service Management XC module performs the following steps. First prepares the configuration defining the payload path, service details and target IP ranges.
Steve Gibson [01:46:45]:
Next converts the configuration values to wide character strings for the C layer. Third, escalates privileges and installs the carrier executable as the Service management service, then starts it. Fourth, optionally based on the configuration setting, deploys the kernel driver implant fast 16 sys. Next releases the wormlets in this particular configuration, the wormlets release the wormlets.
Leo Laporte [01:47:18]:
That's right.
Steve Gibson [01:47:19]:
Only oh, that's good. Only one wormlet slot is populated with the SCM wormlet that hooks that looks for network servers, copies the payload over a network share and starts the remote service and finally repeats the process indefinitely, sleeping for the configured initial delay between waves until a failure threshold or external kill connection is reached. They write the single deployed wormlet found in Service Management xe. That's the SCM wormlet exemplifies a simple but effective propagation strategy based on native Windows capabilities and weak network security. It targets Windows 2000 XP environments and relies on default or weak admin passwords on file shares. All spreading is done through standard Windows Service control and file sharing APIs, an early example of propagation that leans on built in administration features rather than custom network protocols. Before this workflow starts, a pre installation kill switch checks the environment. The okay to install routine calls, okay to propagate, and propagation is only allowed if it's manually forced or if it's made sure common security products are not found by checking for associated registry keys, the routine walks a list of vendor keys and aborts installation if any of them are present, preventing deployment into monitored environments.
Steve Gibson [01:49:12]:
For tooling of this age, that level of environmental awareness is notable. While the list of products may not seem comprehensive, it likely reflects the products the operators expected to be present in their target networks, whose detection technology would threaten the stealthiness of a covert operation. Okay, so the list which they provide in the posting is a bit of a walk down memory lane with many of our old friends present. You know, there's Symantec, Cygate Technologies, Trend Micro Zone Labs, F Secure, there's Network Ice's Black Ice product, McAfee's personal firewall, computer Associates, Easy Trust, Easy Armor, I'm sorry, E Trust, Easy Armor, something called Red Cannons, Fireball, kerio Personal Firewall 4. Kaspersky Lab is there with Kaspersky Anti Hacker, the Tiny Software, Tiny Firewall, Soft Forever Pandas Software's firewall, and so forth. Forth. So a bunch of the standard products at the time they said a separate user mode Component Service Management DLL provides a minimal reporting channel contained within the carrier's internal storage. This DLL is registered through the Windows Add Connect Notify API so that it's called.
Steve Gibson [01:50:42]:
Each time the system establishes a new network connection using the remote access service responsible for dial up connections and early VPNs in the 2000s. When invoked, the DLL decodes an obfuscated string to obtain the named pipe and then they, they give the pipe name, attempts to connect to the local pipe and writes the remote and local connection names to the pipe before closing it. The module does not run independently and must be registered by a host process. So they're just saying that this is a very stealthy means of allowing this agent to connect out and sort of ride the outbound connection when that's being done anyway by that particular workstation, which it is already infected. And, and what that means is that there were some, you know, there were some other communicating component other than this that it was able to talk to. Okay, so the stage is set. We understand now that way back in the time of Windows 2000 and XP, it appears that very clever hackers, probably employed by the U.S. national Security Agency's Equation Group, carefully designed a professional grade, highly stealthful and very cautious Windows infiltration worm that prioritized not being caught.
Leo Laporte [01:52:22]:
Which is always a good thing to prioritize if you're a worm.
Steve Gibson [01:52:25]:
The infiltration worm was designed to be multi purpose, a multi purpose implant delivery system which in this instance was intent upon installing something known as the FAST 16 sys kernel rootkit into Windows systems. Okay. Now we're going to learn why and why I consider its devious functioning to be such a diabolically brilliant maneuver. But first, Leo, we're going to learn why our listeners may be interested in the brilliant sponsor.
Leo Laporte [01:53:03]:
That's diabolical of you, Steve.
Steve Gibson [01:53:06]:
Leo, you're going to love this. I know.
Leo Laporte [01:53:09]:
Do we think this is.
Steve Gibson [01:53:10]:
This is 2005, this is. This is 21 years ago, when you and I began the podcast.
Leo Laporte [01:53:17]:
Oh, my God. We didn't know anything about it, of course.
Steve Gibson [01:53:20]:
No. No one knew anything about it until now because these guys went back and were. We're looking for the earliest instance known where malware was. Was using lua, the LUA VM to. To interpret LUA script. And so they just stumbled on this, and it's like, whoa, look what we found. And this thing went unknown. But you.
Steve Gibson [01:53:45]:
I know you. You're gonna love when you hear what this thing does. Okay, so the Sentinel Labs team reverse engineered the operation of this fast 16 sys rootkit driver to learn the goal of its infiltration mission. Here's what they discovered. They wrote. Once activated, Fast 16sys focuses on executable files. They said a file is a valid target if it meets two criteria. The file name ends with xe, and immediately after the last pe, the Portable Execution section header, there's a printable ASCII string.
Steve Gibson [01:54:26]:
Starting with intel, they wrote this selection. Logic points to executables compiled with the Intel C C compiler, which often placed compiler metadata in that region. It indicates that the developers knew their target software was built with this tool chain. For files meeting these criteria, the driver performs a PE header modification in memory. It injects two additional sections, dot, X data and P data, and fills them with bytes from the original code section, increasing the section count and keeping a clean copy of the code. The intent is likely to increase stability while still allowing extensive patching, although without identifying the target binaries, this remains uninformed hypothesis. Okay, so just to be clear, what Sentinel Labs found was that this rootkit driver, which hooked into the operating system's lowest level file system functions, was able to modify executable files on the fly as they were being loaded into memory to run. So what was stored on the system's drive was never altered in any way, while what was actually loaded into memory when that program was executed was significantly altered on the fly as it was being read from the drive.
Steve Gibson [01:56:07]:
They explain. The patching engine is A minimalist performance optimized stateful scanning and modification tool. It's configured with a set of 101 rules, each containing pattern matching and replacement logic. To maintain performance, the Engine uses a 256 byte dispatch array and only flags the starting byte values of a small number of unique patterns. It allows wildcards inside patterns so a single rule can match several compiler optimized variants of the same code. And it supports state flags that some rules can set or check, enabling multi stage modification sequences similar to those used by advanced antivirus scanning engines. Most patterns Most patched patterns correspond to standard X86 code used for hijacking or influencing execution flow. One injected block is different okay, let's listen to this.
Steve Gibson [01:57:18]:
It's a larger and complex sequence of floating point unit FPU instructions dedicated to precision arithmetic and scaling values in internal arrays. This code is a standalone mathematical calculation function unrelated to code flow hijacking or any other typical malicious code injection. We're going to learn why in a minute, they said. To understand what the driver expected to see, we converted the patching rules into hexadecimal YARA signatures and ran them against a large period appropriate corpus. The results showed a very low hit rate. Fewer than 10 files matched two or more patterns. Those matches, however, shared a clear theme. They were precision calculation tools used with specialized domains such as civil engineering, physics, and physical process simulations.
Steve Gibson [01:58:32]:
The FPU patch in fast 16 SIS was written to corrupt these routines in a controlled way, producing alternative incorrect results. This moves fast 16 out of the realm of generic espionage tooling and into the category of strategic sabotage. By introducing small but systemic errors into physical world calculations, the framework could undermine or slow scientific research programs, degrade engineered systems over time, or even contribute to catastrophic damage. A sabotage operation of this kind would be foiled by verifying calculations on a separate system. In an environment where multiple systems share the same network and security posture, the wormable carrier would deploy the malicious driver module to those systems as well, reducing the chance that an independent calculation would diverge from the corrupted output. At this time, we've been unable to identify all of the target binaries in order to understand the nature of the intended sabotage. We welcome the contributions of the larger InfoSec research community and have included included the Yara rules to hunt for these patterns in this post's appendix. Even after deep analysis, Fast16's driver looks deceptively simple.
Steve Gibson [02:00:17]:
Beneath that minimal code is a rule driven in memory engine that quietly patches executable code as files are read from disk. The engine relies on a compact set of of just over a hundred pattern matching rules and a small dispatch table, so it only inspects bytes that are likely to matter. Most patterns correspond to ordinary x86 instructions, but one stands alone a larger block of floating point FPU code dedicated to precision arithmetic. This injected routine scales values in three internal arrays passed into the function, subtly altering its calculations. Without knowing the exact binaries and workloads being patched, we cannot fully resolve what those arrays represent, only that the goal is to tamper with numerical results, not unauthorized access, not malware propagation or other common malware objectives. Our best clues about the intended victims come from matching these patterns against large era appropriate software corpora. The strongest overlaps point to three high precision engineering and simulation suites from the mid 2000s LS Dyna 970 PKPM and the Mohid hydrodynamic modeling platform. All are used for scenarios like crash testing, structural analysis and environmental modeling.
Steve Gibson [02:02:03]:
However, LS Dyna 970 in particular has been cited in public reporting on Iran's suspected violations of Section T of the JCPOA in studies of computer modeling relevant to nuclear weapons development. So just to make clear how utterly diabolical this is, you're a nation state hostile to the United States. Researchers inside the USNSA have quietly traced your purchases of PCs and very high end nuclear physics modeling software. So they know what you're using to make your calculations. They obtain the same high end modeling tools which they reverse engineer. They then design a subtle set of tweaks which when applied to that package as it's being loaded by the operating system into memory, will cause its calculations to be wrong. Not enough to call attention to itself, but enough to foul up any designs that depend upon the accuracy of those calculations. And as the Sentinel Labs guys explained, by being a super stealth worm, not only did that allow it to worm its way into the design lab, but having arrived there, it also allowed it to similarly infect every other machine within its environment.
Steve Gibson [02:03:43]:
No files were ever altered, reinstalls would have no effect and scans would reveal nothing. Yet every copy of that modeling software would agree upon the wrong results. As I said, breathtakingly diabolical. The Sentinel Labs team concludes by noting something else they observed about the provenance of this worm writing. As we sought to understand the lineage of this unusual set of components, we noticed a quirk. Strings of the form at sign open parens pound sign close parens par.h space dollar revision colon space 1.2 space dollar sign inside the binaries Inside the binaries point to an unusual Source Control Convention. The at sign parens pound parens prefix is characteristic of early Unix source code control system SCCS or Revision Control System RCS tooling from the 1970s and 80s. These markers do not affect execution and are redundant in modern Windows kernel drivers.
Steve Gibson [02:05:04]:
Finding SCCS and RCS artifacts in mid-2000s Windows code is rare. It strongly suggests that the authors of this framework were not typical Windows only developers. Instead they appear to have been long term engineers whose culture and tool chain came from older high security Unix environments often associated with government or military grade work. This detail supports the view that Fast16 came from a well resourced long running development program.
Leo Laporte [02:05:45]:
RCS strings wow. I mean service management using git.
Steve Gibson [02:05:49]:
I mean right? Yeah, Service management was uploaded to virus total nearly a decade ago. It still receives almost no detection.
Leo Laporte [02:05:59]:
Wow.
Steve Gibson [02:06:00]:
What? Yeah, one engine classifies it as generally malicious and even that with limited confidence. For a stealthy self propagating carrier that deploys one of the most sophisticated sabotage drivers of its era, that nearly non existent detection record is notable. Together with its appearance in the shadow broker's leaked signatures, Fast 16 SIS forces a reevaluation of our historical understanding of the timeline of development for serious covert sabotage cyber sabotage operations. The code shows that state grade cyber sabotage against physical targets was fully developed and deployed by the mid 2000s. Embedded scripting engines, narrow compiler based targeting and kernel level patching formed a coherent architecture well ahead of better known families. And some of the most important offensive capabilities in the ecosystem may still sit in collections as old but interesting samples lacking the context to highlight their true significance. So as we know, I've frequently despaired that we're only ever hearing news of Chinese and North Korean and Russian state sponsored attacks. I've worried and wondered and hoped that the US would be able to give as well as it gets.
Steve Gibson [02:07:41]:
This certainly suggests that our bases are all likely well covered. And all of this was 21 years ago. Imagine what's probably going on today.
Leo Laporte [02:07:51]:
Yeah, you could. I mean it's got all the earmarks of a nation state because no script kitty, no hacker is going to write anything with. They're not going to use source control, they're not going to write anything with a built in language compiler. This is way more sophisticated and way and in some ways over engineered. Right? This is exactly what you'd expect from government government programmer.
Steve Gibson [02:08:14]:
Well they, they figured out what probably, probably Iran was using to do their engineering. They bought a copy, they, they, they decompiled it and they, they built a patch. Not so that it not it Wouldn't fail. It would just give slightly wrong results. And you. Who would.
Leo Laporte [02:08:37]:
Diabolical.
Steve Gibson [02:08:38]:
Who would. I know. It is so diabolical.
Leo Laporte [02:08:42]:
Just a little bit off.
Steve Gibson [02:08:44]:
Well, aren't we a chew. Why aren't we choosing achieving nuclear fission? It's supposed to, you know, it should work. All of our calculations say it should work.
Leo Laporte [02:08:56]:
Amazing. I mean, then of course, stuxnet follows right on the heels of that which. Which destroyed the centrifuges, spun them up
Steve Gibson [02:09:03]:
too fast and made them hurt themselves.
Leo Laporte [02:09:05]:
Very sophisticated stuff. And this does you feel. I feel like it sounds like the US Government.
Steve Gibson [02:09:12]:
Yeah, yeah, yeah. I mean, Iran maybe, but.
Leo Laporte [02:09:15]:
Or stuxnet was Israel plus Iran.
Steve Gibson [02:09:18]:
I mean, Israel.
Leo Laporte [02:09:20]:
Yeah, it was targeted to Iran. Yeah. And I mean, certainly Israel. But it feels more. The way this is built.
Steve Gibson [02:09:27]:
Feel like.
Leo Laporte [02:09:28]:
Feels like the federal. Our government. The federal government. I don't know, it's hard to describe, but it just feels that way. It's too, you know, engineered.
Steve Gibson [02:09:38]:
Imagine these guys stumbling upon this and following this little breadcrumb. Breadcrumb trail and. And realizing what this little innocent looking fast 16 sys thing was just sitting around, you know, in. In Windows system directories of the era.
Leo Laporte [02:09:57]:
And what was the thread? The first little thread that they pulled?
Steve Gibson [02:10:01]:
It was. They were. LUA has a distinctive fingerprint. So you can tell when there's a lua A. A compiled LUA binary that. That. That is interpreted by the LUA lvm. So they just scanned all the.
Steve Gibson [02:10:18]:
All the code back then for that little fingerprint and they, they found some hits that they had never seen before and they thought, oh, look at that. LUA was in use in 2005. We didn't know that.
Leo Laporte [02:10:32]:
So then by Microsoft. Microsoft wouldn't have used it for a driver like that. No, it would have been C. And
Steve Gibson [02:10:38]:
so it's like, okay, what? What? And it is a favorite of malware. So they assumed that this was some sort of malware. So then they said, okay, let's reverse engineer this and find out what it does. And little did they suspect something that was probably, you know, state level cyber espionage 21 years ago.
Leo Laporte [02:10:59]:
Very sophisticated, very interesting. I love. This is a great story. This is. It's too bad that it really couldn't be made into a movie. It's far too technical. But it's got a great. There's some real spy stuff in here that's really cool.
Steve Gibson [02:11:12]:
That's great.
Leo Laporte [02:11:13]:
And it's definitely with somebody in a white shirt with a skinny black tie, a pocket protector and black glasses who wrote this, right. Short sleeves. He's got a, you know, he's got his, his name on the desk.
Steve Gibson [02:11:24]:
And then they, you know, they, they turned it loose somehow close enough to its destination where it just literally wormed its way into the lab.
Leo Laporte [02:11:35]:
You know, the person who wrote this or the people who wrote this, 21 years later, they're probably retired or close to it. You should, you should get in touch with us. I'd love to hear this story or write a book. Because now it's kind of. It's statute of limitations is run, you know.
Steve Gibson [02:11:55]:
Well, it does not run on any current OS. It, it will not run on Windows 7 Server 2008 or anything since. So it stopped at 2000 NXP. That, that, that lineage.
Leo Laporte [02:12:11]:
I feel like it was written inside the Pentagon.
Steve Gibson [02:12:15]:
It was written wherever NSA is, you know.
Leo Laporte [02:12:18]:
Okay.
Steve Gibson [02:12:19]:
In Virginia.
Leo Laporte [02:12:20]:
Virginia McLean.
Steve Gibson [02:12:21]:
Yeah.
Leo Laporte [02:12:22]:
Yeah, very cool stuff. Maybe, maybe Goodwill, but.
Steve Gibson [02:12:26]:
Oh, but, but to, to just to look like it's doing complex calculations correctly and just like slip a digit. Yes.
Leo Laporte [02:12:35]:
This, this is like that. You, you nailed it. The Enigma project of the Brits or the man who never was. The idea of just these subtle little.
Steve Gibson [02:12:44]:
And they never admitted to it, never said it. It never became public. No one ever knew that this thing was ever there before.
Leo Laporte [02:12:50]:
There's an Iranian nuclear scientist somewhere going, ah, now I understand why it didn't work.
Steve Gibson [02:12:56]:
Exactly.
Leo Laporte [02:12:58]:
Steve, Great show as always. I hope you all listen every week because this is the kind of thing you miss if you miss a single, single episode. We do security now on Tuesdays right after Mac break weekly. So it's about 1:30 Pacific, 4:30 Eastern, 20:30 UTC. You can watch us live though, even if you're not a club member, because we stream it in public. YouTube, Twitch, X.com, facebook, LinkedIn and Kik. So please, you know, watch live if you want, but you don't have to after the fact. You can get copies in two different places.
Leo Laporte [02:13:26]:
We have it on our website, Twitter, tv sn. There's audio and video there. But Steve has all of the unique versions of the show. First of all, he has a 16 kilobit audio version which is a little scratchy, but is small. It's the virtue of being small. Also a 64 kilobit audio, that's full fidelity. He also has these fantastic show notes. And if you want to read this story, this is the place to get it.
Leo Laporte [02:13:52]:
Page 21 Pages of Good stuff every week. You can either download it from his site while you're there downloading the podcast or you can get on the mailing list and subscribe and that way you'll get it automatically. I got mine on Sunday. Steve works hard all weekend just to go to GRC.com mail and fill out your email address. That's so you can whitelist the email address so that you can send him pictures of the week and stuff and comments. But then below it, when you give them the email address, there will also be two unchecked checkboxes. One for the show notes and then one for an announcement. So when, for instance, the new version of the DNS Benchmark Pro comes out, you'll send out an email, right? Yep.
Steve Gibson [02:14:35]:
I have a video walkthrough to create and then I'll finally be able to let people know.
Leo Laporte [02:14:39]:
Nice. Very good. So that's a good way to go. Grc.com Email he also has transcripts written by Elaine Ferris. Really, really good transcripts because a human wrote them. All of that at Steve's website. While you're there, pick up a copy of Spinrite is bread and butter the world's best mass storage, maintenance, recovery and performance enhancing utility. Also of course, DNS Benchmark Pro is there.
Leo Laporte [02:15:01]:
That's $9.99 and worth every penny. We will be back next week. Next Tuesday I'll be in Hawaii doing this. Steve, how fun.
Steve Gibson [02:15:15]:
It looks like you've already got the shirt on.
Leo Laporte [02:15:17]:
I got the shirt. I'm ready. I'm getting ready for of the trade winds in Kona. We're worried it might rain the whole time we're there. But I'm. I'm bringing a Star Starlink mini to put out in the roof. We'll see. I mean, we'll just see.
Leo Laporte [02:15:31]:
I may. It may be a little scritchy, a little scratchy, but I will be here for that. And if not, if, if for some reason it falls apart, Micah will. Will do the show. But I think. I think I'm gonna do all the shows. So I think it'll be fun.
Steve Gibson [02:15:42]:
Well, we've all seen those. What personal enhancements, promotions or the real estate guys who had the waves in the background. They're always timeshare version of security. Yes. With palm trees and everything. That'll be great. You'll be very relaxed.
Leo Laporte [02:16:01]:
I have the fantasy that I'm going to be able to set up the Starlink on the, on the balcony and that you will see all that. We have an ocean view and you'll see. I have that fantasy. Whether that will materialize is another matter. I might be in a spare bedroom. It might be kind of boring. We'll see.
Steve Gibson [02:16:17]:
Much like Paul and Richard when they're.
Leo Laporte [02:16:19]:
Exactly.
Steve Gibson [02:16:20]:
Traveling.
Leo Laporte [02:16:20]:
Exactly. We always try to get somewhere nice, but we can't always get it. So, yes, Hawaii has Internet Galio, but I'm. We're staying in a hotel and you know how hotel Itel wi fi is. So I thought I'm bringing my own Internet. It was also a proof of concept because if I could do this there. Thank you, Steve. Have a wonderful week and we'll see you next time.
Leo Laporte [02:16:43]:
All of you on security now.
Steve Gibson [02:16:45]:
See you from Hawaii, my friend. Bye.
Leo Laporte [02:16:50]:
Security now.