Thread: TomiScape

Results 1 to 7 of 7
  1. #1 TomiScape 
    Donator
    Join Date
    Apr 2021
    Posts
    6
    Thanks given
    0
    Thanks received
    0
    Rep Power
    0
    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/L...allation_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.
    Reply With Quote  
     

  2. #2  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Hi,

    First of all welcome to the forum.

    Your questions would be better here https://www.rune-server.ee/runescape...2-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.
    Reply With Quote  
     

  3. #3  
    Registered Member
    rebecca's Avatar
    Join Date
    Aug 2017
    Posts
    1,071
    Thanks given
    862
    Thanks received
    915
    Rep Power
    5000
    iiiiiiiiiiiiiiiii do not recall providing you any guidance other than saying 317 is from 2005

    Attached image
    Reply With Quote  
     

  4. #4  
    Donator
    Join Date
    Apr 2021
    Posts
    6
    Thanks given
    0
    Thanks received
    0
    Rep Power
    0
    Quote Originally Posted by Fire Cape View Post
    Hi,

    First of all welcome to the forum.

    Your questions would be better here https://www.rune-server.ee/runescape...2-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.

    Quote Originally Posted by mikan View Post
    iiiiiiiiiiiiiiiii do not recall providing you any guidance other than saying 317 is from 2005

    [img]https://sis.sy/SneakyUntrustworthySimp.png[/img
    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 (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.
    Reply With Quote  
     

  5. #5  
    Registered Member
    Join Date
    Jul 2016
    Posts
    69
    Thanks given
    8
    Thanks received
    17
    Rep Power
    64
    Quote Originally Posted by Totomi View Post
    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.
    Reply With Quote  
     

  6. #6  
    Blurite

    Corey's Avatar
    Join Date
    Feb 2012
    Age
    26
    Posts
    1,491
    Thanks given
    1,245
    Thanks received
    1,729
    Rep Power
    5000
    Quote Originally Posted by Totomi View Post
    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.
    why not ask someone how it works instead of doing this weird docker shit
    Attached image
    Reply With Quote  
     

  7. #7  
    Donator
    Join Date
    Apr 2021
    Posts
    6
    Thanks given
    0
    Thanks received
    0
    Rep Power
    0
    Quote Originally Posted by Curiousity View Post
    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.
    Quote Originally Posted by Corey View Post
    why not ask someone how it works instead of doing this weird docker shit
    I'm an ironman irl
    Reply With Quote  
     


Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •