Change markdown images to html images

Document/0x01-Foreword.md

@@ -16,4 +16,4 @@ Because this isn't a normal security book, the introduction doesn't list impress
 
 We do have a message to our readers however! The first rule of the OWASP Mobile Security Testing Guide is: Don't just follow the OWASP Mobile Security Testing Guide. True excellence at mobile application security requires a deep understanding of mobile operating systems, coding, network security, cryptography, and a whole lot of other things, many of which we can only touch on briefly in this book. Don't stop at security testing. Write your own apps, compile your own kernels, dissect mobile malware, learn how things tick. And as you keep learning new things, consider contributing to the MSTG yourself! Or, as they say: "Do a pull request".
 
-![Summit Team](Images/summit-team.jpg) \
+<img src="Images/summit-team.jpg" width="100%" />

Document/0x02a-Frontispiece.md

@@ -1,6 +1,6 @@
 # Frontispiece
 
-![OWASP MSTG](Images/OWASP_logo.png) \
+<img src="Images/OWASP_logo.png" width="100%" />
 
 ## About the OWASP Mobile Security Testing Guide
 
@@ -28,7 +28,7 @@ Our [Code of Conduct](https://github.com/OWASP/owasp-mstg/blob/master/CODE_OF_CO
 
 Copyright © The OWASP Foundation. This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/ "Creative Commons Attribution-ShareAlike 4.0 International License"). For any reuse or distribution, you must make clear to others the license terms of this work.
 
-![OWASP MSTG](Images/CC-license.png) \
+<img src="Images/CC-license.png" width="300px" />
 
 ## ISBN
 
@@ -128,7 +128,7 @@ Reviewers have consistently provided useful feedback through GitHub issues and p
 
 While both the MASVS and the MSTG are created and maintained by the community on a voluntary basis, sometimes a little bit of outside help is required. We therefore thank our donators for providing the funds to be able to hire technical editors. Note that their donation does not influence the content of the MASVS or MSTG in any way. The Donation Packages are described on the [OWASP Project Wiki](https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide#tab=Sponsorship_Packages "OWASP Mobile Security Testing Guide Donation Packages").
 
-![OWASP MSTG](Images/Donators/donators.png) \
+<img src="Images/Donators/donators.png" width="100%" />
 
 ### Older Versions
 

Document/0x03-Overview.md

@@ -46,7 +46,7 @@ There are three things you should never bring up in polite conversations: religi
 
 This guide is closely related to the OWASP Mobile Application Security Verification Standard (MASVS). The MASVS defines a mobile app security model and lists generic security requirements for mobile apps. It can be used by architects, developers, testers, security professionals, and consumers to define and understand the qualities of a secure mobile app. The MSTG maps to the same basic set of security requirements offered by the MASVS and depending on the context they can be used individually or combined to achieve different objectives.
 
-![OWASP MSTG](Images/Chapters/0x03/owasp-mobile-overview.jpg) \
+<img src="Images/Chapters/0x03/owasp-mobile-overview.jpg" width="100%" />
 
 For example, the MASVS requirements can be used in an app's planning and architecture design stages while the checklist and testing guide may serve as a baseline for manual security testing or as a template for automated security tests during or after development. In the "[Mobile App Security Testing](0x04b-Mobile-App-Security-Testing.md)" chapter we'll describe how you can apply the checklist and MSTG to a mobile app penetration test.
 

Document/0x04b-Mobile-App-Security-Testing.md

@@ -114,7 +114,7 @@ Organizations may have different regulatory and legal obligations in certain ter
 
 Security goals/controls defined earlier in the development process may also be reviewed during the discussion with stakeholders. Some controls may conform to MASVS controls, but others may be specific to the organization or application.
 
-![OWASP MSTG](Images/Chapters/0x03/mstg-preparation.png) \
+<img src="Images/Chapters/0x03/mstg-preparation.png" width="100%" />
 
 All involved parties must agree on the decisions and the scope in the checklist because these will define the baseline for all security testing.
 
@@ -248,7 +248,7 @@ You can use the [OWASP MASVS](https://mobile-security.gitbook.io/masvs/ "OWASP M
 
 The picture below illustrates all the phases and artifacts:
 
-![OWASP MSTG](Images/Chapters/0x04b/SDLCOverview.jpg) \
+<img src="Images/Chapters/0x04b/SDLCOverview.jpg" width="100%" />
 
 Based on the project's general risk profile, you may simplify (or even skip) some artifacts, and you may add others (formal intermediary approvals, formal documentation of certain points, etc.). **Always remember two things: an SDLC is meant to reduce risks associated with software development, and it is a framework that helps you set up controls to that end.** This is a generic description of SDLC; always tailor this framework to your projects.
 
@@ -299,7 +299,7 @@ Security is just as critical to business success as the overall quality, perform
 
 However, DevSecOps is not just a linear process oriented towards delivering the best possible software to operations; it is also a mandate that operations closely monitor software that's in production to identify issues and fix them by forming a quick and efficient feedback loop with development. DevSecOps is a process through which Continuous Improvement is heavily emphasized.
 
-![OWASP MSTG](Images/Chapters/0x04b/DevSecOpsProcess.JPG) \
+<img src="Images/Chapters/0x04b/DevSecOpsProcess.JPG" width="100%" />
 
 The human aspect of this emphasis is reflected in the creation of cross-functional teams that work together to achieve business outcomes. This section is focused on necessary interactions and integrating security into the development life cycle (which starts with project inception and ends with the delivery of value to users).
 
@@ -360,7 +360,7 @@ The security of an application developed with DevOps must be considered during o
 - Pentesting may take place regularly. (The version of the application used in production is the version that should be pentested, and the testing should take place in a dedicated environment and include data that's similar to the production version data. See the section on Penetration Testing for more details.)
 - Active monitoring should be performed to identify issues and remediate them as soon as possible via the feedback loop.
 
-![OWASP MSTG](Images/Chapters/0x04b/ExampleOfADevSecOpsProcess.jpg) \
+<img src="Images/Chapters/0x04b/ExampleOfADevSecOpsProcess.jpg" width="100%" />
 
 ## References
 

Document/0x04e-Testing-Authentication-and-Session-Management.md

@@ -104,7 +104,7 @@ Confirm the existence of a password policy and verify the implemented password c
 
 After adding the zxcvbn JavaScript library to the HTML page, you can execute the command `zxcvbn` in the browser console, to get back detailed information about how likely it is to crack the password including a score.
 
-![OWASP MSTG](Images/Chapters/0x04e/zxcvbn.png) \
+<img src="Images/Chapters/0x04e/zxcvbn.png" width="100%" />
 
 The score is defined as follows and can be used for a password strength bar for example:
 
@@ -167,13 +167,13 @@ Execute the following steps for a wordlist based brute force attack with Burp In
 
 Once everything is configured and you have a word-list selected, you're ready to start the attack!
 
-![OWASP MSTG](Images/Chapters/0x04e/BurpIntruderInputList.png) \
+<img src="Images/Chapters/0x04e/BurpIntruderInputList.png" width="400px" />
 
 - Click the **Start attack** button to attack the authentication.
 
 A new window will open. Site requests are sent sequentially, each request corresponding to a password from the list. Information about the response (length, status code, etc.) is provided for each request, allowing you to distinguish successful and unsuccessful attempts:
 
-![OWASP MSTG](Images/Chapters/0x04e/BurpIntruderSuccessfulAttack.png) \
+<img src="Images/Chapters/0x04e/BurpIntruderSuccessfulAttack.png" width="400px" />
 
 In this example, you can identify the successful attempt according to the different length and the HTTP status code, which reveals the password 12345.
 
@@ -470,7 +470,7 @@ OAuth 2.0 defines four roles:
 
 Note: The API fulfills both the Resource Owner and Authorization Server roles. Therefore, we will refer to both as the API.
 
-![OWASP MSTG](Images/Chapters/0x04e/abstract_oath2_flow.png) \
+<img src="Images/Chapters/0x04e/abstract_oath2_flow.png" width="400px" />
 
 Here is a more [detailed explanation](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 "An Introduction into OAuth2") of the steps in the diagram:
 

Document/0x04f-Testing-Network-Communication.md

@@ -13,7 +13,7 @@ Several free and commercial proxy tools are available. Here are some of the most
 
 To use the interception proxy, you'll need run it on your host computer and configure the mobile app to route HTTP(S) requests to your proxy. In most cases, it is enough to set a system-wide proxy in the network settings of the mobile device - if the app uses standard HTTP APIs or popular libraries such as `okhttp`, it will automatically use the system settings.
 
-![OWASP MSTG](Images/Chapters/0x04f/BURP.png) \
+<img src="Images/Chapters/0x04f/BURP.png" width="100%" />
 
 Using a proxy breaks SSL certificate verification and the app will usually fail to initiate TLS connections. To work around this issue, you can install your proxy's CA certificate on the device. We'll explain how to do this in the OS-specific "Basic Security Testing" chapters.
 
@@ -66,7 +66,7 @@ bettercap will then automatically send the packets to the network gateway in the
 
 On the mobile phone start the browser and navigate to `http://example.com`, you should see output like the following when you are using Wireshark.
 
-![OWASP MSTG](Images/Chapters/0x04f/bettercap.png) \
+<img src="Images/Chapters/0x04f/bettercap.png" width="100%" />
 
 If that's the case, you are now able to see the complete network traffic that is sent and received by the mobile phone. This includes also DNS, DHCP and any other form of communication and can therefore be quite "noisy". You should therefore know how to use [DisplayFilters in Wireshark](https://wiki.wireshark.org/DisplayFilters "DisplayFilters") or know [how to filter in tcpdump](https://danielmiessler.com/study/tcpdump/#gs.OVQjKbk "A tcpdump Tutorial and Primer with Examples") to focus only on the relevant traffic for you.
 
@@ -99,7 +99,7 @@ In both cases the AP needs to be configured to point to your host computer's IP.
 
 > If the separate access point belongs to the customer, all changes and configurations should be clarified prior to the engagement and a backup should be created, before making any changes.
 
-![OWASP MSTG](Images/Chapters/0x04f/architecture_MITM_AP.png) \
+<img src="Images/Chapters/0x04f/architecture_MITM_AP.png" width="100%" />
 
 #### Installation
 
@@ -269,7 +269,7 @@ When a Xamarin app is configured to use a proxy (e.g. by using `WebRequest.Defau
     - Redirect to port: provide original port location.
     - Set 'Force use of SSL' (when HTTPS is used) and set 'Support invisible proxy'.
 
-![OWASP MSTG](Images/Chapters/0x04f/burp_xamarin.png) \
+<img src="Images/Chapters/0x04f/burp_xamarin.png" width="100%" />
 
 <br/>
 <br/>

Document/0x04g-Testing-Cryptography.md

@@ -111,7 +111,7 @@ Block-based encryption is performed upon discrete input blocks (for example, AES
 
 [ECB (Electronic Codebook)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29 "Electronic Codebook (ECB)") divides the input into fixed-size blocks that are encrypted separately using the same key. If multiple divided blocks contain the same plaintext, they will be encrypted into identical ciphertext blocks which makes patterns in data easier to identify. In some situations, an attacker might also be able to replay the encrypted data.
 
-![OWASP MSTG](Images/Chapters/0x07c/EncryptionMode.png) \
+<img src="Images/Chapters/0x07c/EncryptionMode.png" width="100%" />
 
 Verify that Cipher Block Chaining (CBC) mode is used instead of ECB. In CBC mode, plaintext blocks are XORed with the previous ciphertext block. This ensures that each encrypted block is unique and randomized even if blocks contain the same information. Please note that it is best to combine CBC with an HMAC and/or ensure that no errors are given such as "Padding error", "MAC error", "decryption failed" in order to be more resistant to a padding oracle attack.
 

Document/0x05a-Platform-Overview.md

@@ -16,13 +16,13 @@ Android is a Linux-based open source platform developed by Google, which serves
 
 Android's software stack is composed of several different layers. Each layer defines interfaces and offers specific services.
 
-![OWASP MSTG](Images/Chapters/0x05a/android_software_stack.png) \
+<img src="Images/Chapters/0x05a/android_software_stack.png" width="400px" />
 
 At the lowest level, Android is based on a variation of the Linux Kernel. On top of the kernel, the Hardware Abstraction Layer (HAL) defines a standard interface for interacting with built-in hardware components. Several HAL implementations are packaged into shared library modules that the Android system calls when required. This is the basis for allowing applications to interact with the device's hardware. For example, it allows a stock phone application to use a device's microphone and speaker.
 
 Android apps are usually written in Java and compiled to Dalvik bytecode, which is somewhat different from the traditional Java bytecode. Dalvik bytecode is created by first compiling the Java code to .class files, then converting the JVM bytecode to the Dalvik .dex format with the `d8` tool.
 
-![OWASP MSTG](Images/Chapters/0x05a/java_vs_dalvik.png) \
+<img src="Images/Chapters/0x05a/java_vs_dalvik.png" width="400px" />
 
 The current version of Android executes this bytecode on the Android runtime (ART). ART is the successor to Android's original runtime, the Dalvik Virtual Machine (DVM). The key difference between Dalvik and ART is the way the bytecode is executed.
 
@@ -169,7 +169,7 @@ Apps are executed in the Android Application Sandbox, which separates the app da
 
 Installation of a new app creates a new directory named after the app package, which results in the following path: `/data/data/[package-name]`. This directory holds the app's data. Linux directory permissions are set such that the directory can be read from and written to only with the app's unique UID.
 
-![OWASP MSTG](Images/Chapters/0x05a/Selection_003.png) \
+<img src="Images/Chapters/0x05a/Selection_003.png" width="400px" />
 
 We can confirm this by looking at the file system permissions in the `/data/data` folder. For example, we can see that Google Chrome and Calendar are assigned one directory each and run under different user accounts:
 
@@ -410,7 +410,7 @@ The term *Binder* stands for a lot of different things, including:
 
 The Binder framework includes a client-server communication model. To use IPC, apps call IPC methods in proxy objects. The proxy objects transparently *marshall* the call parameters into a *parcel* and send a transaction to the Binder server, which is implemented as a character driver (/dev/binder). The server holds a thread pool for handling incoming requests and delivers messages to the destination object. From the perspective of the client app, all of this seems like a regular method call, all the heavy lifting is done by the Binder framework.
 
-![OWASP MSTG](Images/Chapters/0x05a/binder.jpg) \
+<img src="Images/Chapters/0x05a/binder.jpg" width="400px" />
 
 *Binder Overview - Image source: [Android Binder by Thorsten Schreiber](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.710.6498&rep=rep1&type=pdf "Android Binder")*
 
@@ -614,7 +614,7 @@ The original version of app signing implements the signed APK as a standard sign
 
 With the APK signature scheme, the complete APK is hashed and signed, and an APK Signing Block is created and inserted into the APK. During validation, the v2 scheme checks the signatures of the entire APK file. This form of APK verification is faster and offers more comprehensive protection against modification. You can see the [APK signature verification process for v2 Scheme](https://source.android.com/security/apksigning/v2#verification "APK Signature verification process") below.
 
-![OWASP MSTG](Images/Chapters/0x05a/apk-validation-process.png) \
+<img src="Images/Chapters/0x05a/apk-validation-process.png" width="400px" />
 
 #### APK Signature Scheme (v3 Scheme)
 
@@ -623,7 +623,7 @@ The v3 APK Signing Block format is the same as v2. V3 adds information about the
 The proof-of-rotation attribute in the signed-data of the signing block consists of a singly-linked list, with each node containing a signing certificate used to sign previous versions of the app. To make backward compatibility work, the old signing certificates sign the new set of certificates, thus providing each new key with evidence that it should be as trusted as the older key(s).
 It is no longer possible to sign APKs independently, because the proof-of-rotation structure must have the old signing certificates signing the new set of certificates, rather than signing them one-by-one. You can see the [APK signature v3 scheme verification process](https://source.android.com/security/apksigning/v3 "APK Signature v3 scheme verification process") below.
 
-![OWASP MSTG](Images/Chapters/0x05a/apk-validation-process-v3-scheme.png) \
+<img src="Images/Chapters/0x05a/apk-validation-process-v3-scheme.png" width="400px" />
 
 #### APK Signature Scheme (v4 Scheme)