Manage to connect attacker device to the docker-android device

[VissaMoutafis]

P1 The issue is the following

• Attacker with access to the device tries to connect -> device is offline
• We need to test this step to make sure we are having a working infrastructure

Current progress

• There is a chance that the emulator is not started since when I use the docker compose or docker run command the emulator fails boot the device and the state is always "BOOTING"
• [x] Try to change docker image to test if something different happens
• [x] Search issues on the github repo
• [x] Read the error logs of the docker container emulator

[VissaMoutafis]

Issue remains but tried the following

• connect with adb client from host and exposing 5555 -> device was shown offline
• tried to connect with ubuntu container in the same network
• tried to connect to the emulator device from the container that was spawning the emulator

[VissaMoutafis]

TL;DR

• Figured that this image allows us to run adb commands to the spawned container
• tried it with the nginx deployment -> worked nicely
• Drawback: Spawn a rooted container so the attacker can do adb root; adb shell and get access to a rooted emulator in the network.

Suggestions for later

• [ ] Try to unroot the emulator or block root operations overall
• [ ] Block adb root command overall - firewall task issue
• [ ] Block su command from the phone shell - not sure for how-to
• [ ] Get inspiration from [android hack-trickz] about how to log stuff in the device

Ideas of how to deal with that (How to's and some fun tools for docker rev-eng):

• [ ] configure our own image FROM the image above: we can use docker history <image> or dive or the laniksj/dfimage docker image to reverse engineer the compiled-pushed docker images. Following is a sample of the above image after we feed it to laniksj/dfimage tool

• [ ] delete the su binary overall - some issue with /system/xbin being READ-ONLY but we can try to remount before creation

This issue describes how to run anything before the defined entrypoint. Since out-of-box docker images are immutable, we might need this "hack" to configure our final image (experimental solution, but worth a try)