Mobile applications have been created for practically different purposes. In the combined Apple and Google distribution stores alone, there are believed to be more than 2 million apps covering a large-scale range of functions, including some of the following:

• - Online banking
• - Shopping (Amazon — eBay)
• - Social networking (Facebook — Twitter)
• - Streaming (Sky Go)
• - Instant Messaging (WhatsApp — Viber)
• - Voice chat (Skype)
• - E-mail (Outlook)
• - File sharing (Dropbox)

Please, guys, try to get the basics first, We’ll soon go deeper….

Mobile apps usually overlap with the functionality provided by web applications, in many situations using the same core server-side APIs and displaying a smartphone-compatible interface at the presentation layer.

Now, let’s look at the security aspect

• Mobile apps are affected by a variety of security vulnerabilities, many of which are coming from common attacks against web and desktop applications. But, several other types of attacks are specific to the mobile section and arise due to the way in which mobile apps are used and the relatively unique entry points and the attack surfaces that these apps create.
• Most mobile apps make some sort of network communication, and because of the nature in which mobile devices are used, this communication may usually happen over an untrusted or unsafe network such as airport or café Wi-Fi, or hotel. Unless data is sufficiently secured in transition, it may expose an application to a number of potential risks, including disclosure of sensitive data and injection attacks.
• Mobile devices are usually carried with you wherever you go, which creates many chances for them to be lost or stolen. Mobile application developers must understand the risks from data recovery tries against a device’s system. Any extra data that an app leaves on the system, whether it’s through local storage or temporary caching, can possibly reveal sensitive data to an attacker.
• Mobile apps can receive input from a large number of possible sources, which generates a significant number of potential entry points. For instance, noticing applications accept data from one or many of the following is not uncommon: Bluetooth, camera, microphone, short message service (SMS), and universal serial bus (USB) or quick response (QR) codes
• The most dangerous attacks on mobile applications are those that disclose sensitive data or help compromise the device. These vulnerabilities are not limited to the mobile end user’s data and the device only. But, server-side vulnerabilities cause the greatest risk to mobile application deployments as a whole because they can expose unrestricted access to back-end systems.

Now, let’s look at the Penetration Testing aspect

Hope you’re enjoying the content

Mobile application penetration testing is an attempt to evaluate the security of a mobile application trying to exploit vulnerabilities. It includes decompiling, real-time analyzing, and testing mobile applications from the security point of view.

Now, let’s look at the Areas where Mobile Application Data Resides

• Private Application Folder
• SD Card/Emulated SD Card
• System Log Files
• Key Chain
• RAM
• Source Code
• Web Cache /History

Now, let’s look at the Android Application Architecture

Don’t Worry Guys we’ll soon get into the BattleField……..try to get the basics first.

A normal AndroidManifest.xml file looks like the one shown in the following screenshot. You will see here different permissions needed with the user-permission tag and other tags:

Now, let’s look at What happens when we run our source code

1. Android java code files compile to “.class” files via the java compiler.
2. “.class” files are also known as Java byte-code, this byte code further gets converted to Dalvik byte-code, which is the format that the Android operating system understands. All “.class” files and any .jar library files compile to single “classes. dex” using the dx command.
3. After that, all the files (classes. dex file, resource files, and libraries) are zipped into the .apk package

Now, let’s look at the Android Startup Process

One of the most important things when considering security in Android is the startup process. The whole boot-up process starts with the boot-loader, which in turn starts the init process — the first user-land processor, any change in boot-loader, or if we loaded up another boot-loader instead of the one present by default, we could really change what is being loaded on the device.

The boot-loader is usually vendor-specific, and every vendor has its own modified version of the boot-loader. Regularly, this functionality is disabled by default by having a locked boot-loader, which enables only the trusted kernel defined by the vendor to run on the device.

In order to flash your own ROM to the Android device, the boot-loader requires to be unlocked. The method of unlocking a boot-loader might differ from device to device. In some situations, it could also void the warranty of devices.

Now, let’s look at the Android Application Component

They handle data and database management issues.

And we are done! Our next tutorial will be on

1. Setting up our testing lab.
2. Installation of Virtual Box
3. Installation of GenoMotion
4. Installation of Santoku ISO

It’s gonna be fun!!! Yah…The Real BattleField…

please leave a comment in the comment section.

See you soon…