バイェ先生

Challenge 8 - Wallfacer

Mar 22, 20258 min read

Alright here we go, the most painful and yet rewarding challenge throughout the TISC CTF 2024:

Just playing around…

After installing the mobile application using Genymotion, this is what I was presented with upon loading:

Initial analysis of the mobile application did not seem to have any events triggered based on submitted inputs (based on what was shown in the MainActivity.java app):

Next thing to do is to look at the AndroidManifest.xml file to see if there are any exported Android activities, and turns out there are two:

...
        <activity
            android:name="com.wall.facer.query"
            android:exported="true"/>
        <activity
            android:name="com.wall.facer.MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
...

Launching the other exported activity can be done using ADB:

am start -n com.wall.facer/com.wall.facer.query

But apart from that, there’s nothing much to do from there, welps. Guess I have to look through other resources.

Part I - The Hidden Dex

After digging through thousands of lines of code, when going through the resources, I came across this weird string value called “filename” in the strings.xml file:

Just by doing a quick Base64 decode of that string reveals that there is a sqlite.db file:

red@ops:~$ echo "c3FsaXRlLmRi" | base64 -d
sqlite.db

After looking through the Android app assets folder, i did find the sqlite.db file however there seemed to be some form of error when loading it into the sqlite3 database viewer:

HMMMM…STRANGE…

Normally any values that are being stored in the strings.xml gets referenced in Android applications via an R.id value. In this case, grepping the ‘filename’ keyword resulted in discovering its R.id value of 0x7f0f0038:

What’s even weirder about this is that attempting to search for that value based on the Java source code obtained via Jadx, nothing turned up:

However, if we go through the Android smali bytecode, we discover that there is a file that contains that R.id value reference (K0.smali):

If we look at line 106, there is a method invocation of the ClassLoader function (more info here: https://developer.android.com/reference/dalvik/system/InMemoryDexClassLoader), which loads Dex code that might have additional functionalities that are not included inside the app. And guess where the data for the ClassLoader file is from? Yep you guessed it, our suspicious sqlite.db file.

Another interesting item that i noticed is in line 102 of K0.smali, which is the invocation of the LA8.K() function:

After painstakingly figuring out what this function is about, I finally managed to discover here:

After following through the code, we do know that apparently this function is the one responsible for passing data to the earlier mentioned ClassLoader function. Tracing the code further results in line 259 of the code above to contain the apparent Dex code from the sqlite.db file.

With the mighty power of Frida, I quickly whipped up a Frida script that can extract the data from that function (as the data taken in by the function is in bytes, I used a Base64 encoder to encode the byte data and output it to the command line):

Java.perform(function() {
 
// get the bytebuffer data - which is the final output of the K function.
var className = "java.nio.ByteBuffer";
var classInstance = Java.use(className);
 
classInstance.wrap.overload("[B").implementation = function(arg1)
{
    // create a Base64 object first
    var b64_obj = Java.use("android.util.Base64").$new();
    console.log(b64_obj.encodeToString(arg1,2));
 
    
    return this.wrap(arg1);
};
 
});

Decoded the printed string from Frida and pushed it into a file, and voila whaddya know, we got a dex file:

First thing to do is to run jadx on the .dex file, however errors keep popping up. After doing a quick Google search, the cause for the error is the checksum verification that jadx performs by default. So in this case, the command was slightly modified to turn off checksum verification:

/opt/jadx/bin/jadx fixed.dex -Pdex-input.verify-checksum=no

And whaddya know…

Part II - Getting to know my walls

Based on the Java translated source code obtained from the Dex file, we found two items of interest here n DynamicClass.java:

  • A NativeLibrary file is dynamically generated, but before that there is a pollForTombMessage() function that triggers the generateNativeLibrary() function once the polling is done.
  • After the native library is loaded, there is a function called pollForAdvanceMessage() that will trigger the nativeMethod() function once the polling is done ⇒ chances are that this is from the NativeLibrary file.
  • ADB Logcat messages are tagged with a TAG value, which in this case turned out to be “TISC”.

Within the same Java file, this is the implementation of both the pollForTombMessage() and pollForAdvanceMessage() functions:

pollForTombMessage()

    private static void pollForTombMessage() throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, IllegalAccessException {
        Class<?> cls;
        do {
            SystemClock.sleep(1000L);
            cls = Class.forName("com.wall.facer.Storage");
        } while (!DynamicClass$$ExternalSyntheticBackport1.m((String) cls.getMethod("getMessage", new Class[0]).invoke(cls.getMethod("getInstance", new Class[0]).invoke(null, new Object[0]), new Object[0]), "I am a tomb"));
    }

pollForAdvanceMessage()

private static void pollForAdvanceMessage() throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, IllegalAccessException {
        Class<?> cls;
        do {
            SystemClock.sleep(1000L);
            cls = Class.forName("com.wall.facer.Storage");
        } while (!DynamicClass$$ExternalSyntheticBackport1.m((String) cls.getMethod("getMessage", new Class[0]).invoke(cls.getMethod("getInstance", new Class[0]).invoke(null, new Object[0]), new Object[0]), "Only Advance"));
    }

To obtain the NativeLibrary file, you will just need to do the following:

  • Load up the following Frida script to stop the NativeLibrary file from getting deleted after it is generated (logic of script below is just to return the exists() function to be 0 instead of a 1):

Command to run

frida -U -f com.wall.facer -l nodelete.js

Frida Script called (nodelete.js for this example)

Java.perform(function() {

// get the bytebuffer data - which is the final output of the K function.
var className = "java.io.File";
var classInstance = Java.use(className);

classInstance.exists.implementation = function()
{
    console.log("delete stopped");
        return 0;
}

});
  • Type the words “I am a tomb” and press submit.

You can use ADB to navigate to the application data folder directory (/data/data/com.wall.facer) and view the ‘files’ folder here to see the libnative.so file:

Once done, launch Terminal and type in the following command to download it into your system:

adb pull /data/data/com.facer.wall/files/libnative.so .

Now typing the following text ‘Only Advance’ triggers another set of log messages that are basically from the NativeMethod() function, which is eventually from the libnative.so library:

Guess now we know that there are three walls that we need to overcome.

Part III - Overcoming the walls

Now I would love to do a deep-dive analysis on the shared library, but truth be told, I think i might have delayed this writeup for too long, so much so that there are other people out there that did an AMAZING job in the writeup.

Before proceeding to this part, kindly read up this section of his writeup regarding the deep-dive analysis of the NativeMethod() function here: Challenge 8 Wallfacer Writeup - analyzing nativemethod from libnativeso

Once you are done with reading above, in that case I will only be focusing on the final solution, which is a memory patching technique using Frida. The following steps were taken:

Final Frida Script Code

const baseAddr = Module.findBaseAddress("libnative.so");
console.log("Base Address: "+baseAddr);
 
// knocking down wall 1
var pc0 = new NativePointer(baseAddr.add(0x5ab0));
console.log(Memory.protect(pc0,15,'rw-'));
Memory.writeByteArray(pc0,[ 0x2f, 0x64, 0x61, 0x74, 0x61, 0x2f, 0x6c, 0x6f, 0x63, 0x61, 0x6c, 0x2f, 0x63, 0x61, 0x62 ]); //write to replacement string /data/local/cab (just created a sample file in the phone)
// this is to also preserve the same number of bytes
console.log("[WALL1] Replacing '/sys/wall/facer' to '/data/local/cab'..");
 
// for patching instruction to knock down wall 2
var pc1 = new NativePointer(baseAddr.add(0x1f78));
Memory.protect(pc1,5,'rwx');
Memory.writeByteArray(pc1,[0xbf, 0x39, 0x5, 0x0, 0x0]);
console.log("[WALL2] Patching instruction at offset 0x1f78...");
 
//Knocking down of Wall 3
//2a looks good => removed the "i'm afraid i'm going to have to stop you from getting the correct key and IV"
var pc2a = new NativePointer(baseAddr.add(0x231a));
console.log("[WALL3A] Patching instruction at offset 0x231a...");
Memory.protect(pc2a,6,'rwx');
Memory.writeByteArray(pc2a,[0xc7, 0xc7, 0x39, 0x5,0x0,0x0]);
 
//2b looks good => this is to patch the other switch case that uses 0xa13 instead of the usual 0x539 for others
 
var pc2b = new NativePointer(baseAddr.add(0x3746));
console.log("[WALL3B] Patching instruction at offset 0x3746...");
Memory.protect(pc2b,6,'rwx');
Memory.writeByteArray(pc2b,[0xc7, 0xc1, 0x39, 0x5,0x0,0x0]);

Steps to Take

  • Save script into a file
  • Run the following Frida syntax:
frida -U -f com.wall.facer -l script.js

Now take note that the following error will be shown:

This is because of the NativeLibrary not being loaded when the app is not presented with the words ‘I am a tomb’.

  • Type in the text “I am a tomb” in the application and click ‘submit’ (adb logcat logs will show that the native library is loaded).

  • Open your script.js in a notepad and just click ‘save’. Frida assumes that there are changes made if there’s a file operation, which will refresh the script again (this time it should work as by now the library has already loaded)

  • Once done, go to the app and type ‘Only Advance’, Frida will handle the necessary hooks and overwrites, and you should be presented with the correct key and IV

  • Launch the exported Android Activity that is expecting a Key-IV pair input and enter the values based on what you see at the Android logcat console:

Final flag: TISC{1_4m_y0ur_w4llbr34k3r_!i#Leb}

Thoughts

In my honest opinion, this was the ONE AND ONLY CHALLENGE THAT I GOT HUMBLED BY. Truth be told, previous CTFs that involved Mobile Application challenges were pretty boring because of the fact that it mainly involves static analysis (e.g decompilation of Android app, look look see see, and done).

I think there were some attempts of mobile app CTF challenges in the past that used Frida, but this challenge is really, REALLY annoying indeed. HUGE respect to the challenge creator as well on building this, WELL PLAYED :)

I think after this, my level of knowledge of Frida kind of grew tenfold and I would LOVE to try out other mobile app challenges just like this! Looking forward to more :))

Graph View

Backlinks