Getting command-line access with Android Debug Bridge (ADB)

- [Instructor] As part of setting up Android Studio we loaded the Android SDK. One of the important testing tools that we loaded with that is called ADB, the Android Debug Bridge. This enables us to get command line access to any Android device. To use ADB, I need to put the device into developer mode. Now I can do this by selecting the phone settings, scroll down and select About, and then tap on the entry Build Number seven times. The phone will display a message to say it's in developer mode and add a new entry to the settings menu called Developer Options.

The easiest way to run ADB is over USB. So I can go into Developer Options and select USB debugging. When I connect it to the computer subsequently, it will then ask whether I want to activate debugging mode. I've got my Android phone connected to the computer using a USB cable, so let's do that. Let's look at the commands we can use with ADB. In the basic options we can see a devices command.

Let's use ADB to check what devices it can see. Okay, we can see one device here. Given there's just one device, ADB will automatically select it. If we had multiple devices connected, we'd need to specify for ADB which device to use. There's also a set of device level commands. I won't go into them all right now, but I'll just note some basic ones. Push and pull are used to transfer files in and out of the device. Port forwarding is a useful feature for investigating traffic from the device using an intercepting HTTP proxy and ADB offers a number of commands for this.

Install, install multiple, and uninstall allow application packages to be managed from the command line. However, the main command we want to look at right now is Shell. The Shell command provides a bashlite shell in the Android device. Let's try that. I've confirmed ADB debugging on the mobile and we now have a Shell. Okay, we're now listing the files inside our Android phone. It's worth exploring the device to see how the file base is arranged.

However, the key files we're interested in when testing exist in the /data folder, this is where user loaded applications exist, and /system where the system applications exist. Let's look at these two directories. It's interesting to explore around here, but for the testing, the three areas we're interested in are /system/app, /system/priv-app, and /system/delapp. We can see that we have the system application packages listed in APK and ODEX files.

We noted earlier the application zip archives in which the java code is stored in the classes.dex file. An ODEX is basically a preprocessed version of an application's classes.dex that is execution ready for Dalvik. For our purposes, we can concentrate on the APK files. Again, in priv-app we can see the APK and ODEX files of the priv-apps loaded on the device. From the KitKat release onwards, Android splits its system applications into those that have routine privileges, which are in /system/app, and those that need system level privileges, which are in /system/priv-app.

This provides more control over the more dangerous applications. Here we see, under /delapp, those system applications which were pre-installed on the device which have been removed. They're not actually deleted, just hidden. We can use the exit command to leave the Shell and return to the Windows Command Shell. It's simple with ADB to extract an application so that we can take a look at it. I'll pull down one of the applications we saw in /systems/delapp called LingXi and we can take a look at it.

I've now downloaded this APK file from the device. I'll start jadx to take a first look at it. As we can see, we have the full APK and can browse through the source code and resource folders. If we open the com folder, we can see a chinaMobile folder. In that, we have a number of class files shown in obfuscated form with single character names. Nevertheless, if we look in the routine name D we can see it's doing an AES encryption.

Despite obfuscation, we can see the AES key and the IV.