A while back, I was playing World of Warcraft with a friend. We used Hekili, a Lua addon that recommends which ability to use next. Recommending a spell and automatically casting it are two very different things, though.
\nOn June 17, 2025, Blizzard introduced Assisted Highlight and the Single-Button Assistant: built-in ability recommendations and a button that casts the next recommended ability, with an additional global-cooldown penalty. Separately, on October 23, 2025, Blizzard explained its planned Midnight restrictions on addons using real-time combat information to make decisions for players.
\nAround the time I stopped playing, I came across a paid tool claiming to automate rotations through a macro-related workaround. Naturally, I wanted to know how it worked.
\nThe script was protected by Luraph. That rabbit hole is how I ended up messing with Lua deobfuscation, and in this post I’ll go over what I tried.
\nLuau is Roblox’s fork of Lua 5.1: faster, sandboxed, optional types. Most Lua 5.1 code works, but not all of it.
\nMy idea was to get Luau’s compiler to emit LLVM IR instead of Luau bytecode, then use LLVM’s optimizations to simplify the obfuscated logic. Luau already handles parsing and compiling the source, so I’d just need to replace the backend, right?
\nNope. Emitting LLVM IR is only part of the job: that IR also needs to preserve dynamic operations such as table lookups, function calls, and runtime type checks. And compiling those operations doesn’t necessarily make them easier to understand. (In the end, luauc doesn’t even reuse Luau’s frontend: it has its own small handwritten parser for a subset of Lua.)
Lua is a dynamically typed language, but that doesn’t mean you can’t lift it. Types belong to values rather than fixed variable declarations; a compiler can still infer types in some places. Where it can’t, you can represent values with tags and delegate dynamic operations to helper functions.
\n-- human-hallucinated code below\nlocal Paladin = {}\nfunction Paladin:recomendspell()\n -- super duper calculations\n -- idk idk\n return "something in paladin kit"\nend\nlocal Warlock = {}\nfunction Warlock:recomendspell()\n -- super duper calculations\n -- idk idk\n return "something in warlock kit"\nend\nfunction CastRecommendedSpell(class)\n CastSpell(class:recomendspell())\nend\nCastRecommendedSpell(Paladin)\nCastRecommendedSpell(Warlock)If we compile this with luauc (default -O0) and open CastRecommendedSpell in IDA, it looks something like this:
void __fastcall sub_14000D190(\n LuaState *a1, // Runtime state.\n int a2, // Argument count.\n LuaValue *a3, // Argument array.\n LuaResults *a4) // Output results; unused in this listing.\n{\n LuaValue v5;\n LuaValue result;\n LuaValue v7;\n LuaResults v8;\n LuaValue v9, v10, v11, v12, v13, v14, v15;\n // Default the first argument to an all-zero value: tag 0 is nil.\n v5 = (LuaValue)0LL;\n if ( a2 > 0 )\n v5 = *a3; // class = arguments[0].\n // Resolve the global function CastSpell at runtime.\n j_luau_getglobal(&result, a1, "CastSpell");\n v7 = result;\n // Prepare storage for the recommendation function's return values.\n j_luau_resultsinit(&v8);\n // Construct the string key "recomendspell" (13 bytes).\n j_luau_string(&v9, a1, "recomendspell", 0xDu);\n // Resolve class["recomendspell"] at runtime.\n v10 = v5;\n v11 = v9;\n j_luau_tableget(&v12, a1, &v10, &v11);\n // class:recomendspell() passes class as the implicit self argument.\n v13 = v12; // Function to call.\n v14 = v5; // self.\n j_luau_callresults(a1, &v13, 1, &v14, &v8);\n // Forward the recommendation's results as arguments to CastSpell.\n // A final-position Lua call can contribute multiple arguments.\n j_luau_call(&v15, a1, &v7, v8.count, v8.values);\n // Release the temporary result storage.\n j_luau_resultsfree(&v8);\n}Which is still a little bit hard to understand, because you need to figure out what the luau_* helpers do. Let’s try compiling with -O3:
void __fastcall sub_14000BB70(\n LuaState *a1,\n int a2,\n LuaValue *a3,\n LuaResults *a4)\n{\n unsigned __int8 type;\n char v6, v7, v8, v9, v10;\n int v11;\n __int64 boolean;\n char v13;\n LuaValue v14, v15;\n int v16;\n LuaValue result, v18, v19, v20, v21, v22, v23;\n LuaResults results;\n // The first argument's LuaValue is represented as separate fields.\n if ( a2 <= 0 )\n {\n // Construct the same all-zero default value.\n boolean = 0;\n v13 = 0;\n v11 = 0;\n v10 = 0;\n v9 = 0;\n v8 = 0;\n v7 = 0;\n v6 = 0;\n type = 0;\n }\n else\n {\n // Copy the first argument's tag, padding, and payload.\n // These are not separate Lua variables or class-specific calculations.\n type = a3->type;\n v6 = a3->_pad[0];\n v7 = a3->_pad[1];\n v8 = a3->_pad[2];\n v9 = a3->_pad[3];\n v10 = a3->_pad[4];\n v11 = (unsigned __int8)a3->_pad[5];\n v13 = a3->_pad[6];\n // "boolean" is the displayed member name, not proof of a Boolean value.\n // This copies the payload bits of the tagged LuaValue.\n boolean = a3->boolean;\n }\n v16 = v11;\n // The global lookup remains.\n j_luau_getglobal(&result, a1, "CastSpell");\n v18 = result;\n j_luau_resultsinit(&results);\n j_luau_string(&v19, a1, "recomendspell", 0xDu);\n // Reassemble class into an addressable LuaValue for the lookup helper.\n v14.type = type;\n v14._pad[0] = v6;\n v14._pad[1] = v7;\n v14._pad[2] = v8;\n v14._pad[3] = v9;\n v14._pad[4] = v10;\n v14._pad[5] = v11;\n v14._pad[6] = v13;\n v14.boolean = boolean;\n // The dynamic method lookup also remains.\n v20 = v19;\n j_luau_tableget(&v21, a1, &v14, &v20);\n v22 = v21;\n // Reassemble class again, this time as the self argument.\n v15.type = type;\n v15._pad[0] = v6;\n v15._pad[1] = v7;\n v15._pad[2] = v8;\n v15._pad[3] = v9;\n v15._pad[4] = v10;\n v15._pad[5] = v16;\n v15._pad[6] = v13;\n v15.boolean = boolean;\n // Call the dynamically resolved method, then forward its results.\n j_luau_callresults(a1, &v22, 1, &v15, &results);\n j_luau_call(&v23, a1, &v18, results.count, results.values);\n j_luau_resultsfree(&results);\n}So… what is the issue?
\nIn this build, -O3 didn’t remove any of the seven luau_* helper calls in this function, or change their order. It split the 16-byte LuaValue into separate fields and reconstructed values around the calls; the function’s LLVM IR grew from 47 to 192 lines.
Compiling to native code didn’t change that: the table accesses and calls happen inside runtime helpers. LLVM just sees calls to functions it knows nothing about, so it can’t figure out what’s in the table or what CastSpell is. Faster code, not more readable code.
The same limit shows up on obfuscated code. On my hand-built fixtures at -O2, LLVM removed a simple arithmetic dispatcher, but a table-driven VM kept its interpreter loop and table operations. Luraph is a table-driven VM, so I needed a different approach.
Now, I don’t remember which AI model I used when I first tried this, but to summarize my experience: it was pure AI slop. “Recovered” strings that got completely changed, completely new classes that the AI hallucinated, etc. It looked right. It just wasn’t the original script.
\nInstead, you should make the AI write scripts for you. The way you guide your clanker is the same way you’d deobfuscate scripts yourself:
\nI had three samples: a VM-obfuscated script from https://luaobfuscator.com/ (thank u for creating it, Mr. Ferib), saved as example.txt, and two Luraph-protected scripts, which I’ll call Luraph #1 (breakfastEngine.txt) and Luraph #2 (breakfastPaladin.txt).
I selected OBFUSCATE V1 on the default script luaobfuscator provides. The output is a ~30 KB VM script: the real program is an encoded blob, run by a custom interpreter.
\nHere’s what the AI mapped out:
\nv0 –v14 .LOL! marker: hex pairs, where a pair ending inQ means “repeat the next byte”.v28 ) that turns those bytes into prototypes: a root with 157 instructions and two children with 38 and 54. The payload uses 46 distinct opcodes, and several opcode numbers do the same thing.v29 ) that runs them: fetch op/A/B/C, pick a handler through a nested if-tree, bump the pc.However; the AI didn’t write its own deserializer at this point. It swapped the final return v29(v28(),{},v17)(...) for return v28() and ran the wrapper in Lupa to dump the prototypes. That never runs the VM payload, but it does run the obfuscator’s code, and restricted globals in Lupa are not a sandbox. If you don’t trust the script, do this in a VM.
From there: disassemble, lift to pseudo-Lua, decrypt the six strings, and manually restructure the control flow in the AI session. That interactive recovery took about 11 minutes, and the result is 47 lines. I was steering it the whole time, it’s not a one-click thing. Anyway, the interesting part:
\nfunction sieve_of_eratosthenes(n)\n local is_prime = {}\n for i = 1, n do\n is_prime[i] = i ~= 1\n end\n for i = 2, math.floor(math.sqrt(n)) do\n if is_prime[i] then\n for j = i * i, n, i do\n is_prime[j] = false\n end\n end\n end\n return is_prime\nend\nlocal primes = _G["sieve_of_eratosthenes"](420)\nfor number, prime in pairs(primes) do\n if prime then\n print("Prime found: " .. number)\n end\nendTo check it: the original and the recovered script printed the same 85 lines (four messages plus 81 primes up to 420) on both Lua 5.1 and LuaJIT, and the sieve matched an independent primality check at ten bounds from 0 to 1000. That checks the payload on those inputs, not whole-program equivalence: the wrapper’s own side effects (the FlatIdent_455BF and Descriptor globals) are left out on purpose, and Lua doesn’t generally guarantee pairs iteration order.
This only works for this one sample though. When I asked the AI to turn it into a real deobfuscator (luaudeobf), it got scalar dispatchers and junk arithmetic working, but still couldn’t recover example.txt by itself.
It also gave me my favorite example of why rule 3 matters. Lua 5.1 pools 0 and -0 as the same constant, and whichever appears first in the source wins. The recovery tool reordered statements:
local pc=1\nlocal a,b\nwhile pc~=9 do\n if pc==2 then b=-0; pc=9\n elseif pc==1 then a=0; pc=2 end\nend\nprint(1/a,1/b) -- -inf -inf“Deobfuscated” into a=0; b=-0, it prints inf inf. The tool’s 404-execution test suite passed anyway. The fix was to leave zero-sensitive dispatchers alone rather than change behavior.
Luraph is a whole different league. Same idea (decoder, VM, prototypes), but:
\nLPH blob behind a decompressor, loaded withloadstring(..., "Luraph") . Adding newlines to the decoded layer trips anti-tamper.B[pc] , operandsG[pc] ,T[pc] ,S[pc] .__index , and decoding them clears operand cells: the analysis recorded 1,055 materialization triggers, 4,367 cleared cells, and 19,971 decoy references that just error. Handlers also rewrite opcodes and operands at runtime. The instruction tables you dump at load time are not the program that runs.What worked was partial evaluation: take Luraph’s own interpreter and specialize it against each prototype, carrying the patched instruction tables along. We also tried a handwritten opcode lifter. It got deleted.
\nThe wall was state explosion. The entrypoint hit 691,725 states before the 3,600-second deadline. Raising the limits didn’t help. What helped was summarizing parts that were proven side-effect free, so it didn’t walk every state inside them. CFG structuring then took the root from 3,810 labels down to 212, and later to zero gotos.
\nZero gotos still isn’t deobfuscated, though: the frame slots, child factories and operand patching were all still there.
\nThe VM only disappeared when I asked the AI port the recovered code to Rust, and then to plain Lua 5.1: six modules (decoder, helpers, protector, frames, session, init) with no dispatcher.
So is it correct? Kinda. Under four sandbox setups, the original and the rewrite did the same host lookups, in the same order, with the same results, until the original itself stopped at a frame-template check with error e1x1g. Changing one error code in the rewrite made the comparison fail, so it’s not a check that always passes. Everything after that (rest of decoder/protector, auth/session) was only checked against test vectors made from the source. If the AI misread something, its tests probably misread it the same way.
When I asked whether it was “schizogenerated”, the honest answer was: “It isn’t made up, but it hasn’t been proven the same as breakfastEngine.txt either.” (◕‿◕✿)
Same markers and loader shape as Luraph #1, but the fields are shuffled (the opcode lives in field 8 instead of 4, and so on), so most of the pipeline carried over. 53 prototypes decoded fine; the root blew up again, this time at 200,100 labels after 886 seconds. Raising the label limit from 30,000 to 200,000 only moved where it died. What fixed it was the same summary trick, plus throwing away VM state that nothing reads later.
\nAfter that came a structured root (164/164 sandbox comparisons against the original) and do ... end cleanup. But that’s still a VM, just a prettier one.
The trick was splitting everything into two buckets: stuff only the VM cares about (registers, frames, the patched operand tables) and stuff the script actually does (calls, their order and arguments, return values, errors). The first bucket can go. The second has to stay exactly the same.
\nvmfree_recover.py specialized each child prototype into a normal function body. When a body didn’t match,vmfree_effect_equivalence.py checked whether the difference was only VM internals (renamed variables, copies). If an actual call changed, it got rejected. No “eh, this one looks nicer”.T[203] = 3 ,S[1333] = 7 ,G[1744] = 1 . That’s only true at those spots; the arrays aren’t constant.This produced breakfastPaladin_vmfree.lua, but it was still 350,353 lines. Turns out removing the VM doesn’t remove the copy-paste that structuring added.
The cleanup ran on the AST; I didn’t ask the AI to rewrite the addon from memory. It removed junk and dead stores, folded constants and copies, then merged duplicated paths back into shared branches and loops. Host lookups stayed where they were. After naming, it was 9,563 lines (breakfastPaladin_clean.lua). Then I asked about the empty argument-count checks:
if (select("#", ...) >= 14) then endWith genuine standard select, that condition only counts arguments, so it can go. That removed 1,169 empty checks and 167 unused argument-count assignments, down to 8,223 lines (breakfastPaladin_clean_05_varargs.lua).
But deleting the checks that assign captured variables would be wrong. If an argument is absent, the original can retain a previous value; a normal parameter would receive nil. Explicit nil, false, and an absent argument aren’t interchangeable here. That’s still in v2.
I still told the AI, “this still looks pretty obfuscated”. Its first readability attempt passed the application checks, syntax audit and differential fixtures, but the saved breakfastPaladin_readable.lua was 8,233 lines and the frame-setup example still looked register-based. Renaming those registers hadn’t solved the problem.
The problem was shared continuations: helper functions for code reached from several branches. They captured the recycled variables, so simple copy propagation couldn’t go through them. The next attempt merged those continuations into one control-flow graph, restructured it, and split recycled variables by where they’re defined and used. Captured variables had to keep their scope though: moving a declaration out of a loop would make callbacks share one variable instead of getting a fresh one each iteration.
\nTwo things broke along the way: splitting every register into its own local hit Lua 5.1’s local limit (so locals needed tight scopes, but too many scopes bloated the output), and a Dots vs Varargs mixup in the generated AST broke continuation collapsing until it got fixed.
From there, the AST passes collapsed safe copies, recovered method calls and string expressions, folded table stores into constructors, recovered arguments where the tuple behavior allowed it, simplified predicates, and assigned usage-based names. For example, this saved frame-setup fragment:
\nvalue_24_7 = captured_14_607_2[selectResult7]\ntemporary_24_loop1v7 = value_24_7\ntemporary_24_loop1v14 = temporary_24_loop1v7\nvalue_24_8 = temporary_24_loop1v14\ntemporary_24_loop1v14 = temporary_24_loop1v7\ntemporary_24_loop1v14 = temporary_24_loop1v14.SetAttribute\nvalue_24_7 = temporary_24_loop1v14\nvalue_24_10 = (" " .. value_24_6)\nvalue_24_10 = (selectResult8 .. value_24_10)\nvalue_24_7(value_24_8, "CurrentAttribute", value_24_10)became:
\nframes3[frameKey2]:SetAttribute("CurrentAttribute", (actionValue .. " " .. unit2))The neighboring SetFrameRef and _onshow calls became direct methods too, but they deliberately repeat the frame-table lookup. A preceding host method could mutate that table; caching the receiver across calls would be a different program. Concatenation association, multiple returns, shadowing, and effect order also got tests that make sure the tool doesn’t simplify them.
The accepted readability pipeline produced breakfastPaladin_readable_v2.lua. These are the completion report’s measurements, compared with the argument-count-cleaned baseline:
| Measure | Before v2 | v2 |
|---|---|---|
| Lines | 8,223 | 6,792 |
| Bytes | 403,650 | 349,495 |
| Statements | 6,476 | 4,549 |
| Plain copy statements | 979 | 820 |
| Functions | 248 | 224 |
That still isn’t clean original source. Shared tails, repeat ... break until true blocks, numbered names and argument-retention checks remain. The report even shows more single-use private temporaries at the end: 80 versus 48. Splitting recycled registers exposes separate locals, and some cannot be inlined across an effect or capture-lifetime barrier.
One suspicious numeric helper also stayed. Running it on its own returns 1751328000, July 1, 2025 UTC, which the preserved GetServerTime expiry guard uses. It’s application logic, not a leftover dispatcher; the cleanup didn’t remove the guard. The reason why is, the script is based on a subscription. When July 1, 2025 UTC passes, the users need to renew the script.
Every step had to pass three checks before I kept it: same app behavior, no VM left + valid syntax, and the transformation fixtures. 43 outputs passed, and 31 of them form the chain that leads to the final file. 12 failed attempts are kept separately and don’t count. The first “readable” version passed everything too; I rejected it because it was still ugly.
\nFor the final file: same app behavior in 68 sandbox scenarios, and the check caught all 4 deliberately broken versions (dropped trailing nil, swapped API order, wrong return count, broken shared variables). There are also 3,077 passing fixture comparisons, but those are small transformation tests, not 3,077 app scenarios. It compiles on Lua 5.1 with no VM leftovers, and running the cleanup again doesn’t change a byte (which doesn’t mean it can’t be simplified further).
The catch: this assumes nothing pokes at VM internals, no hooks or environment tricks, the real Lua 5.1 libraries, and the main chunk only runs once per load. Luraph’s anti-tamper isn’t checked; the script’s own guards are. I never ran it in actual WoW, and 68 scenarios aren’t every input.
\nI asked it to “deduplicate the control flow and get rid of register-style variables”. This time it counted what was left before declaring victory: repeat ... until true blocks, repeated argument-count ladders, copy-pasted chunks and numbered locals.
The plan was four passes:
\nand /or still run in the same order.local a, b, ... = ... , but only if those variables are definitelynil beforehand. Otherwise a missing argument has to keep the old value.v3 is still in progress, so I can’t say it worked yet.
\nσ(≧ε≦σ) ♡Usage snapshot: October 12, 2026. Ten sessions and 94 workers; recorded estimates, not final project totals since we still dont understand the logic.
\nI never figured out exactly how the original tool worked. The workaround has since been patched, and I don’t have WoW anymore, so I can’t finish checking it against the game. At some point I stopped caring what the script does and started caring how far AI could get with it.
\nI didn’t get the answer I originally came for. I did find out where AI actually helps with RE, and where it just makes stuff that looks right.
","headings":[{"level":1,"text":"Deobfuscating Luraph: Lifting Lua to LLVM, Then Letting AI Try","id":"deobfuscating-luraph-lifting-lua-to-llvm-then-letting-ai-try"},{"level":1,"text":"Intro","id":"intro"},{"level":1,"text":"The Lua Lifter — luau-rewrite","id":"the-lua-lifter-luau-rewrite"},{"level":1,"text":"Using AI to deobfuscate it","id":"using-ai-to-deobfuscate-it"},{"level":3,"text":"Recovering luaobfuscator","id":"recovering-luaobfuscator"},{"level":3,"text":"Recovering Luraph #1","id":"recovering-luraph-1"},{"level":3,"text":"Recovering Luraph #2","id":"recovering-luraph-2"},{"level":2,"text":"What I learned about using AI for this","id":"what-i-learned-about-using-ai-for-this"},{"level":1,"text":"Closing","id":"closing"}]}}