5 Setting Up Android Emulators, Free Hacking Course Complete Step By Step

-
Free Hacking Course Complete Step By Step

Setting Up Android Emulators In Kali Linux

Now we’ll set up three Android emulators on Kali to use for mobile testing. First we’ll need to download the Android SDK.
  • Open the Iceweasel web browser from within Kali and visit https://developer.android.com/sdk/index.html.
  • Download the current version of the ADT bundle for 32-bit Linux and save it to your root directory.
  • Open a terminal, list the files there (ls), and extract the compressed archive that you just downloaded with unzip (the x’s represent the name of your file, as versions may have changed since this was written).
root@kali:~# unzip adt-bundle-Linux-x86-xxxxxxxxxxx.zip

  •  Now use cd to go into the new directory (with the same name as the file without the .zip extension).

# cd sdk/tools
# ./android

  • The Android SDK Manager should open, as shown in Figure.


We’ll download any updates to the Android SDK tools and Android SDK platform tools (checked by default), as well as Android 4.3 and a couple of older versions of Android with specific vulnerabilities, Android 2.2 and Android 2.1. Select the boxes to the left of each Android version. Then (leaving Updates/New and Installed checked) click Install packages, as shown in Figure. Accept the license agreement, and the Android SDK should download and install the chosen packages. Installation will likely take several minutes.

Now it’s time to set up our Android virtual devices. Open the Android SDK Manager and choose Tools > Manage AVDs. You should see the window shown in Figure.



We’ll create three Android emulators based on Android 4.3, 2.2, and 2.1, as shown in Figure. Use the values shown in the figure for each emulator but set the value of Target to the Android version of the
emulator you would like to build (the Google API versions of Android 4.3 [Google APIs version 18], 2.2 [Google APIs version 8], and 2.1 [Google APIs version 7]). Fill the AVD Name field with a descriptive value. Add a small SD Card value (100MB should be more than sufficient) so you can download files to your Android emulators. Set Device to Nexus 4 and Skin to Skin with dynamic hardware controls. Leave the rest of the options at their defaults.


Once you’ve built all three emulators, your AVD Manager should look like Figure (device names may be different of course).


Once you’ve built all three emulators, your AVD Manager should look like Figure.


To start an emulator, highlight it and click Start. Then click Launch in the pop-up, as shown in Figure



It may take a few minutes for the emulator to boot up for the first time, but once it does, you should have something that looks and feels much like a real Android device. The Android 4.3 emulator is shown in Figure.


Note : To run the Android emulators in Kali, you will likely need to increase the performance of your virtual machine by increasing its RAM and CPU cores. I am able to run all three emulators with 3GB RAM and two CPU cores allocated to Kali. You can make these changes in the virtual machine settings in your VMware product. The amount of power you can give to Kali will, of course, depend on the resources available on your host machine. As an alternative, instead of running the Android emulators on Kali Linux, you can install Android and the emulators on your host system or even another system on the local network. The exercises in Chapter 20 will work as long as the emulators can communicate with Kali.

Smartphone Pentest Framework

Next, download and install the Smartphone Pentest Framework (SPF), which we’ll use for mobile attacks. Use git to download the source code. Change to the downloaded Smartphone-Pentest-Framework directory as shown here.

root@kali:~# git clone -b SPFBook https://github.com/georgiaw/Smartphone-Pentest-Framework.git
root@kali:~# cd Smartphone-Pentest-Framework

Now open the file kaliinstall in the nano text editor. The first few lines are shown in Listing 1-5. Note the lines that refer to /root/adt-bundle-linux-x86-20131030/sdk/tools/android. If the name of your ADT bundle folder is different (due to the release of a subsequent version), change this value to match the correct place where you installed the Android ADT in the previous section.

root@kali:~/Smartphone-Pentest-Framework# nano kaliinstall
#!/bin/sh
## Install needed packages
echo -e "$(tput setaf 1)\nInstallin serialport, dbdpg, and expect for perl\n"; echo "$(tputsgr0)"
echo -e "$(tput setaf 1)#########################################\n"; echo "$(tput sgr0)"
echo $cwd;
#apt-get -y install libexpect-perl libdbd-pg-perl libdevice-serialport-perl;
apt-get install ant
/root/adt-bundle-linux-x86-20131030/sdk/tools/android update sdk --no-ui --filter android-4 -a
/root/adt-bundle-linux-x86-20131030/sdk/tools/android update sdk --no-ui --filter addon-google_
apis-google-4 -a
/root/adt-bundle-linux-x86-20131030/sdk/tools/android update sdk --no-ui --filter android-14 -a
/root/adt-bundle-linux-x86-20131030/sdk/tools/android update sdk --no-ui --filter addon-google_
apis-google-14 -a
--snip--

Now run the kaliinstall script, as shown here.

root@kali:~/Smartphone-Pentest-Framework# ./kaliinstall

This will set up the SPF, which we’ll use in future. Finally, we need to make one more change to the configuration file for SPF. Change directories to Smartphone-Pentest-Framework/frameworkconsole and open the file config in nano. Look for the option #LOCATION OF ANDROID SDK. If your ADT bundle folder name has changed since the version current at the time of this writing, change it accordingly in the line that begins with ANDROIDSDK=.

root@kali:~/Smartphone-Pentest-Framework# cd frameworkconsole/
root@kali:~/Smartphone-Pentest-Framework/frameworkconsole# nano config
--snip--
#LOCATION OF ANDROID SDK
ANDROIDSDK = /root/adt-bundle-linux-x86-20131030/sdk
--snip--

In our last video we had installed all the required tools for hacking, our next tops will be creating Target Virtual Machines for  attacks which we will attack. If you have not followed us yet, then do so so that you do not miss the upcoming topics. Click Here To Read Our Blogs From Getting Started.


    Comments

    Post a Comment

    Popular posts from this blog

    14 Creating Standalone Payloads with Msfvenom, Free Hacking Complete Course Step By Step

    -
    Image
    Free Hacking Complete Course Step By Step Creating Standalone Payloads with Msfvenom In 2011, Msfvenom was added to Metasploit. Before Msfvenom, the tools Msfpayload and Msfencode could be used together to create standalone encoded Metasploit payloads in a variety of output formats, such as Windows executables and ASP pages. With the introduction of Msfvenom, the functionality of Msfpayload and Msfencode was combined into a single tool, though Msfpayload and Msfencode are still included in Metasploit. To view Msfvenom’s help page, enter msfvenom -h . So far with Metasploit, our goal has been to exploit a vulnerability in the target system and take control of the machine. Now we’ll do something a little different. Instead of relying on a missing patch or another security issue, we are hoping to exploit the one security issue that may never be fully patched: the users. Msfvenom allows you to build standalone payloads to run on a target system in an attempt to...
    Read more

    3 Configuring the Network for Virtual Machine, Hacking Complete Free Course Step By Step

    -
    Image
    Hacking Free Complete Course Step By Step Configuring the Network for Virtual Machine After installing Kali Linux as a Virtual machine we must configuring the network for virtual machine because we’ll be using Kali Linux to attack our target systems over a network, we need to place all our virtual machines on the same virtual network. VMware offers three options for virtual network connections:   Bridged  NAT Host only.   You should choose the bridged option, but here’s a bit of information about each: The bridged network connects the virtual machine directly to the local network using the same connection as the host system. As far as the local network is concerned, our virtual machine is just another node on the network with its own IP address. NAT, short for network address translation, sets up a private network on the host machine. The private network translates outgoing traffic from the virtual machine to the local network. On the local network, traffic from the virt...
    Read more