In order to use the commands mentioned in the following example, you will need to be able to either install the find binary or Busybox for Android; the instructions for installation can be found at http://www.busybox.net/ and in the Setting up Busybox section of the Automated native Android fuzzing recipe at the end of this chapter.

To search for files with respect to their access rights, you can find a list of readable files by executing the following command in your ADB shell; firstly, for world readable, this command does the trick:

find [path-to-search] –perm  0444 –exec ls –al {} ;

See the following screenshot for the sample output:

The previous screenshot—and the subsequent ones in this section—were taken from a rooted Samsung Galaxy S3. Here the command-line instruction included a redirect to /dev/null in order to omit the erroneous output caused by permission denial.

Moving on, if you're looking for world writable files, you can find them using the following arguments:

find [path-to-search] –perm  0222 –exec ls –al {} ;

See the following screenshot for the sample output:

And for files that have executable permission set for all users:

find [path-to-search] –perm  0111 –exec ls –al {} ;

You aren't explicitly required to use the octal format; the find command also understands the popular shorthands for user collections and permissions.

For instance, to find files readable to everyone outside of the owner's group, you specify permissions this way:

find [path-to-search] –perm  a=r –exec ls –al {} ;

See the following screenshot for the sample output:

The previous specifications will ensure only exact matches; this means files returned must have only the bits specified. If you're looking for files with at least the specified bits set and any of the other bits—which you will probably be doing most of the time—you can specify the permissions by including a - symbol as a prefix as in the preceding example. For the octal mode, this will work as follows:

find [path-to-search] –perm  -444 –exec ls –al {} ;

See the following screenshot for the sample output:

This will at least match files that have read bits set for all user collections, which means the 445, 566, 777, and so on permission bits will be matched. And the 344, 424, 222, and so on would not be matched.

A couple of really useful access right patterns you would probably be interested in looking for include finding executable files with setuid:

find [path-to-search] –perm  -4111 –exec ls –al {} ;

See the following screenshot for the sample output:

In the previous screenshot, we see that the su binary was found using the preceding command. If you ever find this binary on an Android device, it's always a strong indication that the device has been rooted.

You can also find files with setguid and execute permissions for all:

find [path-to-search] –perm  -2111 –exec ls –al {} ;

See the following screenshot for the sample output:

The find command also allows you to specify users as part of the search criteria; for instance:

You may want to get an idea of how much each user—or rather, application—on your Android system has access to, and to do this you may want to build a list of user IDs—or, more importantly, UIDs for applications. The easiest way to do this is to dump the access rights for the files in the /data/data directory since it contains the data for most of the apps installed on the Android device. However, in order to access this list from an ADB shell, you'll need access to the root or system account or any account that has equivalent permissions; this is easy to obtain on an emulator—it's granted automatically. Alternatively, if you so choose, you could fire off a couple of searches to the XDA developers site to look for a method to root your phone. The XDA developer's site is available at http://www.xda-developers.com/.

There are both good and bad things about rooting your phone; in this case, it allows you to inspect the filesystem and access rights in more detail. However, on the other hand, if access to root privileges are not managed properly, it can expose your phone to a number of very devastating attacks! So be stingy with your root permissions and only temporarily root phones when they need to be rooted.

Moving on, if you list all of the files in the /data/data directory, you should see the following; this is taken from a Samsung Galaxy S3:

You may notice the odd naming convention for each app, namely u[number]_a[number], which means to say u[profile number] for the user profile the app is installed on—since some Android versions support multiple user profiles, namely everything from Jelly Bean and later—and a[number], which is the application ID.

You can use the application ID to construct the actual system user ID (UID) for the app by adding this number to 10000; for instance, for the Mozilla installation that has a username of u0_a170, the corresponding UID will be 10170. To find all of the files that have this UID as its owner, you would then execute this command:

find /data/data/ -user 10170 –exec ls –al {} ;  2> /dev/null

See the following screenshot for the sample output:

You can find other usernames by checking out the Android_filesystem_config.h file referenced in the See also section of this recipe.

A command that can make the output of the find command a little more useful is stat. This command displays properties of the file and allows you to specify the format in which you'd like these details to be displayed. The stat command has a myriad of features and makes hunting for incorrectly "permissioned" files a much more informative experience than just calling ls –al via the find –exec command.

You can use stat with find as follows:

find . –perm [permission mode] –exec stat –c "[format]" {} ;

For instance, if you'd like to display the following:

You can do so by executing the following command:

find . –perm [permission] –exec stat –c "%A %u %g  %f  %N" {} ;

This command produces output as follows—here the example uses -0666 as an example permission mode: