I am working on my school research on Dirty CoW (if you don't know what it is and you think the implementation might be relevant to my problem, see P.S. below).
I have found some solutions (i.e. https://github.com/scumjr/dirtycow-vdso) that use Dirty CoW to inject some shellcode into vDSO. The one in the link is for desktop Linux, but there are also solutions for Android (basically identical, except for a few changes).

I am trying to analyze the existing solutions and I have come to a problem - where is vDSO stored in Android?

The manual pages (http://man7.org/linux/man-pages/man7/vdso.7.html) say, that you can locate the file using

find arch/$ARCH/ -name '*vdso*.so*' -o -name '*gate*.so*'

By running a similar command on my Ubuntu 64bit (find / -name '*vdso*' -o -name '*gate*.*so'), following lines are present in the output:


And by using objdump and hexdump on one of them I can see that it is the one, that is mapped in the memory (I wrote a program, that finds it and dumps it into a file).

However, when I run

adb root
adb shell find -name '*vdso*' -o -name '*gate*.so*'

on my Android 4.4-r4 x86, the only output is /proc/sys/vm/vdso_enabled (and the file content is 1).

I know there is vDSO in the processes' memory, I wrote a dumping program ran from ADB for that as well. And I also adjusted the Dirty CoW exploit to inject my shellcode into the vDSO. I can see that the shellcode is in the vDSO from an app that I wrote and also from the dumping program that I mentioned earlier. My shellcode is only present in vDSO until I restart the device.

How does vDSO work in Android? Is there a file where it is stored? It seems not, because if it was there, the injected code would be there after the reboot as well. But how does the shellcode propagate to the other processes?

I am very grateful for your answers.

P.S.: Dirty CoW is a vulnerability of Linux kernel that lets you write into read only files (or anything that you can map into your memory) by causing a race condition of two threads - the first one has a loop where it is writing any text into memory (either into /proc/self/mem or using ptrace using mmap to find the right place) and the other one is telling the system (also in a loop) that the same part of memory is no longer needed (using madvise(MADV_DONTNEED)).


The vDSO isn’t stored in a separate file on disk, it’s part of the kernel and is mapped into each process’s address space by the kernel. The .so files you found are only used for debugging purposes. The find command in the documentation is given as an example when building the kernel, to find the generated vDSO in the kernel build tree; there’s no requirement that the separate .sos be present in /lib/modules or anywhere else for that matter.

The shellcode injected by the exploit you’re working on propagates because there’s single copy of the vDSO in memory, so any successful write to it shows up in all current and future processes’ mapping of the vDSO...

  • Thank you for you answer! I see now that I misunderstood how vDSO is mapped into memory of processes. I thought there was a vDSO file somewhere that the system just loads into certain address (the one in auxiliary vector). I thought my exploit was rewriting the file and causing memory miss leading to realoading the file in a process whenever a function from vDSO is called. – Topper Harley Feb 15 '18 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.