317 TomiScape

[Totomi]

Ok, starting up, posting this in case someone can help.

Part 1: Analysis

Some initial analysis, please correct me if I'm wrong.

The client is usually very thin, all of the resources (notably models but also text, music and of course game logic,) are loaded as needed from the server.
In addition to old clients, the ps community also builds upon these resources, commonly referred to as caches. While 317 is the cannonical client, 377 seems to be the standard cache revision (which might be a bit after August 07 which would include things like god wars dungeon).

Deobfuscated clients seem to be mostly for those interested in client development, I'd rather download a ready to execute .jar even if it's hard to modify. Since the client is pretty complete ( due to jagex being unable to hide it), I'll just download a 317 client and a 377 cache. Once that's done I'll try to do some basic server with logging in and model loading, depending on how hard it is, I will consider reading or directly using other server implementations.


Part 2: Pivot
Following Mike's advice, I'm transitioning to reverse engineering a live organism. I've managed to run the runescape client on linux based off this halal guide: https://oldschool.runescape.wiki/w/Linux_game_installation_guide

The client downloaded some files, music started playing and I was asked to login. Not too fast, I'd rather inspect what was downloaded, archive it, capture traffic with tcpdump (also known as libpcap or wireshark) and redownload it again, so I can later analyse any client-server interaction if needed.

Thank you @mikan for the guidance.

 

[Fire Cape]

Hi,

First of all welcome to the forum.

Your questions would be better here https://www.rune-server.ee/runescape-development/rs2-server/help/.

1. The client does not contain the resource files. It fetches these from the cache, this can be fetched from the server or loaded locally.
2. The resource files are 'commonly referred' to as a cache, that is because it is also their official name (main_file_cache) and also because it is a file cache.
3. 317 is not the 'cannonical client' it is very common though.
4. The 317s load a cache from around the same period but not the original 317, many now load 377 which requires little modification (minor change to interface packet and change size check).
5. 377 is not August 2007, that period is around 468-471, 377 is not even around August 2006 (which had the new engine by this point). 377 is around June 06 afaik.
6. Deobfuscation has little to do with the 'jar file format'.
7. The client is complete but Jagex do an excellent job at hiding it, they use quite a sophisticated commercial obfuscator, even after reversal we do not have the original names.
8. Running the client on linux is just a case of running the jar file, it is cross platform.

 

[rebecca]

iiiiiiiiiiiiiiiii do not recall providing you any guidance other than saying 317 is from 2005

 

[Totomi]

Hi,

First of all welcome to the forum.

Your questions would be better here https://www.rune-server.ee/runescape-development/rs2-server/help/.

1. The client does not contain the resource files. It fetches these from the cache, this can be fetched from the server or loaded locally.
2. The resource files are 'commonly referred' to as a cache, that is because it is also their official name (main_file_cache) and also because it is a file cache.
3. 317 is not the 'cannonical client' it is very common though.
4. The 317s load a cache from around the same period but not the original 317, many now load 377 which requires little modification (minor change to interface packet and change size check).
5. 377 is not August 2007, that period is around 468-471, 377 is not even around August 2006 (which had the new engine by this point). 377 is around June 06 afaik.
6. Deobfuscation has little to do with the 'jar file format'.
7. The client is complete but Jagex do an excellent job at hiding it, they use quite a sophisticated commercial obfuscator, even after reversal we do not have the original names.
8. Running the client on linux is just a case of running the jar file, it is cross platform.

Thanks for the response! I'll take this into account.

iiiiiiiiiiiiiiiii do not recall providing you any guidance other than saying 317 is from 2005

https://sis.sy/SneakyUntrustworthySimp.png[/img[/QUOTE]

You suggested I go for the live osrs client, I wouldn't have thought of that.
Also, that syrian url looks very creepy, I'd stay away from that site if I were you. Take care


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 ([url]https://bytefreaks.net/gnulinux/how-to-capture-all-network-traffic-of-a-single-process[/url]) 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
[/CODE]

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.

 

[BertJan0]

The client downloaded some files, music started playing and I was asked to login. Not too fast, I'd rather inspect what was downloaded, archive it, capture traffic with tcpdump (also known as libpcap or wireshark) and redownload it again, so I can later analyse any client-server interaction if needed.

Why would you try to reinvent all this? Are you paranoid of bad things getting on your computer? I miss your exact goal. What is downloading is the cache. Most likely the cache is downloaded using either HTTP or JAGGRAB (but then again Hyperion has all this information for you to pick up). Also you might not have much luck looking for incoming and outgoing packets as they might be ISAAC encrypted.

 

[Corey]

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-to-capture-all-network-traffic-of-a-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:

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.

why not ask someone how it works instead of doing this weird docker shit :huh:

 

[Totomi]

Why would you try to reinvent all this? Are you paranoid of bad things getting on your computer? I miss your exact goal. What is downloading is the cache. Most likely the cache is downloaded using either HTTP or JAGGRAB (but then again Hyperion has all this information for you to pick up). Also you might not have much luck looking for incoming and outgoing packets as they might be ISAAC encrypted.

why not ask someone how it works instead of doing this weird docker shit :huh:

I'm an ironman irl