Last article, you decompiled an app aiming to find flags for your CTF. Inside the decompiled app directory, there was a bunch of files with .smali extension, which apparently had some code on it, but this code actually doesn't look like Java or Kotlin (or maybe JavaScript for the React-Native guys). It's something totally diferrent.

Well, what is it then? 🤔

If you access the smali github wiki, you will find this definition:

smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation. The syntax is loosely based on Jasmin's/dedexer's syntax, and supports the full functionality of the dex format (annotations, debug info, line info, etc.)

Probably, you have already heard the word Assembly, which refers to a specific set of instructions/commands written for a specific computer architecture, in order to make a bridge between your code and the computer's hardware.

Assembly code is something that human beings still can read (although it's not as easy as Python code, for example), and each instruction of Assembly code has an equivalent in executable machine code (it's a relationship that the computer won't have with Python code).

Okay, I got it. The smali code is built to be used by my android device's CPU, right? 😎👍

Yeah, but no, but yeah. Coming back to the smali's github, we are going to find that it was meant to be "(...) used by dalvik, Android's Java VM implementation".

Initially, Android apps used to run on dalvik, which is a virtual machine built just for Android. Unlike PC compiled programs, and even unlike iOS apps, the Android code was not executed directly by your phone's CPU, it was executed inside an instance of dalvik. It's an approach very similar to how Java code runs on PCs.

But since Android 5.0 came up, it doesn't work like that anymore. Now that we have Android Runtime (ART), Android code is entirely compiled to executable machine code right after it's installed. Right below, this image shows you how was the process and how it is now:

So yes, when it comes to recent versions of Android, the smali code is built to be, in some point, used natively by your Android device's CPU. It's just important to mention that it was not always so.

So...how am I supposed to use it? 🧐

Once you compile your code, the decompilation process is not something that will bring your code back exactly as it was before, because a lot of data is lost during the compilation, specially content that is 100% unhelpful to the computer, like variable names.

But an option you have, when it comes to reverse engineering, is to work with these .smali files as they are, because they still work the same. In the last article, for example, we were able to find all the CTF flags just "grepping" for them.

They are definitely something you might consider using :)