Just found this on antiforensic reddit a few days ago, but the post and the account got banned for some reason.
Seems pretty decent IMO.
1 Like
If someone needs this level of security they should just buy a Pixel and install GrapheneOS. GOS is up to date and has the duress wipe feature.
9 Likes
I use Samsung Galaxy, and Pixel phones are not officially available where I live. I believe this tool would come in handy to those who can’t use pixel and graphene OS. Besides, it offers more sophisticated features than just simply wiping the whole device.
I have major doubts this tool is effective against the threat model its purporting to be for.
The application has not been updated for 2 years.
The protection provided by the application can be bypassed by booting the device into safe mode, where all user applications are disabled.
The application does not work on Android 14 and above.
EDIT: struck my text that was inaccurate as @8pen-s8urce pointed out
5 Likes
According to the Readme file available in this project’s GitHub repository, those are shortcommings of the Wasted app, an app that inspired Android AntiForensic Tools.
Please reread the “Features and Limitations” section of the Readme more carefully.
In all fairness, this section of the Readme could be written in a clearer manner to not mislead people at a first glance, I also initially thought those shortcommings were this app’s shortcommings, but they aren’t, at least not fully.
To quote the Readme (emphasis mine):
3 Likes
It allows you to prevent booting into safe mode using Dhizuku or root.
Other actions require either dhizuku privileges (device owner privileges that can be obtained via Dhizuku) or root privileges. Some actions can only be performed with root privileges, so it is recommended that you grant root rights to the application.
Rooting a phone to defeat forensics seems like a bad idea, doesn’t it? Not entirely sure how this app works, but rooted android do not have locked bootloaders and thus allow easy flashing of other recoveries without wiping data, making phone forensics Uber easy? Like connect phone to a computer, flash something, get all data levels of easy? Seems like a self defeating app.
Also safe deletion is not well implemented according to readme, and leaves behind logs, traces, etc. (and vulnerable to memory reading attacks, etc. too I’m sure).
If anyone is at risk of actually having forensics used against them, nothing less than Graphene OS (and maybe newest iPhones?) should be ideally recommended.
2 Likes
Just to make it clear, I didn’t want to endorse this app with my previous comment, I was simply correcting the comment I was replying to. When rereading it though, I notice it could be interpreted that way by accident, apologies for the possible confusion.
I agree with most of what you said, but I would like to reply to some parts of your post, for discussion and feedback.
Yes, it does. This app certainly has very significant drawbacks security wise, like the need to trust it with either device owner privileges using Dhizuku or root privileges, which seems counterintuitive for an app that is meant to improve security.
I made a quick search and different sources say different things when it comes to answering the following question: Is bootloader unlocking required to root an Android device?
Some say yes and some say no, so I don’t know, but even if the bootloader doesn’t need to be unlocked to root an Android device, rooting still poses a significant risk.
If someone knows whether unlocking the bootloader is usually needed to root an Android device, please comment.
For people with a treat model high enough to be worth using an app like this, it does come with too many security drawbacks and shouldn’t be relied upon.
Couldn’t have said it any better. 
2 Likes
Yes, rooting requires unlocking the bootloader. This is because the bootloader is responsible for enforcing verified boot. Thus, even if temporary privilege escalation (i.e. root) could be achieved through a vulnerability it would not persist through a reboot. To be clear I do not endorse rooting under any circumstances as it fundamentally undermines the Android security model and compromises your privacy.
2 Likes
Not really. The problem is that this particular solution is an unprivileged app that has no other way of gaining those privileges it needs. Using with root has its place in cases where the forensics are more important than security (post-hack, for example).
Yep. Ideally, something like this is built into the OS or with the OS (as System App). So if this app indeed has super nice abilities (I haven’t checked), then there’s a strong case to be made for its inclusion.
2 Likes
at no point we are going to recommend rooting devices to anyone. This really serves nobody. It massively increases attack vector and really is not in anyway going to help someone who needs anti forensics. If your thread model requires measures against forensics rooting is one of the worst things you could do.
1 Like
“Using with root has its place in cases where the forensics are more important than security (post-hack, for example).”
1 Like
It’s somewhat different from duress wipe feature: wiping the whole device will be obvious for adversary, this app allows to wipe only selected profile silently.
It seems that some devices (Pixels, Nothing phones) support relocking the bootloader after rooting. Unfortunately, on other devices, the bootloader must remain unlocked. However, these devices by themselves generally lack the same level of security as Pixels, which feature Titan chips. It’s unlikely to make budget devices secure against advanced adversaries using any application.
My app can perform specific functions with just device owner privileges, which doesn’t need unlocking bootloader, but it can’t even hide itself from settings after a data deletion in this mode. It can also be used as a Wasted app to wipe all data with just admin privileges (or owner privileges on newer devices), but it will be noticeable to an adversary.
For most devices, the app offers a trade-off: higher stealth means less security against skilled hackers. The best choice depends on your threat model. Consider what’s more likely in your case: an adversary attempting to extract your password through coercion and punishing you for any attempt to delete the data or attempting an advanced hacking attack?
ah I see but that is off topic/ unrelated to the comment before.
Anyway rooting a device for forensics is probably going to destroy the trustworthiness of the data found and more likely destroying the evidence. In certain cases phones are exploited to find new insights but use cases for that are limited. That is all off topic, the question is about defense.
I think it’s my fault that I didn’t make it clear in README.
You fundamentally misunderstand the security characteristics provided by verified boot. The purpose of verified boot is to verify the integrity of the operating system. Rooting the device, whether or not you re-enable verified boot by re-locking the bootloader afterwards, will compromise the security of the device. Re-enabling verified boot in this case offers no additional security and you won’t even have true root access based on the limited restrictions the project you linked enforces.
Firstly, the list of installed apps is not encrypted on Android, and I expect your app would still appear there. Regardless, the fact is that wiping data—such as by deleting the encryption key to a user profile—is not deniable on Android. There is no reason not to simply use owner privileges to wipe the device rather than employing security through obscurity in a way that will nullify the security of the OS.
I disagree that stealth and security are inversely related and even if they were I cannot agree that there is a realistic threat model that would justify breaking security guarantees for superficial stealth.
There is no way to silently wipe anything, you shouldn’t expect any stealth from these kinds of features. They only have one job, which is to either wipe a phone or something else.
2 Likes
It’s explained clearly in README file that there are two versions of app masquerading as other existing apps. After app self-destruction list of installed apps will contain only the package name of the application that my application was disguised as. I don’t deny that it is possible that even renaming the package will not prevent some patterns of the application activity from being detected by an advanced adversary, but I don’t see any trivial way to achieve this.
In some countries with, mhm, alternative approach to justice there is such a threat model.
My translation of beginning of this post in Russian:
So, one bad boy, who had a Punic Button on his smartphone (who do you think set it up?), was taken by policemen. The policemen, out of their feeble minds, put a smartphone in the boy’s hands and politely asked him: “Unlock it, we ask you with all our sergeant’s heart!”.
The boy pressed the button and the smartphone wiped.
Oh and beated this boy upset sergeants!
End of story.
Author also provides some cases when russian law put one suspect in jail because he wiped all his data and that looked suspicious for judge, and let other suspect go away because he just deleted some files on his phone.
I don’t know are there similar laws in other countries, but I don’t think that obvious evidence destruction won’t interest the adversary in some way.
Consider three scenarios:
A) Bootloader is locked, no duress passwords are used. Specialists from KGB don’t want to waste time on cracking the device password and ask politely to unlock the device. If subject refuse to unlock device, they start the process of thermorectal cryptoananlysis. Cryptoanalysis reveals device password, data is decrypted now.
B) Bootloader is locked, duress password wipes all the device. Specialists from KGB are very upset by the results of decryption process and bad behavior of cryptoanalysis subject. Russian “law” takes their side and put subject in jail.
C) Bootloader is unlocked, duress password wipes some data on device invisibly to the eyes of specialist. There is some chance that specialists from KGB will lost their interest to the subject or that specialists from local criminalistic lab would not find anything interesting or at least nothing really helpful during analysis. However, yes, there is the risk that KGB would not ask the password and send the device to criminalists immediately, and they would find the way to flash something and get all the data from device with unlocked bootloader. But if the bootloader was locked and retrieving data will fail, they can just ask specialists from KGB to help, and read scenarios 1-2 again. My app at least doesn’t make situation worse if subject is in hands of adversary not burdened by respect for human rights.
1 Like
That is kind of my point, I have not doubt your intentions are good but the reality is that Android is not designed to allow data to be deleted in a way that is deniable. The best defense against jurisdictions with key-disclosure laws is deniable encryption.
I do not disagree with the need for stealth but surely strong security and strong stealth would be preferable. This is achievable using deniable encryption as mentioned above.
As you have said there are clues that data has been deleted which are still fairly obvious to anyone with basic forensic tools. I do not believe it is likely that the outcome will be different from scenario (A) or (B) in scenario (C). Some chance of getting away with wiping data is not a reasonable approach when your life is in danger.
I get the feeling that I may have offended you, which was not my intention, so I would like to apologise if that is the case. I simply believe there are more robust approaches to accomplishing the same goals.
1 Like
You are right. But for deniable encryption to be really deniable it must be used with live OS. There’s TAILS OS for PC capable to open veracrypt volumes, but I don’t know any such OS for mobile devices, and I don’t see any obvious way to launch live OS on Android. Maybe guest mode may be used for this task, but it’s not convenient. Also there’s another problem. I know only two tools to open veracrypt volume on Android: paid EDS and cryptsetup in Termux which doesn’t work with users other than primary one. Both tools require root rights to mount a volume. Until these problem are solved, antiforensics for Android would always be inferior to PC antiforensics and deniable encryption wouldn’t work as it’s designed to work.
When a hidden volume is mounted, the operating system and third-party applications may write to non-hidden volumes (typically, to the unencrypted system volume) unencrypted information about the data stored in the hidden volume (e.g. filenames and locations of recently accessed files, databases created by file indexing tools, etc.), the data itself in an unencrypted form (temporary files, etc.), unencrypted information about the filesystem residing in the hidden volume (which might be used e.g. to identify the filesystem and to determine whether it is the filesystem residing in the outer volume), the password/key for the hidden volume, or other types of sensitive data.
Everything is OK, it’s hard topic and you was polite and correct. Thanks for your opinion!