fix lint errors

techniques/android/MASTG-TECH-0001.md

@@ -25,7 +25,7 @@ bullhead:/ # id
 uid=0(root) gid=0(root) groups=0(root) context=u:r:su:s0
 ```
 
-> Only if you're working with an emulator you may alternatively restart adb with root permissions with the command `adb root` so next time you enter `adb shell` you'll have root access already. This also allows to transfer data bidirectionally between your host computer and the Android file system, even with access to locations where only the root user has access to (via `adb push/pull`). See more about data transfer in section "[Host-Device Data Transfer](#host-device-data-transfer "Host-Device Data Transfer")" below.
+> Only if you're working with an emulator you may alternatively restart adb with root permissions with the command `adb root` so next time you enter `adb shell` you'll have root access already. This also allows to transfer data bidirectionally between your host computer and the Android file system, even with access to locations where only the root user has access to (via `adb push/pull`). See more about data transfer in section "[Host-Device Data Transfer](MASTG-TECH-0002.md)" below.
 
 ### Connect to Multiple Devices
 

techniques/android/MASTG-TECH-0007.md

@@ -3,7 +3,7 @@ title: Exploring the App Package
 platform: android
 ---
 
-Once you have collected the package name of the application you want to target, you'll want to start gathering information about it. First, retrieve the APK as explained in ["Basic Testing Operations - Obtaining and Extracting Apps"](#obtaining-and-extracting-apps).
+Once you have collected the package name of the application you want to target, you'll want to start gathering information about it. First, retrieve the APK as explained in ["Basic Testing Operations - Obtaining and Extracting Apps"](MASTG-TECH-0003.md).
 
 APK files are actually ZIP files that can be unpacked using a standard decompression utility such as `unzip`. However, we recommend using [apktool](0x08a-Testing-Tools.md#apktool) which additionally decodes the AndroidManifest.xml and disassembles the app binaries (classes.dex) to smali code:
 

techniques/android/MASTG-TECH-0012.md

@@ -18,7 +18,7 @@ There are several ways to bypass certificate pinning for a black box test, depen
 - Objection: Use the `android sslpinning disable` command.
 - Xposed: Install the [TrustMeAlready](https://github.com/ViRb3/TrustMeAlready "TrustMeAlready") or [SSLUnpinning](https://github.com/ac-pm/SSLUnpinning_Xposed "SSLUnpinning") module.
 
-If you have a rooted device with frida-server installed, you can bypass SSL pinning by running the following [Objection](0x08a-Testing-Tools.md#objection) command ([repackage your app](#repackaging-apps) if you're using a non-rooted device):
+If you have a rooted device with frida-server installed, you can bypass SSL pinning by running the following [Objection](0x08a-Testing-Tools.md#objection) command ([repackage your app](MASTG-TECH-0004.md) if you're using a non-rooted device):
 
 ```bash
 android sslpinning disable

techniques/android/MASTG-TECH-0015.md

@@ -3,4 +3,4 @@ title: Dynamic Analysis on Android
 platform: android
 ---
 
-TBD
+TBD

techniques/android/MASTG-TECH-0016.md

@@ -5,4 +5,4 @@ platform: android
 
 If you want to inspect the app's smali code (instead of Java), you can [open your APK in Android Studio](https://developer.android.com/studio/debug/apk-debugger "Debug pre-built APKs") by clicking **Profile or debug APK** from the "Welcome screen" (even if you don't intend to debug it you can take a look at the smali code).
 
-Alternatively you can use [apktool](0x08a-Testing-Tools.md#apktool) to extract and disassemble resources directly from the APK archive and disassemble Java bytecode to smali. apktool allows you to reassemble the package, which is useful for [patching](#patching-repackaging-and-re-signing) the app or applying changes to e.g. the Android Manifest.
+Alternatively you can use [apktool](0x08a-Testing-Tools.md#apktool) to extract and disassemble resources directly from the APK archive and disassemble Java bytecode to smali. apktool allows you to reassemble the package, which is useful for [patching](MASTG-TECH-0038.md) the app or applying changes to e.g. the Android Manifest.

techniques/android/MASTG-TECH-0017.md

@@ -49,4 +49,4 @@ You'll end up with a structure that resembles the original Android Studio projec
 
 <img src="Images/Chapters/0x05c/final_structure.jpg" width="400px" />
 
-See the section "[Reviewing Decompiled Java Code](#reviewing-decompiled-java-code "Reviewing Decompiled Java Code")" below to learn on how to proceed when inspecting the decompiled Java code.
+See the section "[Reviewing Decompiled Java Code](MASTG-TECH-0023.md "Reviewing Decompiled Java Code")" below to learn on how to proceed when inspecting the decompiled Java code.

techniques/android/MASTG-TECH-0018.md

@@ -87,7 +87,7 @@ To support both older and newer ARM processors, Android apps ship with multiple
 - armeabi-v7a: This ABI extends armeabi to include several CPU instruction set extensions.
 - arm64-v8a: ABI for ARMv8-based CPUs that support AArch64, the new 64-bit ARM architecture.
 
-Most disassemblers can handle any of those architectures. Below, we'll be viewing the armeabi-v7a version (located in `HelloWord-JNI/lib/armeabi-v7a/libnative-lib.so`) in radare2 and in IDA Pro. See the section "[Reviewing Disassembled Native Code](#reviewing-disassembled-native-code "Reviewing Disassembled Native Code")" below to learn on how to proceed when inspecting the disassembled native code.
+Most disassemblers can handle any of those architectures. Below, we'll be viewing the armeabi-v7a version (located in `HelloWord-JNI/lib/armeabi-v7a/libnative-lib.so`) in radare2 and in IDA Pro. See the section "[Reviewing Disassembled Native Code](MASTG-TECH-0024.md "Reviewing Disassembled Native Code")" below to learn on how to proceed when inspecting the disassembled native code.
 
 ## radare2
 

techniques/android/MASTG-TECH-0023.md

@@ -3,7 +3,7 @@ title: Reviewing Decompiled Java Code
 platform: android
 ---
 
-Following the example from ["Decompiling Java Code"](#decompiling-java-code), we assume that you've successfully decompiled and opened the [UnCrackable App for Android Level 1](../../apps/android/MASTG-APP-0003.md) in IntelliJ. As soon as IntelliJ has indexed the code, you can browse it just like you'd browse any other Java project. Note that many of the decompiled packages, classes, and methods have weird one-letter names; this is because the bytecode has been "minified" with ProGuard at build time. This is a basic type of [obfuscation](0x04c-Tampering-and-Reverse-Engineering.md#obfuscation) that makes the bytecode a little more difficult to read, but with a fairly simple app like this one, it won't cause you much of a headache. When you're analyzing a more complex app, however, it can get quite annoying.
+Following the example from ["Decompiling Java Code"](MASTG-TECH-0017.md), we assume that you've successfully decompiled and opened the [UnCrackable App for Android Level 1](../../apps/android/MASTG-APP-0003.md) in IntelliJ. As soon as IntelliJ has indexed the code, you can browse it just like you'd browse any other Java project. Note that many of the decompiled packages, classes, and methods have weird one-letter names; this is because the bytecode has been "minified" with ProGuard at build time. This is a basic type of [obfuscation](0x04c-Tampering-and-Reverse-Engineering.md#obfuscation) that makes the bytecode a little more difficult to read, but with a fairly simple app like this one, it won't cause you much of a headache. When you're analyzing a more complex app, however, it can get quite annoying.
 
 When analyzing obfuscated code, annotating class names, method names, and other identifiers as you go along is a good practice. Open the `MainActivity` class in the package `sg.vantagepoint.uncrackable1`. The method `verify` is called when you tap the "verify" button. This method passes the user input to a static method called `a.a`, which returns a boolean value. It seems plausible that `a.a` verifies user input, so we'll refactor the code to reflect this.
 

techniques/android/MASTG-TECH-0031.md

@@ -128,7 +128,7 @@ This is the plaintext string you're looking for!
 
 Setting up a project in an IDE with the decompiled sources is a neat trick that allows you to set method breakpoints directly in the source code. In most cases, you should be able to single-step through the app and inspect the state of variables with the GUI. The experience won't be perfect, it's not the original source code after all, so you won't be able to set line breakpoints and things will sometimes simply not work correctly. Then again, reversing code is never easy, and efficiently navigating and debugging plain old Java code is a pretty convenient way of doing it. A similar method has been described in the [NetSPI blog](https://blog.netspi.com/attacking-android-applications-with-debuggers/ "NetSPI Blog - Attacking Android Applications with Debuggers").
 
-To set up IDE debugging, first create your Android project in IntelliJ and copy the decompiled Java sources into the source folder as described above in the "[Reviewing Decompiled Java Code](#reviewing-decompiled-java-code "Reviewing Decompiled Java Code")" section. On the device, choose the app as **debug app** on the "Developer options" ([UnCrackable App for Android Level 1](../../apps/android/MASTG-APP-0003.md) in this tutorial), and make sure you've switched on the "Wait For Debugger" feature.
+To set up IDE debugging, first create your Android project in IntelliJ and copy the decompiled Java sources into the source folder as described above in the "[Reviewing Decompiled Java Code](MASTG-TECH-0023.md)" section. On the device, choose the app as **debug app** on the "Developer options" ([UnCrackable App for Android Level 1](../../apps/android/MASTG-APP-0003.md) in this tutorial), and make sure you've switched on the "Wait For Debugger" feature.
 
 Once you tap the app icon from the launcher, it will be suspended in "Wait For Debugger" mode.
 

techniques/android/MASTG-TECH-0035.md

@@ -3,7 +3,7 @@ title: JNI Tracing
 platform: android
 ---
 
-As detailed in section [Reviewing Disassembled Native Code](#reviewing-disassembled-native-code), the first argument passed to every JNI function is a JNI interface pointer. This pointer contains a table of functions that allows native code to access the Android Runtime. Identifying calls to these functions can help with understanding library functionality, such as what strings are created or Java methods are called.
+As detailed in section [Reviewing Disassembled Native Code](MASTG-TECH-0024.md), the first argument passed to every JNI function is a JNI interface pointer. This pointer contains a table of functions that allows native code to access the Android Runtime. Identifying calls to these functions can help with understanding library functionality, such as what strings are created or Java methods are called.
 
 [jnitrace](https://github.com/chame1eon/jnitrace "jnitrace") is a Frida based tool similar to frida-trace which specifically targets the usage of Android's JNI API by native libraries, providing a convenient way to obtain JNI method traces including arguments and return values.
 
@@ -17,7 +17,7 @@ jnitrace -l libnative-lib.so sg.vantagepoint.helloworldjni
 
 <img src="Images/Chapters/0x05c/jni_tracing_helloworldjni.png" width="100%" />
 
-In the output you can see the trace of a call to `NewStringUTF` made from the native code (its return value is then given back to Java code, see section "[Reviewing Disassembled Native Code](#reviewing-disassembled-native-code)" for more details). Note how similarly to frida-trace, the output is colorized helping to visually distinguish the different threads.
+In the output you can see the trace of a call to `NewStringUTF` made from the native code (its return value is then given back to Java code, see section "[Reviewing Disassembled Native Code](MASTG-TECH-0024.md)" for more details). Note how similarly to frida-trace, the output is colorized helping to visually distinguish the different threads.
 
 When tracing JNI API calls you can see the thread ID at the top, followed by the JNI method call including the method name, the input arguments and the return value. In the case of a call to a Java method from native code, the Java method arguments will also be supplied. Finally jnitrace will attempt to use the Frida backtracing library to show where the JNI call was made from.
 

techniques/android/MASTG-TECH-0044.md

@@ -182,7 +182,7 @@ In-memory search can be very useful to quickly know if certain data is located i
 
 ### Memory Dump
 
-You can dump the app's process memory with [objection](https://github.com/sensepost/objection "Objection") and [Fridump](https://github.com/Nightbringer21/fridump "Fridump"). To take advantage of these tools on a non-rooted device, the Android app must be repackaged with `frida-gadget.so` and re-signed. A detailed explanation of this process is in the section [Dynamic Analysis on Non-Rooted Devices](#dynamic-analysis-on-non-rooted-devices "Dynamic Analysis on Non-Rooted Devices"). To use these tools on a rooted phone, simply have frida-server installed and running.
+You can dump the app's process memory with [objection](https://github.com/sensepost/objection "Objection") and [Fridump](https://github.com/Nightbringer21/fridump "Fridump"). To take advantage of these tools on a non-rooted device, the Android app must be repackaged with `frida-gadget.so` and re-signed. A detailed explanation of this process is in the section [Dynamic Analysis on Non-Rooted Devices](MASTG-TECH-0026.md). To use these tools on a rooted phone, simply have frida-server installed and running.
 
 > Note: When using these tools, you might get several memory access violation errors which can normally be ignored. These tools inject a Frida agent and try to dump all the mapped memory of the app regardless of the access permissions (read/write/execute). Therefore, when the injected Frida agent tries to read a region that's not readable, it'll return the corresponding _memory access violation errors_. Refer to previous section "Memory Maps and Inspection" for more details.
 

techniques/ios/MASTG-TECH-0055.md

@@ -17,6 +17,6 @@ Finally, the app needs to be installed (sideloaded) and run with debugging commu
 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.
+Refer to ["Installing Apps"](MASTG-TECH-0056.md) 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 ["Repackaging and Re-Signing"](../../techniques/ios/MASTG-TECH-0092.md "Repackaging and Re-Signing").

techniques/ios/MASTG-TECH-0056.md

@@ -96,7 +96,6 @@ This bypass might not work if the application requires capabilities that are spe
 
 Possible values for the property [UIDeviceFamily](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW11 "UIDeviceFamily property") can be found in the Apple Developer documentation.
 
-
 One fundamental step when analyzing apps is information gathering. This can be done by inspecting the app package on your host computer or remotely by accessing the app data on the device. You'll find more advance techniques in the subsequent chapters but, for now, we will focus on the basics: getting a list of all installed apps, exploring the app package and accessing the app data directories on the device itself. This should give you a bit of context about what the app is all about without even having to reverse engineer it or perform more advanced analysis. We will be answering questions such as:
 
 - Which files are included in the package?

techniques/ios/MASTG-TECH-0062.md

@@ -6,7 +6,7 @@ platform: ios
 You can remotely sniff all traffic in real-time on iOS by [creating a Remote Virtual Interface](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819 "Wireshark + OSX + iOS") for your iOS device. First make sure you have [Wireshark](0x08a-Testing-Tools.md#wireshark) installed on your macOS host computer.
 
 1. Connect your iOS device to your macOS host computer via USB.
-2. You would need to know the UDID of your iOS device, before you can start sniffing. Check the section ["Getting the UDID of an iOS device"](#getting-the-udid-of-an-ios-device) on how to retrieve it. Open the Terminal on macOS and enter the following command, filling in the UDID of your iOS device.
+2. You would need to know the UDID of your iOS device, before you can start sniffing. Check the section ["Obtaining the UDID of an iOS device"](/Document/0x06b-iOS-Security-Testing.md#obtaining-the-udid-of-an-ios-device) on how to retrieve it. Open the Terminal on macOS and enter the following command, filling in the UDID of your iOS device.
 
 ```bash
 $ rvictl -s <UDID>

techniques/ios/MASTG-TECH-0064.md

@@ -11,7 +11,7 @@ This section describes various ways to bypass SSL Pinning and gives guidance abo
 
 ## Methods for Jailbroken and Non-jailbroken Devices
 
-If you have a jailbroken device with frida-server installed, you can bypass SSL pinning by running the following [Objection](0x08a-Testing-Tools.md#objection) command ([repackage your app](#repackaging-apps) if you're using a non-jailbroken device):
+If you have a jailbroken device with frida-server installed, you can bypass SSL pinning by running the following [Objection](/tools/ios/MASTG-TOOL-0074.md) command ([repackage your app](MASTG-TECH-0055.md) if you're using a non-jailbroken device):
 
 ```bash
 ios sslpinning disable

techniques/ios/MASTG-TECH-0075.md

@@ -3,4 +3,4 @@ title: Reviewing Decompiled Objective-C and Swift Code
 platform: ios
 ---
 
-TODO: Don't have this yet
+TBD