• General
  • definitely hacked or something

Hi @angela.

The last month or two there have been reports from multiple users on the internet of microphone-in-use dot randomly turning on, and staying on, and that "Unknown" app is using the microphone. These reports come from GrapheneOS, stock Android, and even iOS which doesn't share code with Android at all, and from all sorts of users. Tor Browser certainly isn't installed at all in most cases. What it is that is happening, no one seem to know yet. It might be hacks, the coincidences with iOS leads to me now slowly starting to suspect this. It might also be bugs. It seems the Android case actually might have been a bug.

Either way, I want to clearly state, that the vast majority of users, including those of us with actual threat models, have not experienced this. It is also not clear to me how an attacker is able to get access to the microphone, but cannot prevent the microphone-in-use dot from turning on.

Tor Browser app runs in the Android app sandbox like all other apps you install. An attacker would need to have an exploit against Android app sandbox, in addition to an exploit against Tor Browser, to be able to get microphone access that way. The sandboxing others talk about in this thread, that is lacking, is yet another layer of defense some other browsers specifically implements. But Tor Browser is properly sandboxed like any other app would be.

If you suspect you have been hacked, here is what to do:

Hold power button for at least 30 seconds until phone hard reboots. This is to make sure an attacker cannot fake the reboot. During boot screen, hold volume down button, to enter fastboot screen. Choose recovery using volume buttons and power button to confirm. If I remember correctly, you will now reach a screen that is blank. I think you need to press power button and volume up button simultaneously to get a menu. Select factory reset and perform it. This will ensure all data not verified using verified boot gets deleted, even cryptographically destroyed.

During next boot, compare the boot hash shown with the one from GrapheneOS website, using a device you trust not to have been hacked, or from multiple devices just to be sure.

Your device will now be clean. Only proper non-compromised GrapheneOS code can run now.

How to prevent getting hacked again:

Be considerate about what apps you install, and from what sources, and what websites you visit in the web browser. Prefer to only install highly trusted and reputable apps, and only from official sources, and only visit reputable websites where you trust the website operator to do their best to keep the website clean from malicious code.

    ryrona

    Your device will now be clean. Only proper non-compromised GrapheneOS code can run now.

    Does this wipe your entire device, including all your data?

      Dumdum I read this already but I'm asking for you to clarify what this means.

      Under what circumstances will data not be verified?

      Is it possible to have legitimate data written to my device (eg. a backup for a notes app that I manually performed) that is not verified?

      Can I be 100% certain that "all data not verified" will always mean malicious code?

      Just querying how reliable this function will be if I ever decide to do this. I don't want any of my data lost.

      • de0u replied to this.

        gk7ncklxlts99w1 Under what circumstances will data not be verified?

        Android splits data into two parts.

        The system partition is covered by verified boot and dm-verity, which detect if the contents of the system partition are changed by anything other than installing a new release.

        The user data partition is expected to change over time as user profiles are created and deleted, apps are installed and deleted, and app data is created, edited, and deleted. The user data partition is not (ever) verified by verified boot or dm-verity.

        The "factory reset" function securely erases the user data partition, so no apps or data remain, whether "good" or "bad", and the reboots before and after "factory reset" check that the system partition is intact. Thus at the moment of a "factory reset" everything on the system partition is verified and everything that is not verified, on the user partition, is gone.

        If malicious apps or data are restored from a backup to the user partition then the device might be compromised again.

          de0u

          Got it. So if you suspect you've been hacked, the only safe thing to do is factory reset, then restore phone from a backup.

          • de0u replied to this.

            gk7ncklxlts99w1 So if you suspect you've been hacked, the only safe thing to do is factory reset, then restore phone from a backup.

            It depends on the degree and nature of the suspicion. If a reboot works ok (with the regular "other operating system" alert including the correct key hash) then it's genuinely very unlikely there is malicious code persisting in the system partition. If no apps have access to dynamic code loading, then rebooting should clear any malicious code out of memory.

            But if somehow a malicious app has been downloaded, or if there is persistent malicious app data (such as a downloaded image), then reinfection is possible. If such a scenario is occurring, wiping the system and restoring the corrupted app and its corrupted data from a backup could reinfect the system. So "restore from backup" may be risky!

            There isn't really a "just do this and you'll be fine for sure" recipe, especially when third-party apps are part of the picture.

              ryrona if this is going on with iOS too i would guess certain users are being hacked through the cellular modem and the android bug was placed there to distract from this. This would be a guess, I have no evidence bit know what I saw. I was in AFU after a reset. I do not think this is likely because of malicious software, I think this is a hoarded exploit being deployed. Time for me to get rid of this thing. Back to being no-cell. I just don't trust hardware without switches can be controlled but considered GOS despite it but i can't do this anymore. The usability isn't worth having a modem connected to a tower with data going back and forth I can't review.

                angela your microphone turned on simply because your global microphone toggle was on and you permitted TOR use of microphone. You as a user have a total control over permissions you grant whether it's while in use or on every use and subsequent turning off that toggle. The fact that there is a microphone bug recently occuring and I believe it is going to get dealt with relatively promptly, should not be a reason for your departure from mobile phone use reasoning with completely unrelated (baseband) issue. If the bug was not present, would this still be the case?

                As others said, if you were hacked, you would most likely never notice that, but if you still have a suspicion you can perform a verified boot (restart), use Auditor app or factory reset the device to return it to a clean OS.

                angela
                Yeah, or hear me out.. you're not hacked. Why would someone burn a cellular modem vulnerability on you of all people?

                de0u

                with the regular "other operating system" alert including the correct key hash

                I don't pay much attention to this screen, will it be immediately obvious if this screen changes? Not sure what it would look like if it was irregular.

                dynamic code loading

                I recently changed some of my default settings for dynamic code loading, from allowed to restricted. Is DCL allowed by default? I can't remember. I have it restricted for all apps by default with via memory and via storage.

                • de0u replied to this.

                  gk7ncklxlts99w1 I don't pay much attention to this screen, will it be immediately obvious if this screen changes?

                  The signing-key hash is displayed before every boot so that it can be verified before any boot. How often to verify it is a personal choice. Unfortunately, if the signing-key hash is to provide reasonable protection, it must be long, and any difference (even one digit) is unacceptable.