Decription
Sometimes not all files are needed.
Download Link: https://drive.google.com/file/d/0Bw7N3lAmY5PCOFNQZFgtSVlFZ3M/view?usp=sharing
Solution
First step, of course, is downloading the files. Turned out it was only an apk file called youtube.apk. APKs are just an archive, and can thus be extracted easily. Let’s try that:
1 2 3 4 |
root@kali:~/Downloads/ctf/rc3/youtube# unzip youtube.apk root@kali:~/Downloads/ctf/rc3/youtube# ls AndroidManifest.xml build-data.properties classes.dex lib resources.arsc assets classes2.dex com res youtube.apk |
As the description of the challenge said that not all files would be required, my first try was to do a recursive grep (I’m still surprised each time this approach just shows the flag immediately 🙂 ).
1 |
root@kali:~/Downloads/ctf/rc3/youtube# grep -iR "rc3-2016" |
That yielded no results. Maybe not the entire flag is present in the file in plaintext, but only part of it:
1 2 3 4 |
root@kali:~/Downloads/ctf/rc3/youtube# grep -iR "rc3" Binary file youtube.apk matches Binary file lib/armeabi-v7a/libmoxie.so matches Binary file classes.dex matches |
Let’s have a look in these files (of which the first one, youtube.apk, is of course the original file). As the others are part of youtube.apk, let’s just use that one from now on again.
1 2 3 4 5 |
root@kali:~/Downloads/ctf/rc3/youtube# strings youtube.apk | grep -i "rc3" -rC3 3Rc37> RC3P` |rc3z |
Those four strings indeed contain the string rc3 (not considering case-sensitivity), but how much of a coincidence is that?
1 2 |
root@kali:~/Downloads/ctf/rc3/youtube# strings youtube.apk | wc -l 276637 |
There seem to be 276.637 strings in total, so let’s skip it for now. It might be that these occurrences are just a coincidence.
What if we try and look for the second part we know each flag consists of, namely “2016”?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
root@kali:~/Downloads/ctf/rc3/youtube# grep -R "2016" Binary file youtube.apk matches build-data.properties:build.tool=Blaze, release blaze-2016.04.14-4 (mainline @119748905) build-data.properties:build.time=Tue May 31 15\:02\:21 2016 (1464732141) build-data.properties:UkMz-2016-R09URU0yMQ== Binary file lib/armeabi-v7a/libcronet.so matches Binary file lib/armeabi-v7a/libdrishti_jni_native.so matches Binary file assets/kazoo/super8_frame.png matches Binary file assets/kazoo/vignette.png matches res/raw/third_party_licenses:Copyright (c) 2009, 2010, 2013-2016 by the Brotli Authors. res/raw/third_party_licenses:This software is copyright (C) 1991-2016, Thomas G. Lane, Guido Vollbeding. res/raw/third_party_licenses:Copyright (c) 1997-2016 University of Cambridge res/raw/third_party_licenses:Copyright(c) 2010-2016 Zoltan Herczeg res/raw/third_party_licenses:Copyright(c) 2009-2016 Zoltan Herczeg |
As expected, there are a lot of occurrences here as 2016 is a year, and many of the metadata and additional information of software probably includes it. Still, we can have a look at the exact occurrences:
1 2 3 4 5 6 7 8 |
root@kali:~/Downloads/ctf/rc3/youtube# strings youtube.apk | grep 2016 2016-06-22T14:35:33-07:00 2016-06-22T14:35:33-07:00a 2016-06-22T14:34:18-07:00 2016-06-22T14:34:18-07:00 build.tool=Blaze, release blaze-2016.04.14-4 (mainline @119748905) build.time=Tue May 31 15\:02\:21 2016 (1464732141) UkMz-2016-R09URU0yMQ== |
Well, that looks interesting. Let’s take a closer look at the last result:
1 |
UkMz-2016-R09URU0yMQ== |
As the last part of the string gives away, it is probably base64-encoded. Let’s therefore assume the string above has the following form:
1 |
<base64-encoded string>-2016-<base64 encoded string> |
First, decode the first part of the string:
1 2 |
root@kali:~/Downloads/ctf/rc3/youtube# echo "UkMz" | base64 --decode RC3 |
That already looks like it! Now, we need the last part of the string as well:
1 2 |
root@kali:~/Downloads/ctf/rc3/youtube# echo "R09URU0yMQ==" | base64 --decode GOTEM21 |
If we reconstruct the full string now, we got our flag: RC3-2016-GOTEM21.