Smali By bithowl: Chapter 5 Smali File Structure

When most people open a Smali file for the first time, they have the same reaction.

"What am I looking at?" There's no public class. No familiar Java syntax. No curly braces.

Instead, you see lines like: .class public Lcom/example/app/MainActivity;

.super Landroidx/appcompat/app/AppCompatActivity;

It feels like a completely different language.

But here's the secret: A Smali file isn't random. It's incredibly organized.

Every file follows almost the same structure.

Once you learn that structure, you can open almost any Android application and immediately understand what you're looking at.

Today, we're going to dissect a Smali file line by line.

# The Story (Hook)

Imagine you're standing outside a house you've never visited before.

At first, it looks unfamiliar. But after stepping inside, you begin recognizing familiar rooms.

The entrance. The living room. The kitchen. The bedrooms.

Every house is different, yet almost all follow a similar layout.

Smali files work exactly the same way.

The names may change. The methods may change. The classes may change.

But the structure rarely does.

Once you understand the layout, navigating any Smali file becomes much easier.

# A Typical Smali File

Most Smali files follow this general structure:

.class

.super

.source

.implements

.field

.method

…

.end method

.method

…

.end method

Each directive describes one part of the compiled class.

Let's examine them one by one.

1) .class — Defining the Class

Every Smali file begins with the .class directive.

Example: .class public Lcom/example/app/LoginActivity;

This line tells Android:

• This file represents a class.
• The class is public.
• Its fully qualified name is: com.example.app.LoginActivity

Notice something unusual: Lcom/example/app/LoginActivity;

This is called a Type Descriptor.

In Smali:

• L means Object Type
• / replaces Java's .
• ; marks the end of the type

So: Landroid/content/Intent;

is simply: android.content.Intent

2) .super — Parent Class

Every Java class extends another class.

Smali expresses this using: .super Landroidx/appcompat/app/AppCompatActivity;

Equivalent Java: extends AppCompatActivity

This tells Android which parent class should be inherited.

3).source — Original Source File

Example: .source "LoginActivity.java"

This records the source filename used during compilation.

Although useful for debugging, obfuscation tools often rename or remove this information.

4).implements — Implementing Interfaces

If a class implements interfaces, you'll see: .implements Ljava/lang/Runnable;

Equivalent Java: implements Runnable

A class may contain multiple .implements directives.

This helps Android understand which contracts the class fulfills.

5).field — Class Variables

Fields are variables that belong to a class.

Example: .field private token:Ljava/lang/String;

Equivalent Java: private String token;

Another example: .field public static VERSION:I

Equivalent Java: public static int VERSION;

Fields may include modifiers such as:

• public
• private
• protected
• static
• final
• volatile
• transient

These modifiers behave similarly to Java.

6).method — Defining a Method

Methods contain executable code.

Example: .method public login()V

Equivalent Java: public void login()

Everything between:

.method

and

.end method

belongs to that method.

This block contains:

• Register declarations
• Instructions
• Method calls
• Branches
• Return statements

Most of your reverse engineering work happens here.

7).end method

Every method must end with: .end method

This tells the assembler that the current method definition is complete.

Think of it like the closing brace (}) in Java.

8 ) Constructors

Constructors look slightly different.

Instead of using the class name, Smali uses:

Example: .method public constructor ()V

Equivalent Java: public LoginActivity()

Static constructors use:

These execute once when the class is first loaded.

You'll commonly find initialization code here.

# Understanding Methods

Inside every method you'll eventually encounter instructions like:

invoke-virtual, move-result, const-string, return-void

Don't worry about memorizing them yet.

For now, simply recognize that every method is composed of bytecode instructions executed one after another.

We'll study these instructions in later chapters.

# Inner Classes

Java allows classes to exist inside other classes.

Example: MainActivity.SettingsFragment

In Smali you'll often see: MainActivity$SettingsFragment.smali

The $ symbol indicates an inner or nested class.

Common examples include:

MainActivity$1.smali

MainActivity$2.smali

LoginActivity$Callback.smali

Anonymous classes frequently receive numeric names.

These files are extremely common in Android applications.

# Access Modifiers

Just like Java, Smali uses access modifiers to control visibility.

Common modifiers include:

1.Public: Accessible from anywhere

2.Private: Accessible only within the class

3.Protected: Accessible to subclasses

4.Static: Belongs to the class rather than an object

5.Final: Cannot be overridden or modified

6.Abstract: Method or class has no implementation

These modifiers appear directly within directives such as: .class public or .method private

Understanding these modifiers helps identify sensitive methods, hidden APIs, and internal application logic.

# How Everything Fits Together

Think of every Smali file as a blueprint.

.class

│

▼

.super

│

▼

.implements

│

▼

.field

│

▼

.method

│

▼

Instructions

│

▼

.end method

Once you recognize this pattern, reading Smali becomes much less intimidating.

# Bug Hunter Perspective

Experienced Android security researchers rarely read Smali from top to bottom.

Instead, they scan the file structure to quickly understand what they're dealing with.

Questions they ask include:

• Is this an Activity, Service, Broadcast Receiver, or utility class?
• Which class does it extend?
• Does it implement security-sensitive interfaces?
• Are there suspicious static fields storing secrets?
• Which methods look related to authentication, encryption, networking, or root detection?
• Are there inner classes handling callbacks or background tasks?

By recognizing these structural clues, researchers can quickly prioritize which files deserve deeper analysis.

For example:

• A class extending WebViewClient may contain WebView security logic.
• A class implementing X509TrustManager often relates to SSL certificate validation.
• Fields named API_KEY, SECRET, or BASE_URL may reveal sensitive configuration.
• Constructors can expose initialization routines and dependency injection.

Before reading a single bytecode instruction, the file's structure often reveals its purpose.

# Practical Exercise

Extract any APK using APKTool: apktool d app.apk

Open any .smali file and try to identify:

• The class name (.class)
• The parent class (.super)
• The source filename (.source)
• Any implemented interfaces (.implements)
• All declared fields (.field)
• Constructors ( or )
• Public and private methods
• Inner classes (files containing $)

Don't worry about understanding every instruction.

For now, focus on recognizing the overall layout.

Once you can identify these building blocks instantly, learning Smali instructions becomes much easier.

# Quick Recap

• Every Smali file follows a predictable structure.
• .class defines the class and its access level.
• .super identifies the parent class.
• .source records the original source filename.
• .implements lists implemented interfaces.
• .field declares class variables.
• .method begins a method definition, while .end method closes it.
• Constructors use , and static initializers use .
• Inner classes use the $ naming convention.
• Understanding file structure is the first step toward reading Smali efficiently.

# Final Thought

A beginner opens a Smali file and sees strange symbols.

An experienced reverse engineer opens the same file and immediately sees a class hierarchy, object relationships, fields, methods, and potential attack surfaces.

The code hasn't changed. Only the way it's being read.

Because before you understand what a program does, you must first understand how it's organized.

By — bithowl