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!
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 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==”.
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!