xmas-challenge-writeup.md

Another year passes by, another ØxＯＰＯＳɆＣ Mɇɇtuᵽ Xmas challenge. This year the challenge was an Android one by @zezadas.

I will do this one quite short and to the point.

First thing first, the elected tool of the trade was APK Studio which bundles together a good set of tools (decompiler, app sign, etc.) in a friendly looking interface.

First Flag

The app was a web app that opened the ØxＯＰＯＳɆＣ Mɇɇtuᵽ meetup page. Not much there. Usually, for web apps, if you have debugging enabled, you can easily interact with the app by using the remote debugging capabilities of Google Chrome (more on this later).

Opening the app in the APK Studio, we can see a simple-to-understand decompiled Java code and see that the application is pretty simple, open the meetup page and injected some new JS bundled in a ctfObj. There was noticeable that some magic was happening with the app intents (there was a conditional verifying if a fragment with the key open_sesame existed), but that was a little tricky for my non-existent Android reverse skills.

Searching a little around in the Android API documentation, I noticed that there was an extra code line that must be run to allow the app to be debuggable in Chrome. However, that line was not present.

From WebView Documentation: static void setWebContentsDebuggingEnabled(boolean enabled) - Enables debugging of web contents (HTML / CSS / JavaScript) loaded into any WebViews of this application.

However, adding such lines implied messing around with the app Dalvik code (Smali). With some search, I found a blog post by @speedfox that presented the magic lines needed to enable such debuggable mode (extracted from the blog post Android WebView Hackery):

You will next need to figure out where to put the magic lines of code. I like to do it at the end of the onCreate method on the launcher activity of the app because that will always be run when the app starts. You can work this out by looking for the activity with the "LAUNCHER" intent filter in the AndroidManifest.xml file. In this case, the launcher class was com.aerserv.testapp.MainActivity, so the code needs to be added to the base/smali/com/aerserv/testapp/MainActivity.smali file. Add the following lines right before the return of the method:

const/4 v2, 0x1
invoke-static {v2}, Landroid/webkit/WebView;->setWebContentsDebuggingEnabled(Z)V 

Saving the changes, compile the new Smali, sign the APK and deploy it to the device was pretty straightforward thanks to the APK Studio.

And profit! Now we had a debuggable version on the Chrome browser.

To retrieve the first flag, all that was needed was to call the function:

ctfObj.um()

And the flag was given: "{oposec}This_was_ez"

Second Flag

The second flag by analyzing the app Java code could be retrieved by calling the ctfObj.dois() function with the right five digit pin code. There was a hint that the flag started by {oposec}. In JS with a little brute-force, we could easily get it done:

for(var i = 0; i < 99999; i++){ 
  console.log(ctfObj.dois(('000000' + i).slice(-5)))
}

And, again, profit: "{oposec}you_got_the_pin" . The pin was 31337.

Third Flag

I could crash the app sending a long string of A's to the function, so maybe it was a buffer overflow, but I had too little time to explore and learn about it to get the flag.

Kudos for the challenge @zezadas.