#decompilation

Good news!

Avast has released the source code for their Retargetable Decompiler (RetDec for short).

Why am I excited about this?

Because can decompile PowerPC binaries (i.e. elf files) into a programming language (C or Python).

The main executable program in any Gamecube/Wii game is a Start.dol file, which is a variant of the elf format.  Also, the GC/Wii are both based on the PowerPC architecture.

Most decompilers will only break a game down into what’s called Assembly.  This is a type of machine code that is difficult at best to reverse-engineer.  And those that support recompiling to other programming languages typically only support the x86 architecture.

Previously, one could try RetDec online, but it had a very small limit on decompilation time (which was not enough for a file as large as the game’s main program code).  But now, I can run it on my own machine for as long as needed to run the decompilation process.

I’ve been able to successfully install RetDec and it’s dependencies.  I was then able to convert AWL’s Start.dol file into a Start.elf file using DolTool 0.3 and begin the decompilation process.

Unfortunately the decompilation failed part-way through due to not having enough memory (my laptop only has 4GB RAM).  My roommate offered to let me try on his laptop (which has 8GB), so once I’m able to try on that, I’ll post an update.

From the partial decompilation, I can tell that I’m on the right track though.  I’ve been able to find a few lines in the LLVM code that reference CLZ files and could be the key to their decompression algorithm.

@global_var_80298180.828 = constant [22 x i8] c"mainchapter%d.arc.clz\00"

…

%v4_800131f8 = call i32 @function_80238268(i32 %v2_800131f0, i32 ptrtoint ([22 x i8]* @global_var_80298180.828 to i32), i32 %v0_800131e8)

It appears that the clz file is passed through to a variable, which is them passed through some sort of function (possibly to be decompressed).

I’ll be analyzing this code as much as I can to try and figure out how the files work.

In the past, I’ve tried to decompile the game’s code using RetDec.

While I was successful in translating the games binary into some pseudo-code, I couldn’t really do anything with it.

Recently, the NSA declassified and released a powerful reverse-engineering tool called Ghidra.

In addition to that, someone created a language definitionfor Ghidra, containing specific instructions for the…

We all know Android applications are distributed as APK files, and that those files are a simple ZIP archives, but with changed extension. Peeking into them isn't obvious, though, because Java files inside are compiled and because XML files - most importantly manifest - are compiled as well.

So, we have an application on the phone. How do we look inside it?

First, we should copy it over from the phone to our computer. Let's use Google Keep as an example. To do that, we need to know the package name of this application:

$ adb shell pm list packages package:com.quickoffice.android package:com.google.android.keep ...

Once you find the package of interest in the list printed by the command above, you can get the path to the APK file:

$ adb shell pm path com.google.android.keep package:/data/app/com.google.android.keep-1.apk

Now let's get this file:

$ adb pull /data/app/com.google.android.keep-1.apk 6777 KB/s (6344188 bytes in 0.914s)

Great, we have now Google Keep APK on our computer. 

Let's now peek inside. To view the manifest file, use this command:

$ aapt -l a com.google.android.keep-1.apk

This command will output, among others, the manifest file. It's in a format where lines starting with E: are XML elements, and those starting with A: are attributes.

Okay, so now we can decompile the code. In order to do that, we need two tools: dex2jar and JD-GUI.

$ d2j-dex2jar -f -o output.jar com.google.android.keep-1.apk