Solar2D Decompiler Online

What to Upload

Upload the game's .apk or .xapk, or the resource.car on its own if you already have it. A normal APK decompiler shows you the Java that starts the Solar2D engine — a handful of generated classes. The entire game is Lua, compiled and packed into assets/resource.car, which no APK decompiler opens. The Java, resources and smali output is kept intact and a solar2d/ folder is added next to it.

A split bundle is fine. Store listings routinely split a game into a base APK plus per-architecture config splits. In the games measured here the resource.car is in the base APK while libcorona.so is only in config.arm64_v8a.apk, so neither file on its own identifies the game. Every split inside an XAPK is opened and searched.

What You Get Back

• solar2d/sources/ — the decompiled Lua, laid out in the project's original directory structure.
• solar2d/bytecode/ — chunks the decompiler could not reconstruct, kept as .luac rather than discarded.
• solar2d/README.txt — which archive was found, in which split, and how many chunks came back each way.
• resources/, sources/, smali/ — the normal Android output, untouched.

A bare resource.car upload produces the same sources/ and bytecode/ pair with a DECOMPILATION-NOTES.txt beside them.

The resource.car Format

Solar2D compiles every .lua file in a project to bytecode and packs the results into one archive. It is a plain container: a short header, an index of name-and-offset records, then the payloads. Nothing is compressed and nothing is encrypted, which is why opening one needs no key and no external tool.

Files are stored under their module name rather than their path, so trials/trial_5_golems.lua is packed as trials.trial_5_golems.lu. The original directory tree is rebuilt from those names.

Each payload carries a 12-byte record header in front of it. Strip that and what is left is an ordinary Lua 5.1 chunk, signature and all — which is the single most useful thing to know about this format.

Lua 5.1, Not LuaJIT

Corona and Solar2D bytecode is regularly assumed to be LuaJIT, and it is not. Every chunk across the shipped archives tested here begins with the standard Lua signature and a version byte of 5.1, compiled for 32-bit with 8-byte doubles. Solar2D's own repository vendors lua-5.1.3 and contains no LuaJIT at all.

This matters in practice: a LuaJIT decompiler will refuse these files outright, and a Lua 5.1 decompiler reads them. If you have been trying .lu files against a LuaJIT tool and getting nothing, that is why. Genuine LuaJIT bytecode belongs on the LuaJIT decompiler page instead, and standalone Lua chunks on the Lua decompiler.

Limits

• Stripped bytecode limits what comes back. Around 40% of chunks in a shipped game decompile cleanly; the rest defeat the decompiler's control-flow reconstruction and are returned as bytecode.
• Comments and formatting are gone. They were never stored in the chunk. Local variables come back as L0_0 and upvalues as _UPVALUE0_.
• Only Lua is in the archive. Images, audio and fonts ship as ordinary files and are already in the resources output.
• Downloaded code is absent. Anything the game fetches after installation was never in the upload.

Frequently Asked Questions