Thread: decent deobfuscator [request]

Results 1 to 5 of 5
  1. #1 decent deobfuscator [request] 
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    what's the current state of pre rs3 deobfuscators , couldn't find a link to the old popcorn or white castle one and don't know enough bytecode or anything to do it myself but would be interested in learning - looked at the 'java deobfuscator' project on GitHub and learned a bit about zkm and stringer but don't know enough yet for it to be usable. where did u pros learn this stuff or should I just sit down and sift through the bytecode until something makes sense.

    tldr how do I make the jump from general java deobfuscating to deobfuscating RS
    Reply With Quote  
     

  2. #2  
    l e l w o t

    Box's Avatar
    Join Date
    Jan 2016
    Posts
    230
    Thanks given
    76
    Thanks received
    55
    Rep Power
    156
    Books lots and lots of books....

    OT: Just read up and work with the JD project some more.
    Reply With Quote  
     

  3. #3  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Took me a while to notice this because of the section it's in...

    Copies of Saevion's (popcorn89's is based on this I think, with very few changes) and Whitecastle's deobfuscators:

    saevion-deobfuscator.tar
    whitecastle-deobfuscator.tar

    frank's post here is a pretty good summarry of most of the obfuscation techniques used by Jagex (at least around the 4xx/5xx era):

    https://forum.moparisthebest.com/t/d...eobs/5558.html (scroll down to #15)

    One of the big things missing from frank's post is the integer field multiplication obfuscation in later revisions - super_'s post here has a succinct summary of that:

    https://www.rune-server.ee/runescape...ml#post3710734

    And for a period of time they also had the "cluster flutterer" obfuscation. I never looked into this much, but I think it basically involved compiling all the code to work like Perl's "inside-out objects" - I think each field was turned into a static array, and I think each object had a unique id for indexing into that array to look up each field. However, I'm just going by my rough memory of things here so don't trust me!

    I think OSRS also has some additional techniques too (e.g. splitting exception ranges, inserting extra jumps to obfuscate the control flow?) - but again, I've not really looked at those, so don't take my word for it. I think they also removed the ZKM opaque predicates. OpenOSRS still maintains a fork of the original RuneLite deobfuscator (https://github.com/open-osrs/runelit...r/deobfuscator), which RuneLite were forced to remove from the public repository.

    Many techniques are specific to ZKM and Jagex's own obfuscation tool - so you generally won't have any luck using random deobfuscators from GitHub (at least for the non-ZKM stuff).

    Excluding OSRS from this point onwards. The two most critical obfuscation techniques that actually break decompilation for most clients are both from ZKM:

    * dummy exception handlers that simply re-throw the exception
    * opaque predicates

    The exception handlers simply wrap a piece of code with a handler that either immediately ATHROWs or does a ASTORE ALOAD ATHROW sequence. So if you could decompile it, it'd look something like:

    Code:
    try {
        ...
    } catch (RuntimeException ex) {
        throw ex;
    }
    This is essentially the same as not having a try/catch at all.

    The problem is that the start/end of the try block are actually inserted in a location it'd be impossible for a Java compile to insert them (for example, in the middle of an expression), so the decompiler will never be able to structure the code (and either produces garbage output or just fails to decompile).

    The idea of ZKM's opaque predicate obfuscation is to:

    (1) replace GOTOs with a conditional branch that is always taken
    (2) insert conditional branches in random places that are never taken

    These make the control flow graph look unlike anything a Java compiler would produce, making it impossible for a pattern-matching decompiler to structure the code. (I suspect a decompiler based on DREAM could decompile it, as in theory that can structure _any_ code, though the code would probably look ugly.)

    They're fairly easy to find once you identify the "control fields" (super_ also called these "flow obstructors" in an older post, iirc). These are a pair of integer or boolean fields that every opaque predicate uses (either directly with GETSTATIC (IFEQ | IFNE), or indirectly with a GETSTATIC ISTORE followed by ILOAD (IFEQ | IFNE)). The key to finding them is to track down where they are initialized, which is done in a clever way such that each field is dependent on the other one, which presumably stops naive off-the-shelf static analysis tools from removing them. Saevion's deobfuscator finds it with a regex, though it doesn't find it in all revisions (because it's missing some cases). I use this regex in my current project (which deals with pretty much everything in frank's post, though I've still got a few more things to improve):

    Code:
                (GETSTATIC | ILOAD)
                IFEQ
                (((GETSTATIC ISTORE)? IINC ILOAD) | ((GETSTATIC | ILOAD) IFEQ ICONST GOTO ICONST))
                PUTSTATIC
    Beyond that, most of the obfuscation techniques just make it harder to read the code but don't really break a decent decompiler. The difficulty in removing them varies. Some of them are easy to remove at the bytecode level, some really need to be dealt with at the AST level. This is much more of a pain, as I think the easiest way would either be adding a deobfuscation phase at the end of your decompiler (and if it's Fernflower, good luck - Fernflower's code is awful and I have no idea how someone so bad at programming managed to write a decompiler) or by writing a tool that uses something like JavaParser (which is okay, though any transformations that require typing information don't work very well as its typing code is pretty buggy).
    .
    Reply With Quote  
     


  4. #4  
    Registered Member

    Join Date
    Feb 2010
    Posts
    3,253
    Thanks given
    1,145
    Thanks received
    909
    Rep Power
    2081
    Quote Originally Posted by Graham View Post
    Took me a while to notice this because of the section it's in...
    When I read this yesterday this confused me, came back for another read of your post since it was so detailed I've just realised I posted it in rs2 server. I completely forgot we even had the client section lol
    Reply With Quote  
     

  5. #5  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Quote Originally Posted by Fire Cape View Post
    When I read this yesterday this confused me, came back for another read of your post since it was so detailed I've just realised I posted it in rs2 server. I completely forgot we even had the client section lol
    Well, it's more that I'd never normally read the "Requests" subforum!
    .
    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

Similar Threads

  1. Requesting a decent base
    By LuxuryBrand in forum Requests
    Replies: 16
    Last Post: 08-18-2013, 07:16 AM
  2. Requesting a decent coder -639- dementhium
    By apollon in forum Requests
    Replies: 0
    Last Post: 03-27-2012, 12:33 PM
  3. request a decent spawn config
    By Phat Stacks in forum Requests
    Replies: 1
    Last Post: 03-25-2012, 02:58 AM
  4. Request (Decent Pi Source)
    By Sn0wD0g in forum Requests
    Replies: 0
    Last Post: 02-26-2012, 03:34 AM
  5. Replies: 0
    Last Post: 09-29-2010, 03:56 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •