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.

  • 𝒍𝒆𝒎𝒂𝒏𝒏
    48•1 year ago

    The Qualcomm chipset is making these requests, most likely for GPS almanac data (satellite positioning).

    Older chipsets send these almanac requests to izatcloud.net, unencrypted, containing your IMEI. No idea if newer chipsets have improved things though.

      • @noride@lemm.ee
        19•1 year ago

        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.

          • @MigratingtoLemmy@lemmy.world
            4•1 year ago

            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.

              • @MigratingtoLemmy@lemmy.world
                2•1 year ago

                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_cleaner doesn’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!

                  • @MigratingtoLemmy@lemmy.world
                    2•1 year ago

                    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!

          • @noride@lemm.ee
            3•1 year ago

            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.

      • 𝒍𝒆𝒎𝒂𝒏𝒏
        6•1 year ago

        I don’t ☹️

        There is a hidden LocationServices system app from Qualcomm that proxies the communication on some devices - however removing this causes a bootloop from what I’ve read, and would prevent Android from being able to identify your location even if it didn’t cause a bootloop.

        I use a Fairphone 3 though with a bunch of Google services in the stock OS disabled, so I’ve settled for just keeping my location data out of Google’s hands

        Edit: add info

            • @SpaceNoodle@lemmy.world
              1•1 year ago

              You get pretty good at it after you do a couple. I also came up with a way to manually start a platform service with strace and a custom SELinux context, but that was a few years ago and I left all of that work with my previous employer.

        • @Cossty@lemmy.worldOP
          3•1 year ago

          I actually wanted to get a Fairphone 3 because of headphone jack but I got really good deal on a Fairphone 4 so I took it instead.

        • @MigratingtoLemmy@lemmy.world
          2•1 year ago

          however removing this causes a bootloop from what I’ve read

          Is this document for every Qualcomm device? I’d be interested to remove such calls from my system if possible, but I’m no systems expert, and unlike the other commenter I don’t think I’ll be able to decompile Qualcomm’s platform service just to remove a few system calls.