Smali patching#

All 3 of the aforementioned worked in the same way, smali patches, making development extremely slow and limited in complexity. The way smali patches work is, using something like ApkTool, firstly you disassemble the app into an IR called smali. Think assembly but instead for Java on Android. Next you modify the smali to add your functionality, run a diff utility to document the changes you did, and reassemble into a functional apk.

For reference, here’s an example that adds a simple log statement to the following snippet:

1
int square(int var1) {
2
  System.out.println("squaring: " + var1);
3
  return var1 * var1;
4
}

Equivalent smali changes:

1
sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;
2
new-instance v1, Ljava/lang/StringBuilder;
3
invoke-direct {v1}, Ljava/lang/StringBuilder;-><init>()V
4
const-string v2, "squaring: "
5
invoke-virtual {v1, v2}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;
6
move-result-object v1
7
invoke-virtual {v1, p1}, Ljava/lang/StringBuilder;->append(I)Ljava/lang/StringBuilder;
8
move-result-object v1
9
invoke-virtual {v1}, Ljava/lang/StringBuilder;->toString()Ljava/lang/String;
10
move-result-object v1
11
invoke-virtual {v0, v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
12
mul-int p1, p1, p1
13
return p1

As you can see from the one line example, this approach is extremely time-consuming and overcomplicates even the smallest of changes. While some projects have worked around this by writing as much code as possible separately and merging it into the APK later (the Vanced/ReVanced approach), looking at the codebase is like staring at a photo of SCP-096 (you’re gonna die). Is there a way to modify methods dynamically at runtime with code we compile from source?

Hooking#

The main idea behind “hooking” is to be able to dynamically hook methods (run code before/after) at runtime without requiring you to modify the actual source code. Frida exists to do this, but it’s too complex for what we need and more focused on debugging. Xposed exists, but this is before the LSPatch era, and as such it needs root which only a minority of people have.

Let’s take a look at LSPosed, a Xposed implementation anyway. Firstly, it relies on a Magisk (root framework) module to inject itself into the zygote, which is the root process for all running applications. Skipping a few details, it loads LSPlant, a hooking library into the process and loads any registered Xposed modules. Such modules can then use LSPlant through the Xposed API to hook methods in the target application just by name.

Here’s one such module that changes how the clock is displayed in the built-in SystemUI Android app, which handles your Android “desktop environment”.

1
public class RedClock implements IXposedHookLoadPackage {
2
  public void handleLoadPackage(LoadPackageParam lpparam) throws Throwable {
3
    if (!lpparam.packageName.equals("com.android.systemui")) return;
4

5
    findAndHookMethod(
6
      "com.android.systemui.statusbar.policy.Clock", // Qualified class name
7
      lpparam.classLoader, // Application classloader
8
      "updateClock", // Hook all with this method name
9
      new XC_MethodHook() {
10
        // Run after method
11
        @Override
12
        protected void afterHookedMethod(MethodHookParam param) throws Throwable {
13
          TextView tv = (TextView) param.thisObject; // Get "this"
14
          tv.setText(tv.getText().toString() + " :)"); // Adds a smiley to the clock
15
          tv.setTextColor(Color.RED); // Makes the clock red
16
        }
17
      }
18
    );
19
  }
20
}

To be clear, LSPlant itself does not require root, as every instance of Dalvik (the Java VM on Android, later replaced by ART) is independent and can freely modify itself/the process. As such, libraries such as LSPlant, Pine, SandHook, epic, and YAHFA all modify the underlying ART data that represent runtime methods in order to hook them. More on how this works in this chinese article with a translation. It’s like black magic really, I still don’t fully understand it.

So why not use LSPlant directly? Well there are a few obstacles. For one, a more complicated build process is needed in order to fit all the necessary components together. Next, we need something to compile code down to dex bytecode (Java IR for ART). And lastly, we need to modify the APK enough in order to load LSPlant itself and the rest of our external code, to avoid repackaging the entire thing on any minuscule change.

We eventually solved this with the development of the following projects:

• Aliucord Manager (Github)
  • This is a separate app that repackages a Discord APK on the users phone in order to add LSPlant and the injector.
  • Also serves as a way to avoid DMCA for distributing APKs.
• Aliuhook (Github)
  • This is a wrapper around the native LSPlant C++ API in order to provide a partial Xposed-style Java API.
• Aliucord Injector (Github)
  • Initializes LSPlant / other low level things
  • This is added into the APK to override a Discord method that is close to startup, in order to load Core.
• Aliucord Core (Github)
  • This is the “actual” place where modding starts.
  • It loads external plugins, initializes other utility patches, and adds bugfixes
• Aliucord Gradle Plugin (Github)
  • This is a gradle plugin that is used solely for the build process in development.
  • Builds plugins, core, injector into the necessary format
    • Plugins & Core into a zip containing a manifest & code compiled to dex
    • Injector into an AAR containing dex to be used in manager

Aliucord Manager#

The first time a user touches your project they must have a good experience otherwise they’ll just give up. Manager was designed with this in mind, making the installation process as simple as possible if everything goes right. Unfortunately because of Android™ and other differences between ROMs there’s a ton of issues especially with how obscure what we’re trying to do is. MIUI is the biggest offender with its “MIUI Optimizations” that breaks everything from installing an APK to hooking to literally anything on earth, and is a huge pain in the ass.

Assuming everything goes right however, after the user grants the necessary prompted permissions, the repacking process is hidden under a single button and then installation happens seamlessly.

1. Download a base Discord v126.21 (126021) APK through our proxy, redirecting to an APK mirror site.
2. Download precompiled LSPlant, Core, Injector, and Kotlin builds through Aliucord’s maven.
3. Since APKs are just a zip, open the APK using a zip library and:
   • Add in the LSPlant native library
   • Add in .dex containing Kotlin
   • Add in .dex containing Injector ^{[dex priority]}
   • Modify AndroidManifest.xml in order to:
     • Change app & package name
     • Add additional permissions
     • Change min sdk version, etc…
4. Resign the APK using a key generated on device
5. Install the APK

Aliuhook#

There isn’t much to say other than Ven made a nice Java wrapper around the LSPlant C++ API. We actually used Pine first before LSPlant existed and eventually switched over after plant became stable enough.

It also handles disabling the Hidden API Policy on Android since it’s easier natively.

Aliucord Injector#

This is what initializes Aliuhook (LSPlant) and loads the external Core.

1
package com.discord.app;
2
import android.app.Application;
3
import kotlin.jvm.internal.DefaultConstructorMarker;
4

5
public class App extends Application {
6
  public static final App.a Companion = new App.a(null);
7
  public static final class a {
8
    public a(DefaultConstructorMarker default) {}
9
  }
10
  // ...
11
}

1
// This is a class by Discord which conveniently happens to be empty
2
// Thus it offers an amazing entry point for an injection since we can safely override the class
3
public final class App$a {
4
  static {
5
    InjectorKt.init();
6
  }
7

8
  public App$a(DefaultConstructorMarker defaultConstructorMarker) {}
9
}

Hidden API Policy#

Starting in Android 9, Android now restricts which non-SDK APIs you are allowed to use. This was implemented by literally breaking any references and reflection to such APIs in your app. However, this is purely an ART restriction and as such can be lifted quite easily. Despite Google’s scary warnings this is a shit “feature” and hidden APIs are really useful for some obscure things I’m not going to cover here. Essentially, you have to call dalvik.system.VMRuntime#setHiddenApiExemptions("L") and this will disable it app-wide. But it’s not as simple as it seems because that method is behind the Hidden API as well. There are multiple cursed tricks to get around this, like meta-reflection, JNI, or my favorite and most cursed, the Unsafe class.

We’ve used meta-reflection and later switched to calling it natively instead.

As an example, this also allows you to do dumb shit like this:

1
patcher.before<TextView>("setText", /* ... */) {
2
  it.args[0] = "uwu"
3
}

Aliucord Core#

This where the actual “mod” part begins. After being downloaded and loaded by Injector, we start initializing core patches, and other utilities such as logging, a simpler patcher api, and the plugin manager. If everything goes according to plan then an Aliucord section should appear in settings to configure the mod. Most of this is uninteresting overall and kind of boilerplate, however this is what plugins interface with.

1
import com.discord.models.user.CoreUser
2
import com.discord.stores.StoreUserTyping
3

4
// Rename everyone to Clyde visually
5
patcher.instead<CoreUser>("getUsername") { "Clyde" }
6

7
// Rename a specific user visually
8
patcher.before<CoreUser>("getUsername") {
9
  if (id == 343383572805058560L) it.result = "Not Clyde!!";
10
}
11

12
// Prevent typing indicators from being sent
13
patcher.instead<StoreUserTyping>("setUserTyping", Long::class.javaPrimitiveType!!) { null };

Postmortem#

Is this overcomplicated? Yes. Is it incredibly fragile? Absolutely.

The end goal was reached however, and we have a nice client mod with pretty themes, a saturated list of plugins, and tons of people that still use it. Even though this version of Discord is now more than a year old (outdated since August 2022) it’s still on life support with the help of people who despise the new app built with React Native. (like me)