Apps where AdGuard for Android can't filter and/or remove the ads from!

Boo Berry

Moderator + Beta Tester
Moderator
Here's a list of Android apps that AdGuard for Android can't filter and/or remove the ads from (due to whatever technical reasons - it's likely different case-to-case!). So there will be ads in these apps when running AdGuard for Android...

Facebook
Instagram
Twitter
UC Browser (can't be filtered because of the use of data compression)
YouTube

Keep in mind that Android 7.0 and above effectively prevents HTTPS filtering in most of the apps unless you have root access and can move the AdGuard certificate to the system store!

This list will be updated as more apps are found, thanks!
 

Grah

New Member
This is concerning as it implies that progressively more apps will implement ways to defeat ad blocking. Is more detailed information available about this problem and are efforts underway find a solution?

Here's a list of Android apps that AdGuard for Android can't filter and/or remove the ads from (due to whatever technical reasons - it's likely different case-to-case!). So there will be ads in these apps when running AdGuard for Android...

Facebook
Instagram
Twitter
YouTube (possibly/likely)

This list will be updated as more apps are found, thanks!
 

Boo Berry

Moderator + Beta Tester
Moderator
Well, in the case of Facebook and Instagram, from what I recall, attempting to block those ads would break the apps completely.

In regards to YouTube, they're using a new player where ads are double encrypted.
 
In regards to YouTube: Precisely for this reason I use the factory version, uninstalling (impossible to uninstall because system app) the latest version from the phone settings, have already passed 4 days without seeing advertising.
If you have the latest Android (beta) version exactly 2.10.56, import the settings from the file I have uploaded, uncheck the filter: "EasyList Italy" and select the one you are interested in.
 

Attachments

Bayazid B. Halim

New Member
Keep in mind that Android 7.0 and above effectively prevents HTTPS filtering in most of the apps unless you have root access and can move the AdGuard certificate to the system store!
I am interested in this. I have root access and I'd like to block the ads from the Twitter app.
 

Boo Berry

Moderator + Beta Tester
Moderator
The Twitter app, even with root access and certificate moved to the system store, can't have its ads removed. It's on the list above.
 

msxtj

New Member
So yup, Google and Facebook succeeded. With Android 7.0 unrooted, Youtube and Facebook are bloated with ads. Soon, all other apps will employ techniques used in the Youtube app and Adblockers will be out of a job.

-It is super ill-advised to root a Samsung phone as this blows up an eFuse and all Knox capabilities are gone. For some users (like me), Knox or Secure Folder is highly important.
 

UMX

Member
So yup, Google and Facebook succeeded. With Android 7.0 unrooted, Youtube and Facebook are bloated with ads. Soon, all other apps will employ techniques used in the Youtube app and Adblockers will be out of a job.

-It is super ill-advised to root a Samsung phone as this blows up an eFuse and all Knox capabilities are gone. For some users (like me), Knox or Secure Folder is highly important.
@avatar promised a new version where at least advanced users can restore ad protection.
Today AG doesn't even try to filter :(:mad:
 

Boo Berry

Moderator + Beta Tester
Moderator
The number of apps that can't be filtered by AG for Android will only increase as time passes, due to apps targeting the newer API level(s) that distrust user certificates.

Even rooting your phone and moving the certificate to the system store won't be much help with those apps that use double encryption, and thus can't be filtered either.
 

Bacevs

New Member
Is this relevant?

Universal Android SSL Pinning Bypass #2
The elegance of Frida is Dexguard prevents something it doesn't care about.

Frida works by looking at the application as it runs and does not mind if the bytecode is obfuscated because the application HAS TO call the Android/Java/iOS libraries and the methods/structs/etc they claim to actually do stuff.

The application can take the most meandering path to build a SSL/TLS network message to send out but there has to be a moment just before the message is encrypted using the Java/Android API that you can see the message in the clear in memory.

And then keep stepping backwards if you find issues. If you find the message just before SSL/TLS encrypt stage is alreadyencrypted, trace it back to other suspicious methods (hint, they will be using different crypto libraries and methods) and see what the message was before it was sent to those encrypted methods.

There are already apps out there can detect this with features like memory protection but the frida devs, the beasts that they are, are starting to work around that in amusing ways.

edit: There is no doubt dexguard can cause problems researching the application code to figure out what does what and while it will take longer, Frida can be used and even to the point that it takes advantage of lazy programmers who fully believe their application will never be attack and implement security controls that barely there or just plain wrong.
New Universal Android SSL Pinning Bypass based on Frida
Following the frida script published last year by Piergiovanni, we found another way to bypass all SSL certificate checks performed by most applications on Android devices, obviously including SSL pinning. This means that it can be used also without installing a valid CA on the device, which makes it a very nice tool to have when performing mobile applications penetration testings.
Why would someone “double encrypt”?
HTTPS only provides encryption while the message is in transit over the network/internet.

If the message is stored or processed by an intermediary (e.g. a message queue) at some point between the client and the server that finally processes it then it will not remain encrypted whilst it is in the intermediary.

Also, if the TLS/SSL is terminated at the service perimeters (e.g. on a load balancer) then it may not be encrypted on the internal network. This may be a problem where high security is required, for example in some regulated environments.

In both of these cases, message level encryption will ensure that the data is encrypted at all points in between the client and the final receiver.

As @honze said, this is called defense in depth and it is intended to ensure that even if a system is partially compromised (e.g. they manage to do a man-in-the-middle attack to compromise the SSL/TLS, or exploit a vulnerability in the message queue to get at the data at rest) the attacker cannot get at the protected data.
 
Last edited:

Altenburger

New Member
Bacevs said:

Is this relevant?
essays agency
Universal Android SSL Pinning Bypass #2

The elegance of Frida is Dexguard prevents something it doesn't care about.

Frida works by looking at the application as it runs and does not mind if the bytecode is obfuscated because the application HAS TO call the Android/Java/iOS libraries and the methods/structs/etc they claim to actually do stuff.

The application can take the most meandering path to build a SSL/TLS network message to send out but there has to be a moment just before the message is encrypted using the Java/Android API that you can see the message in the clear in memory.

And then keep stepping backwards if you find issues. If you find the message just before SSL/TLS encrypt stage is alreadyencrypted, trace it back to other suspicious methods (hint, they will be using different crypto libraries and methods) and see what the message was before it was sent to those encrypted methods.

There are already apps out there can detect this with features like memory protection but the frida devs, the beasts that they are, are starting to work around that in amusing ways.

edit: There is no doubt dexguard can cause problems researching the application code to figure out what does what and while it will take longer, Frida can be used and even to the point that it takes advantage of lazy programmers who fully believe their application will never be attack and implement security controls that barely there or just plain wrong.

Hello,

Have you tried Frida or Dexguard? I've just found DexGuard vs. ProGuard compared. But is it possible to recover SQLCipher encrypted data with Dexguard? Thanks.
 
Top