diff --git a/techniques/android/MASTG-TECH-0001.md b/techniques/android/MASTG-TECH-0001.md index ea094c36be..81dd83740c 100644 --- a/techniques/android/MASTG-TECH-0001.md +++ b/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 diff --git a/techniques/android/MASTG-TECH-0007.md b/techniques/android/MASTG-TECH-0007.md index b90a1e1aef..98faa2b325 100644 --- a/techniques/android/MASTG-TECH-0007.md +++ b/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: diff --git a/techniques/android/MASTG-TECH-0012.md b/techniques/android/MASTG-TECH-0012.md index c70ee81fea..3c88b533c3 100644 --- a/techniques/android/MASTG-TECH-0012.md +++ b/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 diff --git a/techniques/android/MASTG-TECH-0015.md b/techniques/android/MASTG-TECH-0015.md index 3750bccda8..da7de6143a 100644 --- a/techniques/android/MASTG-TECH-0015.md +++ b/techniques/android/MASTG-TECH-0015.md @@ -3,4 +3,4 @@ title: Dynamic Analysis on Android platform: android --- -TBD \ No newline at end of file +TBD diff --git a/techniques/android/MASTG-TECH-0016.md b/techniques/android/MASTG-TECH-0016.md index 56db3b2af3..e8f699afc2 100644 --- a/techniques/android/MASTG-TECH-0016.md +++ b/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. diff --git a/techniques/android/MASTG-TECH-0017.md b/techniques/android/MASTG-TECH-0017.md index 12be932b6d..f3d6039405 100644 --- a/techniques/android/MASTG-TECH-0017.md +++ b/techniques/android/MASTG-TECH-0017.md @@ -49,4 +49,4 @@ You'll end up with a structure that resembles the original Android Studio projec -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. diff --git a/techniques/android/MASTG-TECH-0018.md b/techniques/android/MASTG-TECH-0018.md index 83dd1a1fe9..a778220f1b 100644 --- a/techniques/android/MASTG-TECH-0018.md +++ b/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 diff --git a/techniques/android/MASTG-TECH-0023.md b/techniques/android/MASTG-TECH-0023.md index 4bfe94375e..4f421b5d65 100644 --- a/techniques/android/MASTG-TECH-0023.md +++ b/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. diff --git a/techniques/android/MASTG-TECH-0031.md b/techniques/android/MASTG-TECH-0031.md index 4d999ef859..446eee8483 100644 --- a/techniques/android/MASTG-TECH-0031.md +++ b/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. diff --git a/techniques/android/MASTG-TECH-0035.md b/techniques/android/MASTG-TECH-0035.md index 679513d6d0..cc6b636aa0 100644 --- a/techniques/android/MASTG-TECH-0035.md +++ b/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 -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. diff --git a/techniques/android/MASTG-TECH-0044.md b/techniques/android/MASTG-TECH-0044.md index 2f52183f35..1f4605f0de 100644 --- a/techniques/android/MASTG-TECH-0044.md +++ b/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. diff --git a/techniques/ios/MASTG-TECH-0055.md b/techniques/ios/MASTG-TECH-0055.md index 8246597146..5e61b5f2d7 100644 --- a/techniques/ios/MASTG-TECH-0055.md +++ b/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"). diff --git a/techniques/ios/MASTG-TECH-0056.md b/techniques/ios/MASTG-TECH-0056.md index 5b349303c3..348196cceb 100644 --- a/techniques/ios/MASTG-TECH-0056.md +++ b/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? diff --git a/techniques/ios/MASTG-TECH-0062.md b/techniques/ios/MASTG-TECH-0062.md index ca8e899340..7658551516 100644 --- a/techniques/ios/MASTG-TECH-0062.md +++ b/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 diff --git a/techniques/ios/MASTG-TECH-0064.md b/techniques/ios/MASTG-TECH-0064.md index 309e841bef..0aff3ffe3e 100644 --- a/techniques/ios/MASTG-TECH-0064.md +++ b/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 diff --git a/techniques/ios/MASTG-TECH-0075.md b/techniques/ios/MASTG-TECH-0075.md index d13bba685f..d820ffe76f 100644 --- a/techniques/ios/MASTG-TECH-0075.md +++ b/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 diff --git a/techniques/ios/MASTG-TECH-0076.md b/techniques/ios/MASTG-TECH-0076.md index 16cbcca0c9..1b4bd328a8 100644 --- a/techniques/ios/MASTG-TECH-0076.md +++ b/techniques/ios/MASTG-TECH-0076.md @@ -16,9 +16,11 @@ There are no hard written rules for performing static analysis, but there are fe ## Objective-C -In addition to the techniques learned in the "[Disassembling and Decompiling](#disassembling-and-decompiling "Disassembling and Decompiling")" section, for this section you'll need some understanding of the [Objective-C runtime](https://developer.apple.com/documentation/objectivec/objective-c_runtime "Objective-C runtime"). For instance, functions like `_objc_msgSend` or `_objc_release` are specially meaningful for the Objective-C runtime. +To effectively review disassembled native code, it's important to have a basic understanding of the [Objective-C runtime](https://developer.apple.com/documentation/objectivec/objective-c_runtime "Objective-C runtime"). Functions like `_objc_msgSend` and `_objc_release` are particularly significant within the Objective-C runtime. -We will be using the [UnCrackable App for iOS Level 1](../../apps/ios/MASTG-APP-0025.md "UnCrackable App for iOS Level 1"), which has the simple goal of finding a _secret string_ hidden somewhere in the binary. The application has a single home screen and a user can interact via inputting custom strings in the provided text field. +In addition to what you've learned in ["Disassembling Native Code"](MASTG-TECH-0068.md "Disassembling Native Code"), we will apply these concepts using the [UnCrackable App for iOS Level 1](../../apps/ios/MASTG-APP-0025.md "UnCrackable App for iOS Level 1"). The objective of this app is to find a secret string hidden within its binary. + +The application features a simple home screen, allowing user interaction by inputting custom strings into the provided text field. Our goal is to reverse engineer the app to uncover the hidden secret string. @@ -59,4 +61,4 @@ In our first step, we observed that the application verifies the input string on -Now we have followed the complete flow and have all the information about the application flow. We also concluded that the hidden flag is present in a text label and in order to determine the value of the label, we need to revisit `viewDidLoad` function, and understand what is happening in the native function identified. Analysis of the native function is discussed in "[Reviewing Disassembled Native Code](#reviewing-disassembled-native-code "Reviewing Disassembled Native Code")". +Now we have followed the complete flow and have all the information about the application flow. We also concluded that the hidden flag is present in a text label and in order to determine the value of the label, we need to revisit `viewDidLoad` function, and understand what is happening in the native function identified. Analysis of the native function is discussed in "[Reviewing Disassembled Native Code](MASTG-TECH-0077.md)". diff --git a/techniques/ios/MASTG-TECH-0077.md b/techniques/ios/MASTG-TECH-0077.md index 047563e09d..8546ed4cbc 100644 --- a/techniques/ios/MASTG-TECH-0077.md +++ b/techniques/ios/MASTG-TECH-0077.md @@ -38,4 +38,4 @@ To determine the value of the hidden flag we need to know the return value of ea -Manually analyzing all the native functions completely will be time consuming and might not be the wisest approach. In such a scenario using a dynamic analysis approach is highly recommended. For instance, by using the techniques like hooking or simply debugging the application, we can easily determine the returned values. Normally it's a good idea to use a dynamic analysis approach and then fallback to manually analyzing the functions in a feedback loop. This way you can benefit from both approaches at the same time while saving time and reducing effort. Dynamic analysis techniques are discussed in "[Dynamic Analysis](#dynamic-analysis "Dynamic Analysis")" section. +Manually analyzing all the native functions completely will be time consuming and might not be the wisest approach. In such a scenario using a [dynamic analysis](MASTG-TECH-0067.md) approach is highly recommended. For instance, by using the techniques like hooking or simply debugging the application, we can easily determine the returned values. Normally it's a good idea to use a dynamic analysis approach and then fallback to manually analyzing the functions in a feedback loop. This way you can benefit from both approaches at the same time while saving time and reducing effort. diff --git a/techniques/ios/MASTG-TECH-0084.md b/techniques/ios/MASTG-TECH-0084.md index 7a05e77dce..3579c352dc 100644 --- a/techniques/ios/MASTG-TECH-0084.md +++ b/techniques/ios/MASTG-TECH-0084.md @@ -155,7 +155,7 @@ When a binary is opened in a disassembler like Ghidra, it loads a binary by emul -From our previous analysis of the [UnCrackable App for iOS Level 1](../../apps/ios/MASTG-APP-0025.md "UnCrackable App for iOS Level 1") in "[Manual (Reversed) Code Review](#manual-reversed-code-review)" section, the value of the hidden string is stored in a label with the `hidden` flag set. In the disassembly, the text value of this label is stored in register `X21`, stored via `mov` from `X0`, at offset 0x100004520. This is our _breakpoint offset_. +The value of the hidden string is stored in a label with the `hidden` flag set. In the disassembly, the text value of this label is stored in register `X21`, stored via `mov` from `X0`, at offset 0x100004520. This is our _breakpoint offset_. diff --git a/techniques/ios/MASTG-TECH-0086.md b/techniques/ios/MASTG-TECH-0086.md index 768a7f84ee..fbb80e88f0 100644 --- a/techniques/ios/MASTG-TECH-0086.md +++ b/techniques/ios/MASTG-TECH-0086.md @@ -5,7 +5,7 @@ platform: ios Intercepting Objective-C methods is a useful iOS security testing technique. For example, you may be interested in data storage operations or network requests. In the following example, we'll write a simple tracer for logging HTTP(S) requests made via iOS standard HTTP APIs. We'll also show you how to inject the tracer into the Safari web browser. -In the following examples, we'll assume that you are working on a jailbroken device. If that's not the case, you first need to follow the steps outlined in section [Repackaging and Re-Signing](#repackaging-and-re-signing "Repackaging and Re-Signing") to repackage the Safari app. +In the following examples, we'll assume that you are working on a jailbroken device. If that's not the case, you first need to follow the steps outlined in section [Repackaging and Re-Signing](MASTG-TECH-0055.md) to repackage the Safari app. Frida comes with `frida-trace`, a function tracing tool. `frida-trace` accepts Objective-C methods via the `-m` flag. You can pass it wildcards as well-given `-[NSURL *]`, for example, `frida-trace` will automatically install hooks on all `NSURL` class selectors. We'll use this to get a rough idea about which library functions Safari calls when the user opens a URL. diff --git a/techniques/ios/MASTG-TECH-0088.md b/techniques/ios/MASTG-TECH-0088.md index ea8c075786..21cb77063f 100644 --- a/techniques/ios/MASTG-TECH-0088.md +++ b/techniques/ios/MASTG-TECH-0088.md @@ -23,7 +23,7 @@ Note that in order to install an IPA on Corellium devices it has to be unencrypt To use Unicorn's _full power_, we would need to implement all the necessary infrastructure which generally is readily available from the operating system, e.g. binary loader, linker and other dependencies or use another higher level frameworks such as [Qiling](https://qiling.io "Qiling") which leverages Unicorn to emulate CPU instructions, but understands the OS context. However, this is superfluous for this very localized challenge where only executing a small part of the binary will suffice. -While performing manual analysis in "[Reviewing Disassembled Native Code](#reviewing-disassembled-native-code "Reviewing Disassembled Native Code")" section, we determined that the function at address 0x1000080d4 is responsible for dynamically generating the secret string. As we're about to see, all the necessary code is pretty much self-contained in the binary, making this a perfect scenario to use a CPU emulator like Unicorn. +While performing manual analysis in "[Reviewing Disassembled Native Code](MASTG-TECH-0077.md)", we determined that the function at address 0x1000080d4 is responsible for dynamically generating the secret string. As we're about to see, all the necessary code is pretty much self-contained in the binary, making this a perfect scenario to use a CPU emulator like Unicorn. diff --git a/techniques/ios/MASTG-TECH-0089.md b/techniques/ios/MASTG-TECH-0089.md index cb999a7f25..794771cff3 100644 --- a/techniques/ios/MASTG-TECH-0089.md +++ b/techniques/ios/MASTG-TECH-0089.md @@ -9,14 +9,13 @@ You can find an introduction to binary analysis using binary analysis frameworks 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. - ## Angr [Angr](../../tools/android/MASTG-TOOL-0030.md "angr") is a very versatile tool, providing multiple techniques to facilitate binary analysis, while supporting various file formats and hardware instructions sets. > The Mach-O backend in Angr is not well-supported, but it works perfectly fine for our case. -While manually analyzing the code in the [Reviewing Disassembled Native Code](#reviewing-disassembled-native-code "Reviewing Disassembled Native Code")" section, we reached a point where performing further manual analysis was cumbersome. The function at offset `0x1000080d4` was identified as the final target which contains the secret string. +While manually analyzing the code in the [Reviewing Disassembled Native Code](MASTG-TECH-0077.md "Reviewing Disassembled Native Code")" section, we reached a point where performing further manual analysis was cumbersome. The function at offset `0x1000080d4` was identified as the final target which contains the secret string. If we revisit that function, we can see that it involves multiple sub-function calls and interestingly none of these functions have any dependencies on other library calls or system calls. This is a perfect case to use Angr's concrete execution engine. Follow the steps below to solve this challenge: diff --git a/techniques/ios/MASTG-TECH-0095.md b/techniques/ios/MASTG-TECH-0095.md index 070653f41b..28835d7058 100644 --- a/techniques/ios/MASTG-TECH-0095.md +++ b/techniques/ios/MASTG-TECH-0095.md @@ -5,7 +5,7 @@ platform: ios ## Frida -In section ["Execution Tracing"](#execution-tracing "Execution Tracing") we've used frida-trace when navigating to a website in Safari and found that the `initWithURL:` method is called to initialize a new URL request object. We can look up the declaration of this method on the [Apple Developer Website](https://developer.apple.com/documentation/foundation/nsbundle/1409352-initwithurl?language=objc "Apple Developer Website - initWithURL Instance Method"): +In section ["Execution Tracing"](MASTG-TECH-0085.md) we've used frida-trace when navigating to a website in Safari and found that the `initWithURL:` method is called to initialize a new URL request object. We can look up the declaration of this method on the [Apple Developer Website](https://developer.apple.com/documentation/foundation/nsbundle/1409352-initwithurl?language=objc "Apple Developer Website - initWithURL Instance Method"): ```objectivec - (instancetype)initWithURL:(NSURL *)url; diff --git a/techniques/ios/MASTG-TECH-0096.md b/techniques/ios/MASTG-TECH-0096.md index 568f128ca5..8b4fadf5af 100644 --- a/techniques/ios/MASTG-TECH-0096.md +++ b/techniques/ios/MASTG-TECH-0096.md @@ -168,7 +168,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](0x08a-Testing-Tools.md#objection) and [Fridump](https://github.com/Nightbringer21/fridump "Fridump"). To take advantage of these tools on a non-jailbroken 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-Jailbroken Devices](#dynamic-analysis-on-non-jailbroken-devices "Dynamic Analysis on Non-Jailbroken Devices"). To use these tools on a jailbroken phone, simply have frida-server installed and running. +You can dump the app's process memory with [objection](0x08a-Testing-Tools.md#objection) and [Fridump](https://github.com/Nightbringer21/fridump "Fridump"). To take advantage of these tools on a non-jailbroken 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-Jailbroken Devices](MASTG-TECH-0079.md). To use these tools on a jailbroken phone, simply have frida-server installed and running. With objection it is possible to dump all memory of the running process on the device by using the command `memory dump all`. diff --git a/tests/ios/MASVS-STORAGE/MASTG-TEST-0058.md b/tests/ios/MASVS-STORAGE/MASTG-TEST-0058.md index fffefc5f8c..7baa5adf42 100644 --- a/tests/ios/MASVS-STORAGE/MASTG-TEST-0058.md +++ b/tests/ios/MASVS-STORAGE/MASTG-TEST-0058.md @@ -87,7 +87,7 @@ ls: MobileSync: Operation not permitted This is not a permission issue of the backup folder, but a new feature in macOS Mojave. You can solve this problem by granting full disk access to your terminal application by following the explanation on [OSXDaily](http://osxdaily.com/2018/10/09/fix-operation-not-permitted-terminal-error-macos/ "Fix Terminal -Operation not permitted- Error in MacOS Mojave"). -Before you can access the directory you need to select the folder with the UDID of your device. Check the section "Getting the UDID of an iOS device" in the "iOS Basic Security Testing" chapter on how to retrieve the UDID. +Before you can access the directory you need to select the folder with the UDID of your device. 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. Once you know the UDID you can navigate into this directory and you will find the full backup of the whole device, which does include pictures, app data and whatever might have been stored on the device.