Fix broken links to 0x05|6c-Reverse-Engineering-and-Tampering.md

.github/workflows/config/url-checker-config.json

@@ -72,6 +72,12 @@
  {
  "pattern": "^https://secrary.com/"
  },
+ {
+ "pattern": "^https://www.reddit.com/r/"
+ },
+ {
+ "pattern": "^https://www.netspi.com/blog/technical-blog/"
+ },
  {
  "pattern": "^MASTG/"
  },

Document/0x04c-Tampering-and-Reverse-Engineering.md

@@ -123,7 +123,7 @@ Control flow flattening replaces original code with a more complex representatio
 
 <img src="Images/Chapters/0x06j/control-flow-flattening.png" width="100%" />
 
-The image shows how control flow flattening alters code. See ["Obfuscating C++ programs via control flow flattening"](http://ac.inf.elte.hu/Vol_030_2009/003.pdf) for more information.
+The image shows how control flow flattening alters code. See ["Obfuscating C++ programs via control flow flattening"](https://web.archive.org/web/20240414202600/http://ac.inf.elte.hu/Vol_030_2009/003.pdf) for more information.
 
 #### Dead Code Injection
 
@@ -165,7 +165,7 @@ QEMU based emulators for Android take into consideration the RAM, CPU, battery p
 
 In simple words, an emulator is a much closer imitation of the targeted platform, while a simulator mimics only a part of it.
 
-Running an app in the emulator gives you powerful ways to monitor and manipulate its environment. For some reverse engineering tasks, especially those that require low-level instruction tracing, emulation is the best (or only) choice. Unfortunately, this type of analysis is only viable for Android, because no free or open source emulator exists for iOS (the iOS simulator is not an emulator, and apps compiled for an iOS device don't run on it). The only iOS emulator available is a commercial SaaS solution - [Corellium](0x06c-Reverse-Engineering-and-Tampering.md#corellium). We'll provide an overview of popular emulation-based analysis frameworks for Android in the "Tampering and Reverse Engineering on Android" chapter.
+Running an app in the emulator gives you powerful ways to monitor and manipulate its environment. For some reverse engineering tasks, especially those that require low-level instruction tracing, emulation is the best (or only) choice. Unfortunately, this type of analysis is only viable for Android, because no free or open source emulator exists for iOS (the iOS simulator is not an emulator, and apps compiled for an iOS device don't run on it). The only iOS emulator available is a commercial SaaS solution - [Corellium](../techniques/ios/MASTG-TECH-0088.md#corellium).
 
 ### Custom Tooling with Reverse Engineering Frameworks
 

Document/0x05e-Testing-Cryptography.md

@@ -142,7 +142,7 @@ SecretKey secretKey = keyGenerator.generateKey();
 
 The `KeyGenParameterSpec` indicates that the key can be used for encryption and decryption, but not for other purposes, such as signing or verifying. It further specifies the block mode (CBC), padding (PKCS #7), and explicitly specifies that randomized encryption is required (this is the default). Next, we enter `AndroidKeyStore` as the name of the provider in the `KeyGenerator.getInstance` call to ensure that the keys are stored in the Android KeyStore.
 
-GCM is another AES block mode that provides additional security benefits over other, older modes. In addition to being cryptographically more secure, it also provides authentication. When using CBC (and other modes), authentication would need to be performed separately, using HMACs (see the ["Tampering and Reverse Engineering on Android"](0x05c-Reverse-Engineering-and-Tampering.md) chapter). Note that GCM is the only mode of AES that [does not support padding](https://developer.android.com/training/articles/keystore.html#SupportedCiphers "Supported Ciphers in AndroidKeyStore").
+GCM is an AES mode that provides [authenticated encryption](https://en.wikipedia.org/wiki/Authenticated_encryption "Authenticated encryption"), enhancing security by integrating encryption and data authentication into a single process, unlike older modes such as CBC that require separate mechanisms such as HMACs. In addition, GCM does not require padding, which simplifies implementation and minimizes vulnerabilities.
 
 Attempting to use the generated key in violation of the above spec would result in a security exception.
 
@@ -233,7 +233,7 @@ The above method requires a character array containing the password and the need
 
 > Note that if you take a rooted device or a patched (e.g. repackaged) application into account as a threat to the data, it might be better to encrypt the salt with a key that is placed in the `AndroidKeystore`. The Password-Based Encryption (PBE) key is generated using the recommended `PBKDF2WithHmacSHA1` algorithm, until Android 8.0 (API level 26). For higher API levels, it is best to use `PBKDF2withHmacSHA256`, which will end up with a longer hash value.
 
-Note: there is a widespread false believe that the NDK should be used to hide cryptographic operations and hardcoded keys. However, using this mechanism is not effective. Attackers can still use tools to find the mechanism used and make dumps of the key in memory. Next, the control flow can be analyzed with e.g. radare2 and the keys extracted with the help of Frida or the combination of both: [r2frida](0x08a-Testing-Tools.md#r2frida) (see sections ["Disassembling Native Code"](0x05c-Reverse-Engineering-and-Tampering.md#disassembling-native-code "Disassembling Native Code"), ["Memory Dump"](0x05c-Reverse-Engineering-and-Tampering.md#memory-dump "Memory Dump") and ["In-Memory Search"](0x05c-Reverse-Engineering-and-Tampering.md#in-memory-search "In-Memory Search") in the chapter "Tampering and Reverse Engineering on Android" for more details). From Android 7.0 (API level 24) onward, it is not allowed to use private APIs, instead: public APIs need to be called, which further impacts the effectiveness of hiding it away as described in the [Android Developers Blog](https://android-developers.googleblog.com/2016/06/android-changes-for-ndk-developers.html "Android changes for NDK developers")
+Note: there is a widespread false believe that the NDK should be used to hide cryptographic operations and hardcoded keys. However, using this mechanism is not effective. Attackers can still use tools to find the mechanism used and make dumps of the key in memory. Next, the control flow can be analyzed with e.g. radare2 and the keys extracted with the help of Frida or the combination of both: [r2frida](../tools/generic/MASTG-TOOL-0036.md "r2frida") (see ["Disassembling Native Code"](../techniques/android/MASTG-TECH-0018.md "Disassembling Native Code"), ["Memory Dump"](../techniques/android/MASTG-TECH-0044.md#memory-dump "Memory Dump") and ["In-Memory Search"](../techniques/android/MASTG-TECH-0044.md#in-memory-search "In-Memory Search") for more details). From Android 7.0 (API level 24) onward, it is not allowed to use private APIs, instead: public APIs need to be called, which further impacts the effectiveness of hiding it away as described in the [Android Developers Blog](https://android-developers.googleblog.com/2016/06/android-changes-for-ndk-developers.html "Android changes for NDK developers")
 
 ### Random number generation
 

Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md

@@ -219,7 +219,7 @@ for (int i = 1; ; i = 0)
 }
 ```
 
-Missing Google Over-The-Air (OTA) certificates is another sign of a custom ROM: on stock Android builds, [OTA updates Google's public certificates](https://www.netspi.com/blog/technical/mobile-application-penetration-testing/android-root-detection-techniques/ "Android Root Detection Techniques").
+Missing Google Over-The-Air (OTA) certificates is another sign of a custom ROM: on stock Android builds, [OTA updates Google's public certificates](https://www.netspi.com/blog/technical-blog/mobile-application-penetration-testing/android-root-detection-techniques/ "Android Root Detection Techniques").
 
 ### Anti-Debugging
 
@@ -555,8 +555,8 @@ To bypass this, we must modify the app's behavior slightly (the easiest ways to
 
 There are two topics related to file integrity:
 
- 1. _Code integrity checks:_ In the ["Tampering and Reverse Engineering on Android"](0x05c-Reverse-Engineering-and-Tampering.md) chapter, we discussed Android's APK code signature check. We also saw that determined reverse engineers can easily bypass this check by re-packaging and re-signing an app. To make this bypassing process more involved, a protection scheme can be augmented with CRC checks on the app bytecode, native libraries, and important data files. These checks can be implemented on both the Java and the native layer. The idea is to have additional controls in place so that the app only runs correctly in its unmodified state, even if the code signature is valid.
- 2. _The file storage integrity checks:_ The integrity of files that the application stores on the SD card or public storage and the integrity of key-value pairs that are stored in `SharedPreferences` should be protected.
+ 1. Code integrity checks: You can use CRC checks as an additional protection layer for the app bytecode, native libraries, and important data files. This way the app would only run correctly in its unmodified state, even if the code signature is valid.
+ 2. File storage integrity checks: The integrity of files that the application stores on the SD card or public storage and the integrity of key-value pairs that are stored in `SharedPreferences` should be protected.
 
 #### Sample Implementation - Application Source Code
 

Document/0x06b-iOS-Security-Testing.md

@@ -69,7 +69,7 @@ Unlike the Android emulator, which fully emulates the hardware of an actual Andr
 
 ### Testing on an Emulator
 
-[Corellium](0x06c-Reverse-Engineering-and-Tampering.md#corellium) is the only publicly available iOS emulator. It is an enterprise SaaS solution with a per user license model and does not offer community licenses.
+[Corellium](../techniques/ios/MASTG-TECH-0088.md#corellium) is the only publicly available iOS emulator. It is an enterprise SaaS solution with a per user license model and does not offer community licenses.
 
 ### Getting Privileged Access
 

Document/0x06i-Testing-Code-Quality-and-Build-Settings.md

@@ -97,7 +97,7 @@ See the [Technical Q&A QA1788 Building a Position Independent Executable](https:
 
 ### Debuggable Apps
 
-Apps can be made [debuggable](0x06c-Reverse-Engineering-and-Tampering.md#debugging) by adding the [`get-task-allow`](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues "Resolving common notarization issues") key to the app entitlements file and setting it to `true`.
+Apps can be made [debuggable](../techniques/android/MASTG-TECH-0031.md) by adding the [`get-task-allow`](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues "Resolving common notarization issues") key to the app entitlements file and setting it to `true`.
 
 While debugging is a useful feature when developing an app, it has to be turned off before releasing apps to the App Store or within an enterprise program. To do that you need to determine the mode in which your app is to be generated to check the flags in the environment:
 

Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md

@@ -181,7 +181,7 @@ There are several anti-debugging techniques applicable to iOS which can be categ
 
 #### Using ptrace
 
-As seen in chapter ["Tampering and Reverse Engineering on iOS"](0x06c-Reverse-Engineering-and-Tampering.md#debugging), the iOS XNU kernel implements a `ptrace` system call that's lacking most of the functionality required to properly debug a process (e.g. it allows attaching/stepping but not read/write of memory and registers).
+As seen in ["Debugging"](../techniques/ios/MASTG-TECH-0084.md "Debugging"), the iOS XNU kernel implements a `ptrace` system call that's lacking most of the functionality required to properly debug a process (e.g. it allows attaching/stepping but not read/write of memory and registers).
 
 Nevertheless, the iOS implementation of the `ptrace` syscall contains a nonstandard and very useful feature: preventing the debugging of processes. This feature is implemented as the `PT_DENY_ATTACH` request, as described in the [official BSD System Calls Manual](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/ptrace.2.html "PTRACE(2)"). In simple words, it ensures that no other debugger can attach to the calling process; if a debugger attempts to attach, the process will terminate. Using `PT_DENY_ATTACH` is a fairly well-known anti-debugging technique, so you may encounter it often during iOS pentests.
 
@@ -246,7 +246,7 @@ There are two common approaches to check file integrity: using application sourc
 
 #### Application Source Code Integrity Checks
 
-In the ["Tampering and Reverse Engineering on iOS"](0x06c-Reverse-Engineering-and-Tampering.md#debugging) chapter, we discussed the iOS IPA application signature check. We also saw that determined reverse engineers can bypass this check by re-packaging and re-signing an app using a developer or enterprise certificate. One way to make this harder is to add a custom check that determines whether the signatures still match at runtime.
+In ["Debugging"](../techniques/ios/MASTG-TECH-0084.md), we discuss the iOS IPA application signature check. We also learn that determined reverse engineers can bypass this check by re-packaging and re-signing an app using a developer or enterprise certificate. One way to make this harder is to add a custom check that determines whether the signatures still match at runtime.
 
 Apple takes care of integrity checks with DRM. However, additional controls (such as in the example below) are possible. The `mach_header` is parsed to calculate the start of the instruction data, which is used to generate the signature. Next, the signature is compared to the given signature. Make sure that the generated signature is stored or coded somewhere else.
 
@@ -370,8 +370,6 @@ The following steps should guide you when bypassing detection of reverse enginee
 1. Patch the anti reverse engineering functionality. Disable the unwanted behavior by patching the binary through usage of radare2/[iaito](https://github.com/radareorg/iaito "iaito") or Ghidra.
 2. Use Frida or Cydia Substrate to hook file system APIs on the Objective-C/Swift or native layers. Return a handle to the original file, not the modified file.
 
-Refer to the chapter ["Tampering and Reverse Engineering on iOS"](0x06c-Reverse-Engineering-and-Tampering.md) for examples of patching and code injection.
-
 #### Frida Detection
 
 Frida runs under the name of frida-server in its default configuration (injected mode) on a jailbroken device. When you explicitly attach to a target app (e.g. via frida-trace or the Frida CLI), Frida injects a frida-agent into the memory of the app. Therefore, you may expect to find it there after attaching to the app (and not before). On Android, verifying this is pretty straightforward as you can simply grep for the string "frida" in the memory maps of the process ID in the `proc` directory (`/proc/<pid>/maps`).
@@ -462,7 +460,7 @@ Control flow flattening replaces original code with a more complex representatio
 
 <img src="Images/Chapters/0x06j/control-flow-flattening.png" width="600px">
 
-The image shows how control flow flattening alters code. See ["Obfuscating C++ programs via control flow flattening"](http://ac.inf.elte.hu/Vol_030_2009/003.pdf) for more information.
+The image shows how control flow flattening alters code. See ["Obfuscating C++ programs via control flow flattening"](https://web.archive.org/web/20240414202600/http://ac.inf.elte.hu/Vol_030_2009/003.pdf) for more information.
 
 #### Dead Code Injection
 

Document/SUMMARY.md

@@ -29,7 +29,6 @@
 - [Android Network Communication](0x05g-Testing-Network-Communication.md)
 - [Android Platform APIs](0x05h-Testing-Platform-Interaction.md)
 - [Code Quality and Build Settings for Android Apps](0x05i-Testing-Code-Quality-and-Build-Settings.md)
-- [Tampering and Reverse Engineering on Android](0x05c-Reverse-Engineering-and-Tampering.md)
 - [Android Anti-Reversing Defenses](0x05j-Testing-Resiliency-Against-Reverse-Engineering.md)
 
 ## iOS Testing Guide
@@ -42,7 +41,6 @@
 - [iOS Network Communication](0x06g-Testing-Network-Communication.md)
 - [iOS Platform APIs](0x06h-Testing-Platform-Interaction.md)
 - [Code Quality and Build Settings for iOS Apps](0x06i-Testing-Code-Quality-and-Build-Settings.md)
-- [Tampering and Reverse Engineering on iOS](0x06c-Reverse-Engineering-and-Tampering.md)
 - [iOS Anti-Reversing Defenses](0x06j-Testing-Resiliency-Against-Reverse-Engineering.md)
 
 ## Appendix

techniques/android/MASTG-TECH-0004.md

@@ -11,6 +11,6 @@ Use a computer to perform all the steps indicated in the article ["Patching Andr
 objection patchapk --source app-release.apk
 ```
 
-The patched application then needs to be installed using adb, as explained in ["Installing Apps"](#installing-apps).
+The patched application then needs to be installed using adb.
 
-> This repackaging method is enough for most use cases. For more advanced repackaging, refer to ["Android Tampering and Reverse Engineering - Patching, Repackaging and Re-Signing"](0x05c-Reverse-Engineering-and-Tampering.md#patching-repackaging-and-re-signing).
+> This repackaging method is enough for most use cases. For more advanced repackaging, refer to ["Repackaging & Re-Signing"](../../techniques/android/MASTG-TECH-0039.md "Repackaging & Re-Signing").