Part 3: Isolating the client.
So to recap, I tried running the client without isolating, and I noticed that it instantly downloaded a lot of resources, and I can't be sure that I have located them on disk as they are being written to various locations. So I decided to isolate the filesystem access.
I have also decided to isolate the networking so I can review the traffic without it being polluted by other random connections in the background of my pc. I tried to avoid a virtual machine, and even docker, I followed one of those googleable guides (
https://bytefreaks.net/gnulinux/how-...single-process) to isolate the network through namespaces, I don't quite understand it, but it worked.
For the filesystem I wasn't so lucky, first thing I tried is a simple Docker environment that builds from a stripped debian version and installs jdk, I couldn't even get that to work, likely due to the lack of dev tools in the stripped version, but I'd also have to connect the UI and audio between my docker instance and my computer.
I then thought of chroot, but I would have to duplicate all of my binaries and java environment in order for the chroot env to be usable. Ideally I would isolate the java client process so that it uses any resources from my root directory on a read only bases, and writes any changes to an overlay/union filesystem. I couldn't get overlayfs to work though, seems kind of complex, I would have to set up dedicated filesystems instead of playing with directories.
So in the end, I went back to docker and installed a premade jdk Dockerfile:
Code:
from openjdk:11
RUN mkdir /os
ADD jagexappletviewer.jar /os/jagexappletviewer.jar
RUN apt-get update
RUN apt-get install tcpdump -y &
RUN tcpdump -w /os/log.tcpd
ENTRYPOINT java -Djava.class.path='jagexappletviewer.jar' -Dcom.jagex.config='http://oldschool.runescape.com/jav_config.ws' /os/jagexappletviewer oldschool
The logs will be collected within the container, so it will be a bit of a hassle compared to logging the network from outside, but whatever. This probably won't run as well as in my host OS (or at all), I will need to replicate the UI and sound packages from my host, AND connect the host to the guest.
I'll also might need to filter out docker networking packets if there are any. If I'm lucky, this will run fine headless and start downloading the client, so at least I can start analyzing the initial download protocol and downloaded files before getting some eyes on the container.
The forensic approach is not easy, but I hope it's worth it once the packets and filesystem overlays from regular gameplay start flowing in.