ethangreen-dev / lovely-injector

A runtime lua injector for games built with LÖVE
60 stars 10 forks source link

Crashes upon loading bytecode #21

Open bananasov opened 4 months ago

bananasov commented 4 months ago

Some Love2D games do not have the source available like Balatro does, an example of such game is Intravenous 2: Mercenarism.

The injector crashes on https://github.com/ethangreen-dev/lovely-injector/blob/ee3ba182d47eb3b5f5f9d9dde0e6e5674f68124c/crates/lovely-core/src/lib.rs#L142-L145 and could be fixed by checking the first byte of the slice with \033 (ASCII escape character).

Patching games that use bytecode instead of source might prove to be a major headache as it would probably require writing a disassembler and assembler for Lua(JIT) bytecode.

ethangreen-dev commented 4 months ago

Short-term it wouldn't be a bad idea to short-circuit when we detect a bytecode buffer, bonus points if there's a good descriptive message in the error.

Long-term we can implement a decompiler phase to the buffer load step - shouldn't be too hard. I do worry about decomp temporal stability though; emitted code must be the same no matter what.

bananasov commented 4 months ago

Short-term it wouldn't be a bad idea to short-circuit when we detect a bytecode buffer, bonus points if there's a good descriptive message in the error.

Long-term we can implement a decompiler phase to the buffer load step - shouldn't be too hard. I do worry about decomp temporal stability though; emitted code must be the same no matter what.

You could also just compile patches to Bytecode and only insert the instructions of the top level function (commonly referred to as a prototype) instead of just decompiling it, it removes a step that could cause performance issues I've made naively but I doubt performance would be a problem.

For the past few days I've been working on a disassembler for multiple Lua versions (currently I have implemented Lua 5.1 and Lua 5.2) including LuaJIT so that should help make supporting bytecode a bit easier.

ethangreen-dev commented 4 months ago

My big concern is that the current patch system is fundamentally incompatible with bytecode as, at the very least, we would need to lazily decompile just to provide the pattern / regex patches something to compare against. The regex patch specifically would require the entire source document to be decompiled, so that strategy won't even work all of the time.

Thankfully all of this stuff is easy to cache so performance probably isn't that big of a deal.

I have a couple ideas on ways to move forward but I want to let them sit before I make any decisions. I will say though that this is absolutely something I want to support in the future.