The thing that makes interpreted languages hard to hack is their complexity, not just the fact that they move things around.

Of course, that is balanced by a few of attributes that make VM languages very easy to hack:

- Obfuscated bytecode is way clearer to understand than obfuscated x86 assembly.

- Way less potential for weird memory, flow control and register tricks.

- Many de-compilers available that get you back to (mostly) readable source code.

The thing that makes interpreted languages hard to hack is their complexity, not just the fact that they move things around.

Of course, that is balanced by a few of attributes that make VM languages very easy to hack:
- Obfuscated bytecode is way clearer to understand than obfuscated x86 assembly.
- Way less potential for weird memory, flow control and register tricks.
- Many de-compilers available that get you back to (mostly) readable source code.

It’s not so helpful for making a stand-alone cheat that you can distribute.
#1: Very few tools specialize in disassmbling interpreted languages. I wrote an x86 disassembler because there was a demand. I would not go out of my way to write one for Java, even though it is over 10 times easier to do so (I’ve at least looked into it). What is my target audience?
#2: Somewhat a strong point. Just that it won’t prove to help nor hurt conventional hacking methods, which simply aim to seek the locations of values or code. All forms of local game hacking boil down to either “locking” values (as we say) or changing code (through injection or otherwise). Flow control almost never enters into the picture and registers even less often. Hacking a register requires attaching a debugger and placing breakpoints. And weird memory would be considered helpful, though limited in its ability to thwart hackers.
#3: Even if you have the source code, it’s only helpful if you have the addresses, at least in most cases. It’s true that source can help you crack algorithms and decryption schemes, but game companies have wisely given up on these tactics. But basically all hackers are trained to do their “jobs” without source code, since they have never had it anywhere else, so having it or not will ultimately make no difference.


L. Spiro

In theory, couldn't you write your own version of the Java VM, and then run the game in your VM?

Then the fact that the VM does weird stuff like moving memory around, obviously would no longer be a concern, because it would be your system now.

Searching for Java Decompiler in google brings up a dozen of products that solve this task (same for C# decompiler). Apparently there is a huge target audience for these tools. Surely being able to easily edit the code, and being able to modify the entire execution environment is a pretty big weakness (even if 'traditional' tools are of no use)?

That’s not just theory. Yes, it could be done.

It’s just a matter of eliminating all but the most dedicated. That person will write an entire VM just because no other practical alternatives exist.

By the time he’s finished making the whole thing stable and made the garbage-collection system stable and efficient, and optimized it enough to actually play the game at a reasonable speed, the game is already outdated and no one cares about his hacks anymore.

But of course it may be useful for the next game.

Until now no one has ever gone that far out of his or her way and given the evidence it will likely never happen. The game that motivates you will definitely be dead by the time you finish, so only those who believe 2 games in a row will motivate them would even begin such a project. The ultimate weakness in interpreted languages is somehow not its downfall, thanks to the extreme amounts of effort required to exploit it.

L. Spiro

You don't need to write the VM from scratch. You'd use an existing open source one (99% of the official Java VM is open source, or there's alternative implementations).

I think the real reason that this isn't popular in the cheating community is because no one writes games in Java

*hides*

Minecraft is the only Java game I've got experience with. They're not exactly cheats (usually), but in lieu of an official modding API, people took it upon themselves to learn how to disassemble to game and create all sorts of changes and extensions to it's internal (closed source) classes. There's nothing stopping me adding all sorts of client-side hacks to my version of the game and then joining a public server, that has no way of knowing about my nefarious abilities.

That's without a customized VM or runtime hacking tools. That's just decompiling and recompiling the code

In some ways I think you might be overstating the complexity. It's not as if someone is going to write a JVM bytecode interpreter from scratch. You'd take an existing open-source interpreter (say, Mono, or the OpenJDK) and instrument it as necessary.

But it's also wholly unnecessary - the existing CLR/JVM is already an interpreted environment with full debugger support. The trick is to get out of the mindset of native memory hacks.

Why bother searching through the address space for changing values, when you can dump the classes from the jar file, and disassemble them to find the exact variable storing the value you want to edit? After that you can patch the ClassLoader to replace the entire class with one of your own making...

I hinted at it in my first reply (to swiftcoder), but Hodgman just said it straight out (and then ducked for cover).

Conventional hacking methods are the norm (hence the “conventional” part) and no one wants to learn new methods of hacking for…-

What I mean to say is that until there are enough games worthy of hacking on any interpreted language, no one is going to abandon the conventional hacking methods.

As I said, I’ve looked into adding features to MHS for hacking Java and Flash, etc., and even though I felt Java bytecode was extremely easy to decode, and it didn’t matter that sometimes Java/C# are compiled to machine code, since I already had a machine-code disassembler, I still decided against it due to lack of interest from anyone in my core audience.

To be quite frank, I’d add a Nintendo 64 disassembler before I would add a Java disassembler, because MHS is quite popular over at http://tasvideos.org/.

In the end, it is clear why this “obvious” loophole has not been abused yet.

L. Spiro

In the end, it is clear why this “obvious” loophole has not been abused yet.

The reason I said it has not been abused yet is because I have never heard of any Java game being hacked, and Minecraft was the first (and almost only) to come to mind. You’ve only described a potential for “large-scale” abuse, but not shown any evidence it has been done.

Even if it has been, it’s small fries. Partly because it can’t compare to the number of x86 and x64 games’ numbers of players, and partly because I myself would implement a Nintendo 64 disassembler before a Java disassembler because I actually enjoy watching TAS videos and I don’t think it is worth my time to make a disassembler for a whole language just to suit a single game. Partly opinionated, and partly practical. If I did implement any hacking utilities for Java, I can guess that they would go straight to Minecraft, and that is a game about which I do not care. If I implemented a set of tools for Nintendo 64, they will likely be used only by a single community, but on a ton of games that I loved while growing up.

I am trying to exemplify the priorities of a hacker. Every hacker has to weigh the time to make the hack vs. the gain in making it in the long run.

And it’s always a personal issue.

But until now I know of no person who has cared enough about any Java game to make a hack for one. Not even Minecraft.

L. Spiro

Just to clarify: While the JVM may interpret the byte code for some time before translating it to machine code, the CLR (and I believe Mono as well) will never interpret anything.

Like L. Spiro said, what makes memory scanning in managed languages somewhat harder (or rather, more tedious) is the ability of the VM to move around objects in memory at will. This will most commonly happen when the garbage collector compacts the heap after a successful collection.

I never said they make it harder since they move memory around, I'd say it's case dependent. What I mean is that it is harder to hack with memory scanners and easier to hack editing the files, what I found out messing around with one or another. See, it's easier to find a hacked version of a game with the cheats built-in, like a modded version, than a simple CE generated trainer.

Now, to know why it is harder (or why it isn't) on this or on that interpreted technology... I guess it would require a per-technology analysis.