[Magisk] ataraxist:
This is the best write up about safetynet...and it check many items...not just selinux. Any of the following can cause Safetynet to fail.

Credits to ==> https://koz.io/inside-safetynet/

EnterSnet

The system is very modular: snet can be started by Play Services using a configuration file that defines which collection modules will be used. Not all of them are enabled by default.

Let's see what each of these modules does in more detail:

default_packages

This creates a list of the preferred packages for certain actions and reports back which packages are used for web browsing and package installations. It specifically checks if the preferred web browser is com.android.browser or com.android.chrome.

I can assume this is done to detect situations where a user has authorised a non-standard browser that could be a malware - Google could maintain a list on their backend.

su_files

Reports back if the files /system/bin/su or /system/xbin/su exist. If they do, it is a clear indication of tampering.

I do hope that the attestation result is not solely based on this check - although there's evidence it plays a major role. On a non-infected, just rooted device, moving these files elsewhere seems to result in a positive attestation result. The same result is achieved via actions like "Disable SuperSU". Maybe Google is being extra cautious.

settings

Collects various security-related fields from android.provider.Settings$Secure or android.provider.Settings$Global depending on the OS version. Settings collected include the values of variables like adb_enabled, install_non_market_apps, isKeyguardSecure(), getNotificationVisibility(), lock_screen_lock_after_timeout, lockscreen.password_type, lock_pattern_autolock.

Obviously all these are indications that something might be 'interesting' about the device.

locale

Reports back the current locale configuration of the device.

I assume this is done so that they can risk profile users according to locality and adjust their thresholds as needed.

ssl_redirect

This is an interesting module. It tries to establish if the device correctly follows SSL redirects. It collects information like the type of the active connection, the DNS servers in use, the available connections.

It then creates a request to the following hosts: http://accounts.google.com, http://www.google.com, http://pubads.g.doubleclick.net - using random user agent, even mimicking an iPhone, having 'follow redirects' disabled. All these hosts redirect to HTTPS versions of the sites and the module collects the Location HTTP header from the redirect response.

It then does the same request again, this time following the redirects. After the redirects reports back the IP and hostname of the the final endpoint host. This second request is even done randomly using either ApacheHTTPclient classes or HttpURLConnection(!)

Some people asked for more information about the doubleclick.net domain. This is a domain used to serve advertisements to applications and the service is owned by Google. I can only assume this is also an attempt to detect if an ad-blocker is installed.

ssl_handshake

This anothere very interesting module. It attempts to figure out if communications can be intercepted in a number of ways, such as via having an SSL-Kill-Switch app installed.

The code attempts to contact three hosts: accounts.google.com, www.google.com, pubads.g.doubleclick.net

For each host the following algorithm is followed and all results of every step are captured, along with any possible errors.

The module attempts an SSL socket connection using an 'accept-all' TrustAllX509TrustManager.

The peer certificates are retrieved

The code finds all TrustManagers of the system

Each found TrustManager is initialized with no trust anchors and the checkServerTrusted() method is executed on the retrieved certificate chain. This would normally throw exceptions but under most SSL Kill Switch implementations it will not. The code verifies if exceptions are thrown (great check)

TheDefaultHostnameVerifier is used to verify the hostname of the connection

Then the module manually validates the certificate chain, also checking if any certificates use MD5withRSA algorithm and public keys shorter than 2048 bits.

For each received certificate in the chain, the module checks if the issuer exists in the CA store of the system (/system/etc/security/cacerts) OR if it has been added by the user (/data/misc/keychain/cacerts-added)

The module also includes a hardcoded, pinned intermediate certificate for Google and checks if it matches one of the received chain certificates

Finally the Enhanced Key Usage Object Identifiers of the leaf certificate are also retrieved and compared with a hardcoded list (!)

After all these checks, all the information as to whether the connections succeeded, what were the received certificates, if chain validation and trust checks passed, is sent back to Google.

mx_record

For each of the DNS server set up on the device, the gmail.com hostname is resolved and the MX servers are collected, along with the full DNS response.

I assume this exists in order to detect if the device is configured in a way that lets attackers intercept emails.

sslv3_fallback

Connects to https://www.google.com using an SSL Socket initiated with TLS, making use of SNI extensions and SessionTicket features. It gathers if the socket was connected and if hostname verification passes. If the connection doesn't go through, it is retried using SSLv3 instead of the modern TLS features mentioned above. The module collects all resulting artifacts and error messages.

This module is obviously designed to detect network related attacks like SSL downgrade.

proxy

Collects whether there are proxies configured on the device, what are their IP addresses and if these IPs are local IPs for the device.

This tries to establish if there is a traffic-snooping malware on the device (some malware - and ad-blockers - work using proxies) or if the communication is sent to external known-bad locations.

selinux_status

Collects if SELinux support is available on the device (if /sys/fs/selinux/enforce is present) and if it is in enforcing mode (via reading the contents of that file)

If SELinux is in non-enforcing mode on newer Android versions it is a clear indication that something fishy is going on.

sd_card_test

Attempts to understand if the SD card has been tampered with. This creates a JPEG file named gmsnet2.jpg on the SD card, fills it with some hard-coded content. IT then analyses if the length of the file matches a hard-coded value and verifies if the written bytes match what was sent, byte by byte.

I am not sure I understand why this check exists and under what security-related conditions it would fail.

google_page_info

Tries to determine if the length of the HTML code of www.google.com exceeds some preconfigured threshold.

I assume this tries to establish if there is some form of javascript injection happening on pages the user sees.

captive_portal_test

Collects the IP address of clients3.google.com. It then uses a random user agent to connect to http://clients3.google.com/generate_204 and captures the response's return code and the body length.

This tries to establish if the device uses a captive portal that redirects responses. Captive portals can be used as a way to perform MitM attacks.

logcat

Runs the logcat -d command and looks for a configurable set of 'interesting strings'.

Google could just upload all logs to their servers and search in them there, but I am guessing it took this approach so that it avoids accidentally leaking user-private information. The set of 'interesting strings' is empty by default, so I can't tell what they are looking for.

event_log

Similar to the logcat check but for EventLog events. Skips events with a do-not-log- tag prefix.

apps

First checks if a Google Account exists on the device. Then, depending on configuration switches provided by Google Play, it can gather and report information about all Non-System Apps or all System Apps.

This is module is not enabled by default. During application tests we flag such behavior as a privacy issue. But I guess Google already knows which apps you have installed, since you most likely used Google Play to do it, thus it is probably not much of leak. I can understand why Google would be interested to see what other apps are installed on the device.

google_page

Retrieves the http://www.google.com page using a random user agent and stores the received HTML code.

suspicious_google_page

This is the same as the google_page test but first uses the results of the ssl_handshake and the ssl_redirect tests, trying to determine if connections are secure for www.google.com. If they are not, no results are saved.

This sends the retrieved HTML code back to Google. I guess they try to understand if some malware is locally intercepting traffic and injecting things in the HTML.

gmscore

Collects information about the com.google.android.gms application on the device. This is the Google Mobile Services application, also known as Play Services. Information collected includes the full path to the APK and the package signatures.

Here Google tries to see if something (e.g. malware) has tried to statically tamper with play services.

attest

Does an attestation request and collects the AttestationInfo response.

Would be interesting to know how much past attestation results are considered in the calculation of newer responses.

device_admin_deactivator

Retrieves the active device administrators of the device, if any. Checks them against the contents of a file named device_admin_blacklist.txt. This is included in the downloaded snet.jar file and contains more than 70 entries like the following:

com.android.vendlng,66fd5cb0,f84d0d9f

org.helpzek.minecraft,1cf1e47b

google.android.xmppm,e39125e5,40c7d1e7

org.zl.zlorg,d2a16633,38d1153c

com.devguru.minecraft,9746f466

com.adobe.flplayer,1c0ec8e1,98837829,08dadccb,b094083a,81565420,76a05ce0,e5f7325e

com.android.pfx12,dc61b3d0

com.cryengine.gplay,61996cf8

com.wikihelp.minecraftwikiversion,2379f1d0

com.xsys.cfgs,749a7f99,3c0a9c89

com.cheatgroup.app,d2ef0ea4

This is a HashMap where keys are package names and values are the prefixes of the sha256 hash of a full path name.

If it is found that any of the blacklisted apps, on the correct APK path, is an active device admin, then removeActiveAdmin() is called to remove the admin and the package is stopped using forceStopPackage(). The application info for device admin packages is collected.

As evident this goes beyond collection and actualy attempts to protect the device against dangerous applications using a blacklisting approach.

system_partition_files

Collects various information about a configurable list of files of interest under /system. Information includes all permissions, names of files, symlink targets, selinux security context, hashes etc. Currently the list of files of interest seems empty.

It is interesting that the framework makes use of red herring in order to confuse attackers: along with the files of interest, a configurable number of random files can be accessed in the same way.

Great stuff, red herring approaches are commonly used in advanced app protection products. However this is not enabled by default.

system_ca_cert_store

The module contains a configurable list of sha256 hashes of certificates. This check looks at the contents of /system/etc/security/cacerts or /system/etc/security/cacerts.bks (pre-ICS) trying to find those and returns them if found, either the full certs or just subject name, issuer name and signature information, again configurable.

This attempts to understand if traffic is being intercepted via looking for blacklisted certificates. There's malware that drops malicious certificates in the cert store, allowing SSL traffic to be intercepted on the network layer.

setuid_files

This check, as you would expect, collects information about setuid files present in the filesystem. It uses libcore.io.StructStat and libcore.io.OsConstants, libcore.io.OS, libcore.io.Libcore and related classes to retrieve the information.

Presense of setuid executables is an obvious red flag in newer Android versions.