{"id":4024,"date":"2016-12-22T02:50:29","date_gmt":"2016-12-22T02:50:29","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=4024"},"modified":"2016-12-22T03:36:40","modified_gmt":"2016-12-22T03:36:40","slug":"why-decompiling-lua-scripts-doesnt-work-all-the-time","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2016\/12\/22\/why-decompiling-lua-scripts-doesnt-work-all-the-time\/","title":{"rendered":"Why decompiling LUA scripts doesn’t work all the time…"},"content":{"rendered":"

In one of my posts this year I presented a bunch of decompiled LUA scripts associated with FLAME malware<\/a>. The scripts were decompiled using the Lua decompiler<\/a> – and since the decompilation process is non-trivial – it brings us closer to the subject of this post – how to work with the tool that doesn’t work all the time.<\/p>\n

First of all, the Lua Decompiler is only available as a source code and you need to compile it. This can be quite a big obstacle.<\/p>\n

I won’t go into details on how to compile it, but will mention that on a plain vanilla Ubuntu ISO (v16.0) it worked like a charm, but only after updating the environment with the developers’ tools and fixing a few things here and there (think: 2h of research and work at least). Most of the required steps require to install additional (missing packages). If you never compiled open source stuff\u00a0 you are in for a big fun and lots of googling (think: 4-8h of your life \ud83d\ude09<\/p>\n

Secondly, the compiled LUA scripts are a pain in the neck.<\/p>\n

Why?<\/p>\n

They store the size of various types in the header of the compiled LUA script. These types affect the way decompiler works.<\/p>\n

Yes, you hear that right.<\/p>\n

To decompile the byte-coded LUA script you need a version of Lua Decomiler that _matches_ the settings inside the header of a compiled LUA script!<\/p>\n

The below is a fragment of Lua Decompiler code that refers to this – the header of Lua compiled script is not fixed and it depends on the actual architecture of the CPU and compiler settings:<\/p>\n

\n
\/*\r\n* make header\r\n*\/\r\nvoid luaU_header (char* h)\r\n{\r\n\u00a0int x=1;\r\n\u00a0memcpy(h,LUA_SIGNATURE,sizeof(LUA_SIGNATURE)-1);\r\n\u00a0h+=sizeof(LUA_SIGNATURE)-1;\r\n\u00a0*h++=(char)LUAC_VERSION;\r\n\u00a0*h++=(char)LUAC_FORMAT;\r\n\u00a0*h++=(char)*(char*)&x;\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\/* endianness *\/\r\n\u00a0*h++=(char)sizeof(int);\r\n\u00a0*h++=(char)sizeof(size_t);\r\n\u00a0*h++=(char)sizeof(Instruction);\r\n\u00a0*h++=(char)sizeof(lua_Number);\r\n\u00a0*h++=(char)(((lua_Number)0.5)==0);\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\/* is lua_Number integral? *\/\r\n}<\/pre>\n<\/blockquote>\n
An example of one of the Flame files (the header) is shown below:<\/p>\n
<\/a>You can quickly decipher that most of the structures are 4-bytes long i.e. 32-bit – as such you need a 32-bit version of LuaDec compiled for this particular version of compiled bytecode. In my tests I actually compiled various versions of LuaDec and preserved them for further use.<\/p>\n
That’s it.<\/p>\n
The best advice I can give you is to get the Luadec yourself and either compile it on a system with the architectural settings that match your compiled *.lua files, or tweak the compiler settings for Luadec to achieve the same result (I am not claiming this is possible as I have not tried it).<\/p>\n
I am not sure why Lua scripts are compiled this way, but it’s pretty much nonsensical as it’s not very portable. But if the interpreter for the specific encoded Lua script is incorporated into the final malicious package the devs don’t really need to care – it simply works out of the box for them.<\/p>\n
Reversers – as it’s often the case – don’t have it that easy…<\/p>\n","protected":false},"excerpt":{"rendered":"
In one of my posts this year I presented a bunch of decompiled LUA scripts associated with FLAME malware. The scripts were decompiled using the Lua decompiler – and since the decompilation process is non-trivial – it brings us closer … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[9,44],"tags":[],"_links":{"self":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/4024"}],"collection":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/comments?post=4024"}],"version-history":[{"count":6,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/4024\/revisions"}],"predecessor-version":[{"id":4031,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/4024\/revisions\/4031"}],"wp:attachment":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/media?parent=4024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/categories?post=4024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/tags?post=4024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}