Librem 14 Malware Removal Tool

Long story short, I plugged in a 10 year old hard drive into my Librem 14 and ran Windows 10 on it. It ran better than the original windows laptop I took the hardrive from, since the Librem 14 is good hardware.

But when I reboot back to PureOS, how would I know that the system is actually secure and that BIOS or firmwares were not infested by contamination from the Windows 10 drive? Is there any way?


Don’t do this. Windows? Just say no.
You will just be creating hassle for yourself.

Are you using Coreboot or Pureboot? For the latter, it should let you know whether there is Windows contamination (but that of course does not remove the contamination). For the former …

Half answer: The root file system is encrypted (assumption!) and so any contamination by Windows is likely to be uncontrolled and corrupting (but would mean restoring from a known good backup). The boot file system, presumed unencrypted, can’t be guaranteed and therefore would be restored from known good backup. The firmware would need to be reflashed.

Another practical consideration is whether you put the laptop on the internet. A 10 year old version of Windows (any operating system!) is likely to have unpatched known vulnerabilities. So putting it on the internet is living dangerously.

If you must run Windows on your laptop, a safer approach may be a VM.

1 Like

To be more clear, the Windows drive was used intermittently throughout the last 10 years and is not much out of date, nor outside of its officially supported lifetime, as far as I know. The problem I am asking about is not the presence of known malware on Windows, but rather the matter that Windows is itself malware and touched the machine. Windows might also have collected undetected malware in its 10 year life span, too, who knows?

The Librem 14 is running default Coreboot with a default install of LUKS encrypted PureOS, and after removing the external drive that was used for booting the malware called Windows, the Librem 14 acts as if it is fine and any corruption is in a state of hiding itself from the user.

When I look at a guide such as this:

I see in it that they suggest using a physical CH341a programmer to flash the chip. If Windows was able to persistently tamper with the Coreboot firmware without the presence of a CH341a programmer, why can’t I? Is there an obvious and easy way to investigate whether Windows tampered with that?

Also, the Intel ME on the Librem 14 processor was disabled according to something I read online at one point. Could Windows have persistently re-enabled that, or is the decision for whether to neutralize it stored within drivers loaded at boot time/HDD (and thus by PureOS, and thus something that might be either unmodified or that would be reverted if I just reinstall PureOS, which I might do.)?

Any help with any of these questions while I search for answers is appreciated. Thanks!

OK, that’s good. It is still however a higher risk to be on the internet than not to be on the internet (when running Windows or other untrusted code).

Yep, I got that.

No, sorry, you have been misled. That blog post is particularly applicable if you are developing your own BIOS and it goes pear-shaped. So that it is no longer possible even to boot into BIOS. So that it is certainly not possible to flash the BIOS from software.

I guess in theory, after running Windows on bare metal, the only way to be 100% sure of the BIOS is to reflash in hardware. However for the threat model that most people would consider appropriate, you can reflash the BIOS from software just fine as long as you can boot the computer at all.

Good point. That is another potential point of attack by Windows.

I guess it depends on whether you want to look at worst case scenario.

Reasonable scenario: The decision to disable the Intel ME is a boot time choice (set the HAP bit). Something in the boot code will unconditionally set the HAP bit regardless of what choice Windows made. So the only way for Windows to interfere with the normal choice, once Windows has been removed, is for Windows to interfere with the boot code. So as long as you verify the boot code, I don’t think you need to worry about setting the HAP bit.

1 Like

Lots of good advice here, and I agree - just reflash it, not much sense trying to verify it when reflashing is just as easy. Hardware flashing would be great but internal flashing is probably reasonable for most individuals’ threat models.

You can write the firmware internally. In principle, if you think the running firmware could be tampered, it could also interfere with the OS’s ability to write the firmware. Most of us probably won’t be targeted by a sufficiently sophisticated attack that would allow the host software to think it has written the firmware (including a successful verification pass) while remaining resident in firmware, so a successful internal flash is OK. If you do think you could be targeted by attackers of that level (in this case, targeted via a Windows installation from another system), then a hardware flash would be best.


So, as far as the attack I would be hit with, the Windows install on this harddrive had at times connected using a Cisco VPN software to my work VPN for my job, and we had a problem for years that was beyond my skill to diagnose but could be reasonably explained by a state level actor doing surveillance on us using something like the “jellyfish rootkit” research paper I found online a few years ago, where essentially they construct a virus that lives in VRAM or whatever. As I said it was beyond my skill to diagnose, and the IT people said it was caused by sunspots and did not take my complaints seriously.

But in my case, after I connected a home machine to this work VPN and then started having the same “hardware issues” on the home machine that we had in the office, despite the office machines being linux and my home machine running Windows at the time, I was left with this sense that we’re being hacked by somebody more sophisticated than us and nobody takes it seriously and I can’t even prove it’s there, so as a result everything sucks and I just became increasingly paranoid throughout time.

That malware, whatever it was and if it existed and if I wasn’t just imagining it, might have also been on this Windows hard drive that I used on the Librem 14. I like to forget… because the people from work who say hardware issues are caused by sunspots and I imagined it all… offer a very convenient explanation.

So, the upside is that I am most likely not the primary target of that pseudo imaginary threat. They may be extremely sophisticated and may be blanket hacking everything I own because I’m still working at this financial company, or they may not. I suppose when I boot Windows from that USB drive on the Librem 14, and then remove the drive and boot PureOS again and enter my LUKS credentials as though nothing changed, it’s like taking the blue pill to live in the Matrix and believing “they” don’t exist at all.

I had covid19 for the first time and I wanted to play a video game with my friend who gave me the covid19, so I was sick and trying to play a game and the Windows laptop was sucking so I ripped out its hard drive and put it in a USB. I knew this would work because my silly open source OpenGL game that I’ve been making which runs on both Windows and Linux was seeing ludicruous better high performance rendering spewing out from the integrated graphics of the Librem 14 than from my other older windows device. So I thought if I could just boot the Windows but on the hardware of the Librem 14, I could join my friend in the game but with the perfect framerate.

However when I actually had it going, Windows 10 was unable to automatically load the Intel integrated graphics drivers on the Librem 14. For some reason that did not work, even though that other older windows laptop was also an Intel x86_64 machine that also has nothing but integrated graphics.

So I downloaded some drivers from with some very concerning tool that seemingly embedded itself into the default web browser in what seemed to me to be an extremely insecure way (it created a driver install button in the browser instead of downloading an installer, suggesting maybe other sites or web clicks could triggers installs… instead of using the standard browser file download process).

Then after this sketchy process from did whatever it wanted to do, and identified the hardware as Purism Librem 14, it installed Intel drivers that actually worked and I was indeed able to get a perfect framerate and play the video game with my friend.

Does needing to go to the official intel website for drivers, or the pseudo imaginary jellyfish rootkit, change any of your guys’ suggestions in this case? Obviously the pseudo imaginary malware was capable of hopping from linux to windows just from getting on the same VPN, so if it really exists it was probably already on my Librem 14 since when I got it anyway, but I like to simply believe it doesn’t exist and our tech today is so stupidly complicated that proving the negative – that magic spyware doesn’t exist – is effectively impossible. So I just want to do the best I can do. I haven’t been back on the Librem 14 since thinking about this stuff more and creating this topic (atm posting from my Librem 5).

And I think it sounds like I have a solid plan. I can probably scp out some files from the “assumed tainted” configuration, then look up online how to reflash coreboot, do that, and probably also reinstall PureOS.

And hopefully that is enough? On the upside, the threat actor described above would not want to reveal themselves to a tangential non-target like me, so whether they are present or not I assume they would remain in hiding and I would never know for certain if they even existed at all.


If we want a name for the malware, other than the hardware monitor issues it caused, maybe we could name it “WarPewMuch.” About one year into being affected by it, when I wanted to convince myself the freaking thing existed and wasn’t sunspots or whatever, I wrote a recursive search script on the hard drive of my most obviously affected computer to look for any file whose “last modified” date matched the time when it first jumped from the work VPN to my home PC. Coincident with the time I was looking for, there was a Microsoft OneDrive automatic update log indicating that it downloaded a file called “WarPewMuch” automatically. This was not a file in my personal OneDrive storage, but rather the name of new executable stuff supposedly from Microsoft that it downloaded to update itself.

Some page online links to a twitter post that claims “WarPewMuch” is a legitimate Microsoft name used for their legitimate upgrade, if you want to take the blue pill. But I don’t have a twitter account, so I can’t read that thread anyway. If I were the WarPewMuch virus, I would post on twitter saying I was legit, too.

Anyway all of that happened years ago. Would “WarPewMuch” remain operational in secret on a drive for like five years?

Well, obscurity isn’t security but … if someone can write malware for a much older mainstream Windows computer that is going to embed itself deeply and have the malware work when booted on a Librem 14 (relatively niche) and they probably wouldn’t have known that you were going to do that then … your attacker is indeed sophisticated. (You would be safer though running Pureboot.)

As an aside: work and home should be kept separate. Finance sector, squillions of dollars, they should be giving you a computer to use for work at home. Gaming should be on a different computer.

Take the blue pill, um, I think. :wink:

1 Like

No, not for me. It always comes down to deciding what your threat model is, which determines what measures you need to take to reasonably protect yourself. Weigh the risk against the cost of the actions being considered.

It’s still the same sort of attack we’re considering:

  • delivering malware to Windows (the vectors you mentioned are valid, but I don’t think they impact the analysis here much)
  • the malware understands coreboot firmware and the hardware enough to infect the firmware
  • the malware is capable of fooling software into thinking it has flashed the firmware, while still remaining resident

The risk depends on your threats, but is reduced by the complexity of the attack. You need to weigh this against the costs of actions to defend against such a threat. Here, we’re mainly debating between a software firmware flash and a hardware flash. The hardware flash will probably cost you a fair amount of time if you have never done it before, possibly some anxiety if you have trouble getting it right or aren’t sure whether it worked, and a bit of money for the hardware probably (not that much though).

Software flash is just this: Files · master · firmware / utility · GitLab

My impression is that the complexity of this attack, given your risk, probably does not outweigh the cost to hardware flash, but it’s up to you to decide. Whichever way you decide, I’m happy to help (if you want to go the hardware flash route and need help there, might be best to make another thread for that topic).

100%, could not agree more.

1 Like

I started looking into this, and was getting error 500 on the purism source server. That’s not just me, right?

I also get error 500 (presumably HTTP status 500 - Internal Server Error) with the link given in the post before yours. So, no, it’s not just you.

1 Like is up now.


Thanks guys! I reinstalled PureOS and then reflashed Coreboot using your link. Hopefully in the clear now.