We – the s3 group – have several open positions to be filled, and we are looking for brave students who feel up to attempting the Ph.D. adventure!

I have made a couple of slides about my perspective on the Ph.D.

Finally, the slides on who we are and what we do in our research group.

You can write me at the email address: simone.aonzo(AT)eurecom.fr

We were interested in determining how ready the ecosystem is regarding the information required to build a secure app-to-web mapping. Given that the current standard is the Digital Asset Links (DAL from now on) protocol, we set to analyze the adoption rate by querying a dataset of domain names for their related assetlinks.json DAL file.

As a dataset, we considered all domain names from all mapping we extracted from the password managers we have inspected. Note that since they are extracted from password managers, it is very likely that these domain names host at least one page with a login form, thus making them relevant for this observation. In our article published in 2018, we were able to query 8,821 unique websites, but unfortunately, I did not save the complete list with all the domains, so I repeated the measurement on these.

Today (2022-01-13), I have successfully queried 5,506 unique websites for the /.well-known/assetlinks.json file. Namely, I have excluded all those who returned a status code other than 404 or 200. I found that 24% (1,330/5,506) of them host an associated DAL file, and 23% (1,265/5,506) specify an Android app in accordance with Google documentation. Four years ago, such percentages were 8% and 2%, respectively.

I am glad to see an increase, but I was hoping for more. I think DAL is vitally important to the Android ecosystem: not only does it allow to map the package name to websites securely, but it also provides for specifying the app signature, which is crucial for thwarting attacks and identifying malware.

/etc/sysctl.d/core.conf:

With this content:

kernel.core_pattern = /var/lib/coredumps/core-%e-sig%s-user%u-group%g-pid%p-time%t
kernel.core_uses_pid = 1
fs.suid_dumpable = 2

Create such a folder, and set permissions:

mkdir /var/lib/coredumps/
chmod 777 /var/lib/coredumps/

Edit file:

/etc/security/limits.conf

Add this content:

*  soft  core  unlimited

Logoff and logon, then:

ulimit -c unlimited

Check if it worked:

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 7345
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 7345
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Memento gdb core dump analysis:

gdb <executable> <core_dump_file>

Install gdb 8.1

apt install texinfo python2.7-dev python3-dev
wget http://ftp.gnu.org/gnu/gdb/gdb-8.1.1.tar.xz
tar xf gdb-8.1.1.tar.xz
cd gdb-8.1/
./configure --with-python && make && make install

This new feature needs to attach the Java source code for setting breakpoints, but smalidea allow us to do it directly on smali code!

Download the latest version of smalidea, then install it from Android Studio (from now on AS):

• File -> Settings -> Plugins -> Install plugin from disk…

Restart AS and open your apk:

• File -> Profile or debug APK…

Now, on your emulator (I didn’t test it on a real device, but surely you need root permissions) choose your target APK:

• Settings -> Developer options -> Select debug app
  • Flag “Wait for debugger”

Start your app!

Let’s get back to AS. Browse the class/method that you want to debug using the left panel and set the breakpoints.

• Tools -> Android -> Android Device Monitor
  • If you see nothing in the Android Device Monitor panel:
    • Window -> Rest perspective

In the Devices panel you will see a three column matrix:

1. package name
2. pid
3. port

Click your app and take care that in the last column is confirmed that the port on your emulator is mapped with the local 8700 port, as shown in the image.

Last step:

• Run -> Edit configurations
  • Click on the green + button
  • Choose “Remote”
    • Port: 8700

Click the debug icon and… there you are!

If you want to explore the content of a register you need to add a new watch (shortcut: Ins) and type the name of the register.

Everything else works like a normal debug session.

• Root permissions needed
• Android sdk with ndk
• GDB Enhanced Features

In this example the packname of the app is: com.example.nativetest

Find the right gdb executable for your architecture:

$ find ~/Android/Sdk/ -type f -name "gdbserver"
~/Android/Sdk/ndk-bundle/prebuilt/android-mips/gdbserver/gdbserver
~/Android/Sdk/ndk-bundle/prebuilt/android-x86/gdbserver/gdbserver
~/Android/Sdk/ndk-bundle/prebuilt/android-mips64/gdbserver/gdbserver
~/Android/Sdk/ndk-bundle/prebuilt/android-arm64/gdbserver/gdbserver
~/Android/Sdk/ndk-bundle/prebuilt/android-arm/gdbserver/gdbserver
~/Android/Sdk/ndk-bundle/prebuilt/android-x86_64/gdbserver/gdbserver

Copy the gdb server executable (w.r.t. your target architecture, in this example I am using the arm version) in a temporary folder and give to it full permissions:

adb push ~/Android/Sdk/ndk-bundle/prebuilt/android-arm/gdbserver/gdbserver /data/local/tmp/
adb shell "chmod 777 /data/local/tmp/gdbserver"
adb shell "ls -l /data/local/tmp/gdbserver"

In order to find debug information/symbols you’ll need all libraries in your device/emulator to be copied to your PC. Gdb will need them later on.

mkdir -p ~/dbgtmp/
adb pull /system/lib ~/dbgtmp/
ls -l ~/dbgtmp/lib/

You must also copy the native library <NATIVELIBDBG> (contained in your target apk <TARGETAPK>) you want to debug!

mkdir tmp
unzip <TARGETAPK> -d tmp
cp tmp/lib/<ARCH>/<NATIVELIBDBG> ~/dbgtmp/lib

Before continuing forward the port that will be used for the communication between gdb and gdbserver:

adb forward tcp:1337 tcp:1337

Launch the app, but do not trigger the execution of the native code. Become root, disable SELinux and attach gdb to the running process of your app with packagename <PACKAGENAME>):

adb shell
# su
# setenforce 0
# /data/local/tmp/gdbserver :1337 --attach $(ps | grep <PACKAGENAME> | awk '{print $2}')

Start gdb and be careful: use the Android-SDK executable!

~/Android/Sdk/ndk-bundle/prebuilt/linux-x86_64/bin/gdb

Connect to the gdbserver instance, specify the directories where gdb must search for the symbols of shared libraries. Then check if the operation has been successfully completed. Lastly, you can tabbing the function name that you want to debug (usually you are looking for some Java_* entrypoint), and then you can set a break point on such function:

gef> gef-remote :1337
gef> set solib-search-path ~/dbgtmp/lib
gef> info sharedlibrary
gef> break Java_<TAB>
gef> continue

Now you can interact with your app and trigger the execution of the native function. I wish you happy debugging!

In *nix systems the User Id Number (UID) and the Group Id Number (GID) are integers used for identifying uniquely users and groups. Take a look at /etc/passwd and /etc/group files (follow the links for more details about these files):

simo@xps:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
[...]
simo:x:1000:1000:simo,,,:/home/simo:/bin/bash
debian-tor:x:121:133::/var/lib/tor:/bin/false

We can infer:

Their counterparts in the group file:

simo@xps:~$ cat /etc/group
root:x:0:
[...]
simo:x:1000:
vboxusers:x:130:simo
debian-tor:x:133:

Moreover you can see that the user “simo” belong also to the “vboxusers” group.

Real (U|G)ID vs Effective (U|G)ID

Every running process has at least 4 ID numbers associated with it:

• the Real UID (RUID) identifies the user who launched the process.
• the Real GID (RGID) identifies the primary group of the user that launched the process.
• the Effective UID (EUID) and the Effective GID (EGID) are used to determine what resources the process can access.

These information can be found programmatically:

simo@xps:~/example$ cat ids.c
#include
#include
int main()
{
 uid_t real_uid = getuid();
 uid_t effect_uid = geteuid();
 gid_t real_gid = getgid();
 gid_t effect_gid = getegid();
 printf("ruid=%d euid=%d\n", real_uid, effect_uid);
 printf("rgid=%d egid=%d\n", real_gid, effect_gid);
}

Usually the IDs have the same value when you run a program, but sometimes happens that an operating system needs to run programs with temporarily elevated privileges in order to perform a specific task.

The setuid (set user id) is a permission bit, that allows the users to exec a program with the permissions of its owner. The setgid (set group id) is a bit that allows the user to exec a program with the permissions of the group owner.

The s(u|g)id bit on executables only changes the E(U|G)ID the executable will run as, and not the real(U|G)ID. Let’s take a closer look:

$ gcc -Wall ids.c -o example
$ sudo chown root.root example
$ ls -l
total 16
-rw-rw-r-- 1 simo simo 294  gen 17 16:21 ids.c
-rwxrwxr-x 1 root root 8816 gen 17 16:28 example
$ ./example
ruid=1000 euid=1000
rgid=1000 egid=1000
$ sudo chmod 6771 example
$ ls -l
total 16
-rw-rw-r-- 1 simo simo 294 gen 17 16:21 ids.c
-rwsrws--x 1 root root 8816 gen 17 16:29 example
$ ./example
ruid=1000 euid=0
rgid=1000 egid=0

1. I compiled the example;
2. I changed the owner and the group from “simo” to “root”;
3. I ran the program and I got the same ids;
4. I set the setuid and the setgid, pay attention to the s here

   -rwsrws--x 1 root root 8816 gen 17 16:29 example
   

5. Ids changes accordingly!

Hint: in addition to the restriction on s(u|g)id interpreted scripts (any executable text file beginning with “#!”), some shells (like bash) as an extra safety measure will set the EUID back to the RUID; in this case, you will need to wrap the call to the script within a C program and setuid(…) before executing the script.

• a bit is the basic unit of information in computing and digital communications;
• a bit can have only one of two values, and may, therefore, be physically implemented with a two-state device;
• the values of a bit are most commonly represented as either a 0 or 1.

Instead, the size of one Byte, as described in the Jargon file, is architecture-dependent and, more precisely, is a unit of memory or data equal to the amount used to represent one character. In the same link, or in the wiki page, is also explained that there was architecture with 6, 7, or 9 bits… or they operated on bit fields from 1 to 36!

Obviously, it is extremely convenient that, from the architecture/hardware perspective, a Byte is the smallest addressable unit of memory: for this reason every operation that involves data exchange between the CPU and the RAM is made with Byte sizes or its multiples (Word, Double Word, and Quad Word).

We agree that the popularity of major commercial computing architectures has aided in the ubiquitous acceptance that a Byte is 8-bit size, but we must remember that it is only a de facto standard. You can see it by yourself.

Compile this C code with gcc on your Linux machine:

#include<stdio.h>
#include<limits.h>

int main() {
    printf("%zu Byte = %d bits\n", sizeof(char), __CHAR_BIT__);
    printf("%lu Byte = %lu bits\n", sizeof(int), sizeof(int)*__CHAR_BIT__);
    return 0;
}

And run it:

$ gcc test.c
$ ./a.out
1 Byte = 8 bits
4 Byte = 32 bits