So I got Fairphone 4, with /e/ os, a couple of days ago. When I connected it to my NextDNS I saw that it was trying to connect to some weird addresses, like every 5-10 minutes. I searched Internet a bit and found out that it was something with snapdragon cpu and location services. I travel a lot and use Organic Maps for navigation, so location was enabled almost all day on the phone. I turned off location services and connections stopped, and everything was fine for a couple of days.
Today I came home, checked logs in NextDNS and saw that phone started doing the same connections almost constantly even with location turned off.
Can I do something about this, other than allowing these connections? These connections are probably so numerous because they are getting blocked. If I allowed them, phone would maybe call home once in a couple of hours. I would rather not allow them, but I don’t want 20% of battery to be eaten by this.
Chipsets don’t make network requests. More likely some closed-source platform service does.
That really isn’t entirely true anymore since the TPM ecosystem came into existence. I can remotely wipe any pc at my company even if it’s stolen and reformatted because a hardware chip will phone home the second a compatible os is installed and internet access is available.
The TPM can’t do anything. The Intel Management Engine and AMD Platform Security Processor can, but the TPM is just key storage.
That stuff is disabled unless you buy expensive business options, though. Intel makes a lot of money not putting the fancy smart stuff into their desktop platforms.
For remote wipe you also need to get lucky because if the thief doesn’t install the necessary drivers. Enabled encryption should prevent your company’s data from falling into the wrong hands, of course.
I think unless the HAP bit is specifically set to 1, Intel ME is still active on consumer boards, just without an interface for the OS to interact with it. Not sure if someone has hacked an OEM UEFI/BIOS to interact with it, but I have seen a different MAC address from my PC on my network before, and this is without any virtual adapters. This is the only explanation I can come up with.
The IME is active, but only for the bare necessities. Modern Intel CPUs simply will not bootstrap without the IME firmware. I know the thing runs Minix, but so far nobody who has reverse engineered it has found any serious threats when the management service isn’t running.
You can zero out some unnecessary components of the BIOS firmware so it can’t do networking and run daemons, but you need at least the ROMP and BUP partition.
Motherboard manufacturers can also toggle a bit that request the IME to be disabled after it finishes its critical initialisation code (I believe governments really like this feature) but you’d still be relying on Intel’s encrypted code. If you have a BIOS flasher (or a Raspberry Pi and some soldering skills or the right programming clip for your motherboard), you can make a backup of the BIOS and then enable the bit yourself.
I don’t know the source of your phantom MAC address. I’ve never seen an Intel ME DHCP request on my network. As far as I know, the Intel ME is supposed to take the same IP address as the host, unless you’re using a PCIe network adapter. The IME integrates with the Intel network card and extracts packets that it likes to operate on.
There is a Windows tool that will tell you your Intel ME MAC address if you want to confirm (MEInfoWin) if you want to confirm. It’s not a public tool that consumers are supposed to have access to, but you can find it (accidentally) distributed with firmware updates for motherboards.
Thanks for your comment, much appreciated! Could you provide a source for someone who has reverse-engineered a recent version of ME and has found not much incriminating behaviour for consumer motherboards?
Unfortunately,
me_cleanerdoesn’t seem to work too well with newer chips. Fortunately for me, I’m planning to purchase older computers, but for people who aren’t, this doesn’t help much (as far as I can see).Thank you for the idea of extracting the BIOS to enable the HAP bit. Won’t it require some serious reverse-engineering chops to find the HAP bit and enable it inside of such a binary blob? I’m not really used to Ghidra yet haha.
If I remember correctly, ME uses its own MAC address, but the same IP address of the host. Or maybe this is no longer the case. How would it extract packets though? Won’t that require serious compute power? Or does it look for packets with specific labels identifying them?
Thanks for letting me know about MEinfoWIN. I’ll try and find it!
It’s hard to prove a negative, but with people doing deep dives like these not finding any malicious behaviour yet, I doubt there’s anything of note happening in the ME on consumer hardware.
Theoretically the NSA could backdoor the IME, but if they can backdoor the ME firmware, they can also backdoor the tiny Pentium processor inside every Intel CPU, or the UEFI ROM, the microcode, or any other firmware really. In practice they plant tiny their own chips onto existing motherboards, which can be easily removed so they don’t leave a trace.
It looks like the HAP bit has changed location (someone already found out the new offset) but me_cleaner has built in support for setting the bit in many cases; this commit from this PR seems to implement that. Disabling the firmware does, as you would expect, disable the firmware loading process though, meaning Intel Audio won’t work right and booting becomes weirdly slow. You also lose fTPM support and modern sleep (S0ix).
The packets enter the Intel network card, and the network card pre-processes them in a bunch of ways (validating checksums, sometimes even reassembling fragmented frames). Modern network cards are fully aware of IP and in limited fashion TCP, so “extract traffic towards port 664/16993/16995 and do not notify the OS” isn’t that hard to accomplish.
A separate MAC with the same IP would cause tons of conflicts on the network, I don’t think Intel would (intentionally) use that approach.
Thank you, that clears it up. I’m not as informed on this matter as I used to be in the past, apologies for any assumptions I might have made.
Thanks for the link and the link to the PR, I might try this with a PC or two in time. Do I need Intel Audio for Pipewire to work? I didn’t quite grasp the ramifications of certain parts of the firmware not working such as Audio and Sleep; would I need to find a software solution for Sleep? Also, will this affect C-states by any chance?
That makes a lot of sense. Maybe I was looking at something different in my network at that point. Thanks again!
No worries, I only about this stuff because I recently saw a Defcon talk about it on youtube and started Googling. I could be wrong about some of it to be honest, there’s a lot of uncertainty here.
If you use the headphone jack of your PC or a laptop’s integrated speakers: yes. If you don’t care, not really. You can always make a backup of the ROM chip first so you can restore it if you find any problems.
That depends. Some motherboards still have firmware for S3 sleep, that should work just fine I believe. S0ix is a bit weird in that it “sleeps” the same way your smartphone does, waking up occasionally to do things like download updates or do other background tasks. Quite useful for PCs left in sleep mode overnight, not great when the drivers are bugged and tell your laptop’s CPU to wake up in your backpack.
I don’t think so, but I’m not sure.
Here is an alternative Piped link(s):
deep dives like these
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
For what it’s worth, I did specifically say ecosystem because the TPM is just one component, which is required to authenticate the remote wipe. Also the drivers are installed automatically with most modern operating systems, it’s not like you install your own south bridge driver, for example. Linux of course notwithstanding.
I’ve seen it used successfully numerous times. Someone steals one of our laptops, rips the drive out, installs vanilla windows, and boom it reboots and performs a wipe.
Regardless, system-on-a-chip are just that, systems; they can absolutely make remote calls without user interaction, just as intimated by the comment you originally replied to.
Ah, in that case I suspect this has less to do with the TPM or firmware and more with a weird feature Microsoft provides (that I permanently turned off on my laptop).
Windows provides the option for the BIOS to place or replace files on the file system. A bunch of anti-theft tools replace chkdsk.exe, which gets executed on every boot, with a daemon or installer for their service. You can clean install Windows all you want, the moment Windows boots, injection takes place and the payload gets executed. You don’t need TPMs or even encryption or Intel ME/AMD PSP for this.
I believe MS added this API because they noticed motherboard manufacturers messing with the kernel’s memory, and decided to expose a less batshit insane API rather than risk customers blaming Windows for their laptops crashing on boot because the memory layout changed.