Intro
The .zip archive contains a file named “201309” and it’s password protected. I have to admit I didn’t use a specific tool to find out the right password, the truth is that I typed the word “infected” like a robot because most of the archives I open are malwares and “infected” is the most standard used password. Anyway, the file doesn’t have an extension and it’s hard to predict what kind of file is this. To get a general idea about it you can simply use an hex editor, look at the first bytes of “201309”:
50 4B 03 04 14 00 08 00 08 00 DA 6E 1B 43 33 30
“PK” at the beginning, the file is a zip archive. The content of the archive reveals the real nature of the challenge, it’s an Android application based challenge!
AndroidManifest.xml
Among all the files included in the package I always start my analysis from AndroidManifest.xml because it contains a lot of practical information about the application. In this specific case there are some components definition inside the file and you can easily identify one permission, two activities and one receiver definition:
The application has the permission to open network sockets, this means the application can browse the net.
As I told you before there are two activities defined, the first one is our main activity. Everything will start from it so our code inspection could start from SshCloud class. The other activity refers to another behavior of the application so keep in mind to have an eye to DrgLauncher class too when you are in front of the decompiled files.
The application can also receive intents that are broadcast by the system or applications, this is a precious information. The intent is defined as a SECRET_CODE and it represents a special feature of an Android mobile phone. The number 374 represents the value of our secret code and if you want to use it you have to call a special number: *#*#<code>#*#*. Replace “<code>” with 374 and try calling the special number in your Android emulated device. Nothing happens because the code is specific for our application. Run the challenge, put it in background and then try calling the number again. The receiver does his job, the challenge is running again in foreground and a message appears: “getting warm. must be dragons nearby”. I’m on the right path, but now it’s time to take a look at the disasm.
SshCloud and DrgLauncher
To decompile the application you have multiple choices: apktool, dex2jar, etcetc. I use my simple DexInspector loading classes.dex directly inside it. There are some defined classes; the content of AndroidManifest.xml suggests to start the code analysis from main class SshCloud or DrgLauncher, but I follow a different approach starting from the strings used by the application. The message “getting warm. must be dragons nearby” is inside the string list but it’s not alone:
The message is part of a javascript code and it’s referenced inside DrgLauncher class, the place I’m going to inspect:
The above snippet comes from OnCreate method, it’s called when the application receives the secret code signal. The core of the code is represented by the function “loadDataWithBaseURL” which is used to load some data to the view. The URL is a blank page (v1=0) and the data is represented by the javascript code v2. So, the purpose of the snippet is to execute the script. If you isolate the script you can see that it’s composed by two parts, the last one shows the message “getting warm. Must be dragons nearby”. The first part doesn’t have much sense because it’s a call to an undefined function (with one parameter). If you read all the instructions inside OnCreate method you can give a sense to the first part of the script too because “addJavascriptInterface” function permits to inject a specific object into a JavaScript code. In this particular case the method jsFunction from DrgLauncher$JsInterface will be injected and then executed.
JsFunction
The code of this method is quiet easy to understand:
It simply creates a string concatenating three sub strings: “Tm9Nb3JlU”, the function’s parameter (“2VjcmV0cw”) and “==”.
The log message is pretty clear, “Here there be dragons: Tm9Nb3JlU2VjcmV0cw==”.
Hidden message
The application writes some log messages during its execution via android.util.Log. Android’s adb command could be used to catch all these messages, time to have a look at them too.
Every log message has a priority associated with it, the challenge uses two distinct priority levels and for a better visualization I have used this command: “adb logcat DRG *:S”, where “DRG” is the tag of the log messages used by the application.The log sequence confirms the fact that everything is related to the last string, what does “Tm9Nb3JlU2VjcmV0cw==” means?
In this encoded form the last two bytes “==” are really helpful because they are used by base64 encoding when padding is necessary. Try to load the string inside a base64 decoder and look at the result: “NoMoreSecrets”… DRG September 2013 challenge ends here!
Thanks to Dragon Research Group for this nice challenge!