daemon-sec-cheatsheet

smali-changes.md (15701B)

---

 ---
 title: "Smali - Decompiling/[Modifying]/Compiling"
 section: "Mobile"
 sectionSlug: "mobile-pentesting"
 sourcePath: "src/mobile-pentesting/android-app-pentesting/smali-changes.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/mobile-pentesting/android-app-pentesting/smali-changes.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: false
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # Smali - Decompiling/[Modifying]/Compiling
 
 Sometimes it is interesting to modify the application code to access hidden information for you (maybe well obfuscated passwords or flags). Then, it could be interesting to decompile the apk, modify the code and recompile it.
 
 **Opcodes reference:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)
 
 ## Fast Way
 
 Using **Visual Studio Code** and the [APKLab](https://github.com/APKLab/APKLab) extension, you can **automatically decompile**, modify, **recompile**, sign & install the application without executing any command.
 
 Another **script** that facilitates this task a lot is [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh)<sup>[[6]](#references)</sup>
 
 ### Split APKs / App Bundles
 
 Modern targets are commonly delivered as **split APKs** (`base.apk` + `split_config.*.apk`) instead of a single monolithic APK. If you patch only `base.apk`, resources or native libraries can go out of sync and the installation may fail.
 
 Quick triage from a device:
 
 ```bash
 adb shell pm path com.example.app
 adb pull /data/app/.../base.apk
 adb pull /data/app/.../split_config.arm64_v8a.apk
 adb pull /data/app/.../split_config.en.apk
 ```
 
 If the target is a split package, either rebuild the whole set or use tooling that **joins the APKs first**. [**apk.sh**](https://github.com/ax/apk.sh) is handy here because it can combine split APKs into a single patchable APK and fix public resource identifiers.<sup>[[6]](#references)</sup>\
 For Frida/Objection-oriented repacking workflows, also check [Android Anti-Instrumentation & SSL Pinning Bypass](/hacktricks/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass).
 
 ## Decompile the APK
 
 Using APKTool you can access to the **smali code and resources**:
 
 ```bash
 apktool d APP.apk
 ```
 
 If **apktool** gives you any error, try[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/)
 
 Some **interesting files you should look are**:
 
 - _res/values/strings.xml_ (and all xmls inside res/values/*)
 - _AndroidManifest.xml_
 - Any file with extension _.sqlite_ or _.db_
 
 If `apktool` has **problems decoding the application** take a look to [https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files) or try using the argument **`-r`** (Do not decode resources). Then, if the problem was in a resource and not in the source code, you won't have the problem (you won't also decompile the resources).
 
 ## Change smali code
 
 You can **change** **instructions**, change the **value** of some variables or **add** new instructions. I change the Smali code using [**VS Code**](https://code.visualstudio.com), you then install the **smalise extension** and the editor will tell you if any **instruction is incorrect**.\
 Some **examples** can be found here:
 
 - [Smali changes examples](/hacktricks/mobile-pentesting/android-app-pentesting/smali-changes)
 - [Google CTF 2018 - Shall We Play a Game?](/hacktricks/mobile-pentesting/android-app-pentesting/google-ctf-2018-shall-we-play-a-game)
 
 Or you can [**check below some Smali changes explained**](/hacktricks/mobile-pentesting/android-app-pentesting/smali-changes#modifying-smali).
 
 ## Recompile the APK
 
 After modifying the code you can **recompile** the code using:
 
 ```bash
 apktool b . #In the folder generated when you decompiled the application
 ```
 
 It will **compile** the new APK **inside** the _**dist**_ folder.
 
 If **apktool** throws an **error**, try[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/)
 
 ### **Sign the new APK**
 
 Then, you need to **generate a key** (you will be asked for a password and for some information that you can fill randomly):
 
 ```bash
 keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias <your-alias>
 ```
 
 Finally, **sign** the new APK:
 
 ```bash
 jarsigner -keystore key.jks path/to/dist/* <your-alias>
 ```
 
 `jarsigner` still works for some quick tests, but for modern Android builds **`apksigner` is preferred** because it handles the newer APK signature schemes.<sup>[[4]](#references)</sup>
 
 ### Optimize new application
 
 **zipalign** is an archive alignment tool that provides important optimisation to Android application (APK) files. [More information here](https://developer.android.com/studio/command-line/zipalign).<sup>[[7]](#references)</sup>
 
 ```bash
 zipalign [-f] [-v] <alignment> infile.apk outfile.apk
 zipalign -v 4 infile.apk
 ```
 
 If the APK contains bundled native libraries (`lib/*.so`), Android now recommends using **`-P 16`** so the `.so` files are aligned for both 16 KiB and 4 KiB page-size devices:<sup>[[5]](#references)</sup>
 
 ```bash
 zipalign -P 16 -f -v 4 infile.apk outfile.apk
 ```
 
 ### **Sign the new APK (again?)**
 
 If you **prefer** to use [**apksigner**](https://developer.android.com/studio/command-line/) instead of `jarsigner`, **sign the APK** after applying the `zipalign` optimization. **Sign the application only once**: use `jarsigner` before `zipalign`, or `apksigner` after `zipalign`.
 
 ```bash
 apksigner sign --ks key.jks ./dist/mycompiled.apk
 ```
 
 A more practical modern flow is:
 
 ```bash
 apktool b . -o dist/app-unsigned.apk
 zipalign -P 16 -f -v 4 dist/app-unsigned.apk dist/app-aligned.apk
 apksigner sign --ks key.jks --out dist/app-signed.apk dist/app-aligned.apk
 apksigner verify --verbose --print-certs dist/app-signed.apk
 ```
 
 Important notes:
 
 - If you **modify** an APK **after** signing it with `apksigner`, the signature is invalidated and you must sign it again.
 - `apksigner verify --print-certs` is useful to confirm the rebuilt APK is installable and to inspect the certificate that the target will expose at runtime.
 
 ## Modifying Smali
 
 For the following Hello World Java code:
 
 ```java
 public static void printHelloWorld() {
     System.out.println("Hello World")
 }
 ```
 
 The Smali code would be:
 
 ```java
 .method public static printHelloWorld()V
     .registers 2
     sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;
     const-string v1, "Hello World"
     invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
     return-void
 .end method
 ```
 
 The Smali instruction set is available [here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).
 
 ### Light Changes
 
 ### Modify initial values of a variable inside a function
 
 Some variables are defined at the beginning of the function using the opcode _const_, you can modify its values, or you can define new ones:
 
 ```bash
 #Number
 const v9, 0xf4240
 const/4 v8, 0x1
 #Strings
 const-string v5, "wins"
 ```
 
 ### Basic Operations
 
 ```bash
 #Math
 add-int/lit8 v0, v2, 0x1 #v2 + 0x1 and save it in v0
 mul-int v0,v2,0x2 #v2*0x2 and save in v0
 
 #Move the value of one object into another
 move v1,v2
 
 #Condtions
 if-ge #Greater or equals
 if-le #Less or equals
 if-eq #Equals
 
 #Get/Save attributes of an object
 iget v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I #Save this.o inside v0
 iput v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I #Save v0 inside this.o
 
 #goto
 :goto_6 #Declare this where you want to start a loop
 if-ne v0, v9, :goto_6 #If not equals, go to: :goto_6
 goto :goto_6 #Always go to: :goto_6
 ```
 
 ### Bigger Changes
 
 ### Smali gotchas that usually break rebuilds
 
 - Prefer increasing **`.locals`** when you only need temporary registers in the body of an existing method. Parameter registers (`p0`, `p1`...) are mapped to the **highest** registers of the method, so switching blindly to `.registers` often breaks argument layout.
 - `move-result`, `move-result-wide`, and `move-result-object` **must appear immediately after** the matching `invoke-*`. Inserting logging or any other opcode between them makes the method invalid.
 - `long` and `double` values are **wide** values and consume a **register pair**. If you reuse those registers later, remember that `v10` also occupies `v11`.
 - If you need to pass many registers, or very high-numbered ones, use the `/range` variants such as `invoke-virtual/range`.
 
 ### Logging
 
 ```bash
 #Log win: <number>
 iget v5, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I #Get this.o inside v5
 invoke-static {v5}, Ljava/lang/String;->valueOf(I)Ljava/lang/String; #Transform number to String
 move-result-object v1 #Move to v1
 const-string v5, "wins" #Save "win" inside v5
 invoke-static {v5, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I #Logging "Wins: <num>"
 ```
 
 Recommendations:
 
 - If you are going to use declared variables inside the function (declared `v0`, `v1`, `v2`...) put these lines after the `.locals <number>` directive and before the existing variable instructions (for example, `const v0, 0x1`).
 - If you want to put the logging code in the middle of the code of a function:
   - Add 2 to the number of declared variables: Ex: from _.locals 10_ to _.locals 12_
   - The new variables should be the next numbers of the already declared variables (in this example should be _v10_ and _v11_, remember that it starts in v0).
   - Change the code of the logging function and use _v10_ and _v11_ instead of _v5_ and _v1_.
 
 ### Patching common anti-tamper checks
 
 When an app is repacked, one of the first things that may break is an in-app **signature / installer / integrity** check. Good strings to search in JADX or in the smali tree are:
 
 - `GET_SIGNATURES`
 - `GET_SIGNING_CERTIFICATES`
 - `apkContentsSigners`
 - `MessageDigest`
 - `SHA-256`
 - `Base64`
 - `getInstallerPackageName`
 - `com.android.vending`
 
 Modern apps often call `PackageManager.getPackageInfo(..., GET_SIGNING_CERTIFICATES)`, hash the signer bytes with `MessageDigest`, and compare the result with a hardcoded constant. In practice, it is usually easier to patch the **final boolean / branch** than to rewrite all the signature-handling code.
 
 Example patterns:
 
 ```text
 # Force a boolean result to "valid"
 const/4 v0, 0x1
 
 # Or invert the branch that sends execution to the tamper handler
 if-eqz v0, :tamper_detected   # original
 if-nez v0, :tamper_detected   # patched
 ```
 
 If the verification code is noisy, look for the **last comparison** before the error dialog / `finish()` / `System.exit()` / telemetry call and patch there instead of touching the entire routine.
 
 ### Toasting
 
 Remember to add 3 to the number of _.locals_ at the beginning of the function.
 
 This code is prepared to be inserted in the **middle of a function** (**change** the number of the **variables** as necessary). It will take the **value of this.o**, **transform** it to **String** and them **make** a **toast** with its value.
 
 ```bash
 const/4 v10, 0x1
 const/4 v11, 0x1
 const/4 v12, 0x1
 iget v10, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I
 invoke-static {v10}, Ljava/lang/String;->valueOf(I)Ljava/lang/String;
 move-result-object v11
 invoke-static {p0, v11, v12}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;
 move-result-object v12
 invoke-virtual {v12}, Landroid/widget/Toast;->show()V
 ```
 
 ### Loading a Native Library at Startup (System.loadLibrary)
 
 Sometimes you need to preload a native library so it initializes before other JNI libs (e.g., to enable process-local telemetry/logging).<sup>[[3]](#references)</sup> You can inject a call to `System.loadLibrary()` in a static initializer or early in `Application.onCreate()`. Example Smali for a static class initializer (`<clinit>`):
 
 ```text
 .class public Lcom/example/App;
 .super Landroid/app/Application;
 
 .method static constructor <clinit>()V
     .registers 1
     const-string v0, "sotap"         # library name without lib...so prefix
     invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
     return-void
 .end method
 ```
 
 Alternatively, place the same two instructions at the start of your Application.onCreate() to ensure the library loads as early as possible:
 
 ```text
 .method public onCreate()V
     .locals 1
     
     const-string v0, "sotap"
     invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
 
     invoke-super {p0}, Landroid/app/Application;->onCreate()V
     return-void
 .end method
 ```
 
 Notes:
 - Make sure the correct ABI variant of the library exists under `lib/<abi>/` (e.g., `arm64-v8a`/`armeabi-v7a`) to avoid `UnsatisfiedLinkError`.
 - Loading very early (class static initializer) guarantees the native logger can observe subsequent JNI activity.
 
 ## Smali Static Analysis / Rule-Based Hunting
 
 After decompiling with `apktool`, you can **scan Smali line-by-line** with regex rules to quickly spot anti-analysis logic (root/emulator checks) and likely hardcoded secrets. This is a **fast triage** technique: treat hits as leads that you must verify in surrounding Smali or reconstructed Java/Kotlin.<sup>[[1]](#references)[[2]](#references)</sup>
 
 Key ideas:
 - **Library filtering**: suppress or tag findings under common third-party namespaces so you focus on app-owned code paths.
 - **Context hints**: require suspicious strings to appear near the APIs that consume them (within the same method, within N lines).
 - **Confidence**: use simple levels (high/medium) to rank leads and reduce false positives.
 
 Example library prefixes to suppress by default:
 ```text
 Landroidx/
 Lkotlin/
 Lkotlinx/
 Lcom/google/
 Lcom/squareup/
 Lokhttp3/
 Lokio/
 Lretrofit2/
 ```
 
 Example detection rules (regex + context heuristics):
 ```json
 {
   "category": "root_check",
   "regex_patterns": [
     "(?i)invoke-static .*Runtime;->getRuntime\\(\\).*->exec\\(.*\\"(su|magisk|busybox)\\"",
     "(?i)const-string [vp0-9, ]+\\"(/system/xbin/su|/system/bin/su|/sbin/su)\\""
   ],
   "context_hint": "Only report when the same method also calls File;->exists/canExecute or Runtime;->exec."
 }
 ```
 
 Additional heuristics that work well in practice:
 - **Root package/path checks**: require nearby `PackageManager;->getPackageInfo` or `File;->exists` calls for strings like `com.topjohnwu.magisk` or `/data/local/tmp`.
 - **Emulator checks**: pair suspicious literals (e.g., `ro.kernel.qemu`, `generic`, `goldfish`) with nearby `Build.*` getters and string comparisons (`->equals`, `->contains`, `->startsWith`).
 - **Hardcoded secrets**: flag `const-string` only when a nearby `.field` or `move-result` identifier includes keywords like `password`, `token`, `api_key`. Explicitly ignore UI-only markers such as `AutofillType`, `InputType`, `EditorInfo`.
 
 Rule-driven scanners like PulseAPK Core implement this model to quickly surface anti-analysis logic and potential secrets in Smali.
 
 ## References
 - [1] [PulseAPK Core](https://github.com/deemoun/PulseAPK-Core)
 - [2] [PulseAPK Smali Detection Rules](https://github.com/deemoun/PulseAPK-Core/blob/main/APK_ANALYSIS_RULES.md)
 - [3] [SoTap: Lightweight in-app JNI (.so) behavior logger](https://github.com/RezaArbabBot/SoTap)
 - [4] [Android Developers: apksigner](https://developer.android.com/tools/apksigner)
 - [5] [Android Developers: zipalign](https://developer.android.com/tools/zipalign)
 - [6] [apk.sh](https://github.com/ax/apk.sh)
 - [7] [developer.android.com - Command Line - Zipalign](https://developer.android.com/studio/command-line/zipalign)