• Development
  • Phone examination and plausible deniability

So there is a github project that was published as a proof of concept in 2021;
https://github.com/williamtheaker/lockup

This tool was proof that forensic tools that extract data could easy be detected, and that you could design apps to deploy countermeasure against the forensic tools. Signal did something similar in their cellebrite POC (https://www.signal.org/blog/cellebrite-vulnerabilities/), when they corrupt result of the extraction to make the produced report useless.

Would this be something you could see in grapheneOS bundle with dummy password idea? It is clear that some of the methods are naive in nature and might not work, but it would be good for when you have to give password.

I read on the website that these types of features would not be included as if it was a feature of gOS then the OS would become known for it. But 'lockup' app for example has plausible deniability that also has the ability to mitigate any data extraction attempts, meaning it not possible to extract data even with password of phone. It stop the extraction of data because it can be detect by the app, are there any other apps that do this?

    This is absolutely brilliant! The brief video on the Signal website is like "infosec p0rn" and gave me a huge smile. It doesn't really surprise me that Cellebrite contains bad code, and it would be simply AWFUL if random files that could corrupt their product were available to the public 😎. Gosh, I bet someone would even pay some of that evil fake money crypto stuff on ... what do they call it ... garlic sites ... leek sites ... no, wait, I remember: ONION SITES 😂😁🤗

    My reading of the article, especially the final paragraph, suggests that such files can simply be uploaded & nothing needs to be done. All is well until SOMEBODY tries to use Cellebrite to image the device, then they begin to have a BAD DAY.

    I cannot stop smiling about this 😁

    One of the funniest things I have read in years.

    I can only imagine the consternation.

    Bravo, Signal!

    Most anti-forensic mechanisms like these are redundant since GrapheneOS cannot be extracted by the tools by you just refusing to co-operate. Although while your phone is seized that also means your phone isn't being updated, which can open up security issues in the future.

    riskingpilot99 Would this be something you could see in grapheneOS bundle with dummy password idea?

    A dummy password is the most effective method but it is only best in certain scenarios, just as long as they don't know it is possible for this functionality to be there.

    riskingpilot99 I read on the website that these types of features would not be included as if it was a feature of gOS then the OS would become known for it.

    The reason GrapheneOS is against combatting Cellebrite with exploits or detection mechanisms is because they can easily be averted, and applications like Lockup are only effective when they aren't known by forensic investigators. If GrapheneOS was known to have anti-forensic mechanisms then investigators would simply just never plug the device in. Cellebrite sell a mounted camera to record the device's screen so the investigator can browse the phone manually where automated tools cant work. If GrapheneOS became known for having this then they would ALWAYS use the camera, essentially missing the whole purpose of the exploits/apps and making them useless.

    Cellebrite also patch security issues or anti-forensic scenarios, the RCE by Signal was patched and the LockUp application is not fully capable, the original author of LockUp also cooperated and gave responsible disclosure to Cellebrite for UFED security issues. It's very likely they know about LockUp already.

    https://cellebrite.com/wp-content/uploads/2020/03/ReleaseNotes_UFED_7.30_A4.pdf (Page 3 - Web archive doesn't work, also blocks VPNs)
    https://korelogic.com/Resources/Advisories/KL-001-2020-001.txt

    I also did some of my own looking up about the original blog post referenced in the app and saw that the Cellebrite UFED they performed this exploit on is quite old, even for the blog release date. UFED devices don't run Windows XP rather Windows 10, and the UI is also very old. I assumed correct that the exploitation of the UFED was already fixed in a newer version:

    https://korelogic.com/Resources/Advisories/KL-001-2020-002.txt

    Cellebrite could very likely patch or change behaviours of the UFED to overcome the app if this was a problem. If there is a likely chance it still works then all it would need is to ruin one case and they'd change it to overcome it.

    riskingpilot99 But 'lockup' app for example has plausible deniability that also has the ability to mitigate any data extraction attempts, meaning it not possible to extract data even with password of phone. It stop the extraction of data because it can be detect by the app, are there any other apps that do this?

    Some other apps like Wasted can perform a factory reset when connected to any USB device, although they aren't really directly targeted toward forensic toolkits since they will reset on any USB device being plugged in. This can be better than LockUp in some ways but is also extremely risky.

    I wouldn't really consider LockUp plausibly deniable, when these apps perform the factory reset the Android OS says a factory reset is about to occur. Yes you hide what is incriminating, however they would have evidence the deivce had a killswitch and they'd try and use that against you. Plausibly deniable systems are meant to deny knowledge of anything incriminating. Depending on the country they could just get you for tampering.

      Blastoidea GrapheneOS is still resistant to forensics, which is the important part. Unless you had your PINs known or caught on camera then you're fine. The camera scenario is something a duress password wouldn't fix, and neither is getting your device seized, becoming more insecure over time...

      final

      If investigators never plug the phone in because they are scared of the anti-forensic features this is probably a win in most threat models. A manual extract of phone has lot less info than a filesystem or logical extraction.

      I know the camera you talk about, that comes with UFED. The UFED also has screenshot of phone capability. but it is much better for manual examination than full phone download. Full phone download includes delete files and cache data etc.. Manual examination of phone is much more difficult and harder to investigate, only user visible items can be looked at.

      Plausible deniability is my mistake, I know it shows the phone is erasing. But the erase feature is still useful no? It may be better for someone to erase a phone than have it accessed. Also In many country there are key disclosure laws, it may be better to erase the phone than to disclose the key in some situation?

      I would like to see antiforensic features implimented as it is very good at making gOS be tamper resistent.

      Can you think of any way I can achieve this? My country use the software and even crossing borders can mean they download your phone. I would much like and prefer forensic corruption, even phone wipe.

        riskingpilot99 In terms of extraction mode, the manual way can be more than logical in some cases since Logical is just operating system files while manual can let them open apps and view the contents of apps which is only really possible in Filesystem. Some apps that encrypt the application data like Cryptocurrency wallets or messaging apps pretty much require you to extract manually. It's kind of in the middle ground. The UFED screenshot mode is sort of flawed, since if the app blocks screenshots it also doesn't work, it captures exactly like the OS does. Big issue with manual is the heavy risk it takes to undergo doing it.

        The erase feature is useful in some scenarios like I have said, which is why GOS wants to add in the future. You also could in practice use the PIN before something happens for a fast erase or to trick whoever seizes. The erasure is definitely effective but incriminating so it's a tradeoff on if erasing is worth it.

        For the plausible deniability you could theoretically design the OS to have two 'owner' profiles to choose from a boot and select via the PIN you enter, but I honestly can't assure if this is even viable since there would probably be ways to figure out it existed. I think it would also be too much work. It would also kind of be like 'profiles in profiles in profiles' in terms of OS architecture which seems like a flawed design. The user profiles may help, by having an entirely empty Owner profile and everything stored in separate user profiles since they are isolated. Can delete a profile or act like you forgot how to get in one of them etc.

        GrapheneOS also planned a Virtual Machine manager app: https://nitter.net/GrapheneOS/status/1678594436924600325#m - this could be used? Probably wont be made for a while.

        File encryption applications? Disposable users? I'm not so sure of anything else

          final

          This is very interesting. Thank you for taking a lot of time to write this.

          Obviously as you will know very well, software like veracrypt has denyable password in it, but I do not know how graphene would add this to mobile OS. The volume mounted would still be viable and it would be not plausible to deny the existance of second volume? Would only work for pre boot authentication. I think it is not like veracrypt where existence of second volume is impossible to prove.

          Again, I think that a separate download app that is antiforensics could be useful. Is this even possible? especially for countires where you must disclose the passcode. I do not see any apps that do this other than lockup. Lots of people who use it are very under trained, so they likley not even realise that antiforensics in play. it would be great if people think that they caused the erase because of corruption in their software? I would think anti forensics could have many many use cases.

          What do you think of lockup? is it just proof of concept? the code on github does not seem like it actually does a lot.

          Thank you very much

            Threads like this make me realize that no matter how much we love to bitch about it, I am eternally grateful that I was born in and live in the US.

              Blastoidea every US Citizen just collectively sighed a breath of content.... begrudgingly

              final
              Wait. What about a feature that erases all secondary profiles? No phone reset, no warning, no nothing. And the phone is still working, so it should help with plausible deniability, no?

                I am mentioning opinion and anecdotes here, just a forewarning.

                riskingpilot99 Like my previous comments, I said that you cant really assure the viability of such a setup. Plausible deniability (while good at hiding evidence) sadly isn't very feasible in hiding itself, since there are some ways to figure out the existence of a deniable setup with physical access and good equipment. The device would have to be essentially tamper-resistant or have a destruction mechanism which is not just rare, but undesirable for some people. I imagine it could be harder to perform on a mobile device since you'd need to chip-off/get physical access to the logic board instead of just unplugging a hard drive. But, that possibility always remains.

                For plausible deniability to really be effective, the OS would have to look completely identical to an every other setup of the same OS when it comes to forensic artefacts. This often isn't the case, even if they don't show evidence they may show signs. At that point it is just deniable, rather than plausibly deniable.

                For example, you can figure out VeraCrypt plausible deniability setups by calculating entropy of the disk: https://www.researchgate.net/publication/318155607_Defeating_Plausible_Deniability_of_VeraCrypt_Hidden_Operating_Systems (and tools support hidden volumes: https://github.com/4144414D/pytruecrypt). If you have physical access to the Disk then for the most part that's all you would need.

                CryptSetup/LUKS make some good discussion about plausible deniability encryption effectiveness: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects (See 5.18, the headers are not good on this article)

                And also Bruce Schneier: https://www.schneier.com/academic/paperfiles/paper-truecrypt-dfs.pdf

                There'd still be no evidence to collect since everything is encrypted and wouldn't be cracked if you didn't set it up stupidly. Same goes for GrapheneOS. Overall would be better to have an amnestic, immutable operating system or environment (TAILS, a disposable VM, amnestic profile, etc.) that doesn't save any data. The plausible deniability setups are suitable if you aren't accounting threats very in-depth forensics knowledge.

                A singular application like LockUp seems good on paper but like I previously said, investigators could easily just keep a spare phone to keep installing apps like this on to see what causes the app to trigger and then mitigate it from happening. A total solution like erasure on USB would work better but if something like that was an OS feature, they'd never plug the device in to bypass that. The entire system would need to be anti-forensic rather than just one application. From my experience I have found Windows Hyper-V Encrypted VMs/Application Guard instances, Qubes DispVMs, and TAILS to have little to no artefacts even if access to the operating system(s) were possible. I argue that could be more plausibly deniable than any disk encryption feature.

                LockUp is a Proof-of-Concept and hasn't been updated, it was made by a KoreLogic employee to make a POC detector for Cellebrite after they performed attacks on the UFED that they disclosed. I personally don't think it could be viable. Cellebrite would have probably fixed it, or if not, they could very easily. I'll probably give it a try and see for myself.

                Hb1hf
                Erasing your secondary profile or even a possible amnestic profile feature would be deniable. Keeping stuff in a secondary profile and erasing it would make it unable to be recovered completely. Much better reaching plausible deniability with this in my opinion. I think it would help.

                  This is the relevent issue that seems to be the best solution to the duress / panic pin / plausible deniability problem.

                  https://github.com/x13a/Wasted/issues/37

                  This should be combined with regular backup solution like seedvault that is implemented in gos.

                  You can stack that with something like syncthing for intenet / cross platform sync.

                  final Erasing your secondary profile or even a possible amnestic profile feature would be deniable.

                  I would really like a duress PIN on the owner profile that would silently delete specified secondary user profiles. That, and maybe delete specified apps and directories too.

                    Graphite the duress pin/password would ideally be universal, ie, accessible in every profile. No sense switching profiles, logging in and then handling someone a phone with only one profile.

                      Hb1hf

                      I wouldn't want to be on the profile that I want to covertly delete, when the time comes to use it. I wouldn't want them noticing it change at the lockscreen.

                      I wish there was a comprehensive system app for GrapheneOS that included all these options.

                        Graphite not sure we're saying the same thing or not.

                        My proposal is as follows: say the user has the owner profile with some very basic stuff, profile 2 which is your day to day profile, profile 3 with play services and maybe profile 4 with some extra sensitive stuff for people who need it (PS: I was thinking journalists, etc, but in my country it might just be banking apps)

                        In case of duress, that user wants to delete either profiles 2, 3 and 4 or just profile 4.

                        But, unless it's a predicable situation (like traveling to a country with known intrusive border control), users are more likely to be logged to profile 2 when the need arises. But maybe to profiles 3 or 4 as well.

                        So the duress PIN would have to be triggered from whatever profile the user was previously logged, erase the selected profiles (which might include the one currently selected) and then go back to the owner profile, hopefully without the "switching to profile X" message.

                          a year later

                          Hb1hf

                          To keep the thread alive... your idea is also what I would consider the most secure way to implement "plausible deniability"

                          To hand over a completely empty and wiped phone to anyone who lawfully or un-lawfully demands your credentials will just pizz them off and land you (or any other user) in hot water (either because it's considered "destruction of evidence" - or because the bad guys realize what you just did...)

                          unlocking the phone to land in a dummy-profile while in the background the real profiles (2, 3 and 4) get wiped solves the issue. Plus in most scenarios it will buy the user in a pinch enough time to complete the background wipe before anyone realizes what may or may not have happened... and at that point there is no trace of it left... hence "plausible deniability"

                          Further you could set up two potential profiles for spicy situations... one for a theft scenario where the phone starts sending distress signals in the background, and one for anything like border controls etc with no background signal.

                          If anyone is aware of such a solution since this post was last active, the input would be much appreciated.