Update broken links

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

@@ -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). We'll provide an overview of popular emulation-based analysis frameworks for Android in the "Tampering and Reverse Engineering on Android" chapter.
 
 ### 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 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"](0x04c-Tampering-and-Reverse-Engineering.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").
 
 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](0x08a-Testing-Tools.md#r2frida) (see sections ["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") in the chapter "Process Exploration" 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

@@ -555,7 +555,7 @@ 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.
+ 1. _Code integrity checks:_ In the ["Tampering and Reverse Engineering"](0x04c-Tampering-and-Reverse-Engineering.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.
 
 #### 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 chapter ["Debugging"](../techniques/ios/MASTG-TECH-0084.md), 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 the ["Debugging"](../techniques/ios/MASTG-TECH-0084.md) 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.
 
 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,7 +370,7 @@ 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.
+Refer to the chapter ["Mobile App Tampering and Reverse Engineering"](0x04c-Tampering-and-Reverse-Engineering.md) for examples of patching and code injection.
 
 #### Frida Detection
 

Document/SUMMARY.md

@@ -29,7 +29,7 @@
 - [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)
+- [Reverse Engineering on Android](../techniques/android/MASTG-TECH-0013.md)
 - [Android Anti-Reversing Defenses](0x05j-Testing-Resiliency-Against-Reverse-Engineering.md)
 
 ## iOS Testing Guide
@@ -42,7 +42,7 @@
 - [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)
+- [Reverse Engineering on iOS](../techniques/ios/MASTG-TECH-0065.md)
 - [iOS Anti-Reversing Defenses](0x06j-Testing-Resiliency-Against-Reverse-Engineering.md)
 
 ## Appendix

techniques/android/MASTG-TECH-0004.md

@@ -13,4 +13,4 @@ objection patchapk --source app-release.apk
 
 The patched application then needs to be installed using adb, as explained in ["Installing Apps"](#installing-apps).
 
-> 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").

techniques/android/MASTG-TECH-0011.md

@@ -122,7 +122,7 @@ To implement this new setting you must follow the steps below:
     apktool b
     ```
 
-- You need to repackage the app, as explained in the "[Repackaging](0x05c-Reverse-Engineering-and-Tampering.md#repackaging "Repackaging")" section of the "Reverse Engineering and Tampering" chapter. For more details on the repackaging process you can also consult the [Android developer documentation](https://developer.android.com/studio/publish/app-signing#signing-manually), that explains the process as a whole.
+- You need to repackage the app, as explained in the "[Repackaging Apps](../../techniques/android/MASTG-TECH-0004.md "Repackaging Apps")" section of the "Reverse Engineering and Tampering" chapter. For more details on the repackaging process you can also consult the [Android developer documentation](https://developer.android.com/studio/publish/app-signing#signing-manually), that explains the process as a whole.
 
 Note that even if this method is quite simple its major drawback is that you have to apply this operation for each application you want to evaluate which is additional overhead for testing.
 

techniques/generic/MASTG-TECH-0048.md

@@ -5,4 +5,4 @@ platform: generic
 
 For white-box source code testing, you'll need a setup similar to the developer's setup, including a test environment that includes the Android SDK and an IDE. Access to either a physical device or an emulator (for debugging the app) is recommended.
 
-During **black-box testing**, you won't have access to the original form of the source code. You'll usually have the application package in [Android's APK format](https://en.wikipedia.org/wiki/Apk_(file_format) "APK file format"), which can be installed on an Android device or reverse engineered as explained in the section "[Disassembling and Decompiling](0x05c-Reverse-Engineering-and-Tampering.md#disassembling-and-decompiling "Disassembling and Decompiling")".
+During **black-box testing**, you won't have access to the original form of the source code. You'll usually have the application package in [Android's APK format](https://en.wikipedia.org/wiki/Apk_(file_format) "APK file format"), which can be installed on an Android device or reverse engineered as explained in the section "[Decompiling Java Code](../../techniques/android/MASTG-TECH-0017.md "Decompiling Java Code")".

techniques/ios/MASTG-TECH-0055.md

@@ -19,4 +19,4 @@ ios-deploy --bundle Payload/my-app.app -W -d
 
 Refer to ["Installing Apps"](#installing-apps) to learn about other installation methods. Some of them doesn't require you to have a macOS.
 
-> This repackaging method is enough for most use cases. For more advanced repackaging, refer to ["iOS Tampering and Reverse Engineering - Patching, Repackaging and Re-Signing"](0x06c-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 and Re-Signing"](../../techniques/ios/MASTG-TECH-0092.md "Repackaging and Re-Signing").

techniques/ios/MASTG-TECH-0087.md

@@ -9,6 +9,6 @@ As discussed earlier in this chapter, iOS applications can also contain native c
 frida-trace -U -i "open" sg.vp.UnCrackable1
 ```
 
-The overall approach and further improvisation for tracing native code using Frida is similar to the one discussed in the Android "[Tracing](0x05c-Reverse-Engineering-and-Tampering.md#tracing "Tracing")" section.
+The overall approach and further improvisation for tracing native code using Frida is similar to the one discussed in the Android "[Native Code Tracing](../../techniques/android/MASTG-TECH-0034.md "Native Code Tracing")" section.
 
 Unfortunately, there are no tools such as `strace` or `ftrace` available to trace syscalls or function calls of an iOS app. Only `DTrace` exists, which is a very powerful and versatile tracing tool, but it's only available for MacOS and not for iOS.

techniques/ios/MASTG-TECH-0089.md

@@ -5,7 +5,7 @@ platform: ios
 
 TODO: Currently don't have this, but we do have this section below which does talk about Angr and a small intro referring to Android
 
-An introduction to binary analysis using binary analysis frameworks has already been discussed in the "[Dynamic Analysis](0x05c-Reverse-Engineering-and-Tampering.md#dynamic-analysis "Dynamic analysis")" section for Android. We recommend you to revisit this section and refresh the concepts on this subject.
+An introduction to binary analysis using binary analysis frameworks has already been discussed in the "[Dynamic Analysis on Android](../../techniques/android/MASTG-TECH-0015 "Dynamic Analysis on Android")" section. We recommend you to revisit this section and refresh the concepts on this subject.
 
 For Android, we used Angr's symbolic execution engine to solve a challenge. In this section, we will firstly use Unicorn to solve the [UnCrackable App for iOS Level 1](../../apps/ios/MASTG-APP-0025.md "UnCrackable App for iOS Level 1") challenge and then we will revisit the Angr binary analysis framework to analyze the challenge but instead of symbolic execution we will use its concrete execution (or dynamic execution) features.