Lua Devirtualization Part 1: Introduction 21/03/2021

All articles will target Lua, and for those who didn't know yet, Lua is a very minimalistic scripting language with only a handful of bytecodes. Our target is using Lua version 5.1, so to keep things simple we will also target Lua with version 5.1, meaning that, every time I refer to 'Lua', I am referring to Lua version 5.1 (unless I explicitly state a version).

This article is part 1 of 4, you can find a complete overview of all the articles below:

• Part 1: Introduction
• Part 2: Decompiling Lua
• Part 3: Devirtualizing Luraph

Lua Crash Course

Before we get started, there are a few things we need to know about Lua. Lua is a very basic scripting language that comes with exactly 38 bytecodes and a total of 5 registers. The registers can't be used at the same time, because some of them are shared.

The registers are named A, B, C, Ax, Bx and sBx. The first one, A, is a 8-bit register while the next two, B and C are both 9-bit registers. Then the Ax register is a 26-bit register, which is just a combination of register A, B and C. Our last two registers, Bx and sBx are also a combination, Bx is only 18-bits and is combined from register B and C. Lastly, the sBx register is a signed Bx register, this register is often used for all kinds of jumps.

Please note that, unlike traditional VMs, Lua registers are encoded inside the Lua instruction itself resulting in registers that can only be accessed from within the instruction, meaning there are no global registers.

NOTE: everything that is struck through applies to more modern versions of Lua and is out of scope for this article.

But why Lua?

Decompiling and reverse engineering Lua is pretty easy thanks to the nature of the language, it's not a flaw, it was a design choice. But that design choice may be a huge disadvantage for developers who want to make money with their Lua scripts. And trust me, I know plenty of people that do make money by selling such scripts.

The Lua language has become very popular thanks to video games like World of Warcraft, League of Legends, Roblox, Garry's Mod, and probably a lot more. Not all games allow you to execute Lua from the user interface, but World of Warcraft for example allows you to use third-party Lua-based AddOns, such AddOns are limited to only modify the user interface. But spoiler alert, people often modify the game to extend the Lua APIs so that the Lua interface is capable of (for example) automating gameplay.

Now that people figured out how to put Lua on steroids, they can start developing more versatile scripts using just Lua combined with a tool that extends the Lua API. These tools to extend the Lua API are often called 'Lua Unlockers', because, they 'unlock' Lua API's that were not originally in the game. Most of those Lua Unlockers are sold on game hacking forums, and they often are well documented so anyone can use them right away, which, makes everything just a little more interesting.

Lua Obfuscation

When people create their versatile Lua script they often put a lot of time into solving a given problem. Solving that problem often require a lot of research and only a little amount of code, meaning that most of your valuable time was put into questioning "how to fix problem X" while very little time was spend on smashing the keystrokes. So after you found your 'magic' solution, the last thing you want is, having the first guy you sell the Lua script to steal your magic solution.

And this is where Luraph comes in place, Luraph is an obfuscation tool for Lua that, you guessed it, obfuscates Lua. Below you will find a snippet from a Luraph obfuscated Lua file so you can have an idea of how a Luraph obfuscated file looks like.

local lIll1il1I11i111l1iii1 = assert
local lIllIl1IIi1iII1Iii1 = select
local lii1iii11ilIIIl11Il = tonumber
local iI1lili1I1Iiii11i1l = unpack
local i11iIIII1lilIl1i1Il = pcall
local I1lIII1ii111IIIlii1 = setfenv
<...>
    -- table loops here
<...>
local function lIll11ili1IiiIilill()
    while true do
        local IIliIIiiI11111iI1l1 = il1lIllli1illIiiliI[IiI1lIii1iliiI1l1il]
        local liiiil1lii1llll1i11 = IIliIIiiI11111iI1l1[26353]
        IiI1lIii1iliiI1l1il = IiI1lIii1iliiI1l1il + 1
        local I1ilIiIil1ii1iI1i1I = IIliIIiiI11111iI1l1[26628]
        local lilli1II1il1lliiIii = IIliIIiiI11111iI1l1[19330]
        local iIli1iiiIl1li1il1I1 = IIliIIiiI11111iI1l1[63082]
        local iII111IiiIi11liliiI = IIliIIiiI11111iI1l1[19330] - lIl11I1lIliIl1iIilil1
        local lIliiI1iIIIIiill1iI = IIliIIiiI11111iI1l1[22182]
        if liiiil1lii1llll1i11 >= 17 then
            if liiiil1lii1llll1i11 < 25 then
                if liiiil1lii1llll1i11 < 21 then
                    if liiiil1lii1llll1i11 >= 19 then
                        if liiiil1lii1llll1i11 ~= 20 then
                            if I1ilIiIil1ii1iI1i1I == 4 then
                                IiI1lIii1iliiI1l1il = IiI1lIii1iliiI1l1il - 1
                                il1lIllli1illIiiliI[IiI1lIii1iliiI1l1il] = {
                                    [26353] = 31,
                                    [63082] = (iIli1iiiIl1li1il1I1 - 25) % 256,
                                    [22182] = (lIliiI1iIIIIiill1iI - 25) % 256,
                                    [19330] = 0
                                }
                            elseif I1ilIiIil1ii1iI1i1I == 121 then
                                IiI1lIii1iliiI1l1il = IiI1lIii1iliiI1l1il - 1
                                il1lIllli1illIiiliI[IiI1lIii1iliiI1l1il] = {
                                    [26353] = 9,
                                    [63082] = (iIli1iiiIl1li1il1I1 - 233) % 256,
                                    [26628] = (lIliiI1iIIIIiill1iI - 233) % 256,
                                    [19330] = 0
                                }
                            elseif I1ilIiIil1ii1iI1i1I == 75 then
                                IiI1lIii1iliiI1l1il = IiI1lIii1iliiI1l1il - 1
                                il1lIllli1illIiiliI[IiI1lIii1iliiI1l1il] = {
                                    [26353] = 6,
                                    [63082] = (iIli1iiiIl1li1il1I1 - 75) % 256,
                                    [26628] = (lIliiI1iIIIIiill1iI - 75) % 256,
                                    [19330] = 0
                                }
                            else
<...>
        return I11i1IIiil1l11Il11l
    end
    local liIli1lil11ll1Iilli = lIlIilii1illI111i1iii()
    return ll1I1lliii1iiIii1ii(liIli1lil11ll1Iilli, Iii1i11ii1IlIillli1)()
end
lIllll1i1iilIIIi11lIi(
    "LPH!F03BAE013H00D7043H00164H00710A0200393B393BC84FFF4E2H393F436B0F0<...>9C9F5B59001961A7E0E",
    i1llilll1iliI1ii1l1()
)

NOTE 1: I have removed content wherever the <...> signs are located, the file was about 72KB total.
NOTE 2: The Lua script has been parsed through a Lua beautifier to keep things pretty.

The Luraphed file can be divided into four sections, the first section is responsible for setting up the virtual environment for the Lua VM (spoiler alert, we are looking at a Virtual Machine). Section two seems to define a lot of helper functions, which we will discuss in detail later on. Section two also seems to set up some kind of local environment, Section three is this big IF section that seems to be responsible for interpreting instructions, and finally, the last section contains a big string, starting with "LPH!, which seems to be holding hexadecimal values.

Cleaning it up

Before actually starting doing something, I had a look at all those variables and started renaming them using just notepad++. Notepad++ comes with this 'search and replace' feature, which I used to name the first few variables as seen below.

local lassert = assert
local lselect = select
local tonumberf = tonumber
local lunpack = unpack
local pCallF = pcall
local setfenvf = setfenv
local setmettabll = setmetatable
local typef = type
local getfenvv = getfenv
local ToStr = tostring
local err = error
local StrSub = string.sub
local StrByte = string.byte
local StrChar = string.char
local StrRep = string.rep
local StrGsub = string.gsub
local StrMatch = string.match

Not only did I rename those, but I have also renamed a few more obvious things such as the variable name of the "LPH!, and that's when I took another look at the whole script. After having a quick look I released there are functions from section two that get referenced a lot, so I attempted to reverse engineer those first. Have a look at a few of the functions below.

Original:

local function IiIil1I1111ll1i1ii1()
    local lIlliI1i1IIiiI1i1llil = Iiii11iiiIl1lllil1l(IIi1liiiiil1iIiil1l, iiIIIl11IllI1lIl111, iiIIIl11IllI1lIl111)
    iiIIIl11IllI1lIl111 = iiIIIl11IllI1lIl111 + 1
    return lIlliI1i1IIiiI1i1llil
end

local function LPH_GetByte()
  local var1 = StrByte(LPHSTRING, LPH_IP, LPH_IP)
  LPH_IP = LPH_IP + 1
  return var1
end

Original:

local function Ii111I1II1lIl1ll1ll()
    local lIlliI1i1IIiiI1i1llil, lIliIl1il1Ill1l1Iiill, lIll111IlilIlIIi1i1lI, lili1l11lIiIIlIl1i1 =
        Iiii11iiiIl1lllil1l(IIi1liiiiil1iIiil1l, iiIIIl11IllI1lIl111, iiIIIl11IllI1lIl111 + 3)
    iiIIIl11IllI1lIl111 = iiIIIl11IllI1lIl111 + 4
    return lili1l11lIiIIlIl1i1 * 16777216 + lIll111IlilIlIIi1i1lI * 65536 + lIliIl1il1Ill1l1Iiill * 256 +
        lIlliI1i1IIiiI1i1llil
end

local function LPH_GetDWORD()
  local b1, b2, b3, b4 = StrByte(LPHSTRING, LPH_IP, LPH_IP + 3)
  LPH_IP = LPH_IP + 4
  local result = b4 * 0x1000000 + b3 * 0x10000 + b2 * 0x100 + b1
  return result
end

I hope those two are enough to show you how effective the variable re-naming is, and how much content got revealed doing so. Another thing that took my attention was this global variable that always got increased, I renamed it to LPH_IP. Such a variable is often referred to as what's called a Virtual Instruction Pointer, it's what the VM will use to keep track of its current instruction pointer. But that didn't really turn out to be the case, since those helper functions are responsible for decoding the LPH content and thus are only used to initialize the contents for the Lua VM.

For the record, there are more than just those two helper functions. The reason you only got to see these two is that I only need two to prove my point. Below is a summary of all the helper functions I found, the function names are guessed based on their body, I will keep using these function names trough out the whole article.

• LPH_GetByte: Decodes a byte from the LPH string.
• LPH_GetDWORD: Decodes a int from the LPH string.
• LPH_GetBits: Performs weird bitwise logic (possible instruction decoder)
• LPH_GetFloat: Decodes a Float (or Double, not sure) from the LPH string.
• LPH_GetDWORD_2: Decodes Unknown 4bytes from the LPH string.
• LPH_GetString: Decodes Unknown 4bytes from the LPH string.

Unpacking

Section one was basically reversed by simply cleaning up and renaming those variables. Unfortunately, section two won't be as easy as that. It seems like someone spend some actual time in here by using tables with random-looking numbers to throw me off track. Below is the main function for section two:

local function FourLoopFunc()
    local table_result = {[69434] = {}, [58352] = {}, [92302] = {}, [122901] = {}} -- random numbers as obfuscation
    LPH_GetByte()
    local endd = LPH_GetDWORD()
    
    -- do: table_result[#4]
    for index = unk_var_1, endd do
    <...>
    
    -- do: table_result[#2]
    local endd = LPH_GetDWORD() -
    (#{<...>
    for index = unk_var_1, endd do
    <...>
    
    -- do: table_result[9173]
    LPH_GetDWORD()
    LPH_GetByte()
    LPH_GetByte() -- IP += 6
    table_result[9173] = LPH_GetByte()

    -- do: table_result[#3]
    local endd = LPH_GetDWORD() -
    (#{<...>
    for index = unk_var_1, endd do
    <...>

    -- do: table_result[#1]
    LPH_GetDWORD()
    LPH_GetByte()
    LPH_GetByte() -- IP += 6
    local endd = LPH_GetDWORD()
    for index = unk_var_1, endd do
        table_result[69434][index] = LPH_GetDWORD()
    end

    -- do: table_result[81381]
    LPH_GetByte()
    LPH_GetDWORD() -- IP += 5
    table_result[81381] = LPH_GetByte()

    -- do: table_result[109654]
    LPH_GetDWORD()
    LPH_GetDWORD()
    LPH_GetByte()
    LPH_GetByte() -- IP += 10
    table_result[109654] = LPH_GetByte()

    LPH_GetDWORD()
    LPH_GetDWORD()
    LPH_GetByte()
    LPH_GetDWORD()
    LPH_GetDWORD() -- IP += 17
    return table_result
end

Have a good look and you will see that it all comes down to table_result, the table is assigned with 4 entries that have weird numbers. You can see I have added comments such as do: table_result[#1] to indicate which number belongs to which index of the table. But other than that, I snipped out all nasty loops since I don't feel like spending a night or two on this, so well played Luraph, you win this round.

Just kidding, we can just continue to the next section because these tables are only responsible for the Lua VM constants, registers, upvalues, and some other things that will be more explained in Part 2. So bear with me while I explain to you the third section of the Lua VM.

Interpreting the interpreter

The second last section, section three, is where it's at. Do you remember that one function with all the ugly IF statements? well, this is him now:

local function UnpackFunctionidk()
    while true do
        local inst_table = flp_ret_58352[index]
        local loop_opcode = inst_table[26353] -- OPCODE
        index = index + 1 -- VM instruction pointer? (LPH_IP is just stack data?)
        local loop_v1 = inst_table[26628] -- A or B
        local loop_v2 = inst_table[19330] -- Bx
        local loop_v3 = inst_table[63082] -- A or B
        local loop_v4 = inst_table[19330] - unk_var_2 -- sBx (- 2^18/2, 17bit)
        local loop_v5 = inst_table[22182] -- C
        if loop_opcode >= 17 then
          if loop_opcode < 25 then
             if loop_opcode < 21 then
                if loop_opcode >= 19 then
                   if loop_opcode ~= 20 then
                      if loop_v1 == 4 then
                         index = index - 1
                         flp_ret_58352[index] = {
                            [26353] = 31,
                            [63082] = (loop_v3 - 25) % 256,
                            [22182] = (loop_v5 - 25) % 256,
                            [19330] = 0
                         }
                      elseif loop_v1 == 121 then
                         index = index - 1
                         flp_ret_58352[index] = {
                            [26353] = 9,
                            [63082] = (loop_v3 - 233) % 256,
                            [26628] = (loop_v5 - 233) % 256,
                            [19330] = 0
                         }
                      elseif loop_v1 == 75 then
                         index = index - 1
                         flp_ret_58352[index] = {
                            [26353] = 6,
                            [63082] = (loop_v3 - 75) % 256,
                            [26628] = (loop_v5 - 75) % 256,
                            [19330] = 0
                         }
                      else
                         if loop_v5 == 1 then
                            return true
                         end
                         local IiIiil11IIll1ii1li1 = loop_v3 + loop_v5 - 2
                         if loop_v5 == 0 then
                            IiIiil11IIll1ii1li1 = lIlIIIli1iIlll1IlliiI
                         end
                         return true, loop_v3, IiIiil11IIll1ii1li1
                      end
                   else -- opcode 20 (LEN)
                      if loop_v5 > 255 then
                         loop_v5 = table_set_1[loop_v5 - 256][int_44827]
                      else
                         loop_v5 = result_packed[loop_v5]
                      end
                      if loop_v1 > 255 then
                         loop_v1 = table_set_1[loop_v1 - 256][int_44827]
                      else
                         loop_v1 = result_packed[loop_v1]
                      end
                      result_packed[loop_v3] = loop_v5 ^ loop_v1
                   end
                elseif loop_opcode ~= 18 then -- opcode 17
                <...>

Remember those nasty tables we just talked about? here they are again. Pay close attention to the start of the IF chain, the loop_v1 to loop_v5 are temporarily storage variables for the registers, which are obtained from the table inst_table. The following data from the inst_table can be mapped to instruction info:

• inst_table[26353]: Lua Bytecode (custom).
• inst_table[26628]: Register B
• inst_table[19330]: Register Bx.
• inst_table[63082]: Register A.
• inst_table[19330] - unk_var_2: Register sBx.
• inst_table[22182]: Register C.

We can verify the value of unk_var_2 by looking right below section one, there you will find the following code.

local getbyte_7E = StrByte("~", 1) -- 7E
local unk_var_1, unk_var_2 = #{273},
    #{ 5703, 3015, 5331, 6890, 5857, 5221, 219, 1250, 2422, 4066, 2329, 3462, 2189, 6944, 4479, 2107, 6710, 5803, 4390, 5185, 806, 3642, 5866} + getbyte_7E + 130922

Now that we know which register is what, we can have a look at the IF statements. One of the first thing I noticed is those IF statements almost never have an equal statement, instead, they seem to use different kinds of operands like 'less then' or 'greater then'. Basically, any operator that is not the equal operator will be used (if possible) to make reversing a bit harder, as we will see in the next part.

Lifting to Lua

This is it, this is what y'all been waiting for. For those who don't know yet, Lifting is basically the process of mapping one instruction set to another, and in our case, we will be lifting the Luraph instructions to the original Lua instructions. Before we can do this we must identify the Luraph instructions, this explains why the IF statements are obfuscated in the first place. Doing a simple RegEx to check the Luraph bytecode and then read the body of that IF statement to identify the corresponding Lua bytecode will be a bit harder to do. Not only do we have to figure out a way to identify the Luraph bytecode, but we also need to understand the actual functionality of the original Lua bytecodes before we can identify them.

This Lua 5.3 bytecode Reference, which is for Lua 5.3 (which isn't 5.1, I know), can be used to get a better understanding of how each Lua bytecode works. Please note that the reference listed is for Lua 5.3, lets not forget that Lua 5.1 was released on 21 Feb 2006, so finding fancy documentation isn't easy. Lucky for you, there is in fact a Lua Bytecode Interpreter project on Github, which was written for Lua 5.1, in Lua 5.1. The file src/lbi.lua contains the Lua 5.1 bytecode interpreter at line 268, we can use this to manually see how Luraph is interpreting each instruction. Of cours, once we do a few instructions manual, we should jump into making a parser that can automaticlly identify the Luraph bytecode from the IF statement and then compare the body of that IF statement in order to lift the Luraph bytecode to a Lua bytecode.

Automated Lifting

Unfortunately, all the Luraph bytecodes change for every file it generates, meaning that we do have to identify all Luraph bytecodes again for every new Luraph script we want to reverse. Therefore I would like to automate the process. Not only do the bytecodes change, but the table indexing, (used for registers, constants, upvalues, etc.) may also change, which, makes it a little more difficult and very time-consuming to do manual.

Conclusion

We have analyzed a Luraph obfuscated script that is virtualizing custom/unknown bytecodes. Presumably, those bytecodes may have a different identifiers, but their functionalities will be equal to the original Lua bytecodes. After realizing that we concluded that we need to lift Luraph bytecode to Lua bytecode and then decompile them to get a somewhat human-readable Lua script.

In Part 2: Decompiling Lua, we will create a Lua decoder and decompiler that we will use to, first of all, get a better understanding of how compiled Lua works, and then continue to develop tools that we will be used to de-virtualize Luraph.

Next article: Part 2: Decompiling Lua