Create consistency in wording in v2 tests

.github/instructions/mastg-test.instructions.md

@@ -185,7 +185,7 @@ Example:
 ```md
 ## Steps
 
-1. Run @MASTG-TECH-0014 on the app and look for insecure random APIs.
+1. Use @MASTG-TECH-0014 to look for insecure random APIs.
 ```
 
 Notes:

demos/android/MASVS-NETWORK/MASTG-DEMO-0048/MASTG-DEMO-0048.md

@@ -18,7 +18,7 @@ The following sample code demonstrates how to connect to a @MASTG-TOOL-0143 serv
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `SSLSocket` and `HostnameVerifier`.
+2. Use @MASTG-TECH-0014 to look for all usages of `SSLSocket` and `HostnameVerifier`.
 
 {{ ../../../../rules/mastg-android-ssl-socket-hostnameverifier.yml }}
 

demos/android/MASVS-NETWORK/MASTG-DEMO-0049/MASTG-DEMO-0049.md

@@ -18,7 +18,7 @@ However, the code implements a custom `HostnameVerifier` that performs hostname
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `SSLSocket` and `HostnameVerifier`.
+2. Use @MASTG-TECH-0014 to look for all usages of `SSLSocket` and `HostnameVerifier`.
 
 {{ ../../../../rules/mastg-android-ssl-socket-hostnameverifier.yml }}
 

techniques/android/MASTG-TECH-0005.md

@@ -5,7 +5,7 @@ platform: android
 
 ## Basic APK Installation
 
-Use `adb install` to install an APK on an emulator or connected device. The given path is the path of the APK on the host.
+Use `adb install` (@MASTG-TOOL-0004) to install an APK on an emulator or connected device. The given path is the path of the APK on the host.
 
 ```bash
 adb install ./myApp.apk

tests-beta/android/MASVS-CODE/MASTG-TEST-0245.md

@@ -19,7 +19,7 @@ Android apps specify a `minSdkVersion`, which defines the oldest OS version they
 
 ## Steps
 
-1. Use either @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 to identify APIs that check the version of the operating system.
+1. Use @MASTG-TECH-0014 to look for APIs that check the version of the operating system.
 
 ## Observation
 

tests-beta/android/MASVS-CODE/MASTG-TEST-0272.md

@@ -9,11 +9,11 @@ profiles: [L1, L2]
 
 ## Overview
 
-In this test case we will identify dependencies in Android Studio and scan them with @MASTG-TOOL-0131.
+In this test case we will identify dependencies in Android Studio.
 
 ## Steps
 
-1. Follow @MASTG-TECH-0131 and execute a scan through the build environment of Android Studio by using Gradle.
+1. Use @MASTG-TECH-0131 to scan through the build environment of Android Studio by using Gradle.
 
 ## Observation
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0204.md

@@ -19,7 +19,7 @@ In general, if a PRNG is not explicitly documented as being cryptographically se
 
 ## Steps
 
-1. Run a static analysis (@MASTG-TECH-0014) tool on the app and look for insecure random APIs, or you can use @MASTG-TECH-0033 to detect the use of such APIs.
+1. Use @MASTG-TECH-0014 or use @MASTG-TECH-0033 to look for insecure random APIs.
 2. For each of the identified API uses, check if they are used in a security relevant context. You can decompile the app (@MASTG-TECH-0017) and inspect the code (@MASTG-TECH-0023) to confirm.
 
 ## Observation

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0205.md

@@ -17,7 +17,7 @@ Android applications sometimes use non-random sources to generate "random" value
 
 ## Steps
 
-1. Run a static analysis (@MASTG-TECH-0014) tool on the app and look for uses of non-random sources.
+1. Use @MASTG-TECH-0014 to look for uses of non-random sources.
 
 ## Observation
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md

@@ -20,7 +20,7 @@ For more information you can consult the MASTG section about ["Key Generation"](
 
 ## Steps
 
-1. Run a static analysis tool such as @MASTG-TOOL-0110 on the code and look for uses of the cryptographic functions that generate keys.
+1. Use @MASTG-TECH-0014 to look for uses of the cryptographic functions that generate keys.
 
 ## Observation
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0212.md

@@ -13,7 +13,7 @@ In this test case, we will look for the use of hardcoded keys in Android applica
 
 ## Steps
 
-1. Use either @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 or @MASTG-TECH-0033 (dynamic analysis) with a tool like @MASTG-TOOL-0001 to identify all the instances of symmetric key encryption in code and look for uses of the hardcoded cryptographic keys.
+1. Use @MASTG-TECH-0014 or @MASTG-TECH-0033 to look for all the instances of symmetric key encryption in code and look for uses of the hardcoded cryptographic keys.
 
 ## Observation
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md

@@ -27,7 +27,7 @@ Android also provides additional guidance on [broken cryptographic algorithms](h
 
 ## Steps
 
-1. Run @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 on the app binary, or use @MASTG-TECH-0033 (dynamic analysis) with a tool like @MASTG-TOOL-0001, and look for uses of the cryptographic functions that perform encryption and decryption operations.
+1. Use @MASTG-TECH-0014 or use @MASTG-TECH-0033 to look for uses of the cryptographic functions that perform encryption and decryption operations.
 
 ## Observation
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md

@@ -10,17 +10,17 @@ profiles: [L1, L2]
 
 ## Overview
 
-To test for the [use of broken encryption modes](../../../Document/0x04g-Testing-Cryptography.md#broken-block-cipher-modes) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
+To test for the [use of broken encryption modes](../../../Document/0x04g-Testing-Cryptography.md#broken-block-cipher-modes) in Android apps, we should focus on methods in cryptographic frameworks and libraries used to configure and apply encryption modes.
 
-In Android development, the `Cipher` class from the Java Cryptography Architecture (JCA) is the primary API that allows you to specify the encryption mode for cryptographic operations. [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)) defines the transformation string, which includes the encryption algorithm, mode of operation, and padding scheme. The general format is `"Algorithm/Mode/Padding"`. For example:
+In Android development, the `Cipher` class from the Java Cryptography Architecture (JCA) is the primary API for specifying the encryption mode for cryptographic operations. [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)) defines the transformation string, which includes the encryption algorithm, mode of operation, and padding scheme. The general format is `"Algorithm/Mode/Padding"`. For example:
 
 ```kotlin
 Cipher.getInstance("AES/ECB/PKCS5Padding")
 ```
 
-In this test we're going to focus on symmetric encryption modes such as [ECB (Electronic Codebook)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB)).
+In this test, we're going to focus on symmetric encryption modes such as [ECB (Electronic Codebook)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB)).
 
-ECB (defined in [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final)) is generally discouraged [see NIST announcement in 2023](https://csrc.nist.gov/news/2023/decision-to-revise-nist-sp-800-38a) due to its inherent security weaknesses. While not explicitly prohibited, its use is limited and advised against in most scenarios. ECB is a block cipher mode that operate deterministically, dividing plaintext into blocks and encrypting them separately, which reveals patterns in the ciphertext. This makes it vulnerable to attacks like [known-plaintext attacks](https://en.wikipedia.org/wiki/Known-plaintext_attack) and [chosen-plaintext attacks](https://en.wikipedia.org/wiki/Chosen-plaintext_attack).
+ECB (defined in [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final)) is generally discouraged [see NIST announcement in 2023](https://csrc.nist.gov/news/2023/decision-to-revise-nist-sp-800-38a) due to its inherent security weaknesses. While not explicitly prohibited, its use is limited and advised against in most scenarios. ECB is a block cipher mode that operates deterministically, dividing plaintext into blocks and encrypting them separately, which reveals patterns in the ciphertext. This makes it vulnerable to attacks like [known-plaintext attacks](https://en.wikipedia.org/wiki/Known-plaintext_attack) and [chosen-plaintext attacks](https://en.wikipedia.org/wiki/Chosen-plaintext_attack).
 
 For example, the following transformations are all [considered vulnerable](https://support.google.com/faqs/answer/10046138?hl=en):
 
@@ -31,13 +31,13 @@ For example, the following transformations are all [considered vulnerable](https
 
 You can learn more about ECB and other modes in [NIST SP 800-38A - Recommendation for Block Cipher Modes of Operation: Methods and Techniques](https://csrc.nist.gov/pubs/sp/800/38/a/final). Also check the [Decision to Revise NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques](https://csrc.nist.gov/news/2023/decision-to-revise-nist-sp-800-38a) and [NIST IR 8459 Report on the Block Cipher Modes of Operation in the NIST SP 800-38 Series](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf) for the latest information.
 
-**Out of Scope**: Asymmetric encryption modes like RSA are out of scope for this test because they don't use block modes like ECB.
+**Out of Scope**: Asymmetric encryption modes, such as RSA, are out of scope for this test because they don't use block modes like ECB.
 
 In the transformation strings like `"RSA/ECB/OAEPPadding"` or `"RSA/ECB/PKCS1Padding"`, the inclusion of `ECB` in this context is misleading. Unlike symmetric ciphers, **RSA doesn't operate in block modes like ECB**. The `ECB` designation is a [placeholder in some cryptographic APIs](https://github.com/openjdk/jdk/blob/680ac2cebecf93e5924a441a5de6918cd7adf118/src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java#L126) and doesn't imply that RSA uses ECB mode. Understanding these nuances helps prevent false positives.
 
 ## Steps
 
-1. Run @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 on the app binary, or use @MASTG-TECH-0033 (dynamic analysis) with a tool like @MASTG-TOOL-0001, and look for cryptographic functions specifying the encryption mode to insecure modes.
+1. Use @MASTG-TECH-0014 or use @MASTG-TECH-0033 to look for cryptographic functions specifying the encryption mode to insecure modes.
 
 ## Observation
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0307.md

@@ -23,7 +23,7 @@ The [`KeyGenParameterSpec.Builder`](https://developer.android.com/reference/andr
 
 ## Steps
 
-1. Run static analysis (@MASTG-TECH-0014) on the app and look for key generation code for asymmetric keys.
+1. Use @MASTG-TECH-0014 to look for key generation code for asymmetric keys.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0217.md

@@ -28,7 +28,7 @@ The API call `okhttp3.ConnectionSpec.Builder.tlsVersions(...)` can also be used
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Run a static analysis (@MASTG-TECH-0014) tool on the reverse engineered app targeting calls to APIs setting the TLS protocol.
+2. Use @MASTG-TECH-0014 on the reverse-engineered app to look for calls to APIs setting the TLS protocol.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0233.md

@@ -18,7 +18,7 @@ An Android app may have hardcoded HTTP URLs embedded in the app binary, library
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Run a static analysis (@MASTG-TECH-0014) tool and look for any `http://` URLs.
+2. Use @MASTG-TECH-0014 to look for any `http://` URLs.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0234.md

@@ -20,7 +20,7 @@ Such unsafe implementations can allow an attacker to run a [MITM attack](../../.
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `SSLSocket` and `HostnameVerifier`.
+2. Use @MASTG-TECH-0014 to look for all usages of `SSLSocket` and `HostnameVerifier`.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0282.md

@@ -16,7 +16,7 @@ Such unsafe implementations can allow an attacker to run a [MITM attack](../../.
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Run a static analysis (@MASTG-TECH-0014) tool for the app and look for all usages of `checkServerTrusted(...)`.
+2. Use @MASTG-TECH-0014 to look for all usages of `checkServerTrusted(...)`.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0283.md

@@ -16,7 +16,7 @@ Such unsafe implementations can allow an attacker to run a [MITM attack](../../.
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Inspect the source code and run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `HostnameVerifier`.
+2. Inspect the source code and use @MASTG-TECH-0014 to look for all usages of `HostnameVerifier`.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0284.md

@@ -18,7 +18,7 @@ This effectively bypasses SSL certificate checks in the `WebView`, exposing the
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Inspect the source code and run a static analysis (@MASTG-TECH-0014) tool and look for all usages of `onReceivedSslError(...)`.
+2. Inspect the source code and use @MASTG-TECH-0014 to look for all usages of `onReceivedSslError(...)`.
 
 ## Observation
 

tests-beta/android/MASVS-NETWORK/MASTG-TEST-0295.md

@@ -15,7 +15,7 @@ This test checks whether the Android app ensures the Security Provider (@MASTG-K
 ## Steps
 
 1. Reverse engineer the app (@MASTG-TECH-0017).
-2. Use static analysis (@MASTG-TECH-0014) to search for usage of `ProviderInstaller.installIfNeeded` or `ProviderInstaller.installIfNeededAsync`.
+2. Use MASTG-TECH-0014 to look for usage of `ProviderInstaller.installIfNeeded` or `ProviderInstaller.installIfNeededAsync`.
 
 ## Observation
 

tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0250.md

@@ -12,26 +12,26 @@ profiles: [L1, L2]
 
 ## Overview
 
-This test checks for references to Content Provider access in WebViews which is enabled by default and can be disabled using the `setAllowContentAccess` method in the `WebSettings` class. If improperly configured, this can introduce security risks such as unauthorized file access and data exfiltration.
+This test checks for references to Content Provider access in WebViews, which is enabled by default and can be disabled using the `setAllowContentAccess` method in the `WebSettings` class. If improperly configured, this can introduce security risks such as unauthorized file access and data exfiltration.
 
-The JavaScript code would have access to any content providers on the device such as:
+The JavaScript code would have access to any content providers on the device, such as:
 
 - declared by the app, **even if they are not exported**.
 - declared by other apps, **only if they are exported** and if they are not following recommended [best practices](https://developer.android.com/privacy-and-security/security-tips#content-providers) to restrict access.
 
-Refer to [WebView Content Provider Access](../../../Document/0x05h-Testing-Platform-Interaction.md/#webview-content-provider-access) for more information on the `setAllowContentAccess` method, the specific files that can be accessed and the conditions under which they can be accessed.
+Refer to [WebView Content Provider Access](../../../Document/0x05h-Testing-Platform-Interaction.md/#webview-content-provider-access) for more information on the `setAllowContentAccess` method, the specific files that can be accessed, and the conditions under which they can be accessed.
 
 **Example Attack Scenario:**
 
-Suppose a banking app uses a WebView to display dynamic content. The developers have not explicitly set the `setAllowContentAccess` method, so it defaults to `true`. Additionally, JavaScript is enabled in the WebView as well as the `setAllowUniversalAccessFromFileURLs` method.
+Suppose a banking app uses a WebView to display dynamic content. The developers have not explicitly set the `setAllowContentAccess` method, so it defaults to `true`. Additionally, JavaScript is enabled in the WebView, and the `setAllowUniversalAccessFromFileURLs` method is also used.
 
 1. An attacker exploits a vulnerability (such as an XSS flaw) to inject malicious JavaScript into the WebView. This could occur through a compromised or malicious link that the WebView loads without proper validation.
-2. Thanks to `setAllowUniversalAccessFromFileURLs(true)`, the malicious JavaScript can issue requests to `content://` URIs to read locally stored files or data exposed by content providers. Even those content providers from the app that are not exported can be accessed because the malicious code is running in the same process and same origin as the trusted code.
+2. Thanks to `setAllowUniversalAccessFromFileURLs(true)`, the malicious JavaScript can issue requests to `content://` URIs to read locally stored files or data exposed by content providers. Even those content providers in the app that are not exported can be accessed because the malicious code runs in the same process and origin as the trusted code.
 3. The attacker-controlled script exfiltrates sensitive data from the device to an external server.
 
 **Note 1:** We do not consider `minSdkVersion` since `setAllowContentAccess` defaults to `true` regardless of the Android version.
 
-**Note 2:** The provider's `android:grantUriPermissions` attribute is irrelevant in this scenario as it does not affect the app itself accessing its own content providers. It allows **other apps** to temporary access URIs from the provider even though restrictions such as `permission` attributes, or `android:exported="false"` are set. Also, if the app uses a `FileProvider`, the `android:grantUriPermissions` attribute must be set to `true` by [definition](https://developer.android.com/reference/androidx/core/content/FileProvider#:~:text=Set%20the%20android:grantUriPermissions%20attribute%20to%20true%2C%20to%20allow%20you%20to%20grant%20temporary%20access%20to%20files.%20) (otherwise you'll get a `SecurityException: Provider must grant uri permissions"`).
+**Note 2:** The provider's `android:grantUriPermissions` attribute is irrelevant in this scenario as it does not affect the app itself accessing its own content providers. It allows **other apps** to temporarily access URIs from the provider even though restrictions such as `permission` attributes, or `android:exported="false"` are set. Also, if the app uses a `FileProvider`, the `android:grantUriPermissions` attribute must be set to `true` by [definition](https://developer.android.com/reference/androidx/core/content/FileProvider#:~:text=Set%20the%20android:grantUriPermissions%20attribute%20to%20true%2C%20to%20allow%20you%20to%20grant%20temporary%20access%20to%20files.%20) (otherwise you'll get a `SecurityException: Provider must grant uri permissions"`).
 
 **Note 3:** `allowUniversalAccessFromFileURLs` is critical in the attack since it relaxes the default restrictions, allowing pages loaded from `file://` to access content from any origin, including `content://` URIs.
 
@@ -47,7 +47,7 @@ While the `fetch` request to the external server would still work, retrieving th
 
 ## Steps
 
-1. Use a tool like semgrep to search for references to:
+1. Use @MASTG-TECH-0014 to look for references to:
       - the `WebView` class.
       - the `WebSettings` class.
       - the `setJavaScriptEnabled` method.
@@ -59,7 +59,7 @@ While the `fetch` request to the external server would still work, retrieving th
 
 The output should contain:
 
-- A list of WebView instances including the following methods and their arguments:
+- A list of WebView instances, including the following methods and their arguments:
     - `setAllowContentAccess`
     - `setJavaScriptEnabled`
     - `setAllowUniversalAccessFromFileURLs`
@@ -69,7 +69,7 @@ The output should contain:
 
 **Fail:**
 
-The test fails if all of the following are true:
+The test fails if all the following are true:
 
 - `setJavaScriptEnabled` is explicitly set to `true`.
 - `setAllowContentAccess` is explicitly set to `true` or _not used at all_ (inheriting the default value, `true`).

tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0251.md

@@ -16,7 +16,7 @@ This test is the dynamic counterpart to @MASTG-TEST-0250.
 
 ## Steps
 
-1. Run a dynamic analysis tool like @MASTG-TOOL-0001 and either:
+1. Use @MASTG-TECH-0015 to either:
     - enumerate instances of `WebView` in the app and list their configuration values
     - or explicitly hook the setters of the `WebView` settings
 
@@ -28,7 +28,7 @@ The output should contain a list of WebView instances and corresponding settings
 
 **Fail:**
 
-The test fails if all of the following are true:
+The test fails if all the following are true:
 
 - `JavaScriptEnabled` is `true`.
 - `AllowContentAccess` is `true`.