## https://sploitus.com/exploit?id=3C68399F-BEA2-59C7-B9D0-1A0E0F60AD03
#FZ-B2 rootshell
This is an exploit that gains unrestricted root access to the Panasonic Toghpad FZ-B2 tablet.
It does so by using DirtyCoW (CVE-2016-5195) to corrupt the init process, which lets it bypass SELinux.
It is not a complete "rooting kit", does not persist anythig, or install Superuser.
What it does, is create a bind shell, that you can connect to with nc.
##What you need
The tablet device itself, with ADB enabled over TCP. Adjust Makefile with the tablet IP.
Download Android NDK from Google. It won't work with the newest version, choose the "r22b" release.
Adjust Makefile with the NDK path.
Install build-essential, binutils, adb, netcat.
To use it, just invoke `make ritual`. If succesful, you should be greeted by the "evil shell".
The ritual might fail at first, restarting the tablet. This is perfectly normal, since we're live-patching a process.
If it happens, just try again. A reboot will always bring back a clean slate, since `/system` is mounted read-only.
##How it works
DirtyCoW is a race condition in older Linux kernels, that lets you write to read-only memory.
In practice, it lets you overwrite files which you have read (but no necessarily write) access to.
If the file system is read-only, the file-on-disk won't change, but every process will see the new content.
To exploit this, we need a file with elevated permissions which we can target.
One such file is `/system/bin/run-as`. While the file itself does not have setuid *permission*,
it has the setuid *capability* (needed to perform its boring android-y function).
We will replace it with a simple program that sets all user/group ids to 0 (root), and execs to `/system/bin/sh`.
This is not a "real" root shell, in the sense that we are still constrained by SELinux.
However we just gained read access to `/init`, so we can overwrite it with a patched version.
This file is `mmap()`-ed into the init process, which means we can inject code into the highest privilege process.
The read-only `/system` works in our favor, since an init crash will just reboot into a clean slate.
The shellcode will fork-exec `demon.c`, our post-exploitiation deamon. It is a bind shell listening on port 6666.
After this, we can write back the orginal `init` and `run-as`, and left with a clean-yet-pwnded system.
##Corrupting init
Live-patching a process without crashing it is hard, especially if you can only use the ELF file to do so.
For this reason, the shellcode is split into two stages.
`payload.s` is the second stage, and it works like a function. It performs the fork-exec, then returns.
`payload2.s` is the first stage, it just calls the second stage, working with whatever code it's embedded in.
Stage2 should be placed in a large, mostly-unused region, where normal execution won't reach after completing boot.
Stage1 should be placed in a frequently used code region, which can be temporarily messed with.
After quite a lot of reversing, `__libc_init()` [addr=0x808eee0, offs=290528] was selected for stage2. Guaranteed safe.
For stage2, it was [addr=0x8065ead, offs=122541=0x1dead]: the end of `poll()` [addr=0x8065e80], and some stuff after.
It replaces a return with a jump (not call!) to `__libc_init()`, our stage2.
Because of this, when stage2 "returns", it returns from `poll()`, while keeping the original return value.
##Credits
general idea --> looking at XDA forum threads
dirtycow.c dcow.c --> based on https://github.com/timwr/CVE-2016-5195/, modified to fit project
injection targets, patch offsets, payload2.s --> came to me in a dream :)