{"id":47973371,"title":"Show HN: Porting partially deobfuscated Old School Runescape to use LWJGL 3","points":1,"user":"stevefan1999","time":1777633670,"time_ago":"2 hours ago","type":"link","content":"

I tried to make this because I need the port to CheerpJ with a custom WebSocket wrapper that the private server is also modified to accept. The desktop client works flawlessly even on my Mac Mini M4 because LWJGL 3 ships an JNI implementation for mac-arm64. I have all the Windows, Linux and Mac platform to have their JNI bindings shipped together in the shadow jar, so as long as you have a private server running void (https://github.com/GregHib/void) then you are good to go.

What I (or LLM) vibed out is that I told it to observe how the APIs are called, and used Ghidra MCP server that I configured to load and decompile the C native libraries and do a deep research, analyzing how the native libraries worked, and then rewrite the code without using JNI but to for example, use LWJGL's OpenGL binding for the Jagex's implementation for OpenGL, and also some other native libraries like the "C library" which is basically some hardware information. Then Ghidra will puke out the decompiled pseudo C code, and let LLM to make sense of it.

The only native code left is the software rendering mode but it is obviously out of the scope as of now because we all know how worse it could be to implement software rendering in Java even with JIT. AOT might be another story, but software rendering in general is not a good idea anymore today. The code is intentionally snubbed out from being loaded in the class loader so it is a RuntimeClassError. To be fair if you want "software rendering", going through llvmpipe or Zink would fare much better.

As a result, the game client now can run over technically any platform given that LWJGL supports it, not having to care about it being 32-bit or 64-bit, without much limitations on the JVM platform besides from some deprecated APIs that I can just slop it out asking LLM to replace them with modern alternatives but I just don't really want to bother yet.

This is a direct consequences to my findings in https://github.com/stevefan1999-personal/demcstify to decompile and reconstruct Minecraft to source code, but this time I already have a partially working and launchable game only that the state of the source code was obfuscated. This is a direct thesis to the closing part of my demcstify project: you can't hide your code by layering down obfuscations and virtualizations as LLMs are kind of great at dealing with those semantic games.

Instead, now softwares can be cheaply manufactured and cloned to some port, I think it is serious time to think about how the future of software development and open source entangle with each other -- LLM can basically read the binary (binaries if it has multiple platform supports), spew out enough reasonings to know what the code and algo are doing, and even make a reasonable clean-room reimplementation of your software (I have one pending with Picovoice's Porcupine, but I just want it to run on ESP32, I have yet to release it until it really runs)","url":"https://github.com/stevefan1999-personal/void-client/tree/feat/native-to-java-port","domain":"github.com","comments":[],"comments_count":0}