Pegasus, Auditor and the Mobile Verification Toolkit - some questions

circlingdante

I was hoping that someone who understands how Auditor works would be able to answer a few questions I have.

The Mobile Verification Toolkit is a pretty cool project that makes it possible to look for Indicators of Compromise for Pegasus and other spyware with STIX data - see the docs.

This technical overview describes how Pegasus works. What I'm wondering is what (if any) features of Pegasus would go unnoticed by Auditor - I understand that Auditor protects against firmware and OS tampering, but are there limitations to the OS tamper-evidence? Knowing these gaps would enable me to use the MVT more effectively to look for what isn't covered by Auditor.

Thanks!

Nuttso

circlingdante auditor is most useful after rebooting the device. It can't protect against or detect an attack on a already running device. Everything that the os provides as information could be tempered with. It's very hard to put an persistent attack on graphene. The phone shouldn't start if anything is tempered that is covered by verified boot. The attacker has to infect the phone after every reboot, if he wants to stay undetectable. Which indeed could also be an easy task if they have a working chain of exploit. If they don't make any changes to the verified boot covered stuff, than auditor won't be much of a help. It's actually impossible to monitor the running os in any useful way to detect attacks.

[deleted]

Nuttso What if the tampering occured BEFORE graphene was installed? For example a persistent attack was successful, then grapheneOS is flashed. Should the persistence be deleted? Can you think of any circumstance it would still be able to persist? (Other than RE-INFECTING the device, through means outside of the local device)

Thanks!

Nuttso

[deleted] read this https://source.android.com/docs/security/features/verifiedboot

circlingdante

What is Auditor doing at a high-level overview - hashing the firmware and OS files and comparing that value to hashes stored in the Titan M chip? I'm wondering if sophisticated Android malware could persist a reboot in ways that are out of scope for Auditor to check. One vector that is out of scope for Auditor seems to be a malicious apk that doesn't tamper with OS files?