movfuscator VS Unity-game-hacking

Everything can be reduced to assignments. https://github.com/xoreaxeaxeax/movfuscator

However, the movfuscator as implemented does still require a sigaction(2) syscall to set up a signal handler, under the justifications that "it is not actually part of the program" and that "if we were in ring 0, we wouldn't need help from the kernel" [0]. However, the latter part seems a little dubious to me: without the help of the kernel running non-MOV instructions, you'd never be able to escape from 16-bit real mode into 32-bit protected mode, since you wouldn't be able to load a valid GDT with the LGDT instruction (as far as I am aware).

[0] https://github.com/xoreaxeaxeax/movfuscator/blob/90a49f31219...

I _think_ the idea is thinking of an "interface" as "something that you use as a way to interact with something from outside an abstraction". I'd summarize their argument as reasoning that if the goal of an abstraction is to avoid having to care about the internal details of something, an interface is a way to expose a subset of ways to interact with it, and the more you expand it, the more it exposes the internals of the thing being abstracted. I don't think they necessarily mean this only in terms of programming, but you could apply this argument to a programming language interface; if you use an interface for interacting with something instead of its direct functionality, each additional method you add to the interface exposes more details of the inner value, which makes it less of an abstraction.

Assuming my interpretation is correct, I'm not sure I totally buy this argument because there doesn't seem to be an obvious way to define the "size" of an interface where it holds true. The naive way to define the size would be number of methods, but I'd argue that methods can vary so much in terms of the amount of cognitive overhead they "expose" to the user that it's not very meaningful. Consider the Movfuscator compiler[0], which compiles code into binaries only using MOV x86 instructions because it happens to be Turing complete; as complex as it might be to learn x86 assembly as a whole and start writing programs directly in it, I'm dubious that trying to do so only with MOV would somehow be easier. Put another way, an x86 instruction set that only contains the MOV instruction is not a "stronger" abstraction than the actual one because it _introduces_ complexity that doesn't exist in the original. Does adding an ADD instruction alongside MOV increase the strength of the abstraction, or weaken it? I don't think there's an answer that we'd immediately all agree on for this sort of thing.

Ultimately, I think trying to measure interfaces through the number of methods they expose is similar to trying to measure code by the number of lines in it; while there are some extreme cases where we'd likely all agree (e.g. for a fizzbuzz implementation, having 10 lines of code is probably better than thousands of lines of code[1]), we can't really come up with a good objective metric because the "target" number is based on the complexity of what you're trying to define, and we don't have a way of quantifying that complexity. I think the ideas here are still super interesting though, not because they have definitive right or wrong answers, but because thinking about stuff like this overall improves one's ability to write good software for usage by other programmers.

[0]: https://github.com/xoreaxeaxeax/movfuscator

The mov instruction in x86-64 is Turing complete. Someone even made a C compiler using only mov.

Are you sure they didn't use the MOVFUSCATOR?

Yep. In fact you can reduce everything to just one simple assembly instruction.

The game is made with Unity so it uses C# for its code. I like to mod the game using something like BepInEx, so that the actual assets and code of the game remain untouched. This resource, was also helpful for me when I was first learning how to mod the game.

AssetStudio - let's you extract models, textures, sounds, etc. from the game's assetbundles (aka: the game's compressed / packed data). There's also this guide on other programs for Unity modding - less of a guide really, more for finding out what other tools there are.

HK is a unity project that they decompiled the source with tools like these and made changes to build for Android. Halo was on a proprietary engine made specifically for non mobile architecture.

Yea, Unity being so popular means it has a whole ecosystem of decompiler and asset extractor tools: https://github.com/imadr/Unity-game-hacking

Here's a guide regardless. Assumes previous programming knowledge.

I have done some very limited modding of the .dll with Ilspy/Reflexil, but most variable modification does nothing at all. Not exactly sure why that is as, most games that I mod in this manner, if I change a 1 to a 4, then it correctly is applied ingame. In theory I could do further modification with the Unity Assets Bundle Extractor (or UABE for short), but that requires knowing the precise name of specific entities, items, and traits, to do so (the search function is fairly barebones, so unless you know precisely what something is called, you have to manually search through thousands of entries). I have also looked into other tools that might do the job (here is a link to the various tools and suggestions on how to "mod" unity titles) = https://github.com/imadr/Unity-game-hacking), but again, still require the precise name of things to modify them, and for reasons unknown, the QuickBMS script doesn't work on any of the Void Bastard files (but does work on other Unity titles).

If you’re interested in how it works you could start here: https://github.com/imadr/Unity-game-hacking

Haha well, let me give the short version then: Dialog is represented as UUIDs (a long string of digits and letters essentially) in the game's level files. Each UUID is then mapped to different translations under the localization folder. These are in clear text, so you can immediately find (almost) all dialog in the game very easily by going to the Kingmaker_Data/StreamingAssets/Localization folder in your game files and looking at the files there that start with enGB. The harder part is figuring out who is saying what line. To do that, you have to look at the binary asset files. I have seen a few tools online that let you extract them (there's a list of them here), but it's sure to be a long and painful process.