[BUG] Applying Vmify to AntiTamper's code can produce failing code

[9382]

Describe the bug During cases of complex order-of-operation making of a table, the obfuscator will produce code that fails (Example error: attempt to perform arithmetic on field '?' (a nil value))

Expected behavior Not an error

To Reproduce Below is the function used to cause the error

local counter = 0
local function f()
    counter = counter + 1
    return counter
end

print("Expecting '1, 1', '2, 3', and '4, 5'")
local t = {f(), [f()]=f()}
t[f()] = f()
for a,b in next,t do
    print("Table dump", a, b)
end

Note that this only produces bad code on some obfuscations. For example, this one experiences an error but this one runs perfectly fine and with the correct output. I use whatever the default config is (I haven't touched any settings since cloning the repository)

[SpinnySpiwal]

seems to be an issue with using vmify twice

[SpinnySpiwal]

nvm it does not seem to happen on lua 5.1 edit: it does

[9382]

@SpinnySpiwal I've tried reducing this down to the simplest case I can. Hilariously enough, some of the code samples I generated using the Medium preset triggered the Tamper Detected! error without me having tampered with it yet, which is quite funny (and possibly a useful pointer?)

I've managed to find that the AntiTamper step by itself appears to be problematic on the rare occassion - specifically, it'll ocassionally produce the string -1.#INF in the final code (what? division by 0 or something?)

When doing AntiTamper followed by Vmify, the error messages like the one in my initial post can appear. Vmify doesn't appear to fail if I don't include AntiTamper, so I suspect AntiTamper is causing issues somehow. Absolutely no other steps are involved in these examples. Also, AntiTamper occassionally triggers itself when done before Vmify, which is a bug in either Vmify or AntiTamper (couldn't tell you which, though I imagine AntiTamper using a debug library is a very risky move)

For convenice, I've provided below a config which will reliably produce an arithmetic on local <name> (a nil value) error on the code in the original post

return {
    LuaVersion = "Lua51",
    VarNamePrefix = "",
    NameGenerator = "Mangled",
    PrettyPrint = false,
    Seed = 1701461490,
    Steps = {
        {Name="AntiTamper"},
        {Name="Vmify"},
    },
}

[Zaenalos]

replicated.lua

Probably a preset problem, anyways you can check this @9382 . It works with my custom preset and obfuscation steps.

[9382]

It works with my custom preset and obfuscation steps.

And it also works with mine the majority of the time. I've said this isn't a guaranteed error, you need to try obfuscating it multiple times with different seeds.

Looking into this a bit more, something about the AntiTamper code getting VM'd appears to be the issue.

With just the anti-tamper code, just using the Vmify step with seed 1701505585, and without having the debug part of anti-tamper enabled, an attempt to compare number with function error gets thrown by the line valid = valid and arr[1] == false and arr[2] == msg

Something in the VM is broken, what exactly I couldn't tell you since I'm not reverse engineering it from scratch. Given the fact this error doesn't happen when I change a line quite above (local line2 = [ ... ] to just local line2 = ""), you may have an issue with your VM's memory management, though that's purely a guess.

For convenience, here is the config file and input file I used: config-bugtest.txt (github wont let me upload .lua) tester-antitamper.txt

[SpinnySpiwal]

I have my own antitamper which is just 100x better without debug.sethook, but I frequently get the same arithmetic error there too

[levno-710]

I will look into this in the coming days.