> ## Content Index > Fetch the complete content index at: https://taiwanding.com/llms.txt > Use this file to discover other available public pages before exploring further. # OWASP MAS Crackmes โ€” Android UnCrackable Level 2 - URL: https://taiwanding.com/en/android-uncrackable-level-2-writeup/ - Published: 2026-08-07T07:54:56.000Z - Updated: 2026-08-10T11:10:11.000Z - Author: Kevin Chen - Tags: #en, #en-ctf ๐Ÿ“š Series ยท OWASP MAS Crackmes ยท Android UnCrackable 1. [Level 1 โ€” Decompile the APK, recover the AES key (Easy)](https://taiwanding.com/en/owasp-mas-crackmes-android-uncrackable-l1-walkthrough/) 2. โ–ธ Level 2 โ€” Stripped JNI library & ptrace anti-debugging (Medium) (this post) ## Challenge Info - **Platform**: OWASP MASTG (Mobile Application Security Testing Guide) - **Challenge**: Android UnCrackable Level 2 (MASTG-APP-0004) - **Difficulty**: Medium - **Goal**: There's a secret string hidden inside the app โ€” find a way to dig it out - **Link**: https://mas.owasp.org/MASTG/apps/android/MASTG-APP-0004/ - **Environment**: WSL2 Kali Linux [MAS Crackmes - OWASP Mobile Application Security![](https://taiwanding.com/content/images/icon/logo_circle-1.png)logo![](https://taiwanding.com/content/images/thumbnail/uncrackable-logo-1.png)](https://mas.owasp.org/crackmes/?ref=taiwanding.com) In L1 the secret was AES-encrypted and hidden away โ€” you had to re-run the decryption yourself to get it. In L2 the secret **isn't encrypted at all**. It just moved down to the native layer, and then the **compiler chopped it in half** and stashed the pieces in different places. From a cryptographic standpoint L2 is weaker than L1, but in terms of reversing effort L2 takes more work. **"Difficulty" and "security" are two different things**, and that contrast is one of the most valuable takeaways from this level. The point of this write-up isn't the answer โ€” it's "given a stripped .so, how do you know which piece to pull apart?" Because that's the hardest part of real-world reversing. ## Step 1: Break down the structure, look at the diffs ```bash mkdir -p ~/mas/uncrackable-l2 && cd ~/mas/uncrackable-l2 curl -Lo UnCrackable-Level2.apk \ https://github.com/OWASP/mastg/raw/master/Crackmes/Android/Level_02/UnCrackable-Level2.apk unzip -l UnCrackable-Level2.apk ``` 414 files, 1.4MB. A world away from L1's 13 files and 66KB โ€” but **don't panic, diff it against a known sample first**. We have L1 as a baseline, so the differences are where the action is. Running the same five-question checklist we built during L1: - **โ‘ก `classes.dex`** โ†’ ballooned from L1's 5.5KB to **720KB**. Don't let that scare you โ€” **ask "what exactly got bigger?"** We'll prove later that nearly all of those 720KB are `android.support`; the author's own Java code is about the same size as L1's. - **โ‘ข `META-INF/MANIFEST.MF`** โ†’ exploded from 1KB to **50KB**. This is the v1 signature's per-file digest list; it's only that big because the whole support library got stuffed in there. **Zero value for reversing โ€” recognise it and look right past it.** **โ‘  Is there a `lib/`?** โ†’ **Yes, and this time it's the main event.** ``` lib/arm64-v8a/libfoo.so 14176 lib/armeabi-v7a/libfoo.so 13948 lib/x86/libfoo.so 13788 lib/x86_64/libfoo.so 14440 ``` One copy per architecture (the same code compiled for different CPUs), and the filename is `libfoo` โ€” `foo` is the engineer's universal placeholder name, which means **the author wrote it themselves**, it's not some well-known library. Self-written native code + crackme = the key logic is almost certainly in there. And all four files are around 14KB, so they're **small enough to read end to end**. > While we're here, let's clear up something people constantly mix up: `AndroidManifest.xml` (the app's nameplate โ€” main storyline, read it) and `META-INF/MANIFEST.MF` (the signature digest list โ€” noise, skip it) are two completely different things. ## Step 2: Narrowing 300+ classes down to 4 ```bash jadx -d "$PWD/out" "$PWD/UnCrackable-Level2.apk" find out/sources -name '*.java' | wc -l # 300+ ``` 300-odd Java files. A beginner panics; a veteran filters them in three seconds. The trick is **inverse filtering โ€” don't hunt for the main storyline, cross out all the known noise first**: ```bash find out/sources -name '*.java' | grep -v -E 'android/(support|arch|annotation)/' ``` ``` out/sources/owasp/mstg/uncrackable2/R.java โ† auto-generated, skip out/sources/sg/vantagepoint/uncrackable2/CodeCheck.java โ† new face! not in L1 out/sources/sg/vantagepoint/uncrackable2/MainActivity.java out/sources/sg/vantagepoint/a/a.java out/sources/sg/vantagepoint/a/b.java ``` **From 300 down to 4.** `android.support` and `android.arch` are Google's compatibility packages โ€” very unlikely to be hiding a secret, same reasoning as L1's `R.java`. **Knowing what noise looks like is the single biggest time-saver in recon.** Diff this against L1's structure and the delta jumps right out: the author reused the `sg/vantagepoint/a/` skeleton, but **added a `CodeCheck`**. That new face is the target. ## Step 3: Read MainActivity, find the door from Java into native ```java public class MainActivity extends c { private CodeCheck m; static { System.loadLibrary("foo"); } // โ† โ‘  private native void init(); // โ† โ‘ก protected void onCreate(Bundle bundle) { init(); // first thing at startup if (b.a() || b.b() || b.c()) { a("Root detected!"); } if (a.a(getApplicationContext())) { a("App is debuggable!"); } new AsyncTask() { // โ† โ‘ข the new third check public String doInBackground(Void... v) { while (!Debug.isDebuggerConnected()) { SystemClock.sleep(100L); } return null; } public void onPostExecute(String s) { a("Debugger detected!"); } }.execute(null, null, null); this.m = new CodeCheck(); ... } public void verify(View view) { String string = ...getText().toString(); if (this.m.a(string)) { /* Success! */ } // โ† โ‘ฃ } } ``` Four key findings: **โ‘  `System.loadLibrary("foo")` sits inside a `static {}` block** โ€” that runs first when the class loads, meaning `libfoo.so` is in memory the moment the app starts. Confirms those four files under `lib/` are genuinely used. **โ‘ก `private native void init()`** โ€” declared but with no body; the implementation lives in the `.so`. And `onCreate` calls it on the very first line, so **park it on the list: what is it doing over in native land?** **โ‘ข The defences went from L1's two checks up to three**, and the third is new: it spins up a background thread that **polls every 100ms to see whether a debugger has attached**. But the key judgement call is the same as in L1: **which path do these three actually block? All of them only fire at runtime.** Go purely static (just read files, never execute) and you won't hit a single one. Tag them "only matters for dynamic analysis" and ignore them entirely on the static route. **โ‘ฃ `verify()` calls `this.m.a()`**, and `this.m` is a `CodeCheck`. Next stop on the data flow confirmed. ## Step 4: CodeCheck โ€” the end of the line for Java ```java public class CodeCheck { private native boolean bar(byte[] bArr); public boolean a(String str) { return bar(str.getBytes()); } } ``` Five lines, and that's as far as the Java layer goes. `a()` performs no validation whatsoever โ€” it just converts the String to a `byte[]` and **hands the whole thing to `bar()`**, and `bar` is native. **The full data flow, drawn out:** ``` user taps button โ†’ MainActivity.verify() โ†’ CodeCheck.a(string) โ†’ CodeCheck.bar(byte[]) โ•โ•โ•— โ•‘ Java boundary init() โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•ฃ โ–ผ libfoo.so ``` **Both native entry points are now on the list.** ## Step 5: Pinpointing the native coordinates You can't just grep the `.so` for the three letters "`bar`" โ€” **JNI has its own naming convention**: ``` Java___ ``` So `sg.vantagepoint.uncrackable2.CodeCheck.bar` should appear in the `.so` as `Java_sg_vantagepoint_uncrackable2_CodeCheck_bar`. **But first we need to confirm the binding style.** JNI has two: **static registration** (auto-matched by naming convention, so it shows up in the symbol table) and **dynamic registration** (`RegisterNatives`, where the developer can bind a function with any name to `bar`, leaving nothing in the symbol table). And that `init()` that runs at startup would be a very convenient place to pull exactly that kind of stunt. Let's check: ```bash unzip -o UnCrackable-Level2.apk 'lib/*' -d extracted file extracted/lib/arm64-v8a/libfoo.so nm -D --defined-only extracted/lib/arm64-v8a/libfoo.so ``` ``` ELF 64-bit LSB shared object, ARM aarch64, for Android 21, built by NDK r18b, stripped 0000000000000dac T Java_sg_vantagepoint_uncrackable2_CodeCheck_bar 0000000000000d8c T Java_sg_vantagepoint_uncrackable2_MainActivity_init ``` **Static registration, no `JNI_OnLoad` โ€” the dynamic-registration branch doesn't exist here.** **Why this architecture**: WSL2 is x86\_64, but for pure static assembly reading, **arm64-v8a** is the better pick โ€” ARM64 instructions are a fixed 4 bytes and the register conventions are clean, which makes it far tidier than x86\_64. **Bonus intel from the addresses**: `init` is at `0xd8c`, `bar` at `0xdac` โ€” a gap of `0x20` \= 32 bytes. ARM64 instructions are a fixed 4 bytes, so **32 bytes = at most 8 instructions**. You can't do anything meaningful in eight instructions โ†’ `init` is a stub, probably just flipping a switch. **And you can make that call before reading a single byte of it.** ### About "stripped" `file` says `stripped` โ€” `.symtab` (the static symbol table) got cut. But `nm -D` reads `.dynsym` (the dynamic symbol table), and **that one can't be cut**. Why not? Because at runtime the JVM uses `dlsym()` to look up `Java_..._bar` by name. **Cut the name, the JVM can't find it, and the app crashes outright.** > **This principle is worth burning into your brain: stripping has a floor, and that floor is exactly the attack surface. Anything the outside world has to be able to call must keep its name.** The practical consequence: `objdump -d` labels functions using `.symtab`, so there's **no `:` label in the disassembly output to grep for**. The workaround is to **go by address**: ```bash aarch64-linux-gnu-objdump -d --start-address=0xdac --stop-address=0xe98 \ extracted/lib/arm64-v8a/libfoo.so ``` **The name is the label; the address is the thing itself. Lose the label, the thing is still there.** ## Step 6: Read the import table โ€” this one step dictates everything that follows Before reading a single line of assembly, look at this: ```bash nm -D --undefined-only extracted/lib/arm64-v8a/libfoo.so ``` ``` U __cxa_atexit@LIBC โ† C++ runtime, cross it out U __cxa_finalize@LIBC โ† C++ runtime, cross it out U __stack_chk_fail@LIBC โ† compiler-inserted canary, cross it out U _exit@LIBC U fork@LIBC U getppid@LIBC U pthread_create@LIBC U pthread_exit@LIBC U ptrace@LIBC U strncmp@LIBC U waitpid@LIBC ``` **This is the list of functions this `.so` borrows from libc, and it's the single most important section in this entire article.** **Why is it a gold mine?** Same "can't hide it" principle: a `.so` can obfuscate its code beyond recognition, **but it cannot hide which capabilities it needs to borrow from the system** โ€” because the dynamic linker relies on this list to resolve addresses. **It has to declare honestly.** Cross out the three the compiler dragged in and eight remain โ€” and **those eight sort themselves into two piles:** ### Pile one (seven): `fork` `ptrace` `waitpid` `getppid` `pthread_create` `pthread_exit` `_exit` Individually they're all mundane; together there's only one explanation. The chain of reasoning starts with the most unremarkable one, `getppid`: **Why would a program need to ask "who is my parent process"?** Normal programs almost never do. There's really only one scenario where you would: **it has just called `fork`, it's now running in the child, and it wants to do something to the parent.** Do what to the parent? Next clue: `ptrace`. **A child ptracing its own parent โ€” that's fork-ptrace anti-debugging.** The mechanism: **on Linux a process can only have one tracer at a time**. The app forks a child, the child turns around and attaches to daddy, and **the one available ptrace slot is now occupied by the family**. Want to attach gdb or lldb from outside? The kernel says `EPERM` โ€” seat's taken. `waitpid` fills in the last piece: it's a watchdog. Someone tries to kill the seat-warming child to free the slot? The other side notices immediately, and `_exit` closes up shop. `pthread_create` tells us the whole thing runs on a background thread so it doesn't block the main flow. ### Pile two (one): `strncmp` **This single symbol locks down the shape of the whole level**, from three angles: **โ‘  It's a "comparison", not a "computation".** `strncmp` compares byte by byte โ€” it doesn't transform, derive, or calculate anything. **โ‘ก There isn't a single crypto function โ€” this is negative evidence, and it matters just as much as what you do see.** No `AES`, no `EVP_*`, no `MD5`, no `SHA`, not one. And the entire `.so` is only 14KB with `bar` weighing in at 236 bytes โ€” **there's no room to cram in a hand-rolled AES**. > **This is the watershed between L1 and L2, and you can call it before reading any assembly at all**: L1 had `Cipher` and AES, so the secret was "computed"; L2 has only `strncmp`, so the secret must be \*\*"sitting in the file in plaintext"\*\*. **โ‘ข It's `strncmp`, not `strcmp` โ€” that `n` means something.** `strcmp` compares up to `\0`; `strncmp` compares a fixed length. The author picked the version that takes a length, which means **there's a hard-coded length constant in the program**, and hints that it probably checks the length before comparing. ### A behavioural draft, written without reading one line of assembly ``` init() โ† 32 bytes, too small, it's a stub โ””โ”€ kicks off the fork/ptrace/waitpid anti-debug โ””โ”€ probably flips a switch bar(byte[]) โ† 236 bytes, the verification body โ””โ”€ pulls the input byte[] out via JNI โ””โ”€ checks the length (it uses strncmp, so there's a fixed n) โ””โ”€ strncmp(input, plaintext constant, n) โ””โ”€ returns the comparison result The secret: plaintext, right here in this file ``` **And "the plaintext is in the file" points straight to the next move: go look in `.rodata`.** ## Step 7: A three-second shortcut, and one incomplete clue ```bash strings -a extracted/lib/arm64-v8a/libfoo.so | grep -i thanks ``` ``` Thanks for all t ``` **Stop here and think for three seconds.** **That sentence is incomplete.** Most people see `strings` spit out half a sentence, decide they've dredged up garbage, and throw it away. But the correct reversing instinct is: **a string that reads like real English and then abruptly stops means its tail lives somewhere else.** And we already know from the import table that **this has to be a plaintext comparison**, so the truncation can't mean "the secret just looks like that" โ€” it can only mean "the rest isn't in `.rodata`". Let's verify: ```bash aarch64-linux-gnu-objdump -s -j .rodata extracted/lib/arm64-v8a/libfoo.so ``` ``` Contents of section .rodata: 0ea0 5468616e 6b732066 6f722061 6c6c2074 Thanks for all t ``` **The entire `.rodata` section is 16 bytes. Not one byte more, not one less.** Three independent signals all point to the same conclusion: - **`.rodata` is abnormally small.** A normal program's `.rodata` is home to error messages, format strings, constant tables. Shrunk down to half a sentence means **the other stuff isn't there**. "Nothing where there should be something" is just as much a signal as "something where there shouldn't be anything". - **The number 16 should light up a bulb.** SIMD register width, AES block size, a common alignment boundary. An English sentence cutting off at exactly character 16 isn't a coincidence โ€” it's a **machine boundary**. - **English grammar.** The `t` following `for all` is obviously the start of `the`. Don't underestimate this kind of non-technical reasoning โ€” in real reversing it's often the fastest clue you get. **The only place left for the remainder: immediate values inside the code.** ## Step 8: Taking bar() apart โ€” checking the draft section by section ```bash aarch64-linux-gnu-objdump -d --start-address=0xdac --stop-address=0xe98 \ extracted/lib/arm64-v8a/libfoo.so ``` ### โ‘  Prologue (0xdacโ€“0xdd4) ```asm dac: sub sp, sp, #0x50 ; carve out 80 bytes of stack dc0: mrs x22, tpidr_el0 ; read the thread pointer dc4: ldr x8, [x22, #40] ; fetch the stack guard dc8: mov x19, x2 ; x2 = jbyteArray (third parameter) dcc: mov x20, x0 ; x0 = JNIEnv* (first parameter) dd0: mov w0, wzr ; return value defaults to 0 (false) dd4: str x8, [sp, #24] ; stash the canary on the stack ``` **JNI ABI knowledge**: JNI function parameters always come in the order `(JNIEnv* env, jobject thiz, ...actual parameters)`. So `x0`\=env, `x1`\=this, `x2`\=the first real argument. **`mov w0, wzr` โ€” deny by default.** Assume failure first, and only flip it to 1 after every check passes. Security-wise, that's the right design. ### โ‘ก The flag gate (0xdd8โ€“0xde4) โ€” confirming the draft's "probably flips a switch" ```asm dd8: adrp x8, 13000 ; base of the .data section ddc: ldrb w8, [x8, #12] ; w8 = *(0x1300c) de0: cmp w8, #0x1 de4: b.ne e68 ; โ‰ 1 โ†’ return false immediately ``` **The moment `bar` is entered it reads a global byte, and if it isn't 1 it returns false straight away โ€” no comparison at all.** `adrp` is worth understanding: ARM64 can't load a 64-bit address in a single instruction, so `adrp` first computes a 4KB-aligned page base and an offset makes up the difference. When you see `adrp` \+ `ldrb #12`, read it as "access global variable `0x1300c`". **Design intent**: make sure `bar` only works after the normal startup path (`onCreate` โ†’ `init`) has run. If someone tries to skip initialisation and call `bar` directly (say, by forcing the call with Frida), the flag is 0 and `bar` just refuses to play. **But it makes zero difference to pure static analysis** โ€” we're not executing any code at all. ### โ‘ข Assembling the string (0xde8โ€“0xe14) โ€” the heart of the level ```asm de8: adrp x8, 0 dec: ldr q0, [x8, #3744] ; 3744 = 0xea0, load the 16 bytes from .rodata df0: mov w8, #0x6568 df4: movk w8, #0x6620, lsl #16 ; w8 = 0x66206568 df8: mov w9, #0x7369 dfc: mov w10, #0x68 e00: stp xzr, xzr, [sp] ; zero it out e04: str xzr, [sp, #16] e08: str q0, [sp] ; [sp+0 ..15] = "Thanks for all t" e0c: str w8, [sp, #16] ; [sp+16..19] = "he f" e10: strh w9, [sp, #20] ; [sp+20..21] = "is" e14: strb w10, [sp, #22] ; [sp+22] = "h" ``` **`q0` is a 128-bit SIMD register โ€” one instruction moves 16 bytes.** That's the answer to "why did it cut off at exactly 16?" **You need to know `movk`**: ARM64's `mov` can only load a 16-bit immediate at a time, so building a 32-bit value takes two instructions โ€” `mov` loads the low half, and `movk` (move keep, i.e. keep the other bits) loads the high half. **Decoding (little-endian, so the low byte comes first in memory):** | Register | Value | Memory bytes | ASCII | | -------- | ---------- | ------------ | ----- | | w8 | 0x66206568 | 68 65 20 66 | he f | | w9 | 0x7369 | 69 73 | is | | w10 | 0x68 | 68 | h | **Notice the size ladder: `str`(4B) โ†’ `strh`(2B) โ†’ `strb`(1B).** 7 bytes split into 4+2+1 โ€” this is the standard way of assembling an arbitrary length out of powers of two. The result on the stack: ``` [sp+0 .. +15] "Thanks for all t" โ† .rodata [sp+16.. +19] "he f" โ† immediates [sp+20.. +21] "is" โ† immediates [sp+22] "h" โ† immediates โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ 23 bytes = "Thanks for all the fish" ``` Let's double-check the arithmetic: ```python import struct b = bytearray() b += bytes.fromhex('5468616e6b7320666f7220616c6c2074') b += struct.pack('